Picture a team that has built an assistant to summarise customer complaints. A director has announced the launch date. The register entry is in, and the system is T1. The outside red team is booked, but its first free slot comes after the date.
So the team calls the launch a pilot, on one desk, and goes live on the date. Nothing goes wrong. At the next all-hands, the director thanks the engineer who found the way through.
Every other team in the room learned two things. The date held. And “pilot” is the word that gets a system past the gate.
You own the process that team went around. Who was wrong: the team, or your process? Write down your answer.
The move
Find the shortcuts before you build more process. Do three things.
- Ask the people who build. Ask about the last time the process got in their way. Then ask what they did. Make them the promise the framework’s amnesty route makes for unapproved AI tools: what someone declares before it is detected is not treated as a breach, as long as they help register it and clean up. Extending that promise from tools to process shortcuts is the guide’s recommendation. People tell you about shortcuts only when telling is safe.
- Read the traces. Look in the register, the exception register, shadow AI reports, gate results and cloud bills.
- Name three. Write each one in a line: what teams skip, what the skip saves them, and who pays if it goes wrong. Then mark which kind of safety it needs.
The guide’s call: a shortcut tells you something about your process. A team goes around a step when the step costs more than the way around, or when the organisation rewards the way around. Ask what the step costs before you ask who skipped it.
So the guide’s answer to the opening question is your process, first. The call stops where the framework’s amnesty stops: deliberate exfiltration, use after a specific instruction to stop, and repeat breaches. Those are misconduct. Your disciplinary policy handles them.
Your call. Write down the shortcut you think your teams take most. Then write how you know: someone told you, you saw it in a record, or you guessed.
How it works
Every arc lands where the governed path lands, on real data and real users. What it skipped is missing. That is the evidence, and sometimes the safeguard itself, such as the audit log. Where an arc leaves the path, you have found a step that costs more than the way around.
Six forces push teams onto the arcs. None of them needs a careless engineer.
Present bias. Following the process costs now: an entry, a wait for a reviewer, an evaluation set to build. Skipping costs later, if ever. People give the present extra weight. In O’Donoghue and Rabin’s model, people who don’t expect this of themselves keep putting off tasks whose costs come first. “We’ll secure it later” is sincere. That is the trouble.
The demo that becomes production. A demo is built to impress. It has no owner. Then a sponsor wants it live, and it ships as it is. Sculley and colleagues warned that time pressure can turn a prototype into the production system.
Local incentives against shared risk. A team is measured on what it ships, and when. If a skipped control fails, the cost lands on customers and on whoever runs the system next. Steven Kerr called this “the folly of rewarding A, while hoping for B”. Reward the date and hope for the evidence. You get the date.
Normalised deviance. Each shortcut that ends well makes the next one feel safe. Diane Vaughan named the pattern in her study of the Challenger launch decision. More on it below.
Hero culture. The engineer who rescues a launch is thanked in public. Repenning and Sterman found organisations that “reward and promote those who, through heroic efforts, manage to save troubled projects”. An engineer they interviewed gave their paper its title: “Nobody ever gets credit for fixing problems that never happened.”
Security later. A skipped control is a debt. Ward Cunningham, who coined the debt metaphor, wrote that every minute spent on not-quite-right code “counts as interest on that debt”, and Sculley and colleagues added that hidden debt “compounds silently”. Some governance debts can never be repaid. A log you never kept can’t be written afterwards.
Each force leaves a trace.
- Entries that arrived late. The framework records how each register entry was created. An entry from reconciliation is a system found outside the register before anyone declared it.
- Exceptions that come back. A renewal, or a new request that cites an old exception. The guide reads both as deviance on its way to normal. The framework’s metrics guidance reads a rising exception count this way: “either the policy is too rigid or risk acceptance is becoming a habit; either way, investigate.”
- Shadow AI findings and self-reports. Each one is a tool someone chose over the approved route. Ask why.
- First-attempt gate failures. What teams arrive without shows which evidence they leave to the end.
For each of your three, decide which kind of safety it needs. Some shortcuts must be impossible by construction: a forcing function removes the way around, as “no entry, no production credential” does in Step 3. Others can only be caught early and cheap to recover: detection finds them, and people report them. The guide’s call is that a shortcut whose harm can’t be undone needs the first kind. This step only diagnoses. Step 6 builds the paved road and its forcing functions, Step 9 the gates, and Step 7 the culture that reports.
Now look at what you wrote down. If you guessed, test the guess against one trace. If you would take the same shortcut under the same deadline, you have found a process problem.
How it scales
Same method at every size. What changes is who asks, and where the traces live.
Small team
In a team of five, whoever asks also takes some of the shortcuts. Ask someone outside the team to run the conversation. Then read three traces: model credentials issued without an entry, prompt or model changes merged without review, and evidence written after the release it supports. Both are the guide’s recommendations.
The framework’s Start Here lists traps for small teams. Each is a shortcut waiting to be taken: a co-author who signs as the peer reviewer, oversight reviewers agreed only after launch, and an on-call rota of three people.
Enterprise
Ask in every business unit, through the stewards from Step 3. Read the traces centrally. In the framework, AI Risk owns the register, its quarterly reconciliation and the exception register. The AI Risk Committee reviews exceptions every month (GV-004). Security runs shadow AI detection and reports monthly.
Take your three shortcuts and their causes to the AI Risk Committee, beside the governance health metrics it already sees. That is the guide’s recommendation, and so is this reading: the same shortcut in several units points at the centre.
Starter kit
From the open AI governance framework, pinned at v2.2.0.
Deep dive
Present bias
In O’Donoghue and Rabin’s model, a person must do a task once and chooses when. When the task costs now and pays later, people naive about their own self-control put it off again and again, each time sure they will do it next time. With costs up front, the authors show, even a small present bias can do severe harm to naive people.
Governance work has that shape. The register entry, the evaluation set and the outside validator’s booking cost now. Their reward is a problem that never happens.
The framework moves those costs to the start. Start Here tells builders to start evaluation sets early and to book outside reviewers at intake, “because their capacity usually sets your date”. The guide adds one move: tie each cost to something the team wants now, such as a credential.
The demo that became production
A demo answers one question. Can this work? Production also asks who owns it, what data it touches and who can switch it off. A demo that ships as it is answers none of them.
Sculley and colleagues name a prototype smell. They warn of “a significant danger that time pressures may encourage a prototyping system to be used as a production solution”, and add that “results found at small scale rarely reflect the reality at full scale”. The inputs that won the demo were chosen. Your customers’ emails won’t be.
In the framework, pilots and proofs of concept that touch real data are registered. The schema refuses a pilot entry without a tier, a deployed date and a next review date. A demo on synthetic data can still drift towards launch with no entry. Find those in the bill: model spend that grows with no entry to match.
Normalised deviance
The Rogers Commission investigated the loss of Challenger in January 1986. Its chapter on the booster joint, “An Accident Rooted in History”, says NASA and contractor management “first failed to recognize it as a problem, then failed to fix it and finally treated it as an acceptable flight risk.” Erosion of a primary O-ring was first found after the second shuttle flight, in November 1981. As damage recurred, the reaction was “to increase the amount of damage considered ‘acceptable.’”
Diane Vaughan’s study calls the launch a disastrous mistake, and names the process behind it. Faced again and again with evidence that something was wrong, insiders normalised the deviance until it became acceptable to them. A new preface traces a similar decision process in the loss of Columbia in 2003.
Your version starts with an exception granted for a good reason. It is renewed. The next team cites it as precedent. In the framework, an exception lasts 90 days at most and can be renewed once, by an approver one level higher; at T1, a renewal needs a full committee decision and is reported to the Board Risk Committee. Five controls can’t be waived at all. The guide’s call: when a request cites an earlier exception, read it as a trace, and ask what the first one taught the team.
You can now name your three shortcuts, and what each says about your process. That alone changes nothing. Each arc is still quicker than the step it skips. The next date will put a team back on it. Present bias will make it feel cheap. Step 6 makes the governed path the fastest path, so the shortcut stops paying.