Roles and Responsibilities in AI Governance

Why roles matter in AI governance

Artificial intelligence systems cut across functions that have traditionally been managed separately.

A single system may involve:

• business
• technology
• data
• privacy
• security
• risk
• compliance
• legal
• procurement
• human resources
• audit.

One of the most common problems is therefore not a complete absence of controls. It is fragmentation.

Each area controls one part, but nobody has a sufficiently clear view of the whole.

Defining roles makes it possible to answer basic questions:

• who may propose a new use?
• who assesses it?
• who approves it?
• who may reject it?
• who maintains the inventory?
• who controls the risks?
• who oversees actual use?
• who manages incidents?
• who reports to leadership?

When these answers are unclear, AI governance depends too heavily on informal relationships.

A role does not necessarily mean a job title

An organisation does not need to create a new position for every AI-related responsibility.

It is useful to distinguish a role from a job title.

A role describes a responsibility within the governance model. It may be assigned to a person or function that already exists.

Supplier assessment, for example, may continue to sit with Procurement and Security. Privacy may remain within the data protection function. System audits may be integrated into Internal Audit. Oversight of a particular system may belong to those responsible for the business process.

The aim is not to multiply titles. It is to ensure that every responsibility has a clear owner.

Leadership and governing body

Senior leadership has a role that should not be delegated entirely to technical teams.

It should establish the overall framework within which the organisation intends to use artificial intelligence.

Its governance responsibilities may include:

• approving principles or policies
• defining acceptable risk levels
• allocating resources
• resolving significant decisions
• receiving information on risks and incidents
• overseeing the performance of the governance system
• ensuring that responsibilities are defined.

Leadership does not need to review every tool. It does need enough information to know whether the organisation is using AI within the framework it has chosen.

AI governance or AI management system lead

Organisations that make significant use of AI may benefit from a coordinating function.

Its title may vary:

• AI Governance Lead
• Head of AI Governance
• AI Risk Manager
• AI management system lead
• an equivalent function within Compliance, Risk or Technology.

The title is secondary. The function matters.

It may coordinate:

• the AI inventory
• classification
• risk assessments
• impact assessments
• policies
• controls
• evidence
• reviews
• incidents
• reporting.

This person or function should not become responsible for doing everything. Its main purpose is to ensure that the model works and that responsibilities connect.

AI system owner

Every relevant system should have a person or function clearly associated with its management.

The AI system owner does not have to be the person who developed it.

It may be whoever:

• understands its purpose
• controls its use
• understands the process in which it operates
• keeps relevant information up to date
• coordinates reviews
• knows when changes occur
• can escalate incidents.

Without an owner, a system may appear in the inventory while nobody is genuinely accountable for how it evolves.

This is particularly important when the solution comes from an external supplier. Outsourcing the technology does not remove the need to govern its internal use.

Business owner

AI should always serve a purpose connected to a real process. The business therefore cannot sit outside the governance model.

The business owner should be able to explain:

• which problem the system is intended to solve
• what it is used for
• which decision it supports
• who may be affected
• what outcomes are expected
• which errors matter
• what the consequences of poor performance would be.

Technology can explain how a system works. The business must explain why it is used and what its output means within the process.

Technology, data and development

Technical functions hold essential responsibilities.

Depending on the organisation, these may include:

• architecture
• integration
• development
• configuration
• testing
• monitoring
• data quality
• change management
• technical documentation
• performance
• technical security
• intervention capability.

These responsibilities may be particularly broad for systems developed in-house.

For systems bought from third parties, the technical function remains important for understanding integrations, data, dependencies and supplier changes.

AI governance cannot be reduced to technology, but it cannot work without it either.

Risk, compliance, legal and privacy

These functions may contribute to some of the same assessments, but their responsibilities should not be confused.

Risk

It can help establish methods for identification, assessment, treatment and monitoring.

Compliance

It can examine applicable obligations, controls, evidence and alignment with the internal framework.

Legal

It can assess contracts, liabilities, terms of use and relevant legal requirements.

Privacy

Where personal data is involved, it should examine processing, legal basis, rights, minimisation, transfers and other applicable matters.

These functions should participate according to the context. Not every system requires the same level of involvement.

Information security

Many AI systems rely on external infrastructure, data and services.

Security may therefore need to review matters such as:

• access
• authentication
• information protection
• integrations
• storage
• data transfers
• vulnerabilities
• suppliers
• continuity
• incidents.

A tool may appear simple to the user while introducing a significant new technological dependency.

