Who Is Accountable When Responsibility Is Distributed?

The argument in 60 seconds

An AI-supported decision usually passes through many hands: a model provider, an application developer, an integrator, a cloud platform, the organisation that deploys it, the managers who run the process and the employee who makes the final call.

Each holds a fragment of the knowledge and control. That makes it easy for everyone to point somewhere else — and for the person harmed to find no one who can explain or correct what happened.

Accountability should be distributed, but never diluted. Each actor should answer for the risks it can know, control, authorise, benefit from, prevent or remedy — while one identifiable organisation remains answerable for the decision to deploy and to keep using the system.

The answer is neither one universal “AI owner” nor vague “shared responsibility”. It is a chain of differentiated but connected accountabilities, supported by evidence, escalation and accessible remedy.

The Accountability Chain

View the full chain →

1. PreventWho designs or funds the safeguard?
2. DetectWho monitors deviation or harm?
3. DecideWho can approve, pause or accept residual risk?
4. EscalateWho must raise the issue, to whom, and by when?
5. RemedyWho can correct the outcome or restore rights?
6. AnswerWho must ultimately explain what happened?

A conventional RACI matrix asks who is responsible, accountable, consulted and informed. The Accountability Chain asks something more specific to AI: for each material risk, who can prevent it, who will detect it, who may decide, who must escalate, who can remedy — and who will answer.

Why “shared responsibility” so often fails

AI systems are sociotechnical: model behaviour interacts with data, integrations, incentives, operators and context. Risks visible in production may have been invisible during development; deployment risks may be invisible to the provider.¹ “Shared responsibility” becomes “no one is responsible” when:

• each actor can plausibly point elsewhere
• contract labels replace analysis of actual control
• approval authority is separated from technical knowledge
• operators carry formal responsibility without practical authority
• audits find problems that nobody must remediate
• affected people cannot identify anyone able to correct the outcome

Words that are often blurred

Responsibility

A task or sphere of conduct assigned to an actor — forward-looking (“what must you do?”) or backward-looking (“what did you contribute?”).

Accountability

A relationship in which an actor must explain and justify conduct, accept scrutiny and consequences, and support correction.²

Liability

Legally enforceable exposure to compensation or penalties. It depends on a specific legal regime, causation and role — not ethical blame.

Control

Practical ability to shape purpose, design, inputs, use, continuation or remedy. Data-protection law looks at actual purposes and means, not contract labels.³

Remedy

Correction, explanation, reconsideration, compensation, restoration or suspension — the test of whether accountability means anything to the people affected.

AI can exercise operational agency, but legal and moral responsibility stays with human and institutional actors. UNESCO's Recommendation states that AI must not displace ultimate human responsibility.⁴

Who holds which part?

NIST explicitly distinguishes design, development, deployment, operation, testing, procurement, governance, third-party and affected-community roles, and recommends separating model builders from validators where practicable.¹

Five accountability lenses

The lenses often point to different actors. A vendor may have documentation duties, the employer may be the GDPR controller, a manager may own the workflow, an employee may make the final call — and the injured person may still struggle to prove civil liability. Good analysis keeps them apart and never turns an ethical conclusion into an unsupported legal claim.

The European position

The AI Act assigns obligations by market role, not job title. High-risk providers carry duties for quality management, documentation, conformity assessment, registration and corrective action (Article 16); deployers must use systems as instructed, give overseers competence, training and authority, monitor operation, keep logs, suspend risky use and inform affected workers (Article 26); general-purpose AI providers must document their models and give downstream builders information on capabilities and limitations (Article 53).⁵

Roles can change. A distributor, importer, deployer or other third party becomes the provider when it puts its own name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk (Article 25).⁶ Providers must also run post-market monitoring across the system's lifetime, including data from deployers (Article 72).⁷

Penalties reach up to €35 million or 7% of worldwide turnover for prohibited practices, and up to €15 million or 3% for many provider, deployer and supply-chain breaches (Article 99).⁸ Following the AI Omnibus, the high-risk duties apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I); general-purpose AI obligations have applied since August 2025.⁹

GDPR follows actual control. Whoever determines the purposes and essential means of processing is a controller; contracts are relevant but not decisive, and joint controllership does not mean equal responsibility.³ In SCHUFA, the EU Court of Justice held that a score can itself be automated decision-making when a bank gives it a determining role — splitting scoring and the formal decision between companies does not avoid the protections.¹⁰

The revised Product Liability Directive defines software as a product and allows an injured person to seek compensation from both the manufacturer of a defective component and the manufacturer that integrated it. It applies to products placed on the market after 9 December 2026. It does not cover every AI harm: pure economic loss, privacy infringements and discrimination do not by themselves trigger liability under it, though other regimes may apply.¹¹

