AI governance: the framework, the tools, and the operating layer that enforces them

AI governance is a runtime property, not a document.

AI governance is the set of controls that decide which models run, on whose data, for which people, under what authority, and with what evidence left behind. Every word in that sentence is operational. If a control cannot be evaluated at the moment an action is dispatched, it is not governance — it is documentation about governance.

The distinction matters because most organisations buy the documentation first. They write an acceptable-use policy, stand up a review board, and publish a model inventory. All three are useful and none of them can stop an agent from writing to a system of record it should never have touched. The policy has no hands.

A working definition we use with clients: governance exists when a non-compliant action is structurally impossible, and every compliant action leaves evidence a regulator would accept. Anything short of that is a reporting function. It tells you what happened after it happened, which is exactly the position that makes incident response expensive and board conversations uncomfortable.

Three concepts get conflated constantly, so it is worth separating them. Compliance is the obligation — the regulation, the contract clause, the certification you must hold. Governance is the control system that satisfies the obligation. The operating layer is the software that executes the control system inside the workflow. You can have all the compliance obligations in the world and no governance; you can have governance on paper and no operating layer to run it.

Compliance

The external obligation: EU AI Act, sector regulation, customer contract clauses, certification scope.

Governance

The internal control system: authority, policy, evaluation criteria, escalation paths, evidence requirements.

Operating layer

The runtime that enforces the control system at dispatch — permissioning, in-loop scoring, immutable logging.

Govern the autonomy level, not the model.

Model-level governance ages badly. You approve GPT-class model X for use case Y, the vendor ships a new checkpoint, and your approval is now describing something that no longer exists. Worse, model-level approval says nothing about the blast radius of the thing the model is allowed to do.

The durable unit of governance is the autonomy tier — how far an action can travel without a human in the path. A suggestion that a person copies into a document is a different risk object from an agent that writes to your billing system, even when both are produced by the same model on the same prompt.

We govern four tiers. Tier 0 is assistive: the output is advisory, a human executes. Tier 1 is drafted: the system prepares a change and a human approves it before it lands. Tier 2 is bounded-autonomous: the system executes within a hard policy envelope and logs every decision. Tier 3 is autonomous within domain: the system holds delegated authority over a defined domain and escalates only on defined triggers.

Framing governance this way makes the review board's job tractable. Instead of relitigating each model, they set the tier a workflow is allowed to operate at, and the operating layer refuses to exceed it. Changing models becomes a routine engineering event. Changing autonomy becomes the governed decision — which is the correct place for the friction to sit.

NIST gives you the vocabulary. It does not give you a runtime.

The NIST AI Risk Management Framework (AI RMF 1.0) is the best shared language available for talking about AI risk across a mixed audience of engineers, lawyers, and executives. It is voluntary, principle-led, and organised around four functions: Govern, Map, Measure, and Manage.

Govern establishes the culture and accountability structures. Map builds the context — what the system is for, who it affects, what could go wrong. Measure defines the metrics and tests. Manage allocates the response: accept, mitigate, transfer, or avoid. The strength of the model is that it is technology-agnostic, which is also precisely its limitation.

NIST will not dispatch an agent, sign a decision, or refuse an action. It tells you that you should have measurement in place; it has no opinion on where in your stack the measurement executes. Teams that adopt AI RMF and stop there end up with an excellent risk register and no change in what their systems actually do.

Use NIST as the board-facing language and the structure for your risk register. Then answer the question NIST deliberately leaves open: which component in the running system enforces each Manage decision, and what evidence does it emit? If the answer for any row is 'the team remembers to', that row is unmitigated.

ISO gives you a certifiable management system — and an evidence bill.

ISO/IEC 42001:2023 is the first certifiable AI management system standard. Structurally it will feel familiar to anyone who has been through ISO 27001: clauses, Annex A controls, defined roles, internal audit, management review, and a certification cycle with an external auditor.

The commercial argument for 42001 is straightforward and getting stronger. If you sell into regulated buyers — financial services, health, public sector, large enterprise procurement — certification is moving from differentiator to entry ticket. It answers the vendor questionnaire before the questionnaire arrives.

The operational argument is harder. Certification obliges you to produce evidence on a cadence: records of decisions, of evaluations, of incidents, of changes. If that evidence is assembled by hand each cycle, the management system becomes a quarterly fire drill and the standard becomes a tax on the team rather than a property of the system.

