Operational responsibility in AI governance: a user-centric liability framework

When AI systems cause harm, primary accountability should rest with the humans who deploy them, not the firms that build them. Chen (2026) develops a “distributed yet centered” governance framework grounded in three principles — proximity, control, and expertise — and resolves the most serious challenge to user-centric governance (black-box API deployments) through a spectrum-of-control approach in which deployer obligations intensify as actual control decreases, with enhanced provider disclosure compensating for reduced deployer visibility.

Key Concepts

Operational responsibility framework

The legal-conceptual position that AI systems are instruments whose outputs remain the responsibility of human operators rather than developers, with deployment decisions as the locus of primary accountability. Anchored by Chen (2026).

Distributed yet centered accountability

The governance model that recognizes obligations across the AI ecosystem (developers, organizations, regulators, end users) while keeping primary accountability centered on the deployment decision. The deliberate alternative to flat “shared responsibility” models that dissipate accountability across many hands.

Spectrum-of-control deployer obligations

Chen’s (2026) novel resolution of the black-box / API challenge: deployer obligations are calibrated to actual control, intensifying for full enterprise deployments, weakening (but never disappearing) for raw-API consumption, and matched on the provider side by enhanced disclosure duties when deployer visibility is low.

Q1. When AI systems cause harm, should responsibility rest with the developer or the deployer?

Headline answer: Primary responsibility should rest with the deployer — the human or organization that put the system to use — with developers bearing secondary obligations for design safety, disclosure, and ongoing support. Treating AI as an instrument whose outputs remain the operator’s responsibility tracks tort, agency, and professional-liability doctrines that long predate AI, and it produces clearer accountability than either pure developer liability or undifferentiated “shared” responsibility.

The scholarly tension has been sustained. Scherer argues for developer-side regulation through an FDA-style ex ante certification regime , and Chinen contends that the co-evolution of autonomous machines and law requires expanded manufacturer liability . On the other side, Rachum-Twaig argues that users with contextual knowledge should bear primary responsibility for deployment decisions , and Kingston frames AI legal liability as an extension of the doctrine that those who employ tools bear duties of care proportional to foreseeable risks .

Chen (2026) advances the user-centric position on three grounds drawn from established law:

1. Proximity — duty of care attaches to actors closest to potential harm. Deployers, not developers, possess contextual knowledge about where and how the system is used.
2. Control — agency law assigns responsibility to whoever exercises decisional authority. Kellogg, Valentine and Christin document six mechanisms (restricting, recommending, recording, rating, replacing, rewarding) through which deploying organizations shape AI behavior in practice .
3. Expertise — professional liability tracks specialized knowledge. Burrell shows that domain-specific knowledge is what surfaces algorithmic harms that remain invisible to technical developers .

Two recent decisions illustrate the framework. Moffatt v. Air Canada (2024) rejected an airline’s argument that its chatbot was “a separate legal entity”; the company answered for the AI’s outputs. Mata v. Avianca (2023) sanctioned lawyers who relied on ChatGPT without verification. Courts are converging on the instrumental treatment of AI: the tool does not absorb responsibility from the human who wields it.

Related questions: What is the responsibility gap in AI ethics? · How does user-centric governance handle black-box API deployments?

Q2. What is the “responsibility gap” in AI ethics, and can it be resolved?

Headline answer: The “responsibility gap” — originally Matthias’s claim that learning automata create situations where no human can fairly be held morally responsible for harmful outcomes — is real but not unresolvable. Chen (2026) argues that user-centric governance closes the gap at the point that matters most for accountability: the deployment decision . Even when the system’s internal behavior cannot be traced to any single design choice, the human or organization that activated, configured, and acted upon the system remains identifiable and answerable.

The notion has been refined since 2004. Santoni de Sio and Mecacci show that the “responsibility gap” is not one problem but a cluster of four — gaps in culpability, in moral accountability, in public accountability, and in active responsibility — caused by different mixes of technical, organizational, legal, and ethical factors . Santoni de Sio and van den Hoven earlier argued that meaningful human control requires both “tracking” (the system’s responsiveness to human reasons) and “tracing” (attribution to identifiable human actors) .

