Question 1

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

Accepted 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. Chen (2026) advances this user-centric position on three legal-doctrinal grounds: proximity (duty of care attaches to actors closest to harm), control (agency law assigns responsibility to those with decisional authority), and expertise (professional liability tracks specialized knowledge). The position synthesizes Rachum-Twaig (2020) and Kingston (2016) against the developer-centric position of Scherer (2016) and Chinen (2016). Recent decisions — Moffatt v. Air Canada (2024) and Mata v. Avianca (2023) — confirm courts are treating AI as an instrument whose human deployers bear responsibility for its use.

Question 2

What is the responsibility gap in AI ethics, and can it be resolved?

Accepted Answer

The 'responsibility gap' — originally Matthias's (2004) claim that learning automata create situations where no human can fairly be held 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: the deployment decision. Even when internal system behavior cannot be traced to design choices, the human or organization that activated, configured, and acted upon the system remains identifiable and answerable. Santoni de Sio and Mecacci (2021) refine the gap into four interconnected problems — culpability, moral accountability, public accountability, and active responsibility — and Santoni de Sio and van den Hoven (2018) establish that meaningful human control requires both 'tracking' and 'tracing.' User-centric governance directly satisfies tracing by treating the deployer as the primary answer-bearer, while developer obligations function as enabling infrastructure.

Question 3

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

Accepted Answer

The EU AI Act (Regulation (EU) 2024/1689) imposes heavier obligations on providers (developers) than on deployers in its core architecture: providers bear Articles 16–25 obligations (conformity assessment, quality management, technical documentation, post-market monitoring, EU-database registration) while deployers of high-risk systems bear Articles 26–27 obligations (human oversight, monitoring, logging, incident reporting, fundamental-rights impact assessments). Article 28 reclassifies a deployer who substantially modifies a high-risk system or changes its intended purpose as a provider. Chen (2026) reads this architecture as provider-centric in primary burden but treats deployer obligations as the underdeveloped layer where operational governance is most needed. The revised Product Liability Directive (EU) 2024/2853 adds strict producer liability with reversed burden of proof for complex AI cases. The withdrawn AI Liability Directive (February 2025) signals the EU is not currently layering a parallel deployer regime. Chen positions user-centric governance as strengthening the deployer-obligations layer within, not against, producer liability.

Question 4

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

Accepted Answer

Through a spectrum-of-control approach. Chen (2026) calibrates deployer obligations to actual control: full enterprise deployments carry the strongest accountability; fine-tuned managed services carry intermediate validation, monitoring, and human-oversight obligations; raw-API consumption carries minimum but irreducible obligations (output verification, human-in-the-loop for high-stakes decisions, evidence-based provider selection). Provider disclosure obligations move in the opposite direction: the less control deployers exercise, the more information providers must furnish about capabilities, limitations, and known failure modes. Mitchell and colleagues' model cards and Raji and colleagues' SMACTR auditing framework are the operational vehicles. The EU AI Act's Article 28 substantial-modification trigger marks where on the spectrum primary accountability shifts from deployer to provider. The framework directly addresses Burrell's (2016) opacity challenge and Crawford and Calo's (2016) blind-spot concern without abandoning user-centric governance.

Question 5

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

Accepted Answer

Three categories of limitation. First, an attribution problem: Burrell (2016) documents multi-layered opacity in machine learning, and Bathaee (2018) identifies the paradox that more sophisticated systems are harder to causally link to specific design choices. Second, a definitional problem: Maas (2023) finds AI definitions across regulatory systems uniformly fail basic operationalisability tests. Third, an innovation problem: Viscusi and Moore (1993) show that the relationship between liability and innovation is non-linear — at high liability levels the effect turns negative, depressing beneficial innovation. Beyond these, the 'problem of many hands' (Nissenbaum 1994) means distributed causation does not have a single source-of-design solution. Chen (2026) does not deny developer obligations — they function as enabling infrastructure for deployer accountability — but argues that the conditions justifying primary accountability (proximity, control, expertise) do not predominate at the development stage.

Question 6

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

Accepted Answer

Domain-specific allocations should reflect each field's risk profile, professional norms, and operational realities, while keeping the deployer as the primary accountability center. Chen (2026) shows the three foundational principles (proximity, control, expertise) deliver different allocations in different domains. In healthcare, Gerke, Minssen and Cohen (2020) establish 'professional primacy' — clinical judgment authoritative regardless of AI involvement. In autonomous vehicles, a layered allocation gives manufacturers responsibility for basic safety, owners and operators for engagement decisions, regulators for permitted-operation conditions; Germany's Autonomous Driving Act (2021) operationalizes this through technical-supervisor intervention duties. In hiring, credit, and criminal justice, deployer accountability with mandatory bias auditing — via Mitchell et al.'s (2019) model cards and Raji et al.'s (2020) SMACTR auditing — supplies the disclosure infrastructure. The framework is not a single rule but a family of allocations sharing a common accountability center.

Question 7

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

Accepted Answer

