Chapter 21. Roles, Decision Rights, and RACI
Who decides what, and the two role problems the framework has not solved.
21.1 The role catalogue
Table 56.
| Role | Accountable for | Key authority | Owns |
|---|---|---|---|
| Business Sponsor / Capability Owner | Business value delivered | Approve or reject use-case qualification | Use-Case Canvas, Capability Record |
| AI / Enterprise Architect | Architecture quality and pattern conformance | Self-certify Tier 1–2 G2; author ADRs | ADRs, pattern library |
| Data Owner | Data classification and lineage accuracy | Approve or reject data readiness | Data Lineage and Sensitivity Records |
| AI / System Owner | System behavior, conformance, retirement | Responsible for evidence at every gate | Configuration and change records |
| Risk and Compliance Lead | Risk scoring accuracy, control effectiveness | Assign and re-assign tier; countersign scores | Risk Classification Records, Control Matrix |
| Security Architect | Security posture of governed components | Consulted at all gates; can block on unresolved findings | Security control records |
| Procurement | Vendor due-diligence evidence | Consulted at S1–S2 for procured AI | Vendor evidence records |
| Architecture Review Board | Architecture conformance enterprise-wide | Approves Tier 3–4 G2; ratifies patterns | Approved pattern library |
| AI Governance Body | Deployment authorization quality at Tier 3–4 | Approves Tier 3–4 G3/G4; funding concurrence | Deployment authorization records |
| Enterprise Governance Sponsor | Framework integrity; cross-body conflict | Ratifies principles; resolves conflicts | Central principles |
| Transformation / PMO (external) | Portfolio delivery outcomes | Prioritization and funding | Portfolio roadmap (external) |
21.2 Decision rights by tier
Table 57.
| Decision | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| Approve architecture (G2) | Architect self-certifies | Architect self-certifies, ARB notified | ARB | ARB, Enterprise Sponsor briefed |
| Approve deployment (G3) | System Owner | System Owner, AI Governance Lead notified | AI Governance Body | AI Governance Body + Enterprise Sponsor |
| Approve a new foundation model for the enterprise list | Architect proposes, ARB ratifies — applies once, enterprise-wide, not per tier | |||
| Change a system’s risk tier | Risk Lead, self-service if downward or lateral | Risk Lead; AI Governance Body notified if upward | AI Governance Body | AI Governance Body + Enterprise Sponsor briefed |
| Authorize or increase agent autonomy | Not applicable; an increase re-triggers classification | AI Governance Body | AI Governance Body | AI Governance Body + Enterprise Sponsor |
| Approve an exception | System Owner, ≤ 90 days | AI Governance Lead, ≤ 90 days | AI Governance Body, ≤ 90 days, renewal requires re-justification | AI Governance Body + Enterprise Sponsor, ≤ 90 days, no auto-renewal |
| Retire a system (G5) | Owner + Data Owner | Owner + Data Owner | Adds AI Governance Lead | Adds AI Governance Body |
| Accept residual risk | System Owner | AI Governance Lead | AI Governance Body | AI Governance Body + Enterprise Sponsor |
The foundation-model row is deliberately not tier-differentiated. A model either joins the approved list or it does not; that decision is made once, centrally, not re-litigated by every use case that wants to use it.
21.3 The AI Build Lifecycle RACI
Table 58.
| Stage / Gate | Sponsor | Architect | Data Owner | System Owner | Risk Lead | Security | ARB | AI Gov Body |
|---|---|---|---|---|---|---|---|---|
| S0–S1 Opportunity, Qualification | R | C | C | — | I | — | — | I (T3–4) |
| S2 Risk Classification | C | C | C | — | A/R | C | — | I (T3–4) |
| G1 | A | C | I | — | R (T3–4) | — | — | C (T3–4) |
| S3 Architecture | I | A/R | C | C | I | C | C (T3–4) | — |
| S4 Data Readiness | I | C | A/R | C | I | C | — | — |
| G2 | I | R | R | C | C | C | A (T3–4) | — |
| S5 Build / Acquire | I | C | I | A/R | — | C | — | — |
| S6 Assurance | I | C | I | R | A | C | — | — |
| G3 | I | C | I | R (A at T1–2) | A (T3–4) | C | — | A (T3–4) |
| S7 Deployment Authorization | I | I | I | R | C | C | — | A (T3–4) |
| S8 Runtime and Monitoring | I | I | I | R | A | C | I | I (T3–4) |
| S9 Change | I | C | C | R | C | C | — | I (Major, T3–4) |
| G4 | I | C | C | R | A (T1–2) | C | C (T3–4) | A (T3–4) |
| S10 Retirement | I | I | A/R | R | C | I | — | C (T3–4) |
| G5 | I | I | A | R | C | I | — | C (T3–4) |
R responsible, A accountable, C consulted, I informed. Tier qualifiers make involvement conditional. Blanks indicate no defined involvement.
A deliberate design check is visible in this table: no role is accountable at more than roughly a third of stages, and the Enterprise Governance Sponsor is accountable nowhere. Making every senior leader accountable for everything is an anti-pattern the framework actively guards against.
21.4 Two unsolved role problems
Security Architect is consulted, never accountable. Across the entire RACI, the Security Architect advises and can block on unresolved findings, but is never the accountable party. Independent review found this under-weighted relative to security’s actual role in agent and coding-agent failure modes, and it remains an open gap.
[Practice recommendation] Elevate Security Architect to co-accountable with the Risk Lead at G3 for any system with agentic capability or external exposure. This departs from the specification, and you should record it as a local variation. The framework’s own limitations register flags this as a gap worth closing; closing it locally is defensible.
Procurement arrives late in most organizations. The role is named as consulted at S1–S2, but in practice purchasing decisions for AI-embedded software are frequently made outside the technology function entirely. Naming the role does not create the routing. [Practice recommendation] Add an AI-content question to the standard procurement intake and route any positive answer to S0, regardless of contract value. Value thresholds are the wrong filter, because embedded AI arrives in inexpensive software.