How do we actually implement AI governance rather than write a policy about it?
AI governance implementation
Sold asEnterprise AI Platform & Agentic Workflows · Fixed-scope architecture plus production build
Governance written as a policy document changes nothing about what a system does at three in the morning. We implement it as controls: identity and permissions the system enforces rather than assumes, deterministic verifier gates on consequential actions, evaluation running in CI, an audit trail produced as a by-product of those gates, human approval on the decisions that warrant it, and data residency architected in where a region is a requirement. It is built during the platform build, because retrofitting identity, gates and logging onto a running system costs more than designing them in. That is what makes the obligations UK GDPR and the Data Protection Act 2018 place on you testable instead of asserted. It is not a certificate: we hold no ISO or SOC certification, and controls are evidence, not a substitute for one.
Why a policy document governs nothing
An AI policy is a statement of intent: who is accountable, what is allowed, what has to be reviewed. None of it reaches the running system, because a system does not read policies. It reads permissions and configuration.
The gap between the two is where the incidents live. A policy that forbids an agent from writing to a system of record is a sentence. A permission that stops it is a control. Governance an auditor can test is the second kind, and it is engineering work, not drafting work.
What the policy needs underneath it
Each one either exists in your estate or it does not, and anyone with access can check which. That is the difference between a control and an intention. Not every estate needs all six: a read-only assistant over public documents needs identity and logging, and the gates and the residency work start earning their cost when the system can write, or when the data is personal.
Identity and permissions
Every agent, service and person acts as somebody, with entitlements inherited from the systems that already hold them rather than a second permission model standing beside the first.
Verifier gates on consequential actions
Deterministic checks decide whether a proposed action is allowed to land. The pattern is set out in full on the concept page below; this is the engagement that puts it into your estate.
Evaluation in CI
Quality and safety checks run on every change to a prompt, a model or a rule, so a regression is caught by a build rather than by a customer.
An audit trail
The gates write the record as they run: what ran, on which inputs, under whose authority, and what it produced. It is a by-product of the check, so it exists whether or not anyone thought to ask for it.
Human approval where it matters
Approval sits on the decisions that warrant it, and the reviewer sees the specific claim they are being asked to accept. A queue of mostly correct items teaches people to click through it.
Data residency
Where a region is a requirement, the data stays in it by architecture, and we can say which region each store sits in.
What this does for UK GDPR and the DPA 2018, and what it does not
We work to UK GDPR and the Data Protection Act 2018, plus whatever your sector adds. The controls above are how those obligations become testable: lawful access is a permission, minimisation is a schema, a record of processing is an audit trail, and a decision somebody can contest is one whose evidence was kept.
What they do not do is confer a certificate. Controls support your compliance position. They do not stand in for your lawful basis, your own assessments or your data protection officer's judgement, and no supplier can take those off you. We hold no ISO or SOC certification, and we do not imply one. If your security review makes one a hard requirement, we are the wrong supplier for you, and a first call is a cheaper place to find that out than the end of a scoring round.
Where these controls have been built
Governance is easy to assert and awkward to evidence, so here are four engagements where the controls were the deliverable rather than the appendix.
Clinical research
A part-built clinical-research platform taken to launch on a development environment with review gates and a release discipline its own team runs. Its documentation is aligned to MHRA, FDA and EU Annex 11 expectations, and no inspection or audit outcome is claimed for it or for us.
Education assessment
An IELTS speaking assessment where accent fairness and agreement with human examiners are release gates in CI, low confidence routes a case to a human examiner, and the rollout is staged behind controls.
Finance permissions
A connector answering finance questions against a governed semantic model while carrying each person's existing entitlements, so nobody gained access they did not already have.
Identity provisioning
Access to two tools driven from the HR record across a large membership matrix, with deterministic identity resolution, dry runs, an audit trail and a defined path back from a bad run.
What you are left with
An estate whose controls you can demonstrate on request, and governance documentation written from what the system does rather than from what somebody hoped it would do.
Your engineers hold the gates, the evaluation suite and the audit trail, and can change all three. A control your supplier has to be in the building to operate is not a control you own.
Controls already in the estates we run
Each figure is published in full, with its own caveats, on the engagement file it links to.
- 600+
groups, and more than 1,000 users, provisioned from the HR record, so access to Notion and Claude ends when somebody's record changes rather than when a colleague remembers.
Our delivery record · Engagement file D-04
- ~15%
of interviews route to a human examiner on a confidence gate, with a further 5% audited at random whether the system was confident or not.
Our routing thresholds, as built · Engagement file D-02
- 7
regulator-facing governance documents drafted from the controls on that same estate, with the rollout staged behind gates rather than switched on.
Our delivery record · Engagement file D-02
- Unchanged
the permission model on a finance connector. It carries each person's own Looker entitlements, so answering finance questions in the meeting widened nobody's access.
Our delivery record · Engagement file D-06
What you get
- A control map: every consequential action, its gate and its approver
- Identity and permission model, enforced by the system rather than described
- Deterministic verifier gates on the actions that can cause harm
- Evaluation and regression suites running in CI on every change
- Audit logging produced by the gates, with a stated retention position
- Data residency recorded per store, and governance documentation written from the controls as built
Start here if
- An AI policy exists and nobody can show what enforces it
- An agent can write to a system of record and nothing stops it
- Risk, procurement or a regulator has asked how the system is controlled
- Personal or clinical data is in scope and residency is a live question
Frequently asked questions
Do these controls make us compliant with UK GDPR?
They support compliance rather than confer it. Lawful basis, retention, your record of processing and your own assessments stay yours. What changes is that the obligations become testable: a permission either exists or it does not, and an audit trail either holds the action or it does not, and neither answer depends on anyone's recollection.
Can you write the governance documentation as well as build the controls?
Yes, and in that order, which is the order that makes it true. A document drafted first describes intentions. One written from an implemented estate describes behaviour, so the answer to what happens when an agent is asked to write to the ledger is the same in the document and in the code.
Does governance have to be a separate project?
No, and it costs more when it is. Bought as its own workstream it arrives after the system and gets fixed to the outside of it. These controls are implemented inside the platform build, where identity, gates, evaluation and logging are design decisions rather than retrofits.
What if our security review asks for a certification you do not hold?
Then the answer is no, and you have it before anyone spends a procurement cycle on it. We work to UK GDPR and the Data Protection Act 2018 and hold no ISO or SOC certification, and we do not imply one. What we put in front of a reviewer is the control set, the evidence each control produces and the engineers who built them.
Related
Can anyone show what enforces your AI policy?
Point us at one workflow it is meant to govern. The permissions and the logs usually settle which controls exist and which are only written down.
Last reviewed · 1AYM