Why most strategies stall
A common AI governance strategy is a stack of policy documents, a committee, and a model inventory. It looks complete and fails the first audit, because none of it touches a live request. The strategy describes what should happen while the actual AI traffic flows past ungoverned. A strategy that holds has to end in enforcement: a control point that applies the policy you wrote to each request as it runs. The way to get there is to sequence the work so each stage feeds the next, rather than treating documentation as the finish line.
Stage one: policy that can be enforced
Write policy in terms a system can act on, not only terms a committee can approve. For each use case, state which data classes may be sent to which model providers, what must be redacted, who may use the system, and what evidence the use must produce. Vague principles such as use AI responsibly cannot be enforced or audited. Concrete rules, such as never send customer identifiers to an external model and route legal queries only to the approved provider, can be turned directly into runtime controls. Policy is the specification for everything downstream.
Stage two: map the AI landscape
You cannot govern what you cannot see. Map where AI is actually used: sanctioned tools, shadow usage, the data flows behind each, and the providers requests reach. This is where most teams discover the gap between the approved diagram and reality, including assistants and agents no one registered. The map tells you which flows carry the most risk and therefore where enforcement matters first. Keep it current, because the landscape changes faster than an annual review cycle.
Stage three: runtime controls
Translate the policy from stage one into controls that act on the flows from stage two. The mechanism is a single layer in the request path that intercepts each call, redacts personal data in transit, enforces the per-use-case policy, and routes to approved models only. This is the stage that turns a strategy from description into control. Sequencing matters: controls built before policy and mapping enforce the wrong things, and controls built after documentation but never deployed leave the strategy on paper.
Stage four: evidence and review
The final stage makes the strategy auditable. When enforcement runs through one layer, every decision can be recorded as it happens: which policy applied, what was redacted, which model handled the request, and the outcome, mapped to the EU AI Act and ISO 42001. Evidence generated this way is a by-product of enforcement rather than a separate documentation effort, so reviews stop being fire drills. Feed what the evidence shows back into stage one, and the strategy becomes a loop that tightens rather than a binder that ages.
Frequently asked questions
What is the right order for an AI governance strategy?
Policy you can enforce, then a map of real AI usage and data flows, then runtime controls that apply the policy, then automatic evidence and review that feeds back into policy.
Why is policy alone not a strategy?
Policy describes intended behaviour but does not touch live requests. Without enforcement at runtime, the gap between the document and what the system actually does is exactly what an audit exposes.