Global frameworks

The NIST AI RMF assigns executive responsibility for AI-risk decisions and covers third-party risk, go/no-go decisions and decommissioning;¹ the OECD principles link accountability to role, context and ability to act;² ISO/IEC 42001 provides an organisation-wide AI management system.¹² None of them, on its own, decides legal liability or compensates people who were harmed.

What each role should answer for

Developers and providers

Intended use and foreseeable misuse, data provenance and limits, design trade-offs, pre-deployment testing, security, versioning, documentation, downstream instructions, monitoring and correction. Their responsibility is strongest for what they uniquely know and control — and weaker for deployment conditions they cannot see unless feedback channels exist.

Deployers and procurers

A compliant or certified product does not validate the purpose, context, workflow, local data or human consequences of a particular deployment. The deployer chose the use case, population, data, automation level and decision process, so it owns contextual legitimacy, monitoring, contestability and the decision to continue. Procurement should secure version identification, use boundaries, relevant performance evidence, logs, notice of material updates, incident cooperation, audit rights with remediation duties, and exit.

Managers and executives

Leadership answers for the conditions in which AI decisions are made: governance, risk tolerance, authority, staffing, incentives, competence, escalation protection and continued deployment. Delegation is legitimate when authority, information and resources follow the duty.

Employees and frontline operators

Employees should follow legitimate procedure, use professional judgement, document deviations and escalate. But organisational accountability should increase when the worker lacks information, competence, time, the practical ability to override, authority to escalate, protection from retaliation or a realistic alternative to accepting the AI. Without those, a “human in the loop” becomes a liability shield.¹³ This is the question my research on meaningful human oversight examines in depth.

External providers and assurance

Responsibility should attach to the layer each controls: model, application, integration, cloud, data or assurance opinion. Auditors answer for scope, competence, independence and honest reporting — not for deployment risk they have no authority to accept. An assurance report without tracked remediation can create comfort without control.

An allocation test

For each actor and each material risk, ask explicitly — not as a numerical score:

Knowledge

What did or should the actor know?

Control

What could it change?

Decision authority

Could it approve, stop or override?

Benefit

Who gained from the activity?

Proximity

How close was it to the harmful decision?

Capacity

Who could realistically prevent or remedy it?

This works for organisational and moral accountability and echoes the OECD's role-context-ability approach. It is not a substitute for legal doctrine: product liability assigns roles by statute, GDPR controllership turns on purposes and means, and causation and jurisdiction still govern claims.

What real cases show

SyRI (Netherlands)

The District Court of The Hague held the welfare-fraud risk system's legislation incompatible with Article 8 ECHR because it was insufficiently transparent and verifiable.¹⁴ A public authority cannot outsource proportionality to an opaque system.

Robodebt (Australia)

A Royal Commission examined the unlawful automated debt scheme and made 57 recommendations.¹⁵ Responsibility fragmented across policy, legal advice, implementation and frontline administration.

SCHUFA (EU)

A score can be an automated decision when the lender gives it decisive weight.¹⁰ Splitting work across companies does not split away the protections.

iTutorGroup (United States)

The EEOC alleged that recruiting software automatically rejected older applicants; the employer settled for $365,000.¹⁶ Automating a hiring rule does not move the employer's responsibility to the software.

Rite Aid (United States)

The FTC alleged facial-recognition surveillance was deployed without reasonable safeguards, causing false matches; the order restricted its use.¹⁷ Buying technology does not remove deployment duties.

Healthcare risk algorithm

A widely used algorithm under-identified Black patients' needs because it predicted cost, not illness.¹⁸ Proxy choice and institutional deployment matter — this was research, not a liability finding.

Automated test vehicle (Tempe, 2018)

The NTSB identified operator distraction as the probable cause, alongside inadequate safety-risk assessment, ineffective operator oversight and insufficient attention to automation complacency.¹⁹ The last human in the chain is rarely the only cause.

Moffatt v. Air Canada

The tribunal rejected the airline's argument that it was not responsible for information from its own chatbot.²⁰ Organisations answer for their customer-facing automated statements.

The pattern is rarely “the algorithm caused the harm”. It is a chain of specification, procurement, integration, management, oversight and remedy decisions.

What boards and leaders should require

1. One accountable deployment owner for every material AI use case.
2. A complete actor and dependency register — models, data, cloud, plugins, integrators, assurance providers.
3. Named Prevent–Detect–Decide–Escalate–Remedy–Answer owners for each material risk.
4. Evidence-based approval gates with recorded reasoning, not consensus without a trail.
5. Independent challenge with remediation authority and tracked closure.
6. Contractual observability: version notice, logs, limitations, incidents, subcontractors, audit and exit.
7. Operator viability testing: can the human actually understand, challenge and override?
8. Affected-person pathways: notice, explanation, human reconsideration and an identifiable entity that can correct.
9. Stop criteria: serious incident, material drift, loss of observability, vendor non-cooperation, ineffective oversight or repeated harm.
10. Continued-use reviews: the accountable executive periodically re-authorises deployment on current evidence.