The right sequencing is to make the evidence a by-product of running the workflow. When dispatch decisions, policy evaluations, and escalations are logged immutably as they occur, the audit becomes a query rather than a project. That is the difference between a certified organisation and a certifiable one.

Pick NIST when

You need shared vocabulary, a risk register, and board-legible structure — fast, and without an audit budget.

Pick ISO 42001 when

Certification unblocks revenue, or a customer contract already names an AI management system.

Run both when

You are enterprise-scale: NIST as the reasoning model, ISO as the audited management system. They are complementary, not competing.

Four tool categories, and what each one genuinely covers.

The AI governance tooling market is not one category. It is four, they solve different problems, and the confusion between them is where most procurement money gets wasted. Buying two tools from the same category and none from the others is the standard failure pattern.

Model registries (MLflow, Weights & Biases, SageMaker Model Registry) are the system of record for ML assets: what was trained, on what, versioned how, deployed where. They are necessary infrastructure and they stop at the model card. A registry does not know who dispatched an agent or under what authority.

Policy and assurance dashboards (Credo AI, Fairly AI, and the broader GRC-adjacent category) produce control-evidence reports mapped to NIST and ISO. They are genuinely good at the auditor-facing artefact. They sit beside the workflow rather than inside it, which means the quality of the report depends entirely on the quality of what feeds it.

Evals and guardrails (OpenAI Evals, Promptfoo, LangSmith, NeMo Guardrails, Guardrails AI) catch known failure modes pre-deployment and at the prompt boundary. Essential, and deliberately narrow: they do not know your authority graph, your data classifications, or your escalation policy. They check the text, not the entitlement.

The fourth category is the operating layer, and it is the one most stacks are missing. It owns dispatch: it holds the policy, evaluates the action against it before execution, refuses what fails, and writes the immutable record. Registries, dashboards, and evals all plug into it — none of them replace it.

Registry

Inventory and lineage of models. Answers: what do we have?

Dashboard

Control evidence and reporting. Answers: can we show an auditor?

Evals & guardrails

Pre-flight and boundary checks. Answers: does the output behave?

Operating layer

Runtime authority and enforcement. Answers: should this action happen at all, and what proves it did?

Where A/DVNT Risk sits, and what it actually enforces.

A/DVNT Risk is the runtime the frameworks assume exists. Policy is expressed as canons — machine-evaluable rules bound to identity, data class, and autonomy tier — and canons are enforced at dispatch rather than reviewed afterwards. An action that violates a canon does not execute; the refusal itself is a logged, attributable event.

Coherence is scored in-loop. Before a decision ships, it is evaluated against the intent it claims to serve and the policy envelope it operates within. Low-coherence actions escalate rather than proceed silently, which converts a class of silent failures into routed exceptions with an owner.

Every dispatch, evaluation, refusal, and escalation writes to an immutable SEAL ledger. That ledger is the artefact your ISO auditor asks for and the artefact your incident review needs — one record, produced as a by-product of operation, not reconstructed after the fact from four log stores and someone's memory.

Because the three-layer architecture (ADVNT-ARCH-001) separates Intelligence, AI Operating, and Application concerns, policy and audit travel with the work rather than living inside each application. Swap a model, add an application, extend to a new business unit — the governance substrate is the constant.

The 90-day sequence that survives a board review.

Governance programmes fail in a predictable order. Policy is written before inventory, so it governs an imagined estate. Tooling is bought before authority is assigned, so nobody owns the exceptions. Certification is scoped before evidence is automated, so the first surveillance audit consumes a quarter.

Run it in the opposite order. Weeks 1–2: inventory what is already running, including the shadow estate — the team-level subscriptions and prompts that never went through procurement. You cannot govern an estate you have not enumerated, and the shadow estate is almost always larger than the sanctioned one.

Weeks 3–6: assign authority and set autonomy tiers per workflow. This is a decision-rights exercise, not a technology exercise. Name the accountable owner for each tier-2 and tier-3 workflow, and define what triggers escalation. If a workflow has no named owner, it does not get a tier above 1.

Weeks 7–12: encode the policy into the operating layer and switch enforcement on for the highest-blast-radius workflows first. Evidence generation comes free at that point. Only then pick a framework posture — NIST-aligned, ISO-certified, or both — because you now have a running system to certify rather than an intention to describe.

A/DVNT Govern™ runs exactly this sequence as a six-week engagement, and A/DVNT Assess™ runs the inventory and tiering half of it in four. If you would rather start with a read on your current posture, the AI Audit benchmarks you against the 2026 dataset in fifteen minutes.