Picture a team that wants a model to summarise support tickets. The governed path starts with a form. The team hunts for whoever approves vendors. Does the vendor keep the data? Nobody knows. The next committee slot is weeks away.
The workaround takes an afternoon. An engineer buys an API key on a company card and calls the model directly. The demo works by Friday. By the time anyone asks where the tickets went, it has users.
The team did what people do. It took the shorter path.
You can ban personal keys, or make the governed path the shorter one. Which do you do first? Write your answer down.
The move
- Race one system. Take one real system and the shortcut your teams take most, from Step 5. List every step and every wait on both paths. A wait is time spent on someone else: a reply, a ticket, a meeting slot.
- Pave the common case. Offer pre-approved patterns: an approved model behind an approved endpoint, a credential issued from the register entry, and a repository template with the pipeline built in.
- Put the rules in the pipeline. Any check a rule can make runs on every change and blocks the release when it fails.
- Let the build write the evidence. The pipeline produces the evaluation report, the gate result and the approval record.
The guide’s call: make the safe way the easy way, and enforce it in the pipeline, not in a meeting. People take the short path. Make the safe path the short one, and put its rules where they run on every change, whoever is in the room.
Keep the meeting where a decision needs judgement. A pipeline can show that evidence exists. It can’t decide that a risk is acceptable. T1 and T2 systems still get approval and independent validation from outside the team, and every exception goes to its approver. The road clears the waits around those decisions. The decisions stay with people.
Most of this step builds the first of the guide’s two kinds of safety: the wrong move made impossible by construction. The second kind, caught early and cheap to recover, is Step 7’s.
Your call. Write down the shortcut your teams take most, and each step and each wait it saves them today.
How it works
Netflix calls this a “paved road”: tools and practices that central teams support. Teams aren’t made to use them. The aim is that working on the road beats working off it (Netflix). Spotify’s golden path is “the ‘opinionated and supported’ path to ‘build something’” (Spotify). A team that leaves it loses the support. In governance, a team can leave the road, and it still owes every control.
An approved endpoint. One way to reach each approved model, with Step 4’s four safeguards set once: no vendor data retention, a regional endpoint, a signed data processing agreement (DPA), and personal data cut down before each call. It writes the audit record for every call, so nobody has to remember a control no tier can waive. The safeguards live in the harness, the engineering around the model, outside each team’s code.
A credential from the register. The register entry issues the key, and the key works only through the endpoint. Step 3’s gate is built in.
A repository template. A governance.yaml with the system’s ID and tier, an evaluation job that writes its report in the gate’s format, and a pipeline with the gate wired in.
The gate. The framework’s governance gate runs in the pipeline before deployment. It fails the job when a control it checks has no evidence, an evaluation misses its threshold, or an exception has expired or names the wrong approver. A valid exception can cover a gap where the framework allows one. Its result file becomes the release’s evidence for control DA-003. Run it before sign-off, so approvers sign after it passes.
Pre-approved patterns. A pattern is an approved model, endpoint and template used together. The framework has a small version. At T3 and T4 the team lead picks the model from the approved vendor list, and a T4 system on an approved vendor needs no separate vendor assessment. The guide’s recommendation goes further. Answer the questions that don’t depend on the system once per pattern, such as the endpoint’s data residency, and let each system’s evidence point there. Questions about the system’s own data and use still get asked.
Evidence the build produces. Prompt history comes from version control. Code-owner reviews and deployment environments with required reviewers record who approved what (GitHub features as evidence). The evaluation job writes the report, and the gate records its hash. Nobody assembles a pack the night before a meeting.
At T3 and T4 the road carries the framework’s fast lane: the same ten stages, less evidence and no committee. The team lead approves, and at T3 the business owner co-signs the deployment. Book the outsiders at intake: at T3, a red-teamer from outside the build team and AI Risk’s simplified vendor assessment for an external API; at either tier, the DPO’s DPIA screening when personal data is processed.
And the road waives nothing on the framework’s non-waivable list: a DPIA the law requires, the prohibited-use check, zero unresolved Critical red-team findings, a kill switch for T1 customer-facing and all agentic systems, and audit logging.
Now look at what you wrote. For each step your shortcut saves, have the road do it for the team. Remove each wait it skips, unless your tier requires it. Then race again. You are done, by the guide’s test, when the governed path has fewer steps and fewer waits than the shortcut, and a registered team reaches its first model call as fast as someone with a personal key. Any wait your tier doesn’t set is a pothole.
How it scales
Same road at any size. Who builds it changes.
Small team
Your road can be small. Hold one account per approved vendor with the safeguards set, its keys kept by the team lead and issued only for a register entry. Keep one repository template with the framework’s gate in CI, your build pipeline. The gate needs Python and PyYAML, and no network. Pin it to one exact commit of the framework release, by its full SHA, so your controls change only when you move the pin.
Holding the keys is the guide’s recommendation. The road can carry your whole fast lane. A T1 or T2 system still needs approval and validation from outside your team.
Enterprise
A platform team builds and runs the road, and AI Risk approves each pattern on it. The framework’s CoE design puts model serving, evaluation pipelines, monitoring and guardrails with AI Platform Engineering. It warns against a governance-only CoE, and its remedy is “platform and tooling that makes compliance easy”. Pattern approval by AI Risk is the guide’s recommendation. Step 20 builds the gateway that holds the endpoints.
Starter kit
From the open AI governance framework, pinned at v2.2.0.
Deep dive
Forcing functions
A policy asks people to remember a rule. A forcing function removes the wrong move. Don Norman uses the term for a constraint where failing one step stops the next from happening (The Design of Everyday Things). Its manufacturing cousin is poka-yoke, mistake-proofing, which Shigeo Shingo paired with inspection at the source on his route to zero defects (Zero Quality Control).
You have built some already. Step 3 issues no production credential without a register entry, and Step 4 computes the tier so nobody can type one in. The framework’s gate adds one: an exception against a non-waivable control fails, whoever approved it.
A forcing function that blocks good work teaches people to find the next workaround. Make the road quick before you make it strict.
Guardrails, not gates
In this guide, a gate is any point that can stop a release (Step 9). Trouble starts when the gate is a meeting, held when diaries allow, checking what the people in the room think to ask. A guardrail runs on every change and checks the same things each time. The framework’s pipeline gate is a guardrail in this sense.
It checks evidence for the controls that apply before go-live: stages 2 to 7, and the stage 8 controls in the minimum evidence pack. It tests the framework’s metrics against their thresholds. At T1 and T2 a metric passes on its one-sided 95 percent confidence bound, so a good score on a small test set is not enough. It fails on any open Critical finding, which no exception can cover, and on an exception that has expired or names the wrong approver role. It reads what the file declares. It can’t confirm a signature.
The framework is plain about what stays with people. The gate checks that evidence is present. People judge whether it is adequate. The gate also trusts the evaluation report, so the pipeline must generate it.
The framework also uses the word guardrail for runtime filters on a model’s inputs and outputs (control DE-004). The guide’s recommendation is to put those in the endpoint, and to run a new statistical detector in shadow on real traffic before it blocks anything. One that wrongly blocks good work sends teams back to the workaround.
Risk budgets
Google’s SRE book supplies the model (Embracing Risk). Product management sets a service level objective, and monitoring, “a neutral third party”, measures actual uptime. The difference is the error budget. While budget remains, releases ship. When failures use it up, releases halt for a while and effort moves to testing. And the development team “becomes self-policing”.
The framework has nothing like this for risk. Its nearest relative is the cost budget, with alerts at 80, 100 and 120 percent of the monthly budget. What follows is the guide’s recommendation.
Agree a risk budget for each system with its tier approver at deployment. Count events your monitoring already records, such as sampled live responses that fail online scoring. Inside the budget, changes ship under the tier’s normal rules, and nobody adds a review because a change feels risky. Once it is spent, only fixes ship, and the next change waits for the tier approver.
A budget adds a brake. It never removes a control: the non-waivable list, re-tiering and revalidation on material change all stay. Incidents stay out of the budget. They go to incident response. Set the budget before you see the numbers, as you would a threshold.
You now have a road shorter than the workaround, and rules that run on every change. Some things never pass through a gate. A support agent fixes a dangerous draft and says nothing, and the lesson is lost. Step 7 builds a culture that reports problems, and thanks the person who does.