Enterprise

AI governance.
Not a slide deck.

Most AI governance is a policy document that no deployed system references. Governance that works is enforced in the architecture: what a system may do, who reviews it, and what happens when it is wrong.

Last reviewed 4 September 2026 · Engineering guidance, not legal advice.

THE PROBLEM WITH POLICY-FIRST GOVERNANCE

A written AI policy is necessary and insufficient. It states that systems must be fair, explainable and overseen. It does not stop a team wiring an agent to a production database with write access, because nothing in the deployment path checks the policy.

Governance that survives contact with delivery has three properties. It is enforced where systems are built and deployed, not only in a document. It is proportionate to risk, so a marketing copy assistant is not subjected to the controls a credit decision needs. And it produces evidence as a by-product of operating, rather than requiring a scramble whenever an auditor asks.

THE COMPONENTS

A real inventory

You cannot govern what you cannot enumerate. Every AI system in the organisation, its owner, what data it touches, which models it calls and what it is permitted to do — maintained as a live register, not an annual survey. Shadow AI is the norm, and the inventory is what surfaces it.

Risk tiering with real consequences

Tiers only matter if they change requirements. A high-tier system requires an evaluation set, human review above a threshold, full trace logging and a named owner before it can deploy. A low-tier system requires none of that. The tier is assigned at design time and gates the release.

Human oversight that is not a rubber stamp

Meaningful oversight means the reviewer has the context, the authority and the time to disagree. Track override rate — a rate near zero means the control is theatre, and salting the queue with known-bad cases is how you find out.

Evaluation as a release gate

A regression suite that runs before each deploy and blocks it on a drop. This is one of the most effective controls available, because it converts “the model changed and nobody noticed” from a likely event into a detectable one. It catches what the evaluation set covers, which is why the set is a living artefact rather than a one-off.

Traceability by construction

Inputs, retrieved context, tool calls and outputs persisted per decision. Built in at the start it is nearly free; retrofitted it is a project. It is also what makes an incident investigable at all.

An incident path that has been rehearsed

What happens when a system produces a harmful output: who is paged, how it is disabled, how affected decisions are identified and remediated. Written down, and tested at least once before you need it.

QUESTIONS

QUESTIONS — 4

The technical controls above overlap substantially with what the Act asks of high-risk systems — risk management, data governance, logging, human oversight, accuracy and robustness. Building them because they make systems work well reduces the engineering gap. It does not remove the legal obligations that sit alongside them — conformity assessment, registration, post-market monitoring, and the provider/deployer distinction — which are for your legal function to own. Our EU AI Act page covers the obligations and timelines. This is not legal advice.

Yes, which is why tiering matters. A tool that drafts internal meeting summaries should carry almost no governance overhead. Applying uniform controls is the fastest way to make governance unpopular and therefore routed around. The point of tiering is to spend the oversight budget where the exposure actually is.

A named individual with authority over the release process — in practice usually a head of engineering, a CISO, or a dedicated AI lead in larger organisations. What does not work is a committee that meets monthly and has no gate in the deployment pipeline. The ownership has to sit where the release decision sits.

We implement the technical components — inventory tooling, evaluation harnesses, trace logging, release gates — and work alongside your risk or legal function on policy. We are engineers rather than a compliance consultancy: our contribution is making the controls real in the systems, not drafting the framework document.

Keep reading

Evaluating AI Systems

→

Trust

Security Architecture

→

30-minute technical call · no deck