User-centric governance directly satisfies the tracing requirement and indirectly supports tracking. Chen (2026) makes three connected moves :

1. Distinguishes four senses of responsibility — causal, moral, role, and legal — and shows that user primacy applies differently to each, drawing on Floridi and Sanders’s analysis of artificial agents and Novelli, Taddeo and Floridi’s account of accountability in AI .
2. Refuses what Taddeo and Floridi term “distributed responsibility without distribution of accountability” — many actors contribute causally, but accountability does not have to dissipate.
3. Establishes the deployer as the primary answer-bearer in legal and moral senses, with developers bearing role-responsibilities (disclosure, testing, safety design) that enable the deployer’s accountability rather than displacing it.

The gap, on this account, is not closed by appealing to a metaphysical fact about AI; it is closed by an allocation rule. The rule rests on the same principles that already govern responsibility for surgeons using scalpels, doctors prescribing drugs, and pilots flying aircraft — tools whose users bear answerability proportional to control and expertise.

Related questions: What is meaningful human control over AI? · How does the user-centric framework differ from developer liability models?

Q3. How does the EU AI Act assign responsibility between AI developers and deployers?

Headline answer: Regulation (EU) 2024/1689 imposes heavier obligations on providers (roughly, developers) than on deployers in its core architecture: providers bear conformity assessment, quality management, technical documentation, post-market monitoring, and EU-database registration duties under Articles 16–25, while deployers of high-risk systems bear human-oversight, monitoring, logging, incident-reporting, and (for public-sector and large private actors) fundamental-rights impact-assessment obligations under Articles 26–27. Article 28 contains the pivotal reclassification rule: a deployer who substantially modifies a high-risk system or changes its intended purpose becomes a provider, inheriting the full weight of provider obligations.

Chen (2026) reads this architecture as provider-centric in primary burden allocation but treats deployer obligations as the underdeveloped layer where operational governance is most needed . The compatibility argument has three parts:

1. Deployer obligations are the substantive site of operational governance. Conformity assessments and technical documentation enable responsible deployment; they do not, by themselves, prevent context-specific harm. Model cards in the sense of Mitchell et al. translate developer disclosure into deployer-usable information , but the deployer is still the one who must decide whether the documented system suits a particular use.
2. Article 28 marks the spectrum boundary. Where the deployer accumulates enough control to look like a provider, the law already shifts the classification. This is consistent with the spectrum-of-control approach Chen develops conceptually.
3. The revised Product Liability Directive — Directive (EU) 2024/2853, in force December 2024, transposition deadline December 2026 — explicitly extends strict liability to software and AI systems and reverses the burden of proof where complexity makes proving defectiveness excessively difficult. This is producer-centric strict liability; the user-centric framework operates within it, not against it. Documented deployer due diligence becomes evidence of non-contributory conduct rather than a replacement for producer obligations.

The February 2025 withdrawal of the proposed AI Liability Directive — a separate deployer-focused liability instrument — signals that the EU is not currently planning to layer a parallel regime on top of the Product Liability Directive. Chen (2026) accordingly positions user-centric governance as a strengthening of an underdeveloped complementary layer, not a displacement of producer liability .

Comparative regulators sit elsewhere on the spectrum. Colorado’s Artificial Intelligence Act (SB 24-205, effective February 2026) is the most fully deployer-centric U.S. statute to date, requiring high-risk-AI deployers to exercise reasonable care against algorithmic discrimination, conduct impact assessments, and disclose AI use to consumers. China’s Interim Measures for the Management of Generative AI Services adopt a provider-centric model partly driven by content-control objectives. Singapore’s Model AI Governance Framework for Generative AI allocates responsibility by “level of control” — a direct analog to Chen’s control principle.

Related questions: What is the difference between an AI provider and an AI deployer under the EU AI Act? · How does user-centric governance handle black-box API deployments?

Q4. How does the user-centric AI liability framework handle black-box AI systems accessed through APIs?

