AI Governance that engineers will actually follow
A short policy stack, named owners, a living model inventory and review gates built into delivery. Enough structure to satisfy the EU AI Act and ISO 42001, not so much that teams route around it.
- 4–8 week set-up
- Aligned to EU AI Act + ISO 42001
- Templates you keep
More than one AI system, and nobody holds the full list
Governance becomes necessary the moment AI stops being one team's experiment. Product has a copilot, marketing has a content tool, support has a bot, and someone in finance is pasting invoices into a chat window. Each is fine alone; together they are a risk nobody owns.
- Leadership teams that need to answer "what AI do we run and is it safe?"
- Companies selling into enterprises that send AI governance questionnaires.
- Regulated firms in financial services, healthcare, HR technology and the public sector.
- Organisations preparing for the EU AI Act or ISO 42001 certification.
Outcomes
- One AI policy and a handful of standards, written in plain language.
- A model inventory with an owner and a risk tier for every system.
- Review gates in your delivery process, with templates.
- An evidence folder that answers auditors and customers.
Four layers, each derived from the one above and proven by the one below
Principles are the handful of commitments leadership signs: human oversight for consequential decisions, transparency to users, no use of personal data without a lawful basis.
Policies turn principles into rules: which use cases need approval, which data classes may reach which providers, who may deploy what.
Controls are the mechanisms that enforce policies: a use-case register, security review before launch, tool allow-lists, evals as a release gate, logging and spend caps.
Evidence is what proves the controls ran: the inventory, review records, eval reports, access logs, DPIAs and incident reports.
Who does what: a starting RACI
Governance fails when everyone is consulted and nobody is accountable. This is the default split we propose; we adapt it to your org chart in the first week.
| Activity | Executive sponsor | AI owner | Security | Legal / DPO | Engineering lead |
|---|---|---|---|---|---|
| Approve the AI policy | A | R | C | C | I |
| Register a new AI use case | I | A | C | C | R |
| Classify risk tier (EU AI Act, internal) | I | A | C | R | C |
| Threat model and security review | I | I | A | I | R |
| DPIA and lawful basis | I | C | C | A/R | C |
| Evals and release gate | I | A | C | I | R |
| Monitoring and incident response | I | A | R | C | R |
| Quarterly review of the inventory | A | R | C | C | C |
R = responsible, A = accountable, C = consulted, I = informed.
The one artefact every framework asks for
The EU AI Act, ISO 42001 and every customer questionnaire start with the same question: what AI do you run? The inventory answers it. We set it up as a simple table or register and wire it into your deployment process so it stays current.
| Field | Example | Why it matters |
|---|---|---|
| System and use case | Support assistant: ticket summaries and suggested replies | Scopes every other field; one row per use case, not per model |
| Model, provider, version | Claude (Anthropic API), pinned model id | Supply chain, change control, provider terms |
| Owner and sponsor | Head of Support; CTO | Someone answers when it misbehaves |
| Data classes in and out | Customer PII in; summaries out; no payment data | Privacy, DPIA trigger, provider eligibility |
| Tools and permissions | lookup_ticket (user scope); no outbound email | Agency and injection exposure |
| Risk tier | EU AI Act: limited (transparency); internal: medium | Determines required controls and review depth |
| Controls and evidence | Security review 2026-Q3; eval suite v4; DPIA ref | Links to the evidence folder |
| Last review and next | Reviewed Sept; next on model change or in 6 months | Keeps the register alive |
A governance sprint, then a rhythm
Discover
Interviews and a tooling scan to find every AI system in use, sanctioned or not. First draft of the inventory.
Decide
Principles workshop with leadership, risk-tier definitions, RACI agreed. Output: a one-page policy.
Build gates
Use-case registration form, review checklists, eval and security gates added to your delivery process.
Run the first cycle
Take the top three systems through the gates with us. Fix what the gates find. Populate the evidence folder.
Hand over
Quarterly review calendar, templates, and optional fractional AI CTO support to chair the first reviews.
Governance connects to everything else
Frequently asked questions
What is AI governance, in one sentence?
The set of decisions, roles, rules and evidence that lets an organisation say what AI it runs, why, who is accountable, and how it knows the controls are working. See the glossary definition.
How much paperwork does this create?
Less than people fear. A mid-sized company typically ends up with one AI policy, two or three standards, a model inventory and a review checklist. The evidence is mostly generated by the systems themselves: eval results, logs, access reviews.
We already have ISO 27001. Do we need separate AI governance?
You need an extension, not a parallel system. ISO 27001 covers information security; AI governance adds use-case approval, impact assessment, model lifecycle and oversight. Our ISO 42001 page explains how they fit together.
Who should own AI governance?
A named executive sponsor, a working owner (often the head of product, data or engineering) and a small cross-functional group: security, legal or data protection, and the engineers who ship. We help you set the RACI and run the first cycle.
How long does it take to stand up?
Four to eight weeks for the policy stack, inventory and first review cycle. Ongoing governance is a few hours a month per role once the gates are part of the normal delivery process.