AI governance implementation

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.

If the policy itself is still to be written, our AI governance framework guide has an eight-clause template, with each clause mapped to the control, the owner and the evidence behind it.

Legal work shows the gap clearly. US bar guidance expects lawyers to check AI output, protect client information and supervise anyone using the tools, and our guide to AI contract review and where a lawyer signs sets out the controls that make those duties hold.

Which of those controls a particular system needs depends on how much could go wrong with it, and our guide to scoring an AI use case before it is built sets out the six factors, the tiers and what legal, security and risk will ask for.

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.

Agents bought off the shelf can write too. Tools such as Claude Cowork can read and write files and act in connected apps, and our explainer on Claude Cowork and its admin controls, listed at the end of this page, sets out the switches Anthropic, OpenAI and Microsoft each give an administrator.

Governance software sits beside these controls. A platform can hold the register, the risk assessments and the evidence the controls produce, but it cannot enforce them inside your systems, and our guide to what governance platforms record and what they cannot enforce sets out where that line falls.

In IT operations these controls meet change control: an agent that restarts a service or grants access is making a change. Our guide to which IT operations work an agent can take on shows where each control sits.

• 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.

We work to UK GDPR and the Data Protection Act 2018, plus whatever your sector adds. We work inside our clients' ISO and SOC 2 compliant environments, including banks and other highly regulated organisations, and follow each client's policies and controls throughout. 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.

Controls support your compliance position, and your lawful basis, your own assessments and your data protection officer's judgement stay yours.

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.

• 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.

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.