AI Governance Framework Design
A governance framework proportionate to what you actually build, with named accountability and decision rights, designed so that teams route through it rather than around it.
Two failure modes, and the second is more common. A framework so light it governs nothing, or one so heavy that teams stop declaring what they are building. The second is worse: it produces the appearance of control while pushing the real activity out of sight, and it is what most enterprise AI policies achieve in their first year.
An AI governance framework defines how an organisation decides what AI it will build or buy, who is accountable for each system, what review each must pass in proportion to its risk, and how systems are monitored, documented and retired. It is the operating model that regulation, certification and assurance all sit on top of.
Proportionality is the whole design problem
Applying the same review to a meeting summariser and a credit decisioning model guarantees that one is over-governed and the other under-governed. Risk tiers are defined by consequence and reviewed in proportion:
| Tier | Typical systems | What it requires |
|---|---|---|
| Minimal | Internal drafting, summarisation, code assistance | Registration and acceptable-use policy only |
| Limited | Customer-facing content, internal search over sensitive data | Registration, transparency check, named owner |
| Elevated | Materially affects a customer or employee outcome | Risk assessment, bias testing, human review, monitoring |
| High | Regulated decisions, safety, or Annex III scope | Full documentation, conformity work, sign-off, audit trail |
| Prohibited | Uses your organisation will not pursue | Named explicitly, with the reasoning recorded |
The last row is the one organisations skip and later wish they had not. Deciding in advance what you will not build is faster than deciding it under commercial pressure with a deadline attached.
What the framework has to settle
Accountability with a name on it
Every AI system has an accountable owner who is a person, not a committee or a function. Shared accountability is the reliable route to nobody being answerable when something goes wrong, and it is the most common structural defect we find.
Decision rights, including who can say no
Who approves an elevated-risk deployment, who can halt one in production, and what happens when the business owner and the risk function disagree. If the escalation path is undefined, the answer in practice is that nothing is ever stopped.
A review process teams can actually pass
Sized to the tier, with realistic turnaround times and a triage step that clears the minimal tier in days. A review queue with a six-week wait teaches people to describe their project as something else.
Third-party and embedded AI
Most AI in a large organisation arrives inside purchased software rather than being built. Procurement criteria, vendor questions and the treatment of AI features switched on inside existing products belong in the framework, or it governs a minority of your actual exposure.
The link to how work is really done
Governance that lives in a separate portal is governance nobody sees. Registration and review are placed in the workflows engineering and procurement already use, which is what makes compliance the path of least resistance.
Review, retirement and change
Systems change and drift; a framework that only governs launch is governing the least risky moment. Periodic review by tier, re-assessment on material change, and a defined retirement process are all part of it.
Build for the frameworks you will be asked about
A well-designed framework maps cleanly onto the EU AI Act, ISO/IEC 42001 and the NIST AI RMF without being rebuilt for each. We design once against the union of what they ask for, so certification or an enterprise customer's questionnaire is an evidence exercise rather than a new programme.
How we keep it from becoming shelfware
- Start from your real inventory. What is actually running, including the tools teams adopted without telling anyone. See AI inventory and model registry.
- Write the tiers around those systems, not around a generic taxonomy, so every tier has real examples people recognise.
- Pilot the review on live projects during the engagement, and fix what proves unworkable before it is published.
- Measure the review itself — turnaround time, rejection rate, and how many systems appear that were never registered. The last one tells you whether the framework is working.
- Train the people who will operate it, not only the people who approved it.
How the engagement runs
The framework is piloted on live projects before it is published, so unworkable steps are found early.
Inventory and assessment
What AI actually exists, built and bought; current policies, decision rights and gaps established.
Design
Risk tiers, accountability model, decision rights, review process and prohibited uses drafted with legal, risk and engineering.
Pilot
Run on live projects; turnaround, friction and gaps measured, and the process revised.
Embedding
Registration and review placed in existing engineering and procurement workflows.
Training and handover
The people operating the framework trained, with templates, guidance and a review cadence.
What you receive
A framework that has already survived contact with real projects, with accountability named.
Risk tier definitions
Tiers built around your real systems, with worked examples and the prohibited-use list.
Accountability model
A named owner per system, decision rights, and the escalation path when parties disagree.
Review process
Proportionate by tier, piloted on live projects, with measured turnaround times.
Third-party and procurement criteria
Vendor questions and treatment of AI features inside purchased software.
Embedded workflow integration
Registration and review inside the tools your teams already use.
Training and templates
For the people who operate the framework, not only those who approved it.
Is this the right engagement?
Worth being direct. AI Governance Framework Design is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- AI use is growing and nobody can say what is running or who owns it.
- An existing policy exists on paper and is routinely bypassed.
- Regulation, certification or customer questionnaires are approaching.
- A board or audit committee has asked what controls exist.
- Teams want to move faster and need a defensible route to yes.
Choose something else if
- You need certification specifically. See ISO/IEC 42001 implementation.
- You need EU AI Act readiness specifically. See EU AI Act compliance.
- AI use is one pilot with one owner; a policy page will do for now.
- No executive will own the framework, which makes it advisory at best.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What does an AI governance framework actually contain?
Risk tiers defined by consequence, a named accountable owner per system, decision rights including who can stop a deployment, a review process proportionate to tier, criteria for third-party and embedded AI, and processes for periodic review and retirement. The framework is the operating model that regulation and certification sit on top of.
How do we stop governance slowing everything down?
By making it proportionate and by measuring it. Minimal-risk systems clear a triage step in days; only elevated and high-risk systems attract real scrutiny. We measure review turnaround during the pilot, and we treat the number of systems discovered that were never registered as the honest indicator of whether the framework is working.
Does one framework satisfy the EU AI Act, ISO 42001 and NIST?
Largely, if it is designed that way from the start. The three overlap substantially on inventory, risk assessment, documentation, human oversight and monitoring. We design against the union of their requirements so that certification or a regulatory question becomes an evidence exercise rather than a fresh programme.
What about AI inside software we bought?
It is usually the majority of your exposure and the part most frameworks ignore. Procurement criteria, supplier questions and the treatment of AI features switched on inside existing products are part of the design — otherwise you have governed the minority of AI your organisation actually uses.
Who should own AI governance?
A named executive with authority over both the risk and the delivery sides, supported by whichever functions you already have. What does not work is shared accountability across a committee, which reliably produces nobody being answerable at the moment it matters.
Often paired with this
Most clients combine two or three engagements from the AI Governance, Security and Compliance pillar. These are the ones that most often run immediately before or after.
AI Inventory and Model Registry
A complete inventory including shadow and vendor AI, kept current by discovery rather than by annual survey.
Read more →AI Policy and Acceptable-Use Documentation
Specific rules with named tools and worked examples, plus an approval route fast enough that people use it.
Read more →AI Risk Assessment and Model Cards
Risk assessments that end in decisions, and model cards that state limits honestly rather than advertising.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.