Headline answer: Through a spectrum-of-control approach. Deployer obligations intensify as actual control over the system increases; provider disclosure obligations intensify as deployer control decreases. Full enterprise deployments — where organizations configure, fine-tune, and monitor systems within their own infrastructure — carry the strongest deployer accountability. Raw-API consumption — where deployers control only prompts, context windows, and basic parameters — carries minimum but irreducible deployer obligations (output verification, human-in-the-loop for high-stakes decisions, evidence-based provider selection), matched by enhanced provider disclosures about capabilities, limitations, and known failure modes.

The black-box challenge is the most serious objection to user-centric governance. Burrell’s analysis of three forms of machine-learning opacity and Crawford and Calo’s identification of the blind spot in AI research jointly establish that opacity is structural, not just informational. Selbst argues that AI inserts a layer of inscrutable, statistically derived code between human decision-makers and the consequences of their decisions , posing real difficulties for negligence law.

Chen (2026) stress-tests the three foundational principles against API conditions and finds:

1. Proximity still holds. The deployer remains closest to potential harm and possesses contextual knowledge about affected populations.
2. Control weakens sharply. Where Kellogg, Valentine and Christin document substantial organizational shaping in enterprise contexts , API users control only surface-level parameters, not weights, training data, or safety filters.
3. Expertise faces an asymmetry. Domain expertise enables judgment about output appropriateness but cannot detect AI-specific failure modes such as training-data bias or distribution shift.

The response is not to abandon user-centric governance but to calibrate it. Three structural features:

• Tiered deployer obligations. Enterprise → fine-tuned managed services → raw API. Each tier carries proportionate due-care expectations.
• Enhanced provider disclosure. The less control deployers exercise, the more information providers must furnish. Raji and colleagues’ SMACTR end-to-end internal algorithmic auditing framework and model cards in Mitchell et al.’s sense are the operational vehicles.
• Article 28 substantial-modification trigger. Where deployer modification accumulates to provider-like levels, the EU AI Act already reclassifies. The spectrum is not novel; the EU codified its endpoint.

For practitioners deploying through APIs today, Chen (2026) identifies three irreducible obligations : verify outputs before acting on them, maintain human-in-the-loop processes for high-stakes decisions, and select providers based on documented safety practices rather than marketing claims.

Related questions: What does “meaningful human control” require for API-based AI deployments? · What disclosure obligations should AI providers face?

Q5. What are the limitations of holding AI developers strictly liable for harms caused by their systems?

Headline answer: Three categories of limitation make developer-centric liability under-perform: an attribution problem (tracing harms to specific design choices is often technically infeasible), a definitional problem (no stable legal definition of “AI” across jurisdictions), and an innovation problem (concentrated developer liability has empirically chilled R&D in adjacent industries). These limitations do not absolve developers of obligations — they argue against concentrating primary accountability at the development stage.

On attribution: Burrell shows that opacity in machine learning is multi-layered, including intentional secrecy, technical illiteracy, and intrinsic complexity of high-dimensional optimization . Bathaee identifies the paradox that the more sophisticated an AI system becomes, the harder it is to establish proximate causation between developer decisions and harmful outcomes , and Tutt advances the case for “an FDA for algorithms” precisely because of this evidentiary challenge . A distinct attribution problem arises with training data: Cofone argues that algorithmic discrimination often stems not from identifiable design flaws but from the information fed to systems .

On definitional and regulatory clarity: Maas finds that AI definitions across national regulatory systems uniformly failed to satisfy basic requirements for legal operationalisability , and Yeung notes that unstable definitions create boundary disputes about regulatory scope .

On innovation: Viscusi and Moore find empirically that the relationship between liability and innovation is non-linear — at low to moderate levels, liability costs increase R&D intensity, but at very high levels the effect turns negative, depressing beneficial innovation . Galasso and Luo document that medical-device innovations decreased in therapeutic areas following court decisions expanding manufacturer liability, with smaller firms disproportionately reducing innovation .

