Chapter 31. Introducing IRGF to Delivery Teams

The framework’s adoption risk is not technical. It is that the people it governs conclude it is overhead.

31.1 The objections you will actually get

Six objections recur. Each has a legitimate core, and answering the legitimate part is more effective than defending the framework.

“This will slow us down.” Partly true and worth conceding. Tier 3–4 work will be slower, deliberately. Tier 1–2 work should be faster once patterns and self-certification are in place, and that is the claim to make and then evidence. What you must not do is promise overall speed improvement in month one, because the first quarter is slower for everyone.

“We already do this.” Often partly true. Most organizations have architecture review, some risk assessment, and some testing. The honest answer is that IRGF connects those rather than replacing them, and the specific thing that is usually missing is a single tier that drives all of them consistently. Ask the team to run the seventeen questions against one of their own systems; the gaps make the argument better than you can.

“Our system is low risk.” Frequently correct, and the framework agrees: Tier 1–2 is self-service. The response is not to argue but to run the scoring, because the scoring is what establishes the claim. A team that scores its own system honestly and lands at Tier 1 has just used the framework correctly.

“The gate will reject us.” Usually the fear is delay, not rejection. Publishing gate lead times and outcome distributions defuses this faster than reassurance does.

“We’re just piloting.” The most dangerous objection, because it sounds reasonable. Pilots reach production. The answer is the deployment-state model in Chapter 5: pilot is a state with an expiry, not an exemption.

“The vendor handles governance.” Common for procured AI and almost never accurate at the level the enterprise needs. The vendor governs their model; you govern its use in your context, including the decisions it influences and the data it processes.

31.2 What to do in the first ninety days

Make the first experience good. The first three teams through the process shape its reputation permanently. Over-support them: sit with them for the scoring, pre-review their ADR, and make sure the first gate runs to time.

Show a Tier 1 pass early. The most persuasive artifact is a system that went through the framework quickly because it was genuinely low risk. It demonstrates proportionality is real, which no amount of policy text achieves.

Publish lead times from the start. Uncertainty about how long governance takes causes more avoidance than the actual duration does.

Never let a gate be the first time a team hears about a requirement. If a gate rejects work for a requirement the team did not know existed, you have lost that team and everyone they talk to. The requirements belong in the intake conversation.

31.3 What to say about the framework’s status

You will be asked whether this is a standard. It is not, and the answer should be direct: IRGF is a designed framework that has been adversarially stress-tested but never deployed in a real organization, and it defers to the actual standards — NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894, COBIT, ISO/IEC 27001 — for the things those standards already cover.

That answer is stronger than a claim of authority, for two reasons. It is accurate, and accuracy survives the first person who checks. And it invites teams to treat the thresholds as adjustable, which is exactly right, because they are reasoned defaults awaiting your calibration data.

[Practice recommendation] Make the limitations register (Appendix A) available to delivery teams rather than restricting it to the governance function. A framework that publishes its own weaknesses attracts better challenge, and the challenge is how the thresholds get calibrated.

31.4 Signs adoption is going well

Table 80.

The last signal is the strongest. A framework nobody challenges is a framework nobody is really using.