Enterprise AI governance
Most AI governance is a policy document describing behaviour nothing enforces. The useful version is a set of properties the system cannot violate — and the difference shows up the first time somebody asks you to reconstruct a decision from four months ago.
Proposals arrive faster than the framework for evaluating them. Each one has a business sponsor, a deadline, a model name and a demo. Very few can tell you which identity the system acts as, what it is prohibited from doing, or what evidence would exist afterwards.
So the review defaults to the only thing that is legible: the vendor’s security questionnaire, their certification list, and whether the data leaves the region. All of which are necessary and none of which answer the question that actually matters — what is this thing permitted to do inside our environment, and how would we know what it did.
And the pressure is asymmetric. Refusing has a visible cost that lands on you this quarter. Approving has an invisible cost that lands on somebody else later, which is exactly the shape of decision that produces regret at scale.
Nearly every AI governance failure is the same failure: the system’s capability was evaluated and its authority was never represented anywhere a machine could enforce.
A model that can draft a refund can issue one if something hands it the tool. Whether it should is a policy question, and policy that lives in a document is not a control — it is an intention that survives exactly as long as the next integration.
Governance that works binds execution to identity, delegation, purpose, policy, tenant, data boundary, budget, environment, approval state and tool authority, and evaluates that binding at the moment of action rather than at design review.
The second half is evidence. A consequential action should leave a record connecting the objective, the authority, the policy version, what executed, what it cost and what changed. Not so somebody can be blamed — so a decision can be reconstructed when the person who made it has left and the model that assisted it has been replaced twice.
How long it takes to reconstruct a decision after the fact — measured by time to answer "why did the system do that" for a sampled action, tried before and after.
Whether a prohibited action is prevented or merely discouraged — measured by attempted-and-refused counts by policy, which only exist if the boundary is enforced.
Model changes reaching production without review — measured by promotions that went through replay and shadow versus those that did not.
Shadow AI you did not know about — measured by named machine identities and their granted tool authority, enumerable in one place.
Evidence being generated rather than reconstructed — measured by share of consequential actions carrying a complete receipt at the time they occurred.
that governance makes an AI system safe. It makes its behaviour bounded, attributable and reconstructable. Whether the bounded behaviour is the right behaviour is a judgement that stays with your people.
A governance layer maintaining its own parallel entitlement model is a second source of truth about who may do what, and the one that drifts is whichever is edited under time pressure.
Human identity comes from your identity provider. Machine and agent identities are named and enumerable rather than implicit in a service account somebody created in 2023. Evidence can stream to your SIEM so AI actions appear alongside everything else your security operations already watch.
Model providers are dependencies rather than owners: the registry records which model participated in which action, and replacing a provider does not disturb the authority model or the history.
This page would be worthless if it described an ideal. So: the authority model, the receipts, the registry and the change control are designed and built into the architecture. None of it has been independently attested yet, and we mark that rather than letting a questionnaire imply otherwise.
An organisation evaluating us should apply the same questions above to us, and should expect the same specificity we are recommending they demand elsewhere.
Take this list to every proposal on your desk. It is more useful to you than anything we could say about ourselves, and a vendor who cannot answer it has told you something regardless of what their certification list says.
Which identity does it act as. What is it prohibited from doing, and what enforces that. What data can it reach, for what purpose. What evidence exists afterwards. What happens when it is uncertain or wrong. What happens when the model changes. Can you reconstruct a decision in six months. Can you get your state back if you leave.
A single AI deployment already running in your environment — ideally one somebody else owns, because the governance gaps are easier to see when you did not design them.
Before adopting anything, try answering the eight questions above about a system you already run. Most organisations discover they cannot answer four of them, and that discovery is worth more than any procurement conversation.
If you then want to see the enforced version, the smallest real test is a bounded workflow with a deliberately narrow authority grant — narrow enough that you can enumerate everything it is permitted to do on one page.
What you are evaluating in that phase is not whether the work gets done. It is whether the boundary holds, whether the evidence is there when you go looking, and whether a reconstruction is possible without asking us.
That is the distinction this page exists for. A policy describes intended behaviour; a control prevents unintended behaviour. The test is simple — pick a prohibited action from your policy and ask what would happen if a system attempted it today. If the answer is "someone would notice in a review", you have a policy rather than a control.
Correct, and that is where authority belongs rather than at the model. A model with no tools cannot do anything; the risk enters with what it is handed. So tool authority is part of the delegation and is evaluated at execution, which means the answer to "what could it possibly do" is enumerable rather than theoretical.
Yes, and marking it that way is the point. A SOC 2 Type II attestation is in progress and no report exists; we hold neither a FedRAMP authorization nor a FedRAMP certification. You should weigh that against whatever the alternative proposal claims, and you should check whether the alternative distinguishes its held certifications from its architectural intentions at all.
Then settle it structurally rather than by choosing a provider. If the operating state, authority model, workflows and history belong to the platform rather than the model, provider selection stops being an irreversible governance decision and becomes a procurement one. You can bring your own key, run local inference, or use deterministic paths where a model adds nothing.