whitepaper

AI Governance: An Engineering Reference.

Governance work stalls at the point where a policy has to become a control. This reference skips the argument and lists what to build: twenty-six controls across seven families, each with the artefact that proves it exists, the place it already lives in a normal engineering stack, and the way it usually fails. Nothing here needs a governance platform. The controls that survive contact with a real audit are the ones whose evidence is generated by the pipeline rather than written by a person before a review.

Download whitepaper Talk to Our Engineers

In depth

A Control You Cannot Evidence Is A Control You Do Not Have.

Seven families cover the whole surface, and each attaches to the register.

Inventory and ownership, data governance, documentation artefacts, human oversight, logging and traceability, evaluation and monitoring, and change control together hold twenty-six controls, and every one of them hangs off a row naming a system and the person accountable for it. Build the register first or the other six families have nothing to attach to. An inventory with a named human against every entry is the cheapest control in the catalogue and it blocks everything else.

In shortAn inventory with a named human against every entry…

Generated evidence survives an audit, and written evidence goes stale.

A model card emitted by the release pipeline carries the version, the eval run and the date it actually shipped, while a hand-written conformity file describes whatever was true on the afternoon somebody sat down to write it. The test is simple enough to apply to every control you own. Ask whether the artefact appears on its own when the system runs, or whether a person has to be asked for it.

In shortwhether a person has to be asked for it

Checkpoint retirement is a change you did not choose.

Release pinning treats the model, the prompt, the retrieval configuration and the tool list as one unit, so a prompt edited in a console is a release that never went through a gate. Hold an evaluated fallback before a provider gives you a date. The eval that approved your system stops describing it the moment any of those four moves without a re-approval reference.

In shortThe eval that approved your system stops describing…

The detail

Three Controls That Are Missing Almost Everywhere.

The register usually exists, the model card usually exists, and the logs usually exist. These three turn up absent, in that order of frequency, and all three cost a little at build time and a great deal to retrofit.

Zone · 01

Output lineage

Teams log the prompt and the answer, and rarely the corpus version, document ID and chunk behind it. A question about a March decision then cannot be answered in October, because the index has been rebuilt twice and the document edited since. GOV-2.2 costs a few trace fields at build time and cannot be added afterwards.

Zone · 02

Deletion that reaches copies

Deletion is implemented against the primary store and stops there. The embedding survives, and so do the cache, the eval snapshot, the fine-tuning extract and the backup, which means the record is gone from the place you look and still answering questions. Run GOV-2.4 on one real record and count the stores it touches: usually five or six, two of them with no delete API.

Zone · 03

Proof of real oversight

Oversight is asserted in documentation and almost never measured. Two numbers settle it, and the review interface already emits both: override rate and median time-on-decision. Route 220,000 decisions a month to four reviewers with 600 hours between them and each decision gets 9.8 seconds, which is the arithmetic that fails GOV-4.3 whatever the policy claims.

By the numbers

The figures that make it a board-level conversation.

controls across seven families, each with a named artefact that proves it

92%

of organisations with an AI-related breach had no AI access controls in place

40%

of organisations control access to their own AI models and data

Inside the report

What you'll take away.

Step 1 - Build the register before anything else

Every other family attaches to a row in it. One entry per system, a named individual who can suspend it, and a model registry entry written by the pipeline rather than by hand.

Step 2 - Put trace fields in with the retrieval layer

Corpus version, document ID and chunk ID belong in the trace from the first retrieval commit. Add them later and you are re-instrumenting a live system to answer a question already asked.

Step 3 - Run a deletion drill on a real record

Pick one subject, delete it, and count every store the delete had to reach. The drill is the artefact, and the stores with no delete API are the finding worth escalating.

Step 4 - Pin the release as one unit

Model, prompt, retrieval configuration and tools versioned together, with the build failing when any of the four is unpinned. Rollback then restores all four instead of three and a console edit.

Questions

Frequently asked.

How many controls are in the catalogue, and how are they grouped?

Twenty-six, across seven families: inventory and ownership, data governance, documentation artefacts, human oversight, logging and traceability, evaluation and monitoring, and change control. The first four are build-time controls you put in while the system is being made. The last three have to be running before anybody asks, which is why they are the ones that fail.

Do we need a governance platform to implement any of this?

No. Every control in the catalogue attaches to something you already run: the service catalogue, the model registry, CI, the observability stack, object storage and your existing incident process. A platform can hold the register, but it cannot generate the artefacts, and the generated artefact is the whole point.

Which controls should we build first if we can only do a few?

GOV-1.1 and GOV-1.3, the register and the named owner, since nothing else has anywhere to attach. Then GOV-2.1 provenance at ingestion and GOV-5.1 the event record, both of which are cheap on the day you turn them on and cannot be reconstructed for the months you ran without them.

How long should we retain AI event logs?

Six months is the working minimum, and the clock starts at write rather than at export. Keep the full record on a stable schema that is queryable by subject, use hashes in place of raw personal data, and make the storage append-only so a broken hash chain raises an alert.

What proves human oversight is real rather than a logged approval step?

Two numbers the review interface can emit: override rate and median time-on-decision, reported monthly on the same dashboard as everything else. Divide reviewer hours by queue volume first. If the seconds available per decision are in single figures, GOV-4.3 fails on arithmetic before anybody looks at the interface.

How does this sit alongside your other governance papers?

This one is the build list. AI Governance Under Regulation covers which regime makes each control mandatory and by when, Benchmarking AI Governance scores how far you have got, and AI Governance: What Buyers Should Ask turns the same controls into questions for a vendor. Read this one with a repository open.

Who is this reference for?

Platform and application security engineers who have been handed a policy and asked to make it true. It assumes you can read a CI config and would rather see the artefact and the pipeline step than the argument for why governance matters.