AI governance framework: how to build one that holds
A structure for an AI governance framework that survives contact with daily use: approval flows, cost limits, audit trails and named ownership.
by Elias Mahdavi · Published on · 8 min read
An AI governance framework is the operational structure, approval flows, cost limits, audit ownership and escalation paths, that makes an AI policy enforceable day to day rather than just a document. Unlike the policy itself, it defines who approves what, within what budget, logged how. Record-keeping duties under the EU AI Act (Regulation (EU) 2024/1689) depend on this structure existing.
Key takeaways
- An AI governance framework is the operational structure behind a policy: who approves what, within what budget, logged how, and escalated to whom when something breaks.
- It is distinct from the policy document itself; the policy states the rules, the framework is what makes them actually happen day to day.
- A framework that holds needs six structural elements: approval flows, cost limits, audit ownership, escalation paths, role-based access mapping and a fixed review cycle.
- Approval flows fail in practice when they have no defined SLA; a request that takes three weeks to approve simply gets bypassed.
- Cost limits only work when they are enforced at the point of use, not reported after the fact on a monthly statement.
- The strongest AI governance platforms are the ones where the framework's structure and the technical enforcement are the same system, not two things that have to be kept in sync manually.
Contents
- What is an AI governance framework?
- 6 structural elements of an AI governance framework that holds
- How approval flows and escalation paths should work
- Setting cost limits that survive daily use
- What are the best AI governance platforms?
- Frequently asked questions
- Building the framework, not just the document
What is an AI governance framework?
An AI governance framework is the operational structure that turns an AI policy into something that actually happens: defined approval flows for new tools and exceptions, enforced cost limits, clear ownership of the audit trail, and a named escalation path for when something goes wrong. It is the mechanism, not the rulebook.
This is a narrower, more operational concept than AI governance as a whole, covered fully in <a href="/en/blog/what-is-ai-governance">what AI governance means and its eight core components</a>, and a different artefact entirely from the policy document itself, covered in <a href="/en/blog/ai-policy-template-free">a usable AI policy template</a>. The policy says what is allowed. The framework says who decides, how fast, logged where, and what happens next.
6 structural elements of an AI governance framework that holds
Most frameworks fail quietly, one missing element at a time, rather than through one dramatic gap. Each of these six needs to exist and be tested against real daily use, not just documented once.
1. Approval flows
A defined process for requesting a new tool or an exception, with a named approver and a target turnaround time. Without a deadline attached, "pending approval" becomes indistinguishable from "no."
2. Cost limits enforced at the point of use
Budgets attached to the account or key actually making the request, not a spending report reviewed after the month closes. A limit that only appears on an invoice is not a limit; it's an observation.
3. Audit trail ownership
A named owner for the audit log itself, responsible for knowing it exists, that it is complete, and that it can be produced on request. An audit trail nobody owns is an audit trail nobody checks until it's needed and found incomplete.
4. Escalation paths
A specific path for what happens when a rule is broken or a request falls outside normal approval, including who is notified and within what timeframe. Escalation without a defined path becomes an email that sits in an inbox.
5. Role-based access mapping
Access assigned by what a role actually needs, not granted uniformly to make provisioning simpler. A data scientist and a business analyst need different reach into models, data and tools, and the framework should encode that difference rather than flatten it.
6. A fixed review cycle
A schedule for reviewing whether the framework still matches how the organisation actually uses AI, triggered by events, such as a new model or tool being adopted, not only by the calendar.
These six elements are not an internal best-practice preference; they map directly onto what regulators now expect an organisation to demonstrate. The <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener">EU AI Act (Regulation (EU) 2024/1689)</a> imposes record-keeping obligations on higher-risk AI use that are difficult to meet without named audit ownership and a working approval flow behind them. The National Cyber Security Centre's <a href="https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development" target="_blank" rel="noopener">Guidelines for Secure AI System Development</a> makes the same point structurally: security and governance responsibility has to be assigned across an AI system's whole lifecycle, not left implicit. The Information Commissioner's Office is equally direct in its <a href="https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/" target="_blank" rel="noopener">guidance on AI and data protection</a> that accountability under UK GDPR means being able to evidence a decision, not merely assert that a process exists.
How approval flows and escalation paths should work
An approval flow only functions if it is faster than the alternative of simply not asking. The table below sets out a workable structure by request type.
| Request type | Typical approver | Target SLA | Escalation trigger |
|---|---|---|---|
| New tool or model request | IT / Policy & Compliance owner | 3–5 working days | No response within SLA auto-escalates to a named backup approver |
| Data classification exception | Data owner + Compliance | 5 working days | Any request involving regulated data auto-escalates to Compliance lead |
| Budget increase for a virtual key | Team lead + Finance | 2 working days | Repeated requests from the same key trigger a usage review, not just approval |
| Cross-team model access | Project owner | 2 working days | Access spanning more than one business unit auto-escalates to IT |
The pattern across all four rows is the same: a named approver, a real deadline, and automatic escalation when it's missed. A framework without that third column produces shadow AI, because a slow, undefined approval process is exactly what pushes people to route around it.
Setting cost limits that survive daily use
A cost limit survives daily use only when it is enforced at the point a request is made, not discovered afterwards. That means budgets attached to the virtual key or account actually calling a model, with a hard stop or an approval step when a threshold is reached, rather than a dashboard someone checks once a month.
The same structure that enforces the limit should also be the source of the number: per-user, per-model request metering, so the budget and the actual usage are drawn from the same data rather than reconciled by hand later. This mirrors the baseline the UK government sets out in its <a href="https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice" target="_blank" rel="noopener">AI Cyber Security Code of Practice</a>, developed with the National Cyber Security Centre: controls that depend on individual vigilance are weaker than controls built into how the system operates by default. DevKira's approach ties spend limits directly to the virtual key issued through its LLM gateway, so the limit is a property of the request itself, not a policy applied retroactively; the mechanics of that metering are covered in <a href="/en/blog/llm-gateway-explained">how request-level metering and per-user keys work</a>.
What are the best AI governance platforms?
For a framework specifically, the best AI governance platforms are the ones where approval flows, cost limits and audit ownership are properties of the platform itself rather than a separate process layered on top of a generic model API. A platform that requires a spreadsheet to track approvals or a separate tool to reconcile spend has not actually implemented the framework; it has documented one.
Evaluate a platform against the six structural elements above directly: can it enforce an approval step before a new model becomes reachable, does it cap spend at the point of use, does it produce an audit trail with a clear owner, and does it support role-based access out of the box. DevKira is built around all four as core capabilities of one governed workspace rather than optional integrations.
Frequently asked questions
What are the best AI governance platforms?
For running an actual framework, the best AI governance platforms are ones where approval flows, cost limits and audit ownership are built into the platform itself, not tracked separately in a spreadsheet or a second tool. Evaluate any candidate against whether it enforces approval before access, caps spend at the point of use, and produces an owned audit trail.
What is the difference between an AI governance framework and an AI policy?
A policy is the written document stating the rules. A framework is the operational structure, approval flows, cost limits, audit ownership and escalation paths, that makes those rules actually happen in daily use. A policy can exist without a framework; it just won't be enforced.
Who should own an AI governance framework?
Typically a named individual in IT, security or compliance, with defined approvers for each request type feeding into that owner rather than every decision routing through one person. Ownership without delegation to specific approvers becomes a bottleneck that recreates the slow-approval problem the framework was meant to solve.
How do approval flows work in AI governance?
A request, for a new tool, a data exception, or a budget increase, goes to a named approver with a fixed target turnaround time. If that time passes without a decision, the request automatically escalates to a backup approver rather than sitting indefinitely unanswered.
What happens when someone exceeds their AI budget?
In a framework that enforces limits at the point of use, the request is blocked or held for approval before the spend occurs, not flagged afterwards on an invoice. Repeated attempts to exceed a budget should also trigger a usage review, since that pattern often indicates the limit itself needs revisiting.
How often should an AI governance framework be reviewed?
On a fixed schedule, commonly quarterly, and additionally whenever a new model, tool or significant use case is adopted. A framework reviewed only once a year will consistently lag behind how quickly the underlying AI landscape changes.
Building the framework, not just the document
A framework is tested the first time a request doesn't fit neatly into the process it describes, which is usually within the first month of real use. The elements that matter most, a real SLA on approvals, spend limits enforced before the fact, and an audit trail with a named owner, are the ones worth building first, before the framework is asked to cover every edge case.
To see approval flows, cost limits, audit ownership and role-based access working as one governed system rather than a framework maintained by hand, <a href="/en/book-a-demo">book a DevKira demo</a>.
