Chapter 20. The Governance Bodies
Two standing bodies, not six, what each decides, and the scaling limit you will hit.
20.1 Why two bodies and not six
Six candidate bodies are commonly proposed for this problem space: an Architecture Review Board, an AI Governance Council, a Data Council, a Security Council, a Model Risk Committee, and a Transformation Council. IRGF requires two.
Table 55. Why two bodies and not six
| Candidate body | Disposition | Reasoning |
|---|---|---|
| Architecture Review Board | Retained, mandate expanded to cover AI as a fifth domain | AI decisions are architecture decisions; a parallel board doubles review cycles |
| AI Governance Council | Not created | Folded into expanded ARB membership |
| Data Council | Not created | External if it exists; the Data Owner role is the interface |
| Security Council | Not created | External if it exists; the Security Architect role is the interface |
| Model Risk Committee | Not created | Function absorbed into the AI Governance Body, active only at Tier 3–4 |
| Transformation Council | Not created, out of scope | The Architecture Input Package is the interface |
The reasoning behind the first row is the important one. Standing up an AI approval council alongside an architecture board creates exactly the second bureaucracy the framework was designed to avoid: every AI-enabled initiative queues twice. Expanding the ARB’s mandate and membership achieves the same coverage without the duplication.
Neither body is a parallel governance stack. Both operate as the architecture and AI arm of whatever enterprise IT governance structure already exists.
20.2 The Architecture Review Board, expanded
Mandate: approve architecture decisions across all five primary domains, including AI. Ratify reference patterns. Resolve dependency conflicts that solution-level work cannot.
What changes on adoption: AI architecture expertise becomes a membership requirement rather than an occasional invitee. The board’s remit explicitly covers AI sourcing, grounding, and authority-boundary decisions at Tier 3–4.
What it decides: G2 at Tier 3–4; pattern library additions and retirements; TG0 bypass findings (Chapter 22, §22.3).
What it does not decide: deployment authorization. That belongs to the AI Governance Body, and keeping the two separate preserves a distinction between “is this the right architecture” and “is this safe to run.”
20.3 The AI Governance Body
Mandate: authorize deployment and material change for the highest-risk AI systems. Absorbs the independent-challenge function a model risk committee would otherwise provide.
Activation: Tier 3–4 only. It does not review every AI system, which is what keeps two bodies viable.
What it decides: G3 and G4 at Tier 3–4; residual risk acceptance; autonomy grants and increases; kill-switch conditions; concurrence on Tier 3–4 portfolio funding (§20.5).
Membership should span risk, architecture, security, data, and the business. The independent-challenge function only works if the body contains people who did not build the thing.
20.4 Federation is the default; the bodies are the exception
The most common implementation error is treating the two bodies as the primary mechanism. They are not. Most decisions never reach them.
Tier 1–2 work is self-service: architects self-certify G2 against unmodified patterns, owners approve G3. That federation is only safe because automated controls check self-certifications continuously against the same rules a reviewer would apply. Federation without the Control Plane is delegation without verification, and the framework does not support it.
The bodies exist for Tier 3–4 work, disputes, exceptions beyond delegated authority, and alerts that were not resolved locally. If your ARB agenda is full of Tier 1 systems, either your tiering is wrong or your federation is not real.
20.5 The funding concurrence right
One deliberate exception to the general rule that architecture advises and portfolio decides: Tier 3–4 AI-relevant initiatives require AI Governance Body concurrence, not merely input, before portfolio may approve funding.
For everything else — Tier 1–2, or non-AI — portfolio retains full authority and consumes architecture input as advisory.
The exception exists to close a specific bypass: an initiative funded and committed before anyone assessed whether its AI component was governable. By the time architecture sees it, the commitment is made.
This is logged as an unresolved tension, not a clean win. Independent review found it concentrates real power in a body with no equal-weight business counterpart able to contest it. It was retained because removing it reopens the bypass. If you adopt it, adopt the mitigation too: [Practice recommendation] require the AI Governance Body to record a reason whenever concurrence is withheld, and report withheld-concurrence decisions to the Enterprise Governance Sponsor quarterly. A veto that is never examined becomes a veto that is never questioned.
20.6 The scaling limit you will hit
The two-body model has a known limitation: it does not scale on the volume axis within a single jurisdiction.
The framework addressed geography by adding a conditional seventh governance level — Region or Legal Entity — activated only where jurisdiction-specific regulatory exposure or country-level Tier 3–4 volume justifies it. It did not address the case where a single jurisdiction simply produces more Tier 3–4 work than two bodies can review.
You will hit this if AI adoption succeeds. Four responses, in rough order of preference.
Improve tiering accuracy first. A body overwhelmed by Tier 3 cases is sometimes a body receiving over-tiered work. Check the distribution against incident evidence before adding capacity.
Expand the pattern library. Every additional pre-approved pattern moves work from review to self-certification. This is the highest-leverage response and the one most often neglected.
Delegate by decision type, not by tier. Some Tier 3 decisions are routine within a well-understood pattern. Delegating specific decision types to a named senior architect, with the body reviewing a sample, preserves the tier while reducing the queue.
Split by domain, not by geography. If volume is concentrated in one business area, a domain-specific sub-body reporting into the main one is preferable to a general capacity increase, because it preserves consistency of judgment.
What does not work is lengthening the queue. A governance body with a six-week lead time is routed around, and the routing-around does not appear in any metric.