For AI decisions someone will eventually have to defend
AI Governance
A business can adopt AI quickly and still have no way to answer a regulator, an auditor or a customer asking how a decision got made. This practice builds the control layer that answers that question before it gets asked, through policies, audit trails, risk tiers and the human checkpoints a specific use case actually needs. It exists so AI adoption does not outrun the business's ability to explain itself.
What an AI control layer actually contains
Policy, audit trail and checkpoint design walked through against a real use case.
85 secSample frame · video pending01Before writing a policy
Not every AI use case carries the same risk
Applying the same scrutiny to a spellchecker and a lending decision wastes effort on one and endangers the business on the other. Four checks sort which AI use cases need governance now.
Does the decision affect a person's rights or money?
Lending, hiring and eligibility decisions need audit trails and human review before governance can be considered adequate.
Can a wrong output cause real harm?
A miscategorised support ticket is recoverable; a misdiagnosed clinical flag is not, and governance depth should follow that gap.
Who can explain a specific decision later?
If nobody on your team can reconstruct why the model produced a given output, the audit trail is the missing piece.
Does a regulator have a view on this use case?
Some sectors already carry duties around automated decisions, and governance has to be built to satisfy them, not guessed at.
| Ungoverned | Governed | |
|---|---|---|
| Decision trail | Reconstructed after the fact, if at all | Logged as the decision happens |
| Human checkpoint | Wherever someone remembers to look | Placed where risk classification requires it |
| Policy | Assumed or informal | Written and enforced in the system |
| Accountability | Diffuse across the team | Assigned to a named owner |
| Right for | A single low-stakes internal tool | Anything touching customers, money or rights |
02Agreed before any policy is written
The ledger that keeps control honest
Every governance engagement fixes what you bring, what we design, what comes back as a working control, and what authority never leaves your organisation regardless of engagement shape.
- Your side
You bring
- The AI tools already in informal use
- Whatever incidents or near-misses have surfaced
- The teams currently making ad hoc calls
- Our side
We build
- A risk classification across current use cases
- An acceptable-use policy grounded in that classification
- Checkpoints placed where the risk actually sits
- Your side
You receive
- A written, enforceable acceptable-use policy
- A risk-tiered map of every use case
- A checkpoint design ready to implement
Never leaves you
- Final sign-off on the policy's tone and limits
- Every hiring and personnel decision the policy touches
- Authority over which use cases get approved
Where the line sitsWe classify and draft the controls. Approving what the business is actually willing to allow stays a decision only you make.
03From exposure to enforced control
Four stages, each closing on a control you can audit
Governance fails when it stays theoretical, so this process closes each stage with a control your team can inspect rather than a policy nobody has tested.
Classify every AI use case by risk
Each use case is scored against harm, reversibility and regulatory exposure before any control gets designed around it.
A sorted inventoryDesign the checkpoints and audit trail
Human review sits exactly where the risk classification demands it, and every consequential decision leaves a traceable record.
Controls with a purposeWire the policy into the system
Acceptable-use rules are enforced where the AI actually runs, not left as guidance in a document nobody consults.
A tested policyHand over the audit and review process
Your team owns the ongoing audit cadence and the checkpoint reviews, so control does not depend on us staying involved.
A team that can prove it
04What actually drives the number
Four drivers behind a governance engagement
Governance work is priced against how much exposure the AI use case actually carries, not a flat compliance fee, because these drivers change the effort by multiples.
Number and variety of AI use cases
One well-scoped assistant needs less governance work than a dozen use cases scattered across departments.
Regulatory exposure of the sector
Financial services and healthcare carry duties that shape the audit trail depth far beyond a typical internal tool.
How much human review is required
Fully automated decisions need less checkpoint design than ones where a person must approve before anything happens.
Existing policy and audit maturity
A business with no acceptable-use policy starts further back than one simply extending controls it already has.
05Evidence and proof
Controls that held up when someone outside the company asked to see them.
Governance proof is measured in audits passed and decisions explained, not in policies written. Every record here waits for written client approval before it reaches production.
Explore case studies
A healthcare AI tool got an audit trail before its second customer signed.
Koru Health's triage assistant launched without a record of why it flagged a case a certain way. A governance pass added checkpoints and a trail an auditor could follow.
- Decisions now logged
- Every consequential case
- Audit findings on relaunch
- None outstanding
A product SaaS team sorted forty AI features by actual risk.
Aster North had AI spread across forty features with no shared view of exposure. A risk classification separated the two that needed human review from the rest.
- Features classified
- Forty, in one pass
- Features requiring new controls
- Two
We could finally show an auditor exactly why the model flagged what it flagged, and who signed off on it.
Sample · pending client approval
06Read this first
When AI governance is the wrong spend
Building a full control layer around one internal, low-stakes assistant spends trust the practice cannot yet claim back, so the exits are marked early. When the work is justified, controls sit inside the stack already running, never a separate compliance product bolted on top.
You run one low-stakes internal tool
A lightweight acceptable-use note may cover this until the use case grows into something that touches customers or money.
- AI integration
You need systems connected before anything else
Governance without a working system to govern is premature. Integration work fits better as the starting move here.
- AI transformation
The whole organisation is changing how it works with AI
A single control layer is not enough on its own. Transformation work sets the wider programme this fits inside.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The use cases are already known | Risk appetite and policy tone | Classification, controls, audit design |
| Delivery pod | Use cases keep appearing | Priorities each cycle | Ongoing control design and review |
| Team extension | Your compliance team leads | Standards and sign-off | Named engineers embedded in the work |
07Straight answers
Asked before a control layer gets approved.
01Is AI governance the same as data privacy compliance?
No, though the two overlap. Data privacy governs what happens to information; AI governance also covers how a model's decision gets made, reviewed and explained, which privacy rules alone do not address.
02Do small teams need formal AI governance?
Not always, and forcing heavy controls onto one low-stakes internal tool wastes effort better spent elsewhere. The moment a use case affects money, rights or health, though, the calculus changes fast.
03What counts as a human checkpoint?
A point in the process where a person must review or approve an AI output before it takes effect. Where that point sits depends entirely on the risk classification of the use case.
04Can governance slow down AI adoption?
Poorly designed governance can, when every use case gets the same heavy review regardless of risk. Proportionate controls do the opposite, because low-risk use cases move fast once they are classified as such.
05Who owns the audit trail once it is built?
You do. Governance work hands over a system your compliance and engineering teams can run and extend, not a report that ages the day it is delivered.
06Does governance apply to third-party AI tools we did not build?
Yes, and often more urgently, because a vendor's model still produces decisions your business is accountable for. Classification and checkpoints apply regardless of who wrote the underlying model.
07How does governance connect to a wider AI transformation programme?
Governance is one control layer inside a larger programme, not a replacement for it. Transformation sets the broader adoption plan; governance makes sure each step in that plan stays defensible.