Chapter 4. Running the AI Build Lifecycle
How the eleven stages and five gates fit together, how intensity scales with tier, and the sequencing rules that are commonly misread.
4.1 The shape of the lifecycle
Eleven stages, numbered S0 to S10. Five gates, G1 to G5, placed at the points where an accountable decision must be recorded, not at every stage boundary.
Table 9. The shape of the lifecycle
| Stage | Name | Core question | Gate that follows |
|---|---|---|---|
| S0 | Opportunity | Should this problem use AI at all? | — |
| S1 | Use-Case Qualification | Is there value, feasibility, and a data path? | G1 |
| S2 | Risk Classification | What tier does this carry? | G1 |
| S3 | Architecture Decision | What architecture delivers it, and does it conform to a pattern? | G2 |
| S4 | Data Readiness | Is the grounding data governed, traced, and classified? | G2 |
| S5 | Build / Configure / Acquire | Construct, integrate, or procure | — |
| S6 | AI Assurance | Does it perform as intended and as safely as its tier requires? | G3 |
| S7 | Deployment Authorization | Is it authorized, by whom, on what evidence? | G3 |
| S8 | Runtime Operation and Continuous Monitoring | Is it still behaving, compliant, and valuable? | — |
| S9 | Change | Has something changed enough to re-enter an earlier stage? | G4 |
| S10 | Retirement | Has it been decommissioned with evidence preserved? | G5 |
Three features of this structure are easy to miss and cause most sequencing disputes.
S8 is a concurrent state, not a stage you pass through. Runtime operation and monitoring begin at deployment and continue until retirement. They are deliberately not modeled as two sequential stages, because placing monitoring after operation reintroduces the periodic assumption the framework exists to remove.
S2 is not visited once. Risk classification has one identifiable first occurrence, but it re-triggers whenever a change plausibly moves a risk dimension, and whenever runtime evidence suggests the original tier was wrong. Risk travels with the system.
Loop-backs are structural, not exceptional. S8 can re-open S2, S6, or S9. S9 routes to S2, S3, S6, or S7 depending on change classification. A lifecycle diagram showing only forward arrows would misrepresent how the framework actually operates.
4.2 Where the gates sit and why there are five
The framework consolidated an illustrative eleven checkpoints into five gates. The consolidation criterion was specific: a gate exists where a distinct accountable decision must be recorded, not wherever a stage ends.
Table 10. Where the gates sit and why there are five
| Gate | Sits after | The decision being recorded |
|---|---|---|
| G1 | S1–S2 | Is this use case justified, and what tier does it provisionally carry? |
| G2 | S3–S4 | Is the architecture and its data foundation acceptable? |
| G3 | S6 | Is this authorized to run in production? |
| G4 | S9 | Does this change require re-authorization? |
| G5 | S10 | Is decommissioning complete and evidenced? |
Gates that were proposed and rejected are as informative as those retained. A separate “AI necessity” gate distinct from strategic alignment was rejected because it does not correspond to a decision anyone records separately; it is an entry condition on G1. A separate data-readiness gate was folded into G2 because architecture and data readiness are assessed against each other, and separating them produces two reviews that each lack half the context.
4.3 Intensity scales, procedure does not
The same five gates apply at every tier. What changes is who decides, how much evidence is required, and how much can be automated.
Table 11. Intensity scales, procedure does not
| Gate | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| G1 | Self-service, rule-based auto-approval possible | Self-service with notification | AI Governance Lead review | AI Governance Lead review |
| G2 | Architect self-certifies against unmodified pattern | Architect self-certifies, ARB notified | ARB decision | ARB decision, Enterprise Sponsor briefed |
| G3 | System Owner | System Owner, AI Governance Lead notified | AI Governance Body | AI Governance Body plus Enterprise Sponsor sign-off |
| G4 | Often bypassed (minor changes) | Scaled to post-change tier | AI Governance Body | AI Governance Body plus Enterprise Sponsor |
| G5 | Owner plus Data Owner | Owner plus Data Owner | Adds AI Governance Lead confirmation | Adds AI Governance Body |
G3 is the most sharply differentiated gate in the framework. At Tier 1 it is a single owner clicking approve against automated evidence checks. At Tier 4 it is an executive decision with board-level visibility. If your implementation makes G3 feel similar across tiers, the tiering is not doing its job.
4.4 What the five gates actually cost
This section exists because the framework’s own stress-testing produced an uncomfortable finding, and adopters who are not told about it form the wrong expectation.
Reducing eleven illustrative checkpoints to five gates reduced the number of labeled decision points more than it reduced the evidence teams must produce. Independent review characterized the consolidation as largely bundling. The evidence required at G2, for instance, is the union of what an architecture gate and a separate data gate would each have demanded; merging the reviews saved a meeting, not a document.
Two consequences follow for how you introduce IRGF.
Do not market it as lighter governance. Teams told to expect a lighter process and then asked for an ADR, a data lineage record, a pattern conformance result, and a risk score at a single gate will conclude the framework was oversold, and that impression is difficult to reverse.
Look for burden reduction where it is real. Genuine reduction comes from three places, none of which is gate consolidation: pattern-based self-certification at Tier 1–2, evidence-as-code capture of roughly two-thirds of the minimum evidence set, and the tier system keeping most work out of standing bodies entirely. Those are worth promising. Fewer gates is not.
[Practice recommendation] Track evidence-production time per gate from the first month, separated by tier. It is the only way to know whether your implementation is achieving proportionality or simply relabeling a uniform process.
4.5 Governance weight by build type
The eleven stages apply to every AI build type, but the weight of each stage differs sharply. Applying identical rigor to a vendor-embedded feature and a multi-agent system would breach risk proportionality as surely as under-governing the latter.
Table 12. Governance weight by build type
| Build type | S3 weight | S4 weight | Distinguishing concern |
|---|---|---|---|
| Traditional ML / predictive | Moderate | High | Training data governance; well covered by existing model-risk practice |
| External foundation model API | High | Moderate | Vendor concentration; what leaves the enterprise boundary |
| General-purpose generative AI | High | Moderate | Non-determinism; guardrail configuration |
| Retrieval-augmented generation | High | High | Grounding lineage is the dominant concern |
| Fine-tuned models | High | High | Training-data governance; treated as a major change |
| Copilots (human-paired) | Moderate | Moderate | Placement and usability of the oversight point |
| Single tool-using agent | High | Moderate–High | Authority and permission boundary |
| Multi-agent systems | Highest | High | Inter-agent delegation; weakest standards coverage |
| Vendor-embedded AI features | Low | Low–Moderate | Risk of being governed as a feature toggle |
The last row deserves specific attention. Because S3 to S5 are light for embedded vendor AI, there is a standing temptation to skip S2 entirely on the reasoning that it is just a purchased feature. S2 applies to every build type without exception. A vendor feature that influences credit decisions carries the risk of a credit decision system regardless of how it was acquired. Chapter 28 treats this as a named anti-pattern because it recurs reliably.