Runtime proof · OVERT
What Is AI Governance? Intent vs. Proof
What is AI governance? It's how an organisation directs and proves its AI behaves — the policies that state intent, and the runtime evidence that proves controls ran.
So, what is AI governance? At its plainest, AI governance is the set of policies, roles, processes, and controls an organisation puts in place to make sure its AI systems behave the way they're supposed to — safely, lawfully, and in line with the organisation's own commitments. It's how a company answers the question "who decided this model could do that, and on what terms?"
That's the textbook definition, and it's correct as far as it goes. But it describes only one half of the discipline: the half about intent. Good AI governance defines what ought to happen. The harder, often-missing half is proof — evidence that the controls you defined actually executed when your AI was running. This guide covers both: the fundamentals newcomers and stakeholders need, and the verification layer that most governance programmes still lack.
What is AI governance? A working definition
AI governance is the practice of directing and constraining how artificial-intelligence systems are built, deployed, and operated, so their behaviour stays inside boundaries the organisation has chosen. Think of it the way corporate governance directs a company, or data governance directs how information is handled — except the thing being governed can now generate text, make decisions, call tools, and act with a degree of autonomy.
A mature programme typically spans the whole lifecycle:
- Design and procurement — deciding which models are permissible, for which uses, with which data.
- Deployment — setting the guardrails, access rules, and human-oversight requirements before a system goes live.
- Operation — monitoring behaviour, logging actions, and responding when something drifts out of bounds.
- Retirement and review — retiring models responsibly and learning from incidents.
The point of all of it is accountable, predictable behaviour. Governance is what lets a regulated business deploy AI without flying blind.
Governance, risk, and compliance — how they relate
These three terms travel together but mean different things. Governance sets direction and policy. Risk management identifies what could go wrong and how badly. Compliance checks that you're meeting external obligations — regulations, standards, contractual promises. AI governance is the layer that ties them into a coherent operating model, so that risk assessments inform policy and policy is testable against compliance requirements.
The core pillars of an AI governance framework
An AI governance framework is the structured model an organisation uses to put these ideas into practice. Frameworks vary, but most converge on a recognisable set of pillars. If you're building one from scratch, these are the load-bearing elements:
1. Accountability and ownership
Someone must own each AI system and its outcomes. That means named roles — often a cross-functional group spanning legal, security, data science, risk, and the business line. Stakeholders need clarity on who approves a model, who can override it, and who answers when it misbehaves.
2. Risk classification
Not every model carries the same stakes. A spam filter is not a credit-decisioning engine. Frameworks tier systems by risk so that oversight scales with consequence — light-touch for the trivial, stringent for the high-impact.
3. Policies and standards
The written rules: acceptable uses, prohibited uses, data-handling requirements, human-in-the-loop thresholds, and the controls each risk tier must satisfy. This is where intent gets codified.
4. Controls and guardrails
The actual mechanisms that enforce policy at runtime — input filtering, output checks, permission boundaries on what an agent may do, escalation paths when a control trips. Controls are where governance stops being a document and starts being a behaviour.
5. Monitoring and assurance
Ongoing visibility into what systems are doing, plus the assurance activities — testing, AI governance auditing, attestation — that confirm the whole apparatus is working. This pillar is where most programmes quietly fall short, and it's the one we'll spend the rest of this guide on.
The half that's missing: from intent to evidence
Here's the gap that almost no introductory explainer mentions. Walk through the five pillars again and notice something: four of them produce documents and intentions. Policies state what should happen. Risk tiers state how much oversight is warranted. Ownership states who's responsible. Even most monitoring produces self-reported logs — records the operator generates about its own behaviour.
The OVERT standard puts it plainly: governance has always been able to say what ought to be done; it has rarely been able to prove what was. Policies, audit narratives, and self-reported logs record intentions and recollections. They are not, in any strict sense, evidence.
That distinction matters more every year, because AI systems increasingly act. A model that drafts a memo is one thing. An agent that calls tools, moves data, and takes consequential steps on your behalf is another. When an agent does something it shouldn't, the questions that follow are not "what was your policy?" They are: which control was active at that moment? Did it actually fire? Can you prove it — independently, after the fact — without exposing the sensitive data involved?
A policy document can't answer that. Neither can a log the operator could, in principle, have edited. What you need is a different category of artefact: a record that an outside party can verify, produced by the control itself as a by-product of doing its job. Not a better log — evidence that is tamper-evident, independently checkable, and silent about everything it doesn't need to disclose.
Runtime coverage: governing AI where it actually acts
This is where the conversation moves from paperwork to runtime. Runtime coverage is the idea that governance controls should enforce at the points where an AI system actually does things — at the inference boundary, at each tool call, at the agent's decision points — and that every enforcement decision should leave behind proof that it happened.
Under this model, when a control permits, denies, overrides, or escalates an action, it emits a signed receipt recording that the enforcement event occurred. The receipt is the unit of evidence. Crucially, the design keeps protected content where it belongs: only cryptographic fingerprints, signatures, and verification metadata cross the boundary — never the underlying sensitive data. You get proof of what your controls did without turning your evidence trail into a new way for data to leak out.
This is the difference between saying an oversight requirement was in force and being able to demonstrate, to an auditor or a regulator who wasn't in the room, that it was — and which configuration of which component enforced it.
What verifiable AI governance looks like in practice
Verifiable AI governance rests on a few commitments that separate evidence from assertion. The OVERT standard names them, and they translate cleanly into what any rigorous programme should aim for:
- Evidence, not assertion. A governed action yields a receipt a third party can check — not a claim it's asked to trust.
- Containment by construction. Only fingerprints and signatures cross the boundary; the content stays home. Proving compliance never becomes a data-egress risk.
- Independence by structure. Whoever attests is separate from whoever is governed. Self-attestation is not independent attestation — a log you produced about yourself isn't the same as proof someone else can confirm.
- Measurement, not adjective. Safety expressed in intervals and sample sizes an auditor can reproduce, rather than in reassuring words.
For mature operations, this is what makes AI governance auditing tractable. Instead of an auditor reading your narratives and taking your logs on faith, they can verify enforcement events directly: what was in scope, what was excluded, which component was active, and that the telemetry hasn't been quietly rewritten. Post-incident reconstruction becomes possible without forcing you to disclose the protected content the incident touched.
None of this replaces the governance framework. You still need policies, ownership, and risk tiers — intent has to be defined before it can be enforced. Verification simply closes the loop the framework leaves open: it turns "we have a control for that" into "here is the receipt proving the control ran."
Where to start
If you're new to the discipline, the honest answer to what is AI governance is that it's two halves. The first half — frameworks, policies, risk tiers, ownership — is well-charted, and you should build it. The second half — proof that your controls actually executed at runtime — is the part the industry is only now catching up to, and it's the part that determines whether your governance survives contact with an audit, an incident, or a regulator.
For organisations deploying AI that acts — in healthcare, financial services, defence, and other regulated settings — the practical move is to design for evidence from the start, so your controls produce verifiable receipts rather than after-the-fact stories.
Ready to make that move? Get runtime coverage to put enforcing controls and signed receipts at your inference and agent boundaries. Or see the evidence first: verify a sample OVERT receipt and read the open standard for yourself — the framework half describes intent; the receipt is the proof.