AI Accountability: Who's Responsible?

When an AI system denies someone a loan, misdiagnoses a patient, or makes a harmful recommendation, the question that follows is almost always the same one: who is responsible for that? “AI accountability” is the umbrella term for the answer — the roles, sign-offs, audit trails, and incident-reporting obligations that organizations and regulators use to make sure a human (or a defined role) can always be pointed to when an AI system causes harm, rather than the harm dissolving into “the algorithm did it.”

This guide covers what AI accountability means as a general concept, the mechanisms that actually implement it, and how several real frameworks — California’s SB 53, the NIST AI Risk Management Framework, and the EU AI Act — assign it differently. If you landed here looking for one specific framework’s accountability role, jump to SB 53’s accountable decision-maker requirement directly; this page is the broader map those framework-specific pages sit inside.

What “AI accountability” actually means

Strip away the framework-specific language and accountability for an AI system’s harm breaks into three distinct, separable questions:

Decision responsibility. Who had the authority to approve deploying this system, accept a known risk, or block a release — and can that be shown after the fact? This is the “accountable decision-maker” question: a named role (not necessarily a named individual) that owns the call.
Technical traceability. Can the organization reconstruct what the system actually did — what data it used, what version was running, what output it produced — well enough to investigate a harm after it happens? This is the audit-trail and logging question.
External obligation. Does a regulator, a court, or an affected person have a legal channel to demand an answer, and does the organization have a legal duty to report certain harms proactively rather than waiting to be asked? This is the incident-reporting and liability question.

A system can score well on one axis and fail on another. A company might keep excellent internal logs (traceability) while having no one formally authorized to approve deployment (decision responsibility), or it might have a named accountable executive while keeping no record of what that executive actually reviewed. Real accountability mechanisms have to cover all three, and the frameworks below split up which one they emphasize.

The mechanisms organizations and regulators actually use

In practice, “assign accountability” cashes out as a short list of concrete organizational mechanisms, not a philosophical position:

A named accountable role. A title or function — not necessarily a person, since people change jobs — that holds authority to approve or block a specific class of decision: deploying a model, accepting a residual risk, approving a change to a safety framework.
A sign-off and approval record. A timestamped record of what was approved, by which role, and when — independent of whether any of it is ever published externally. Without this, a “named role” is just a title with no evidence attached to it.
An audit trail. System-level logging (inputs, outputs, model version, configuration) sufficient to reconstruct what happened after an incident, not just who approved the system in general.
Escalation paths. A defined route from whoever first notices a problem up to whoever is authorized to decide what happens next, and ultimately to whoever files any legally required external report.
Incident-reporting obligations. A legal or policy duty to notify a regulator, a customer, or the public when a defined class of harm occurs, on a defined clock, rather than accountability existing only in theory until someone asks.

These mechanisms are the practical layer underneath every framework discussed below — the frameworks differ in which of these five they make legally mandatory versus leave to organizational judgment.

How different frameworks assign accountability

No framework covers all three axes above equally. Each tends to regulate one or two mechanisms tightly and leave the rest to the organization’s own governance design. This guide surveys three; each has its own dedicated CASRAI page with the full statutory or regulatory detail, linked below rather than repeated here.

California SB 53: the “accountable decision-maker” gap

California’s SB 53 (the Transparency in Frontier Artificial Intelligence Act) requires a large frontier developer to publish a frontier AI framework describing how it reviews deployment-decision assessments and what internal governance practices it uses — but the statute’s text does not name a required role, title, or individual who must hold that authority. It regulates decision responsibility only at the level of “a process must exist and be described,” not “a specific person must sign it.” See Accountable Decision-Makers Under SB 53 for exactly what the statute does and does not require, and why organizations designate a named role anyway even though the law doesn’t force it.

The NIST AI RMF’s Govern function: accountability structures as a named category

The NIST AI Risk Management Framework (AI RMF 1.0) organizes AI risk management into four functions — Govern, Map, Measure, and Manage — and accountability sits explicitly inside Govern. Govern’s second category, GOVERN 2, states the outcome directly: “Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks.” Unlike SB 53, the NIST AI RMF is voluntary guidance rather than binding law in most contexts, but it is far more explicit than SB 53 about naming accountability structures as their own category of practice, alongside policies (GOVERN 1), workforce diversity in risk management (GOVERN 3), risk culture (GOVERN 4), AI actor engagement (GOVERN 5), and third-party/supply-chain risk (GOVERN 6). See Building an AI Safety Framework with NIST’s Govern, Map, Measure, Manage Functions for how to actually implement all four functions, not just Govern.

The EU AI Act: accountability folded into provider obligations

The EU AI Act takes a third approach: rather than naming an “accountable decision-maker” role or a standalone “accountability structures” category, it assigns accountability functionally to whichever entity is the “provider” of a high-risk AI system. Article 16 sets out the provider’s obligations directly, including maintaining a quality management system (Article 17), keeping technical documentation (Article 18) and automatically-generated logs (Article 19), completing a conformity assessment before market placement, signing an EU declaration of conformity, affixing CE marking, registering the system, and taking corrective action and notifying authorities when a system is found non-compliant (Article 20). Accountability here is less about a named internal role and more about an organization-level legal obligation that attaches automatically to whichever party fits the “provider” definition. See EU AI Act High-Risk System Compliance Checklist for the full obligation set, sourced against the Act’s actual articles.

