Chapter 3. Readiness
What must be true before IRGF can work, and how to find out in a week.
3.1 Five preconditions
IRGF assumes several things that are not universally present. Where a precondition is missing, adoption does not fail immediately; it fails about six months in, when a mechanism that depends on it produces nothing usable.
A functioning architecture review body. IRGF expands an existing ARB instead of creating one. If no body currently makes binding architecture decisions, you are standing up architecture governance and AI governance simultaneously, which is a materially larger program than adopting IRGF.
An accountable-owner convention. Every AI system needs exactly one named human owner at all times. Organizations that cannot name an owner for an existing production system will not be able to name one for a new one, and the “no orphaned systems” principle will be violated from the first week.
Some inventory of AI in production. You cannot risk-classify what you cannot enumerate. Most organizations discover during adoption that their AI footprint is substantially larger than recorded, largely because of AI features embedded in purchased software.
A risk function willing to countersign. Independent countersignature of risk scores is the single highest-leverage control in the framework. It requires a risk or compliance partner with capacity to review scores and authority to change them. Without that, self-scoring stands unverified and the framework’s most confirmed weakness goes unaddressed.
Executive tolerance for saying no. Gates that never reject anything are not gates. If the organization’s culture makes rejection or conditional approval unavailable in practice, IRGF becomes documentation overhead.
3.2 The one-week readiness assessment
Run this before committing to a roadmap. It is deliberately small, and the output is a decision about where to start rather than a maturity score.
Table 8. The one-week readiness assessment
| Day | Activity | Output |
|---|---|---|
| 1 | Enumerate AI systems in production, including vendor-embedded features. Ask procurement, not just engineering | Draft inventory, deliberately incomplete |
| 2 | For three systems spanning low and high consequence, attempt the seventeen questions (§1.5) | Gap list |
| 3 | Interview the ARB chair and a risk partner on capacity and appetite | Governance capacity note |
| 4 | Sample five recent architecture decisions. Check whether each records a rationale, an owner, and any risk view | Decision-record quality baseline |
| 5 | Identify which telemetry sources already exist and who owns them | Control Plane feasibility note |
Two findings from this week usually determine the shape of adoption. The first is how large the unrecorded AI footprint is; a large gap means retroactive classification becomes a program in its own right. The second is decision-record quality; poor records mean Part B’s gates will produce evidence nobody trusts, and remediating that comes before any Control Plane work.
3.3 Sizing the effort honestly
The research report is explicit that no cost, staffing, or service-level model exists for IRGF, and this handbook will not invent one. What can be said is structural rather than numeric.
The dominant recurring cost is risk classification and its countersignature, because it applies to every new initiative and re-triggers on every material change. The dominant one-off cost is retroactive classification of existing systems, which scales with the size of the unrecorded footprint found in §3.2. Control Plane work is usually the largest technical investment but can be deferred and staged; governance body time is the constraint most likely to bind first, and it binds on Tier 3–4 volume specifically.
Any figure you are given for FTE or turnaround time, including by a vendor, is an assertion until your own first two quarters produce data. Instrument the process from day one so that by month six you can replace assumptions with measurements. Chapter 29 sets out which measurements are worth taking.