Key takeaways
- AI accountability is not a character trait of an organisation. Under the EU AI Act it is a legal position, assigned to a named operator role, with its own line in the penalty article.
- The Act never makes an AI system accountable. It makes five human roles accountable: provider, deployer, importer, distributor and authorised representative.
- Article 25 can move AI accountability onto you without a new contract. Rebrand a system, substantially modify it, or change its intended purpose, and you become its provider.
- AI accountability that cannot be evidenced on demand is intent, not accountability. Every duty has a matching artifact: technical documentation, logs, an oversight assignment, a declaration of conformity.
- Article 99(4) prices failure role by role, up to EUR 15 million or 3 percent of worldwide turnover, and private damages now run through the revised Product Liability Directive.
What AI accountability actually means
Most definitions of AI accountability stop at a sentiment: someone should be answerable when an AI system causes harm. That is true and useless. It gives no test for who, no test for what they owe, and no test for whether they have done it.
The Alan Turing Institute’s public-sector workbook on the subject offers the cleanest decomposition available. It splits AI accountability into two components: answerability, the obligation to provide clear and accessible justifications for decisions and outcomes to the people affected by them, and auditability, the demonstrable, evidence-based ability to show how a system was designed, built and operated (Alan Turing Institute). Answerability is what you say. Auditability is what you can show. An organisation that manages the first but not the second is doing public relations.
The same workbook adds a second axis that most vendor content ignores. AI accountability runs in two directions in time. Anticipatory accountability is the forward-looking governance, justification and documentation undertaken before and during a project so that harm is prevented. Remedial accountability is the backward-looking machinery of redress, contestation and correction after an outcome has landed. Almost every article on who is responsible when AI goes wrong addresses only the remedial half, which is the half you reach for once it is too late to be cheap.
This changes what AI accountability looks like on a Monday morning. It stops being a values statement in a policy and becomes two concrete questions. Who is answerable for this specific system, by name? And what evidence would we hand a regulator tomorrow if they asked us to prove it? AI governance is the operating model that makes those two questions answerable at all.
One clarification before the legal detail, because the search results are thick with it. AI accountability is not the same thing as transparency, explainability or responsibility. Those are inputs. Explainability helps you answer, and logging helps you audit. AI accountability is the relation itself: a named party owes an account of a decision to someone entitled to demand it.
The five roles the EU AI Act makes accountable
When people ask whether AI can be held accountable, they are asking a question the law has already declined to entertain. The EU AI Act does not assign duties to systems. It assigns them to operators, and it names five.
| Role | Test that puts you in it | Core duty | Article |
|---|---|---|---|
| Provider | Develops a system, or has one developed, and places it on the market or into service under its own name or trademark | The full high-risk stack: risk management, data governance, technical documentation, conformity assessment, registration | Article 16 |
| Deployer | Uses an AI system under its own authority in a professional context | Use per instructions, assign human oversight, monitor and suspend, retain logs, inform workers and affected persons | Article 26 |
| Importer | Places on the EU market a system from a provider established outside the EU | Verify conformity assessment, documentation and marking before placing | Article 23 |
| Distributor | Makes a system available on the market, other than the provider or importer | Verify marking and documentation, act where non-conformity is suspected | Article 24 |
| Authorised representative | Appointed in writing by a third-country provider | Verify the declaration and documentation exist, keep them 10 years, give authorities log access, terminate on breach | Article 22 |
The umbrella term the Act uses for all of them is operator. Most organisations reading this are deployers, and most have never written that down. If your firm uses a vendor tool in a professional context, you are the deployer of that system, and the Article 26 duties are yours regardless of what the vendor’s marketing says about compliance. The operator’s guide to the EU AI Act walks the full obligation set per role.
The authorised representative deserves a moment, because it is the role with teeth. A provider established outside the EU must appoint one by written mandate before placing a high-risk system on the market. That representative verifies the EU declaration of conformity and technical documentation were drawn up and the conformity assessment carried out, keeps the documentation at the disposal of authorities for ten years, and supplies competent authorities with information including access to automatically generated logs. If it comes to believe the provider is acting contrary to its obligations, it must terminate the mandate and tell the market surveillance authority why (Article 22). The Act built an informant into the AI accountability chain.
Article 25: how AI accountability transfers without you noticing
This is the mechanism most likely to cost a deployer real money, and it is almost entirely absent from the published commentary.
You can become the provider of a high-risk AI system without signing anything new. Article 25(1) sets out three triggers (Article 25):
- You put your own name or trademark on a high-risk system already placed on the market, absent contractual arrangements allocating obligations otherwise.
- You make a substantial modification to a high-risk system in a way that affects its compliance or changes its intended purpose, and it remains or becomes high-risk.
- You modify the intended purpose of a system, including a general-purpose AI system not originally classified as high-risk, such that it becomes high-risk under Article 6.
The third trigger is the modern one. Take a general-purpose model, fine-tune it on your own data, and point it at CV screening or credit decisioning. You have not bought a high-risk system. You have made one, and you are now its provider, carrying the entire Article 16 stack including conformity assessment.
What happens to the original vendor is equally underreported. Under Article 25(2) the initial provider ceases to be considered the provider of that system. It is not released immediately: it must cooperate closely with the new provider and hand over the technical documentation, the known limitations and failure modes, and the targeted technical access needed to comply. But there is a carve-out that belongs in every procurement conversation. That cooperation duty falls away if the original provider explicitly specified that its system may not be modified into a high-risk one. A vendor can contract its way out of helping you, and many will.
Article 25(4) closes the loop by requiring providers and third-party suppliers to set out in a written agreement the information, technical access and assistance needed for compliance. Free and open-source components are excluded, and the AI Office may publish voluntary model contract terms. If you assemble systems from components, that written agreement is your AI accountability instrument, and it belongs in vendor due diligence rather than in the legal review three days before launch.
What each role must actually produce
AI accountability you cannot evidence is a claim, not a position. The Act is unusually specific about the artifacts, and this is where AI accountability becomes operational rather than aspirational.
- Technical documentation drawn up before the system reaches the market and kept current, per Annex IV. This is the master file proving design choices, data governance and testing. See our breakdown of the AI system documentation requirements.
- Automatically generated logs, designed in under Article 12 so events are recorded across the system’s lifetime, and retained by the deployer under Article 26(6) for a period appropriate to the intended purpose and in any case at least six months, unless other Union or national law provides otherwise.
- A documented human oversight assignment naming the natural persons who exercise it, under Article 26(2).
- The EU declaration of conformity under Article 47, signed by the provider, which is the moment AI accountability is formally accepted in writing.
- Post-market monitoring under Article 72, plus serious incident reports to the provider and the market surveillance authority under Article 73. Our guide to AI incident reporting covers the clock and the thresholds.
Read as a set, these are the auditability half of the Turing definition rendered as legal obligation. Each artifact answers one question a regulator can ask: what did you build, what did it do, who was watching, who signed, and what did you do when it went wrong.
AI accountability has a price list
The clearest evidence that AI accountability is a role rather than a virtue is that the Act prices it role by role.
Article 99(4) sets administrative fines of up to EUR 15,000,000 or 3 percent of total worldwide annual turnover, whichever is higher, and then enumerates who: providers under Article 16, authorised representatives under Article 22, importers under Article 23, distributors under Article 24, providers and operators under Article 25(2) and (4), deployers under Article 26, notified bodies, and providers and deployers under the Article 50 transparency duties (Article 99). Prohibited practices under Article 5 sit higher, at up to EUR 35,000,000 or 7 percent. Supplying incorrect, incomplete or misleading information to a notified body or a national competent authority carries up to EUR 7,500,000 or 1 percent.
That last tier deserves a pause, because it means the account you give is itself regulated. Getting the answer wrong on purpose is its own offence.
Public enforcement is only half the picture. Private damages run on a separate track, and that track moved recently. The proposed AI Liability Directive was withdrawn by the Commission in February 2025, so claims by injured people now proceed under the revised Product Liability Directive (EU) 2024/2853, which treats software and AI systems as products, applies strict liability so the claimant need not prove negligence, widens the range of liable economic operators, and introduces evidentiary presumptions favouring the injured party. Member States must transpose it by 9 December 2026 (EUR-Lex). Two regimes, two different claimants, one set of facts.
Naming the humans: competence, training and authority
Article 26(2) contains three words that quietly defeat most oversight programmes. Deployers must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support (Article 26).
Competence and training are procurable. Authority is not. It means the named person can actually stop the system. Article 26(5) makes that concrete: where the deployer has reason to consider that use presents a risk, it must suspend the use of the system and inform the provider. An oversight role held by someone who cannot halt a production service without three approvals does not satisfy this, whatever the responsibility matrix says. The difference between human in the loop and human on the loop is exactly the difference between holding authority and merely watching.
Two other frameworks converge here, which makes the mapping cheap if you are already certified. ISO/IEC 42001 Clause 5.3 requires top management to assign, communicate and authorise the roles for the AI management system, producing documented lines of AI accountability and empowering designated people to verify conformity and report performance to leadership. Auditors read that clause as a demand for named owners across the lifecycle, not a committee. The ISO 42001 and EU AI Act standards stack shows where the clause and the article meet. On the US side, the GOVERN function of the NIST AI Risk Management Framework calls for accountability structures so that the appropriate teams and individuals are empowered, responsible and trained (NIST AI 100-1).
Where AI accountability breaks in practice
Four failure modes account for most AI accountability breakdowns.
No role, because no inventory. You cannot assign AI accountability for a system you do not know exists. Shadow AI is an AI accountability failure before it is a security one: an unregistered tool has no provider of record, no deployer of record and no named overseer.
The many-hands problem in agentic chains. A workflow spanning a foundation model, an orchestration layer, a retrieval store and three vendors spreads the causal contribution so thinly that nobody feels answerable. The Act’s answer is the Article 25(4) written agreement, which forces the allocation to be recorded before it is needed rather than litigated afterwards.
The contract myth. Commercial terms between a provider and a deployer allocate risk between those two parties. They do not displace the statutory duties each owes to authorities and to affected persons. A deployer that has indemnified itself has changed who pays, not who is accountable.
The deadline myth. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the Annex III standalone high-risk obligations to 2 December 2027 and the Annex I embedded ones to 2 August 2028. It did not pause everything. Prohibited practices have applied since 2 February 2025, and the Article 50 transparency duties are unchanged. Read the shift as time to build the AI accountability map properly, not as permission to skip it. Our view of the wider AI regulatory landscape tracks what moved and what did not.
Build your AI accountability map this quarter
Seven steps, in order.
- Inventory every AI system in use, including the ones procured on a card and the ones embedded in software you already own.
- Classify each against Annex III and Article 6 to establish whether high-risk duties attach.
- Assign your role per system, not per organisation. You will be the deployer of most and the provider of a few.
- Name the natural person exercising oversight for each high-risk system, and confirm in writing that they hold suspension authority under Article 26(5).
- List the artifact that discharges each duty and where it lives: documentation, logs and retention window, declaration of conformity, incident procedure.
- Test your roadmap against the Article 25 triggers. Any planned rebranding, fine-tuning or repurposing goes on a provider-shift watchlist before engineering starts.
- Set a review cadence and an owner for the map itself, because roles change the moment a system is modified.
Steps 1 through 3 are the ones organisations skip, and every later step depends on them. An AI audit that begins without them spends its first week reconstructing the inventory.
FAQ
Can AI be legally held accountable?
No. No jurisdiction grants AI systems legal personality, and the EU AI Act does not attempt it. The Act assigns obligations to human and corporate operators: providers, deployers, importers, distributors and authorised representatives. When commentary asks whether AI can be accountable, the operational translation for AI accountability is which operator role you occupy for a given system, and what that role owes under its article. The system is the subject of the duty, never the bearer of it.
Why is accountability a problem in AI?
Because causal contribution is distributed and the artifacts are ephemeral. A single output can reflect training data chosen by one party, fine-tuning by a second, an orchestration prompt by a third and a deployment decision by a fourth. Add systems that are probabilistic and that change with retraining, and the ordinary evidentiary trail breaks. The regulatory answer is to fix AI accountability to roles and to require durable artifacts, logs and documentation, so the account survives the diffusion.
What is the difference between AI accountability and AI responsibility?
Responsibility describes a duty to act with care. AI accountability is relational and retrospective: a named party owes an account of a decision to someone entitled to demand one, and faces consequences if the account fails. You can be responsible for a task without being accountable to anyone in particular. Under the AI Act, accountability is the stronger notion, because it arrives with a defined counterparty, a defined artifact and a defined penalty.
Does a contract with our vendor transfer AI accountability?
Not as against authorities. A contract allocates commercial risk between the parties, and it can matter under Article 25(1)(a), where trademark-based provider status applies absent contractual arrangements allocating obligations otherwise. But statutory duties owed to market surveillance authorities and to affected persons are not privately assignable. If you are the deployer, Article 26 applies to you whatever the services agreement says about compliance being the vendor’s problem.
What does an AI accountability framework need to contain?
At minimum: a system inventory, a per-system role determination, a risk classification, a named oversight owner holding suspension authority, an evidence map linking each duty to its artifact and retention period, an incident and redress path, and a change trigger that re-tests roles whenever a system is modified. Frameworks that stop at principles fail the auditability half of the definition, because principles cannot be produced on request.
Who is accountable when a general-purpose AI model causes harm downstream?
AI accountability here depends on what you did to it. The model provider carries the GPAI obligations attaching to the model itself. If you fine-tuned or repurposed it so the resulting system is high-risk under Article 6, Article 25(1)(c) makes you the provider of that system, with the full Article 16 stack. If you deployed it unchanged for its intended purpose, you hold the Article 26 deployer duties. The question is always which act you performed, not whose logo sits on the model.
Conclusion
The published material on AI accountability is full of principles, and principles are not the hard part. The hard part is that accountability under EU law is a position you occupy, sometimes without intending to, and every position carries an article number, an artifact and a fine. Start with the inventory, assign the role per system, name the person who can switch it off, and file the evidence where you can produce it within a day. That is AI accountability in practice. Everything else is commentary. For the wider operating model this sits inside, start with AI governance.