Security review should be proportionate to the risk and context.

Procurement and supplier management

Much of the AI used by organisations is provided by third parties. Procurement can therefore become a particularly valuable control point.

Before entering into a contract, the organisation should understand:

• who the supplier is
• which service it provides
• which documentation it supplies
• how it uses data
• which sub-suppliers are involved
• what happens when the service changes
• which contractual obligations apply
• how incidents can be reported
• what options exist to terminate or change the service.

Governance begins before signature. Once the tool has been contracted, some controls may be much harder to introduce.

Human oversight and users

Human oversight should not be treated as a generic label.

The organisation must identify who actually oversees a system and what that person is able to do.

Depending on the context, the person providing oversight should have:

• sufficient knowledge
• training
• information
• time
• the ability to interpret outputs
• authority to intervene
• the ability to reject or change a decision.

For certain high-risk systems subject to the AI Act, the AI Act obligations for deployers include assigning human oversight to people with appropriate competence, training, authority and support.

This does not mean that the same obligation applies identically to every AI tool. Responsibility must be assessed against the particular system and applicable framework.

Users are also part of governance. They need to know:

• which uses are permitted
• which information they may enter
• which outputs they must review
• when approval is required
• when a problem must be reported.

Internal audit

Internal Audit performs a different function from the teams operating the system.

Its purpose should not be to design controls that it later assesses itself.

It may review whether:

• responsibilities are defined
• processes are carried out
• evidence exists
• controls operate effectively
• incidents are managed
• corrective actions are closed
• the governance system works as designed.

Independence matters. Governing, operating, controlling and auditing are not the same function.

How to assign responsibilities without creating unnecessary structure

There is no universal organisation chart for AI governance.

A small organisation may manage its responsibilities through existing functions. An organisation with many systems, in-house development or greater exposure may need a more formal structure.

The question should not be:

“Do we need an AI committee?”

It should be:

“Which decisions do we need to make, and who should own each one?”

A simple sequence can provide a starting point:

1. someone proposes
2. someone assesses
3. someone decides
4. someone implements
5. someone oversees
6. someone verifies.

Real functions can then be assigned to each step.

The model should grow with the organisation's complexity, not ahead of it.

Responsibility matrix: who decides and who executes

A responsibility matrix can turn the governance model into something operational.

It does not need to be complex. It may use a structure similar to RACI:

Responsible

Carries out the activity.

Accountable

Owns the final decision.

Consulted

Provides information or specialist knowledge.

Informed

Needs to know the outcome.

For the approval of a new AI system, for example:

• the business may propose the use
• Technology may assess integration
• Security may review technical risks
• Privacy may examine personal data
• Compliance may review particular requirements
• Procurement may manage the supplier
• a designated function may approve or escalate the decision.

The important point is not to use RACI exactly. It is to ensure that the organisation can answer without ambiguity:

Who does what, and who has the final say?

Common mistakes

Creating a committee without defining its decisions

Bringing people together does not guarantee governance. The committee must know what it can approve, reject or escalate.

Assigning all responsibility to Technology

Purpose, impacts and many decisions also belong to the business and other functions.

Making the AI lead the owner of everything

A coordinating function should not absorb responsibilities belonging to business, security, privacy, procurement or other areas.

Naming different owners in different documents

If the inventory names one owner and the risk assessment names another without explanation, the governance model becomes inconsistent.

Failing to define who may stop a system

Some situations require genuine authority to suspend use or escalate a decision.

Confusing internal roles with regulatory roles

An internal “AI system owner” is not automatically a provider or deployer under the AI Act.

Failing to review responsibilities

Systems change, suppliers change and organisations change. The responsibility model must be capable of being updated.

Governance begins when someone knows they have to decide

An organisation may have detailed policies, inventories, risk matrices and procedures.

But if nobody knows who must act when an important decision arises, governance remains weak.

Defining responsibilities does not mean creating more bureaucracy. It means ensuring that each system has an owner, each risk has someone responsible and each decision has identifiable authority.

The most useful question is often the simplest:

If this system causes a problem tomorrow, who knows they have to act?

If the answer is unclear, a governance gap remains. ISO/IEC 42001 can help structure this model without turning recommended internal functions into legally mandatory job titles.

References

• Regulation (EU) 2024/1689 — AI Act.
• ISO/IEC 42001:2023 — Artificial intelligence management system.
• ISO/IEC 23894:2023 — Guidance on AI-related risk management.