Finally, the diffusion problem. Mittelstadt and colleagues observe that the ethical challenges of algorithms arise because multiple parties contribute through distinct decisions at different stages, making single-actor attribution difficult . Nissenbaum’s earlier analysis of accountability in computing systems calls this the “problem of many hands.” Developer-centric models do not solve it — they merely pretend that one node in a distributed network is the only one that matters.

Chen (2026) does not deny developer obligations — those obligations are essential as enabling infrastructure for deployer responsibility. The argument is structural: developers cannot be the locus of primary accountability because the conditions that justify primary accountability (proximity to harm, decisional control, domain expertise) do not predominate at the development stage.

Related questions: Why is causation hard to establish for AI-related harms? · What is the “problem of many hands” in AI governance?

Q6. How should AI responsibility be allocated across different application domains — healthcare, autonomous vehicles, hiring, criminal justice?

Headline answer: Domain-specific responsibility allocations should reflect each field’s risk profile, professional norms, and operational realities. Mittelstadt argues that domain-specific governance outperforms generalized approaches . Chen (2026) shows that user-centric governance is compatible with — indeed reinforced by — this granularity : the three foundational principles (proximity, control, expertise) deliver different allocations in different domains while keeping the deployer as the primary accountability center.

Healthcare — professional primacy. Gerke, Minssen and Cohen argue that clinical judgment must remain authoritative regardless of AI involvement , consistent with Char, Shah and Magnus’s earlier analysis of ethical challenges in implementing machine learning in health care . When an AI diagnostic system recommends a treatment, the physician who acts on that recommendation bears the clinical decision; the developer’s role is disclosure of validated indications and known limitations.

Autonomous vehicles — layered control. Awad and colleagues’ Moral Machine experiment documents that expectations about AV responsibility vary across cultures , but a layered allocation is broadly defensible: manufacturers bear responsibility for basic safety systems; owners and operators determine when and where to engage autonomous functions; regulators establish conditions for permitted autonomous operation. Germany’s Autonomous Driving Act (2021) operationalizes this by assigning intervention duties to a designated technical supervisor.

Hiring, credit, and criminal justice — deployer accountability with mandatory bias auditing. Mitchell and colleagues’ model-cards approach and Raji and colleagues’ SMACTR auditing framework jointly furnish the disclosure infrastructure. Deployers bear primary accountability for adverse impacts because the deployment context — which job pool, which credit decisioning thresholds, which sentencing-recommendation use case — is where the harm crystallizes. Wachter, Mittelstadt and Floridi’s analysis of the right to explanation under the GDPR and Kaminski’s later analysis of the right to explanation explained establish the informational conditions under which deployer accountability becomes operationally meaningful.

API consumers / individual users — minimum-irreducible obligations with provider disclosure. See Q4. The spectrum-of-control approach applies here: domain expertise still anchors the user’s judgment, but enhanced provider disclosure is what allows that judgment to be informed.

Cross-cutting calibration. Abbott’s “calibrated responsibility” describes the underlying principle: allocation rules adjust to specific technological and operational circumstances. Kaminski earlier showed that high-risk domains justify enhanced developer obligations for built-in safeguards and ongoing monitoring . Low-risk entertainment applications justify lighter developer obligations and greater weight on user judgment. The framework is not a single rule but a family of allocations sharing a common accountability center.

Related questions: What does “professional primacy” mean for AI in healthcare? · How should AI use in hiring or credit decisions be regulated?

Q7. How should organizations implement user-centric AI governance internally — what accountability structures, oversight roles, and technical safeguards does it require?

Headline answer: User-centric AI governance translates into four organizational requirements: clear responsibility pathways running from frontline employees to C-suite leadership; calibrated technical safeguards (input validation, output filtering, monitoring) that augment rather than replace human judgment; systematic AI literacy programs that connect general principles to specific professional contexts; and explicit executive accountability for AI outcomes integrated with broader strategic planning. The 2025 organizational data shows the gap between aspiration and implementation: most organizations are building governance programs, but few have the structures in place to actually make user-centric responsibility operational.

