You finish the regulation map. Which laws apply to your company, which of your systems they touch, where every source is. It takes weeks, and almost none of that time goes on reading legislation. It goes on chasing answers around the company: which legal entity does what, whether a tool touches retail customers, who owns which system.
Then it’s done, and it does the thing it was built to do. The scope stops being arguable. “Does this even apply to us” has an answer now, with citations, and the conversation can finally move.
It also produces a list of gaps.
I thought the hard part was over at that point. What actually happened was that people stopped disputing the gaps and started avoiding eye contact instead.
Nobody argued. That’s the part worth sitting with. The list worked exactly as intended, and made the problems undeniable. What it could not do was put a name against any of them.
If you have run this exercise you already know how it ends. The gaps get logged. The document gets circulated. Someone says we should probably look at that. Six months later it is still true.
There is a reason that happens, and it isn’t organizational cowardice. It’s in the regulation.
The EU AI Act Asks for a Responsibility Map Exactly Once
Article 17 sets out the quality management system a provider of a high-risk AI system has to put in place. Thirteen items: compliance strategy, design control, testing, data management, risk management, post-market monitoring, incident reporting, record-keeping, resource management. Then, at the bottom of the list:
(m) an accountability framework setting out the responsibilities of the management and other staff with regard to all the aspects listed in this paragraph.
That is the only place in the EU AI Act that asks an organization to write down, in one document, who is responsible for what. One sub-point, thirteenth of thirteen, in the article about quality management.
But there are three limits.
It applies to providers. Article 17 sits in Chapter III and binds providers of high-risk AI systems. If you deploy AI rather than build it, you have no equivalent obligation. If you build AI that isn’t high-risk, same thing.
It can be satisfied by something you already have. Article 17(3) lets any provider already subject to quality management obligations under sectoral EU law fold these aspects into the existing system. That reaches further than it sounds: medical device manufacturers, machinery and automotive suppliers, anyone already running a certified quality management system for a regulated product. Build the accountability framework into the system you were already audited on, and you have complied.
Article 17(4) goes further still for financial institutions. Comply with your internal governance requirements under EU financial services law and the quality management obligation is deemed fulfilled, with three exceptions: risk management, post-market monitoring, incident reporting. Point (m) is not among the exceptions.
Article 17(4) does add a sentence though:
To that end, any harmonised standards referred to in Article 40 shall be taken into account.
The deeming comes with a duty to take harmonised standards into account. No harmonised standard under Article 40 has been cited in the Official Journal yet. A duty to take into account something that doesn’t exist is a duty in form only, and it stays that way until CEN-CENELEC delivers and the Commission cites the result.
And it isn’t in force. The Digital Omnibus on AI deferred the bulk of Chapter III. Article 17 applies from December 2, 2027 for stand-alone Annex III systems and August 2, 2028 for AI embedded in regulated products.
Writing in August 2026, that is just under sixteen months. For providers. For high-risk systems only. And satisfiable by pointing at a governance framework you built for something else.
Then the Regulation Steps Back, In Writing
Article 26 covers what deployers of high-risk systems have to do, and it contains the closest thing the EU AI Act has to a named-person requirement:
Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.
Natural persons. Authority. Not a function, not a committee. That’s real, and it asks for more than a one-line summary of Article 26 suggests.
But read what it covers: human oversight of a specific high-risk system while it’s running. It says nothing about who owns the compliance program, who owns a documented gap, or who gets to decide that a gap is acceptable for now.
The obligations in paragraphs 1 and 2 are without prejudice to other obligations under EU or national law, and then, in paragraph 3, to:
..the deployer’s freedom to organise its own resources and activities for the purpose of implementing the human oversight measures indicated by the provider.
The regulation is declining, on the record, to tell you how to organize yourself.
This is a drafting decision, not an omission. Article 96 gives the European Commission open-ended power to issue guidelines, but nothing on its published guidance program addresses who inside your company should own AI compliance. If you have been holding the assignment question open until guidance arrives, it probably won’t.
Deployers get their own version of the deeming move. Article 26(5) requires deployers to monitor the operation of a high-risk system, then adds that for deployers who are financial institutions subject to internal governance requirements under EU financial services law, that monitoring obligation is deemed fulfilled by complying with those rules.
If you built the AI system, Article 17 is yours. If you bought it, Article 26(5) is. Either way the move is identical, and so is the consequence. A structure you built for a different regulation is treated as sufficient, and whether it was designed with AI risk in mind never gets asked.
Other Regulations Name Someone
The GDPR names the data protection officer. Articles 37 and 38: mandatory designation in defined cases, reporting directly to the highest management level.
DORA names the management body. Articles 5 and 6: ultimate responsibility for ICT risk, a duty to define, approve and oversee the framework, and an annual review of it.
NIS2 names management bodies. Article 20: they approve and oversee the risk-management measures, undergo training, and can be held liable under national implementing law.
The Medical Devices Regulation names a person responsible for regulatory compliance. Article 15 requires at least one named individual inside the manufacturer, with defined qualifications and minimum years of experience.
Solvency II names key function holders. Article 42 on fit and proper, then Articles 44, 46, 47 and 48: named holders of risk management, compliance, internal audit and actuarial functions.
The EU AI Act names the company.
Every one of those regimes decided that an obligation without a name attached to it doesn’t get met. The EU AI Act reached the opposite conclusion, or more precisely, declined to reach one.
The practical consequence is to pick any regulated system in your company and you will find a named accountable person for its data, its security, or its operational resilience, and no named owner for the fact that it runs on AI.
Supervisors have started noticing this, and one of them has already acted. EIOPA published an Opinion on AI governance and risk management in August 2025 that creates no new rules and instead reads the EU AI Act alongside the sectoral rules it supervises, including DORA and the GDPR. It says the board remains responsible for the use of AI in the business, calls for clear definition of roles and responsibilities, and notes that firms may appoint AI officers to advise the other functions. The scope is the interesting part: the Opinion covers AI systems that are neither prohibited nor high-risk, expressly to avoid overlapping with the EU AI Act.
Which means a European supervisor wrote guidance on who owns AI, specifically for the systems the EU AI Act doesn’t reach.
That is probably the pattern to watch out for. The bodies that will fill this hole are not going to be the European Commission. They are the supervisors who already regulate you, who already hold a view on who should be accountable for what, and who are used to saying so.
The One Place the EU AI Act Does Allocate Ownership
There is a counter-example though.
The General-Purpose AI Code of Practice, drawn up under Article 56 and endorsed in August 2025, has a Safety and Security chapter that does what the rest of the EU AI Act doesn’t. Signatories commit to define responsibilities for managing systemic risk across all levels of the organization, allocate resources to it, and follow specific guidance on distributing those responsibilities, including assigning supervisory duties to the management board and pushing the obligations down defined reporting lines.
That is an EU instrument naming who owns AI risk, and it is EU AI Act machinery.
It is also voluntary, provider-side, and very narrow. The Code is not binding law, signatories can adopt some chapters and not others, and the Safety and Security chapter reaches only providers of general-purpose AI models with systemic risk: a handful of frontier labs, not the roughly 190 organizations that have signed the Code overall.
It buys no presumption of conformity, only the AI Office weighing your commitments when it sets a fine under Article 101.
What a Documented Ownership Gap Does To Your Legal Position
Article 99(7) lists what a national authority weighs when deciding whether to fine you and how much. Ten factors, (a) through (j). I find two of them important:
(g) the degree of responsibility of the operator taking into account the technical and organisational measures implemented by it
(i) the intentional or negligent character of the infringement
Point (g) puts your organizational measures directly into the fine calculation. Assigning an owner is an organizational measure. So is not assigning one, and the absence shows up on the face of your own governance documents.
Point (i) is sharper. A gap you never found is negligence. A gap you identified, wrote down, circulated to the people who could have fixed it, and left unassigned for eighteen months is a different animal. You have produced a written record of knowledge and a written record of inaction, and they are in the same document.
The list that ended the scope argument is also the list that proves you knew.
None of which is an argument for keeping worse records. Deliberately not looking is its own exposure, and a supervisor who finds no regulation map at all will draw the obvious conclusion about your organizational measures under point (g). The argument is narrower: documenting a gap starts a clock that assignment is supposed to stop.
Timing matters here. Until December 2027 there is no high-risk obligation to breach, so an unassigned high-risk gap is not yet fineable under the EU AI Act. What is live today: Article 5 on prohibited practices, Article 50 on transparency, the general-purpose AI obligations in Chapter V, and your GDPR exposure running alongside all of it. A documented gap in any of those is fine-relevant now. A documented high-risk gap is a record being built for a regime that arrives in sixteen months.
What Assignment Actually Takes
The reason the ownership gaps stay unassigned is that the assignment step has no deadline attached to it. Everything else on the roadmap has a date. This has nothing, because the one provision that would force it is sixteen months out and doesn’t reach deployers at all. Organizations focus on the work that has a date on it.
So it has to be made non-optional by someone with the standing to do that, and there are only three things they need to hand over.
A name. Not a function, not a committee, not “Legal and IT jointly.” Article 26(2) already tells you the standard for human oversight: natural persons with competence, training and authority. Apply the same test one level up. If your governance document says a department owns something, nobody owns it.
A budget. An owner who has to negotiate for resources every time the ownership gap needs work is a person with a title and a problem.
The authority to stop the system. This is the one that gets skipped. ISO/IEC 42001 is explicit about it in its treatment of AI roles and responsibilities: the role needs documented authority to act, not a designation. If your named owner cannot pull a system out of production without escalating to three other people, you have assigned blame rather than ownership.
ISO/IEC 42001 and the NIST AI Risk Management Framework both put role assignment at the foundation, which tells you the practitioners who drafted them hit this same wall. Neither is a harmonised standard under Article 40, so certifying to one discharges no EU AI Act obligation. What it gives you is a defensible answer to Article 99(7)(g) when someone asks what organizational measures you implemented. That’s not nothing, and it’s also not compliance.
None of this works without an honest inventory underneath it, which is the step before this one.
AI Governance Ownership Across Functions
The IAPP and Credo AI asked over 670 governance professionals across 45 countries which function holds primary responsibility for AI governance. Privacy came first at 22 percent. Legal and compliance also came first, at 22 percent. Then IT at 17, data governance at 10, ethics and compliance at 6, security at 5. The fieldwork ran in spring 2024, so read it as how the profession arranged itself as the regulation arrived.
No function holds a majority. Those six account for 82 percent, which leaves roughly one in five organizations answering something else entirely.
Distributed is the word the reports use. In practice, distributed is what an ownership gap becomes when it has no name against it.
Set the frontier labs aside and every EU AI Act obligation in force today applies to the company as an abstraction. Article 4 on AI literacy, which the Omnibus rewrote in July to soften the standard from ensuring a level of literacy to supporting its development. Article 5 on prohibited practices. Article 50 on transparency, live since August 2. All of them binding on “providers and deployers,” which is to say on nobody in particular.
The first provision that requires a written answer to who is responsible arrives in December 2027, for providers, for high-risk systems, and can be satisfied by pointing at a structure you built for a different regulation.
Which leaves the ownership gap where it started. On the page, undeniable, and still no one’s.
Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.
There is one more place the Act names a party. Article 22 requires providers established in third countries to appoint, by written mandate, an authorised representative established in the Union before a high-risk system is made available here.
Article 22(3) makes that representative produce the mandate to market surveillance authorities on request, and verify that the EU declaration of conformity and the Article 11 technical documentation have been drawn up.
Narrow, provider-side, and silent on who owns a documented gap. But it is the one named party an authority can reach without first asking the company who to talk to.