AI Governance: The Controls That Actually Prevent Incidents
Most AI governance is a document nobody reads. Four controls prevent the incidents that actually happen, and all four are mechanical.
AI governance means the enforced constraints on what your systems may send where, and who is accountable when something goes wrong. The distinction that matters is between a stated intention and an enforced one — a routing rule that cannot be bypassed is governance, whereas a policy PDF is documentation of an aspiration.
What the evidence says about AI governance
The last row is the governance argument in one line: adoption is already near-universal, so the question is not whether AI touches your data but whether anyone has decided which data, going where, under what terms.
Which controls actually prevent incidents
Data classification before routing
Sort your content into public, internal, confidential and regulated. This is a one-afternoon business exercise and it determines the entire architecture that follows.
Every downstream control depends on it. Without classification, "is this safe to send" becomes a judgement call made repeatedly by whoever is closest to the keyboard.
Provider terms confirmed in writing
Free tiers of major providers generally use submitted content to improve their products; paid tiers contractually do not. Confirm the tier you are actually on, not the one on the marketing page.
This is discovered in a pilot and inherited into production more often than any other governance gap.
A routing layer you control
Application code calls your own interface, not a provider SDK directly. Regulated classes pin to a model inside your boundary; everything else routes to whichever provider is best value.
Roughly a week of work up front, and close to impossible to retrofit cheaply once workflows are in production.
Human review at consequence points
Anything reaching a customer, a financial record or a regulated artefact passes a person. Define these points explicitly rather than leaving them to individual judgement.
Audit trail on decisions
Log what was sent where and what came back, in a form that answers "what did we send to which provider" as a query rather than an investigation.
Named owner for spend and for outcomes
Two roles, and they can be the same person, but neither can be "the team". Consumption pricing and unclear value are two of the three causes Gartner names.
Where governance theatre wastes money
- You are writing a policy document before deciding the routing rules. The document will describe intentions the systems cannot enforce.
- The governance model requires people to remember something at the moment of use. Controls that depend on recall fail at the worst possible time.
- You are building an approval committee for individual prompts. That does not scale, and it pushes usage into unofficial tools.
- Nobody has classified the data yet. Everything else on this page depends on that step, and it is the cheapest one.
Green light, red light
| Dimension | Go ahead when | Do not when |
|---|---|---|
| Scope of controls | Controls attach to specific systems and specific decisions those systems make | A general policy document exists that no system is actually measured against |
| Human review | Any output reaching a customer, a financial record or a regulated artefact passes a person first | Review is described as a maturity stage to graduate out of rather than as the design |
| Auditability | You can answer why a particular decision was made with a query | Answering 'why did it do that' requires convening a meeting |
| Ownership | Named owners for model behaviour, data access and spend | Governance is owned by a committee with no individual accountable |
| Proportionality | Control effort scales with consequence of the decision | The same approval burden applies to a draft email and a payment instruction, so people route around it |
How to start governing AI — without hiring anyone
-
01
Classify your data into public, internal, confidential and regulated. One afternoon, business stakeholders, no technology required.
-
02
Confirm in writing whether your current provider tier trains on submissions.
-
03
Put a thin routing interface between your applications and any model, even if it initially routes everything to one provider.
-
04
List the points where output reaches a customer, a financial record or a regulated artefact, and require review at each.
-
05
Name the spend owner and put a monthly review in the calendar.
Questions buyers ask about AI governance
Generally yes — the major providers' free tiers state that submitted content may be used to improve their products, while paid tiers contractually do not. Check the terms of the tier you are actually on and keep a record of the answer.
It is necessary and not sufficient. A policy states intent; a routing rule enforces it. Auditors increasingly ask to see the enforcement mechanism, not just the document describing it.
Start by acknowledging that the traffic exists — DORA found 90% developer adoption, so unofficial usage is the default rather than the exception. Provide a sanctioned route that is easier than the unofficial one, then measure.
Roughly a week of engineering for a thin abstraction. The cost of not having one is a rewrite when pricing changes, a model is retired, or compliance asks a question the current architecture cannot answer.
Continue the kit
Want an honest read on your readiness?
Six evidence tests, four minutes, no email required. It will tell you plainly if the foundations are not there yet.
Run the assessment →Read the rest of the kit.
Five capability guides, every figure cited to a named source and year.
Open the AI Resource Kit →