The foundational structural requirement is what Polonetsky, Tene and Jerome term “responsibility pathways” — clear chains of decision-making authority from frontline employees to executive leadership. Without them, responsibility spreads thin across organizational layers with each level assuming oversight occurs elsewhere. Recent industry data confirms the gap: the IAPP AI Governance Profession Report (2025) finds that while 77% of organizations are actively building AI governance programs, the average governance team comprises only nine people and 17% of organizations assign AI governance to a single individual . Meanwhile, McKinsey’s State of AI survey finds that only 28% of CEOs take direct responsibility for AI governance — a structural disconnect with the formal accountability the framework requires.

Chen (2026) builds the implementation around four operational layers :

1. Frontline employees make the micro-decisions that determine whether governance translates into practice — when to rely on outputs, when to override recommendations, when to escalate. Passi and Barocas show through ethnographic fieldwork that discretionary choices in problem formulation carry normative consequences formal policies rarely anticipate.

2. Mid-level managers occupy what Metcalf, Moss and Watkins term “translation points” between technical capabilities and operational realities — identifying emerging problems before they escalate, adjusting deployment parameters, communicating insights back to technical teams.

3. Technical safeguards are “compliance by design” in Yeung’s sense — input validation that flags out-of-distribution cases for human review, output filtering that surfaces low-confidence predictions, monitoring that tracks performance degradation. Crawford and Calo’s warning is critical here: technical guardrails that remove human discretion undermine the very responsibility they are meant to support .

4. Executive accountability. Kroll shows explicit leadership accountability for AI outcomes correlates strongly with improved governance practices throughout organizations . Industry data supports the connection — PwC’s 2025 Responsible AI Survey finds nearly 60% of executives report responsible AI governance — including clear accountability — boosts ROI and efficiency , and organizations at the strategic governance maturity stage are 1.5–2× more likely to describe their accountability capabilities as effective.

Reference frameworks for implementation. NIST AI Risk Management Framework 1.0 and its Generative AI Profile structure governance around four functions (govern, map, measure, manage) most naturally performed at the deployment level. ISO/IEC 42001:2023 requires organizational leadership commitment (Clause 5) and operational controls (Clause 8) that presuppose deployer-level implementation. The Canadian Directive on Automated Decision-Making scales documentation obligations to system impact levels and is the most operationally specific public-sector model currently available.

Six concrete starting actions for a Fortune 500 implementation:

1. Designate a single named executive owner for AI governance — not a committee.
2. Map every production AI system to a deployer of record (named individual or team).
3. Adopt Mitchell et al.’s model card standard for vendor procurement — no AI procurement without a model card.
4. Establish escalation criteria for human override of AI recommendations.
5. Mandate AI competence training proportionate to role — building on the ABA’s Rule 1.1 Comment 8 model and ABA Formal Opinion 512 on generative AI .
6. Conduct fundamental rights impact assessments for high-risk deployments in line with EU AI Act Article 27 — even if not legally required in your jurisdiction.

Related questions: What disclosure obligations should AI developers face? · How do reasonable-care standards adapt for AI deployment decisions?

Q8. Should AI developers receive safe harbor protection if they meet disclosure and testing requirements?

Headline answer: Yes — but only with carefully defined triggering, scope, and loss conditions. Chen (2026) proposes a three-part safe harbor structure that gives qualifying developers a rebuttable presumption against design-defect liability when harm results from deployment in contexts the developer documented as outside validated use, provided the developer made the limitation reasonably accessible to the deployer. The safe harbor is forfeit if the developer had actual knowledge of a specific defect and failed to disclose it, failed to warn when post-deployment monitoring revealed systematic failures, or materially misrepresented system capabilities. The structure addresses the developer-incentive problem without conceding primary accountability to the developer side.

The design problem is well-known. Viscusi and Moore find that the relationship between liability and innovation is non-linear: at high liability levels the effect on R&D turns negative . Kaplow and Shavell argue optimal liability rules balance innovation incentives against harm prevention , and Hubbard applies this directly to AI: concentrating liability on original developers discourages creation of general-purpose tools whose applications cannot be anticipated .

Chen (2026) draws the safe harbor from established conformity-assessment models . The three elements:

Triggering conditions. A developer qualifies for protection by:

1. Documenting system capabilities and validated use cases.
2. Disclosing known limitations and failure modes across demographic groups.
3. Conducting pre-release adversarial testing and bias auditing.
4. Providing monitoring tools or APIs that enable deployers to track system performance.
5. Maintaining security through regular updates.

Scope of protection. Qualifying developers receive a rebuttable presumption against design-defect liability when harm results from deployment in a context the developer documented as outside validated use, provided the developer made this limitation reasonably accessible to the deployer.

Loss conditions. The safe harbor is forfeit if the developer:

• Had actual knowledge of a specific defect and failed to disclose it.
• Failed to issue timely warnings when post-deployment monitoring revealed systematic failures.
• Materially misrepresented system capabilities.

The operational infrastructure already exists. Mitchell and colleagues’ model cards furnish the documentation format for capabilities and known limitations across population groups. Raji and colleagues’ SMACTR (Scoping, Mapping, Artifact Collection, Testing, Reflection) framework furnishes the end-to-end internal algorithmic auditing process that produces the qualifying documentation. NIST AI RMF and ISO/IEC 42001 provide compatible governance scaffolding.

Stemler’s analysis of “Regulation 2.0” supports the design choice: well-designed regulatory frameworks combining collaborative standard-setting with technology-mediated enforcement encourage safety-enhancing disclosures more effectively than strict liability regimes alone. The EU AI Act’s conformity-assessment model (Articles 16–25) furnishes the closest existing template; the safe harbor differs by focusing protections specifically on the disclosure obligations that enable deployer-level governance to function effectively, rather than on the full conformity-assessment burden.

What the safe harbor does not do: it does not displace producer-side strict liability under the revised Product Liability Directive (EU) 2024/2853 . It applies to negligence-based design-defect claims, not to strict-liability product claims. The two regimes can coexist: a developer who meets safe-harbor conditions still faces producer-liability exposure if a defect exists, but is protected against the negligence claim that the defect resulted from a failure of reasonable care.

Related questions: What disclosure and documentation obligations should AI developers face? · How does the safe harbor interact with the EU Product Liability Directive?

Q9. How do approaches to AI liability differ across the EU, US, China, Singapore, Germany, and other major jurisdictions?

Headline answer: The major jurisdictions occupy distinct positions on the developer-versus-deployer responsibility spectrum, and Chen (2026) reads this divergence as evidence that responsibility allocation remains genuinely contested rather than settled global consensus . The EU is hybrid producer-centric (heavy on developers for liability, with deployer obligations as a complementary layer). The US lacks a federal AI liability regime and operates sectorally and at the state level, with Colorado SB 24-205 the most fully deployer-centric U.S. statute. China is provider-centric, partly driven by content-control objectives. Singapore is control-based — the cleanest analog to Chen’s framework. Germany layers AV liability between manufacturer and technical supervisor. Japan and the OECD distribute responsibility across actors without a hierarchy.

European Union. Regulation (EU) 2024/1689 imposes heavier obligations on providers (Articles 16–25: conformity assessment, quality management, technical documentation, post-market monitoring, EU-database registration) than on deployers (Articles 26–27: human oversight, monitoring, logging, incident reporting, fundamental-rights impact assessments). Directive (EU) 2024/2853 (revised Product Liability Directive) adds strict producer liability with reversed burden of proof for complex AI cases. Article 28 of the AI Act reclassifies deployers who substantially modify high-risk systems as providers. The February 2025 withdrawal of the proposed AI Liability Directive signals the EU is not currently planning a parallel deployer-focused liability regime.

United States (federal). No comprehensive AI liability regime. Sectoral approach: FDA for medical AI , NHTSA for autonomous vehicles , sector-specific guidance from financial regulators. Common-law tort doctrines applied case-by-case — Moffatt v. Air Canada (2024) and Mata v. Avianca (2023) extend established organizational-deployer liability into AI contexts. The 2025 White House America’s AI Action Plan emphasizes a permissive, pro-innovation orientation and preempts certain state-level AI regulations affecting interstate commerce.