The pattern across all three

Read together, the three frameworks emphasize different points on the same underlying structure: SB 53 requires that a governance process exist but is silent on who runs it; the NIST AI RMF names accountability structures explicitly as a best-practice category without legal force in most settings; the EU AI Act skips naming an internal role altogether and instead attaches binding, enumerated obligations directly to the “provider” entity. None of them is wrong, and none of them is a complete accountability program on its own — an organization operating across all three (a frontier developer doing business in California and the EU, following NIST guidance voluntarily) needs a governance design that satisfies all three simultaneously, not a single “accountability” checkbox.

From accountability structure to incident response

An accountability structure only matters once something actually goes wrong, and that is where it connects to incident reporting and response — a different, more operational layer built on top of the roles and sign-offs described above. Two practical questions follow directly from having a named accountable role:

What has to be reported externally, and on what clock? Under SB 53, a large frontier developer must report a critical safety incident to California’s Office of Emergency Services within 15 days of discovery (with a faster clock for the most severe incidents). See SB 53 Critical Safety Incident Reporting for the exact triggers, deadlines, and notification requirements.
What does the internal machinery that feeds that report look like? Detection channels, a severity taxonomy for triage, and an escalation path from whoever first notices a problem up to the named accountable decision-maker — the same role this guide has been describing — who decides what gets reported and when. See Building an Internal AI Safety Incident Response Program for how to structure that machinery.

In short: accountability structure answers “who decides,” and incident response answers “what happens when that decision has to be made under time pressure, about something that already went wrong.” Neither works without the other — an accountable role with no incident-response process to escalate through is a title with nothing to do, and an incident-response process with no accountable role at the top of the escalation path has nowhere to send a decision that needs to be made.

CASRAI’s NIKOLAI dictionary and the accountability-role concept

This whole concept — a named role responsible for a decision, with a record of what was approved and when — maps closely to a specific element in CASRAI’s own NIKOLAI project, its independent, unendorsed dictionary of frontier-AI-safety terminology. In NIKOLAI’s Commitments and Governance track (N9), the Accountable Decision-Maker and Sign-Off element defines exactly the cross-framework concept this guide surveys: “the named role (and, where published, the named person) who makes or approves a threshold determination, risk-acceptance decision, deployment decision, redaction, or framework change,” together with the approval record itself. It is the same element the narrower SB 53 accountable-decision-maker page above references — here it functions as the general, cross-framework definition that SB 53’s role, the NIST AI RMF’s GOVERN 2 accountability structures, and the EU AI Act’s provider-level obligations can all be read against, even though none of those three frameworks uses NIKOLAI’s terminology directly. NIKOLAI is CASRAI’s own reference work, not an official cross-framework standard, and every crosswalk row it draws between its own element and a real framework is a shadow mapping — CASRAI’s own reading of the published text — unless the organization behind that framework has filed its own statement through NIKOLAI’s Mapping Declarations system. An organization that wants to confirm, correct, or add to how its own accountability-role terminology maps across the frameworks it operates under — whether that’s SB 53’s undefined signatory, NIST’s GOVERN 2, or the EU AI Act’s provider obligations — can do exactly that through Mapping Declarations, replacing CASRAI’s own reading with its own declared position.

FAQ

Who is responsible when an AI system causes harm?

It depends on the harm and the jurisdiction, but the general pattern across the frameworks above is: whoever holds the internal accountable role that approved the deployment or risk-acceptance decision bears internal responsibility, while external legal liability typically attaches to whichever organization is the “provider” or “developer” under the relevant law (the EU AI Act’s provider obligations, for example, or SB 53’s obligations on a “large frontier developer”). There is no single universal answer across all AI systems and jurisdictions — check which framework(s) actually apply to the system in question.

What is an AI accountability framework?

An AI accountability framework is the combination of a named accountable role, a sign-off/approval record, audit trails, escalation paths, and (where legally required) incident-reporting obligations that together let an organization show who decided what, when, and on what basis. It is not one document but a set of organizational mechanisms — see “The mechanisms organizations and regulators actually use” above.

Is AI accountability the same as AI liability?

No. Accountability is about internal and organizational responsibility — who decided, who signed off, who can explain what happened. Liability is a legal question about who owes damages or faces penalties when harm occurs, which depends on the specific law and jurisdiction. A clear accountability structure makes it easier to establish liability when it applies, but the two are not interchangeable.

Does every AI regulation require a named accountable person?

No. SB 53 requires that internal governance practices exist and be described, without naming a required role or individual. The NIST AI RMF recommends accountability structures as a best practice (GOVERN 2) without binding legal force in most contexts. The EU AI Act does not name an internal role at all — it attaches obligations directly to the “provider” entity under Article 16. Organizations frequently designate a named accountable role anyway, as a practical way to satisfy governance requirements that are stated more generally.

How is this different from the SB 53 accountable decision-maker page?

That page is scoped narrowly to what one state law, SB 53, actually requires and does not require regarding a named decision-maker role. This page is the broader concept sitting above it — how accountability gets assigned across multiple frameworks, of which SB 53 is one example alongside the NIST AI RMF and the EU AI Act.