Who the EU AI Act Actually Holds Accountable: Mapping AI Leadership Roles to Provider, Deployer and Oversight Duties

Jason Holloway
EU AI Act AI Act Preparedness Accountability AI Governance Compliance

The EU AI Act assigns obligations to providers and deployers of AI systems, not to job titles. A Chief AI Officer, a Director of AI Governance or a CDAO carries statutory weight only if the organisation maps each obligation to a named owner with the authority and evidence to discharge it. Accountability under the Act follows function, not fashion.

This is the second half of a pair. Our companion piece described the emerging AI leadership titles and the confusion around them. Here we map those titles onto what the Act actually expects, and show where the popular roles leave statutory duties unowned.

This article is informed guidance, not legal advice. Confirm your obligations with qualified counsel before acting.

The Act’s actors in plain English

The EU AI Act regulates organisations by what they do, using four roles: provider, deployer, importer and distributor. The two that matter most are provider and deployer.

A provider develops an AI system, or has one developed and places it on the market under its own name. A deployer uses an AI system under its own authority in the course of business. Most organisations are deployers. Many are unknowingly providers too, because fine-tuning a model, rebadging a system or making substantial modifications can pull you into provider obligations, which are heavier.

A wrong classification here is not a technicality. Provider duties include technical documentation and conformity assessment that deployers never face. If you assume you are only a deployer while your data science team is fine-tuning a high-risk model, you have unowned obligations sitting in a blind spot.

The obligations that need an owner

The Act creates a set of accountability functions that someone must own. Each one carries evidence expectations and, in most cases, a reporting line.

  • Risk management (Article 9): a continuous process across the system lifecycle.
  • Data governance: training, validation and testing data must meet quality criteria.
  • Technical documentation and conformity assessment: the paper trail that proves compliance.
  • Human oversight (Article 14): people who can understand, monitor and, where needed, override the system.
  • Transparency: users must know when they are interacting with AI.
  • Post-market monitoring: tracking performance and risk after deployment.
  • Serious incident reporting: notifying authorities within defined windows.
  • AI literacy (Article 4): ensuring staff have sufficient understanding of the AI they use.

Each of these needs a single named owner. A shared or implied owner is an unowned function under audit.

Mapping the roles to the obligations

Here is where the fashionable titles meet the statutory reality, and where they conflict.

A Chief AI Officer who leads adoption and strategy naturally owns AI literacy and much of the transparency and governance framing. The conflict is human oversight sign-off. A role whose incentive is faster adoption should not also certify that oversight is adequate; that pairs the accelerator with the brake.

A Chief AI Risk Officer or Director of AI Governance is the more natural home for risk management, post-market monitoring and incident reporting. These roles carry the independence the oversight and reporting duties require.

A Head of AI Strategy and Governance blends both, which is convenient organisationally and dangerous legally, because it can fold adoption and risk sign-off into one person. A CDAO usually owns data governance well but rarely owns human oversight or incident reporting at all.

The pattern is consistent: strategy and adoption roles gravitate towards literacy and enablement, while risk and governance roles must own oversight, monitoring and reporting. Where one person holds both, separation of duties breaks.

The gaps nobody owns

Three statutory functions are routinely left unowned even in organisations that have appointed a senior AI leader.

AI literacy (Article 4) is the most common gap, and it is already in force. It reads as a training obligation, so it falls between HR, the CAIO and no one. Post-market monitoring is treated as an engineering afterthought rather than a named duty. Serious incident reporting often has no owner until an incident forces the question.

“We have a CAIO” closes none of these gaps. A title is not a control. The Act cares whether a named person can produce evidence that the function is discharged.

A practical mapping approach

Start from the obligations, not the org chart. The sequence is short:

  • List every statutory function that applies to your systems
  • Assign a single accountable owner to each one in a RACI
  • Define the evidence that owner must hold, and where it lives
  • Check for conflicts, particularly adoption owning oversight sign-off
  • Re-test the mapping whenever a system is modified or a new one is deployed

Then work the timeline as a planning backbone:

  • 1 August 2024: the Act entered into force
  • 2 February 2025: prohibited practices and the AI literacy obligation applied
  • 2 August 2025: governance rules and general-purpose AI model obligations applied
  • 2 August 2026: the Commission’s enforcement powers and the remaining governance provisions apply
  • 2 December 2027: high-risk obligations apply to standalone Annex III systems
  • 2 August 2028: high-risk obligations apply to AI embedded in already-regulated Annex I products

The two high-risk dates were deferred by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026. A deferral is more time to build controls that operate, not less work to do. Our EU AI Act preparedness guide carries the full timeline.

UK and other non-EU organisations are frequently in scope. If you place an AI system on the EU market, or your AI output is used in the EU, the Act reaches you. “We are not an EU company” is not an exemption.

Turn the regulation into an ownership map

The honest question a board should ask is not whether it has an AI leader, but whether it can name who owns each obligation and prove it. We help organisations map EU AI Act duties to accountable owners and build the evidence to stand behind the mapping.

For the shorter answers to the questions compliance leads ask first, see our EU AI Act accountability Q&A.

Turn the regulation into an ownership map

Our AI Act Preparedness work maps each statutory duty to a named owner and builds the evidence trail that stands behind the mapping.