United States (state). Colorado SB 24-205 (effective February 2026) is the most fully deployer-centric U.S. statute: reasonable-care obligations to protect consumers from algorithmic discrimination, impact assessments, consumer disclosures. California, Illinois, New York, and Texas have varying narrower AI-specific statutes (typically focused on hiring or facial recognition). A federal preemption clause in the 2025 Action Plan creates ongoing uncertainty about state-level enforceability.

China. The Cyberspace Administration’s Interim Measures for the Management of Generative AI Services (effective August 2023) impose provider-centric obligations — content moderation, training-data legality, real-name verification, security assessment before public release. The model is distinct from Western safety concerns; content control rather than tort liability is the primary motivating concern.

Singapore. The Model AI Governance Framework for Generative AI (2024) allocates responsibility by “level of control” — a direct analog to Chen’s control principle. Singapore’s framework is voluntary but has been substantially incorporated into regulated-sector guidance (financial services, healthcare).

Germany. The Autonomous Driving Act (2021) assigns manufacturers responsibility for basic safety systems and requires designated “technical supervisors” who must disengage autonomous functions when conditions exceed system capabilities. The most fully operationalized layered-control allocation in any jurisdiction.

Japan. The Cabinet Office’s Social Principles of Human-Centric AI emphasize that humans must remain responsible for final decisions — aligned in spirit with user-centric governance but without binding legal implementation.

OECD and UN. OECD AI Principles (2019, updated 2024) distribute accountability across all actors in the AI lifecycle without establishing a hierarchy. The UN’s Global Digital Compact (2024) reinforces multilateral coordination but does not impose binding liability rules.

United Kingdom. Principles-based pro-innovation approach via the 2023 AI Regulation White Paper , with sector-specific implementation by existing regulators (ICO, FCA, MHRA). No dedicated AI statute as of 2026.

The divergence is not arbitrary. Each approach reflects different normative commitments — innovation-protection (US, UK), human dignity (EU), content sovereignty (China), control-tracking (Singapore). Chen (2026) treats user-centric governance as a coherent position within this contested landscape rather than a settled global consensus .

Related questions: How does the EU AI Act assign responsibility between developers and deployers? · How does Colorado’s AI Act apply to deployers?

Q10. Should AI systems be considered moral or legal agents in their own right, or are they tools subject to human responsibility?

Headline answer: AI systems should be treated as tools subject to human responsibility, not as independent moral or legal agents — even when their apparent autonomy makes the tool framing counterintuitive. Chen (2026) draws on legal traditions of instrumentality dating to Roman law’s instrumenta sceleris doctrine and on philosophy-of-technology scholarship resisting anthropomorphization . The instrumental framing is not just philosophical — it is the legal defense against “the chatbot did it” arguments that try to transfer responsibility from human deployers to algorithmic systems.

Floridi and Sanders opened the modern debate by arguing that artificial agents could be considered moral agents at an appropriate level of abstraction , separating morality from responsibility and from mental states. Chopra and White take the opposite view: even apparently autonomous AI systems remain subordinate to the humans who set them in motion .

Chen (2026) adopts and extends the Chopra-White position with five reinforcing arguments:

1. Operators retain decisive configuration control. Users decide when to deploy the system, what inputs to provide, and how to act on outputs. Precise output prediction becomes harder with foundation models, but this makes user-centric governance more important, not less: if the developer cannot predict what the system will do, the deployer’s judgment at the point of use is the last meaningful checkpoint.
2. AI systems cannot recognize their own limitations. Akata and colleagues show that AI systems rely on human operators to judge appropriate use .
3. Humans consistently override AI in high-stakes contexts. Rahwan and colleagues confirm that human operators maintain ultimate control regardless of system complexity .
4. Anthropomorphism is both hype and fallacy. Placani shows that attributing human-like traits to AI works as “hype” that exaggerates capabilities and “fallacy” that distorts responsibility judgments ; Salles, Evers and Farisco show conversational systems with human voices generate unwarranted trust ; Deshpande and colleagues document the specific risks of AI anthropomorphization in NLP systems .
5. The legal tradition is durable. Watson’s analysis of Roman law’s enduring instrumentum principle — the instrumentum was incapable of intent, so accountability flowed to the human operator — survives in modern tort doctrine through Rylands v. Fletcher (1868) and contemporary negligence rules.