User-centric AI governance translates into four organizational requirements: clear responsibility pathways from frontline to C-suite, calibrated technical safeguards that augment rather than replace human judgment, systematic AI literacy programs, and explicit executive accountability. Chen (2026) builds the implementation around four layers: frontline employees making micro-decisions (output reliance, override, escalation), mid-level managers serving as 'translation points' between technical capabilities and operational realities (Metcalf, Moss and Watkins 2021), technical safeguards as 'compliance by design' in Yeung's (2018) sense, and executive ownership that — per Kroll (2021) — correlates with improved practices throughout the organization. The 2025 IAPP AI Governance Profession Report finds 77% of organizations are building programs, but the average team is only nine people and 17% assign governance to a single individual — a structural disconnect with the formal accountability the framework requires. Reference frameworks for implementation: NIST AI RMF 1.0, ISO/IEC 42001:2023, and Mitchell et al.'s (2019) model cards for vendor procurement.

Question 8

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

Accepted 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 undocumented contexts. Triggering conditions: documented capabilities and validated use cases, disclosed limitations and failure modes across demographic groups, pre-release adversarial testing and bias auditing, monitoring tools for deployers, regular security updates. Loss conditions: actual knowledge of a defect without disclosure, failure to warn when monitoring reveals systematic failures, or material misrepresentation of capabilities. The design aligns with Viscusi and Moore's (1993) finding that liability and innovation have a non-linear relationship, Kaplow and Shavell's (2002) framework for balancing innovation incentives with harm prevention, and the EU AI Act's conformity-assessment model (Articles 16–25). The safe harbor applies to negligence-based design-defect claims; it does not displace strict producer liability under the revised Product Liability Directive 2024/2853.

Question 9

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

Accepted Answer

The major jurisdictions occupy distinct positions on the developer-versus-deployer responsibility spectrum. Chen (2026) reads this divergence as evidence that allocation remains genuinely contested rather than settled global consensus. The EU is hybrid producer-centric: heavy developer obligations under AI Act Articles 16–25 and strict producer liability under the revised Product Liability Directive, with deployer obligations (Articles 26–27) as a complementary layer. The US has no federal AI liability regime; Colorado SB 24-205 is the most fully deployer-centric U.S. statute. China is provider-centric under the CAC Interim Measures (2023), partly driven by content-control objectives distinct from Western safety concerns. Singapore's Model AI Governance Framework (2024) allocates by 'level of control' — a direct analog to Chen's control principle. Germany's Autonomous Driving Act (2021) layers manufacturer responsibility with technical-supervisor intervention duties. Japan's Social Principles emphasize human responsibility for final decisions. The OECD AI Principles (2019) distribute accountability across all actors without a hierarchy.

Question 10

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

Accepted 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 Roman law's instrumenta sceleris doctrine and on philosophy-of-technology scholarship resisting anthropomorphization. Although Floridi and Sanders (2004) opened the possibility that artificial agents could be moral agents at an appropriate level of abstraction, Chopra and White (2011) argue that even apparently autonomous AI remains subordinate to the humans who set it in motion. Five reinforcing arguments: operators retain decisive configuration control; AI systems cannot recognize their own limitations (Akata et al. 2020); humans consistently override AI in high-stakes contexts (Rahwan et al. 2019); anthropomorphism is both hype and fallacy (Placani 2024); the legal tradition is durable. The 'chatbot did it' defense was directly rejected in Moffatt v. Air Canada (2024), echoing State Farm v. Bockhorst (1972): 'if the computer does not think like a man, it is man's fault.'

Dimension	Developer-Centric Liability	Flat "Shared Responsibility"	User-Centric / Distributed Yet Centered (Chen 2026)
Core claim	Concentrate primary liability on those who build AI to incentivize safety at the source.	Responsibility is distributed across all ecosystem actors without a designated primary center.	Primary accountability rests with deployers; developer and ecosystem obligations function as enabling infrastructure.
Key references	Scherer (2016), Chinen (2016), Tutt (2017)	Mittelstadt et al. (2016), Taddeo & Floridi (2018), OECD (2019)	Rachum-Twaig (2020), Kingston (2016), Abbott (2018), Chen (2026)
Justification	Information asymmetry: developers know the system best; ex ante incentives steer design.	Many actors contribute causally; no single actor controls outcomes.	Three principles: proximity, control, expertise — each tracking established legal doctrines (tort, agency, professional liability).
Treatment of black-box / API cases	Strengthens the developer-liability argument (only they know what the system does).	Accountability dissipates further; no actor is clearly answerable.	Spectrum-of-control: deployer obligations intensify with control; provider disclosure intensifies as deployer control decreases (Chen 2026).
Empirical and doctrinal traction	Limited. Attribution problem (Bathaee 2018); non-linear innovation effects (Viscusi & Moore 1993).	Weak — "problem of many hands" (Nissenbaum 1994) with no rule for primary attribution.	Strong. Aligned with Moffatt v. Air Canada (2024), Mata v. Avianca (2023), ABA Model Rule 1.1 cmt. 8, AMA Augmented Intelligence policy, and EU AI Act Articles 26–28.
Regulatory compatibility	Partial — aligns with EU AI Act Articles 16–25 and the revised Product Liability Directive's strict producer liability.	Weak — does not provide a clear locus for enforcement.	Strong with deployer-side rules (EU AI Act Arts. 26–27; Colorado SB 24-205; Singapore Model AI Governance Framework); operates within, not against, producer-liability architectures.
Named concept	Developer-centric / source-of-design liability	Distributed responsibility (without center)	Operational responsibility framework · Distributed yet centered accountability · Spectrum-of-control deployer obligations (Chen 2026)

AI Governance | Robin Chen

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

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

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

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

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

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

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

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

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

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

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

Legal Sources Cited

Citation