How should decision rights, accountability, and liability be structured for…

Research Question

How should decision rights, accountability, and liability be structured for AI systems and low-code applications in enterprise environments, specifically, who should be empowered to approve new use cases, who owns system behaviour in production, how should formal Responsible-Accountable-Consulted-Informed (RACI) structures and escalation paths be defined, what separation of duties is required, and how should legal and operational liability boundaries be delineated across business, technology, and risk functions?

Findings

Executive Summary

• Decision rights for enterprise AI and low-code systems should be tiered by risk and boundary crossing, and production accountability should be split by lifecycle decision rather than assigned to one blanket "system owner."
• The minimum workable production model is a named business service owner accountable for justified use and human decisions taken on outputs, a named technology system owner accountable for runtime reliability and controlled change, and an independent risk or assurance function that can challenge, block, or escalate.
• Current legal liability is not determined by internal RACI charts alone, because the AI Liability Directive proposal was not adopted, the AI Act leaves existing remedies in place, and the current Product Liability Directive treats software and AI systems as products whose developers or providers can be manufacturers.
• The best governance artefact is therefore a package of three linked matrices, approval, lifecycle accountability, and escalation, with explicit stop authority, incident triggers, and senior review thresholds.

Key Findings

1. High confidence: Approval rights should be tiered so that bounded low-risk use cases can move under preapproved patterns with named business approval, medium-risk or cross-functional use cases need delegated domain approval with technology and risk concurrence, and high-risk or regulated use cases require enterprise committee or executive sign-off.
2. High confidence: No single actor can honestly own enterprise AI behaviour end to end, because business use decisions, runtime operation, and provider compliance are different obligations, so the accountable owner must be defined separately for each lifecycle decision.
3. High confidence: Production ownership means continuous monitoring, incident escalation, log retention, controlled change, remediation tracking, and decommissioning authority, not merely sponsoring the use case at launch.
4. High confidence: Effective separation of duties requires that the team building or configuring a system cannot also be the final independent approver or assurance reviewer, because prudential, resilience, and model-risk precedents all require independent challenge.
5. High confidence: Escalation paths should be trigger-based and include explicit stop or override authority for anomalies, harmful outputs, control failures, serious incidents, material changes, and provider or regulator notifications.
6. High confidence: Internal accountability maps do not displace external legal liability, because the AI Liability Directive proposal was not adopted, the AI Act preserves existing remedies, and the current Product Liability Directive applies no-fault defective-product liability to software and AI systems.
7. High confidence: In regulated entities, boards or management bodies remain ultimately accountable for the control framework itself even when day-to-day approvals and operations are delegated to business, technology, and risk teams.
8. Medium confidence: Standard RACI remains useful only if it is converted into a lifecycle matrix with named natural persons and explicit handoffs, because a static one-row "A" column hides the multi-surface reality of AI governance.

Assumptions

• None.

Analysis

• The strongest evidence came from sources that allocate responsibility directly, NIST for AI governance design, APRA and DORA for regulated operational-accountability patterns, and the AI Act for live provider and deployer duties.
• Legal-liability analysis was weighted toward current binding texts, so the withdrawn AI Liability Directive proposal was treated as context while the current AI Act and Product Liability Directive were treated as live allocation mechanisms.
• Model-risk and operational-resilience precedents were used to resolve the approval and independence questions because they already deal with complex systems that need expert build teams, independent challenge, and senior management accountability.

Risks, Gaps, and Uncertainties

• Public COBIT material did not expose the detailed governance-objective or RACI text, so COBIT influenced framing only at the framework level and not at the detailed matrix level.
• The European liability landscape may evolve again if the Commission later tables a new AI-specific civil-liability instrument, so the current liability guidance should be treated as correct for 2026 but not necessarily permanent.
• The exact threshold between bounded self-service and delegated approval still depends on the risk-tier framework in Q5, so the approval tiers are structurally strong but still need calibration thresholds.

Open Questions

• How should Q5's risk-tier framework define the exact boundary between bounded self-service and delegated approval for internal productivity agents?
• How should vendor contracts, indemnities, and insurance be structured once the vendor-constraints item is complete?
• How should human-in-the-loop requirements from Q9 differ by approval tier and by high-risk category?

sources

• [x] European Union (EU) AI Act, Regulation (EU) 2024/1689 — - canonical legal text for provider, deployer, documentation, logging, and post-market obligations
• [x] EU AI Act Service Desk, Article 9 — - current summary of provider risk-management obligations for high-risk AI systems
• [x] EU AI Act Service Desk, Article 12 — - current summary of logging and traceability obligations
• [x] EU AI Act Service Desk, Article 14 — - current summary of human-oversight obligations and stop or override rights
• [x] EU AI Act Service Desk, Article 26 — - current summary of deployer obligations, including monitoring, competent human oversight, log retention, and suspension of risky use
• [x] EU AI Act Service Desk, Article 72 — - current summary of provider post-market monitoring obligations
• [x] Proposal for an AI Liability Directive, COM(2022)496 — - historical proposal used only to describe the withdrawn approach to AI-specific civil-liability reform
• [x] European Commission 2025 Work Programme Annexes — - official Commission source showing that COM(2022)496 had no foreseeable agreement and would be reassessed rather than adopted as proposed
• [x] Directive (EU) 2024/2853 on liability for defective products — - current EU product-liability text confirming that software and AI systems can be products and that software developers or producers can be treated as manufacturers
• [x] APRA Prudential Standard CPS 230, Operational Risk Management — - prudential source for board accountability, senior-management roles, incident escalation, testing, and service-provider oversight
• [x] Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554 — - financial-sector source for management-body accountability, clear roles, audit, change control, and continuous framework review
• [x] Federal Reserve SR 26-2, Revised Guidance on Model Risk Management — - current official guidance that supersedes SR 11-7 and preserves the model-risk precedent for clear governance, independent challenge, and risk-based lifecycle review
• [x] NIST Artificial Intelligence (AI) Risk Management Framework (AI RMF) 1.0 — - foundational governance framework for AI risk management
• [x] NIST AI RMF Core — - authoritative subcategories for governance, accountability, roles, monitoring, and decommissioning
• [x] Control Objectives for Information and Related Technologies (COBIT) resources — - public evidence that COBIT remains a live enterprise-governance framework with AI-governance material, although the detailed RACI content is not publicly exposed on this page
• [x] Enterprise AI use-case routing frameworks — - prior completed repository work on three-lane intake routing, governance checkpoints, and escalation signals
• [x] Business-led low-code agent governance: conditions for durable value versus fragmentation in regulated environments — - prior completed repository work on bounded low-code governance and intake controls
• [x] What control-plane architecture is required to manage AI agents and low-code systems as distributed, semi-autonomous actors within enterprise environments? — - prior completed repository work on control-plane separation, policy propagation, and feedback loops
• [x] Enterprise AI platform operating models: organisational structure and ownership — - prior completed repository work on hub-and-spoke ownership and central governance roles