Boundary cases

• Open-source models — less central control can shift responsibility toward deployers and integrators; commercial integration can create new provider roles.
• Shadow AI — organisations stay accountable for governance they could reasonably have set up; employees acting outside their authority may carry separate responsibility.
• Agents and plugins — accountability attaches to permissions, tool access, integration and monitoring, not to the fiction that the agent is responsible.
• Multi-vendor stacks — no one sees the whole system, so component traceability, interface testing and an end-to-end deployer are essential.
• Indemnities redistribute financial loss between parties; they do not rewrite statutory roles or regulator-facing duties.
• Standards provide structure and evidence, but certification cannot by itself establish legality, fairness or safety.

Conclusion

The answer to “who is accountable?” is rarely one person. But it must never be “everyone” in the abstract.

Developers answer for design, evidence, limitations and system-level correction. Deployers answer for purpose, context, workflow and continued use. Executives answer for authority, resources, incentives and risk acceptance. Managers answer for operational conditions. Employees answer within their genuine knowledge and agency. Suppliers answer for the layers they control. Regulators answer for effective supervision.

Every foreseeable harm needs someone able to prevent it, someone positioned to detect it, someone authorised to decide, a protected route to escalate, someone capable of remedy — and an identifiable organisation that must ultimately answer.

Method and limits

This is a research-led synthesis of legislation, case law, regulatory guidance and governance frameworks, prepared in October 2026. It is not legal advice; legal status is described as of 3 October 2026 and may change. I checked each source below against its official or published record. The Accountability Chain, the allocation test and the board requirements are my own proposals.

Sources

1. Framework NIST (2023). AI Risk Management Framework (AI RMF 1.0). doi:10.6028/NIST.AI.100-1. ↩
2. International principles OECD AI Principles — Accountability. oecd.ai. ↩
3. Regulatory guidance European Data Protection Board. Guidelines 07/2020 on the concepts of controller and processor in the GDPR. edpb.europa.eu. ↩
4. International recommendation UNESCO (2021). Recommendation on the Ethics of Artificial Intelligence. unesco.org. ↩
5. Legislation AI Act, Articles 16, 26 and 53. Art. 16 · Art. 26 · Art. 53. ↩
6. Legislation AI Act, Article 25 — Responsibilities along the AI value chain. artificialintelligenceact.eu. ↩
7. Legislation AI Act, Article 72 — Post-market monitoring. artificialintelligenceact.eu. ↩
8. Legislation AI Act, Article 99 — Penalties. artificialintelligenceact.eu. ↩
9. Official guidance European Commission. AI Act — regulatory framework for AI (including AI Omnibus dates). digital-strategy.ec.europa.eu. ↩
10. Case law CJEU, Case C-634/21, SCHUFA Holding (Scoring), 7 December 2023. eur-lex.europa.eu. ↩
11. Legislation Directive (EU) 2024/2853 on liability for defective products. eur-lex.europa.eu. ↩
12. Standard ISO/IEC 42001:2023, Artificial intelligence — Management system. iso.org. ↩
13. Philosophy Santoni de Sio, F. & van den Hoven, J. (2018). Meaningful human control over autonomous systems: A philosophical account. Frontiers in Robotics and AI, 5. doi:10.3389/frobt.2018.00015. ↩
14. Case law Rechtbank Den Haag, 5 February 2020, ECLI:NL:RBDHA:2020:865 (SyRI). rechtspraak.nl. ↩
15. Public inquiry Royal Commission into the Robodebt Scheme (2023). Report. robodebt.royalcommission.gov.au. ↩
16. Regulatory action U.S. EEOC. iTutorGroup to pay $365,000 to settle EEOC discriminatory hiring suit. eeoc.gov. ↩
17. Regulatory action U.S. Federal Trade Commission. Rite Aid Corporation, FTC v. ftc.gov. ↩
18. Empirical research Obermeyer, Z. et al. (2019). Dissecting racial bias in an algorithm used to manage the health of populations. Science, 366(6464), 447–453. doi:10.1126/science.aax2342. ↩
19. Accident investigation NTSB (2019). Collision Between Vehicle Controlled by Developmental Automated Driving System and Pedestrian, Tempe, Arizona (HAR-19/03). ntsb.gov (PDF). ↩
20. Case law Moffatt v. Air Canada, 2024 BCCRT 149. canlii.org. ↩