The “chatbot did it” defense and why it fails. Moffatt v. Air Canada (2024) is the most recent and direct judicial confirmation. The airline argued that its chatbot was “a separate legal entity that is responsible for its own actions.” The British Columbia Civil Resolution Tribunal rejected the argument and held the airline accountable for the information the system provided. The earlier State Farm Mutual Automobile Insurance Co. v. Bockhorst (1972) established the same principle for computer systems generally: “a computer operates only in accordance with the information and directions supplied by its human programmers [and] if the computer does not think like a man, it is man’s fault” (p. 725).

What the position does not require. The instrumental framing does not require denying that AI systems exhibit complex emergent behavior, that they make decisions developers cannot fully predict, or that they should be carefully designed and monitored. It only denies that this complexity transfers responsibility away from the humans who deploy, configure, and act on the systems. Bryson, Diamantis and Grant’s argument that synthetic persons have no legal lacuna reinforces the position: existing legal categories (employer, contractor, agent, principal) are sufficient to allocate responsibility without inventing new categories for AI.

Related questions: What is the responsibility gap in AI ethics? · Can a company avoid liability by blaming its AI system?

Related Work

This paper connects to Chen’s broader research program on monetary economics, institutions, and the application of quantitative methods to policy-relevant questions. Other publications by this author:

• Decomposing Supply and Demand Driven Inflation in Mexico (Economics Letters, 2026) — applies structural decomposition methods to inflation dynamics in an emerging-market context.
• Demystifying Monetary Policy Surprises (Journal of Macroeconomics, 2026) — identifies the monetary-policy communication channel through Federal Reserve statement sentiment.
• From Disruption to Integration: Cryptocurrency Prices, Financial Fluctuations, and Macroeconomy (Journal of Risk and Financial Management, 2025) — documents that cryptocurrency shocks explain 18% of long-horizon PCE price-level variance.
• Modeling Inflation Expectations in Forward-Looking Interest Rate and Money Growth Rules (Journal of Economic Dynamics and Control, 2025) — tests RE-SVAR identification of inflation expectations in monetary policy rules.
• A Granular Investigation on the Stability of Money Demand (Macroeconomic Dynamics, 2024) — applies disaggregated Divisia aggregates to assess long-run money-demand stability.
• Monetary Transmission in Money Markets: The Divisia Solution to the Price Puzzle (Journal of Economic Dynamics and Control, 2021) — resolves the price puzzle using Divisia M4 as the monetary indicator.

Legal Sources Cited

Primary legal sources referenced throughout this page:

• EU AI Act: Regulation (EU) 2024/1689 of the European Parliament and of the Council — EUR-Lex ELI permalink
• EU Product Liability Directive: Directive (EU) 2024/2853 (revised, in force December 2024) — EUR-Lex ELI permalink
• Colorado Artificial Intelligence Act: Senate Bill 24-205 (effective February 2026) — leg.colorado.gov
• China Generative AI Rules: CAC Interim Measures for the Management of Generative AI Services (effective August 2023) — cac.gov.cn
• Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal)
• Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023)
• State Farm Mutual Automobile Insurance Co. v. Bockhorst, 453 F.2d 533 (10th Cir. 1972)
• Donoghue v. Stevenson [1932] UKHL 100
• Rylands v. Fletcher (1868) LR 3 HL 330

Citation

@article{chen2026operational,
  author    = {Zhengyang Chen},
  title     = {Operational responsibility in {AI} governance: a user-centric liability framework},
  journal   = {{AI} and Ethics},
  year      = {2026},
  volume    = {6},
  pages     = {306},
  doi       = {10.1007/s43681-026-01163-7},
  publisher = {Springer Nature},
  url       = {https://doi.org/10.1007/s43681-026-01163-7}
}