AI Governance Framework: Controls, Gates, and Owners

An AI governance framework is the set of policies, risk tiers, accountable roles, approval gates and monitoring controls that decide what an organization's AI systems are allowed to do, who answers for them, and what evidence exists afterwards. It is not an ethics statement, and it is not a maturity score. It is control machinery: a use case enters at intake, gets classified by risk, passes named gates before launch, and stays under monitoring with an owner attached until someone retires it.

The reason this stopped being optional has a date on it. The EU AI Act reached its general application date on 2 August 2026, prohibited practices under Article 5 have been enforceable since 2 February 2025, and the penalty ceiling for breaching them is 35 million euro or 7% of worldwide annual turnover. In the United States, Colorado's AI Act took effect on 30 June 2026 after a delay. Meanwhile the AI Incident Database logged 362 incidents in 2025, up from 233 the year before. Governance became a compliance obligation and an operational one in roughly the same eighteen months.

This is the framework we run with clients, written out so you can take it to a risk committee and argue with it. We build AI systems for a living rather than audit them, which shapes the bias: everything here is designed to be enforced in a delivery pipeline rather than described in a binder.

The short version

• An AI governance framework has seven parts: policy, risk tiering, inventory, approval gates, per-system documentation, monitoring with incident response, and third-party governance. Anything that does not produce an artifact or a decision is decoration.
• Risk tiering comes first. You cannot govern a portfolio you have not classified, and the EU AI Act's own structure is a four-tier classification before it is anything else.
• Ownership is thinner at the top than people assume. McKinsey found the CEO oversees AI governance at 28% of AI-using organizations and the board at 17%.
• The three reference frameworks agree more than they differ. The EU AI Act is law, ISO/IEC 42001 is certifiable, and the NIST AI Risk Management Framework is voluntary vocabulary. Run one control set mapped to all three.
• Governance fails in predictable ways: the review board that becomes a queue, the policy nobody can find, the inventory that was accurate once, and the vendor who added an AI feature without telling you.
• Governance maturity has to track capability maturity. Controls designed for one pilot collapse at twenty systems, and controls designed for twenty systems stop the first one from ever shipping.

What an AI governance framework is

An AI governance framework, or artificial intelligence governance framework in the phrasing most regulators use, answers four questions about every AI system in the organization: what is it allowed to do, who decided that, what happens when it misbehaves, and where is the proof. A framework that cannot answer the fourth question is a policy, not governance.

Worth separating from three neighbors it gets confused with. Data governance controls inputs: provenance, permitted use, retention, quality. IT governance controls change, access and availability for systems whose behavior is deterministic. AI risk management is one component of the whole, the analytical part where you rate what could go wrong. AI governance binds those to named humans and dated decisions, and it exists because AI systems degrade quietly, behave differently on data they have not seen, and produce outputs that look equally confident whether they are right or wrong.

The second distinction is between a framework and a maturity model. A maturity model tells you where you stand. A framework tells you what happens on Tuesday when a product manager wants to put an LLM in front of customers. Most published material sold as an AI governance framework is a maturity model with the levels relabeled, which is why teams read one, recognize themselves at level two, and change nothing operational.

Governance also sits one altitude below the question of which AI problems are worth solving at all. That is enterprise AI strategy, argued at the exec table. Governance is what any chosen use case then passes through on its way to production.

A governance framework is only as good as the moment it lets you say no. Everything else in it is a description of work you were going to do anyway.

Why AI governance stopped being optional

Three forces converged, and only one of them is legal.

The first is regulation with dates and numbers attached. Regulation (EU) 2024/1689, the EU AI Act, entered into force on 1 August 2024. Prohibited practices under Article 5 and AI literacy duties applied from 2 February 2025. Obligations for general-purpose AI models under Articles 53 to 55 applied from 2 August 2025, with additional duties for models trained above the systemic-risk threshold of 10^25 floating point operations. The general application date was 2 August 2026. The high-risk chapter did not arrive with it: the AI Omnibus, in force since 27 July 2026, moved obligations for Annex III high-risk systems to 2 December 2027 and for Annex I high-risk systems embedded in physical products to 2 August 2028. That deferral is a scheduling change, not a reprieve, and the technical documentation those articles demand takes longer to assemble than the extension is worth.

The United States has no federal equivalent, so the obligations arrive by state. Colorado's SB 24-205, the Colorado Artificial Intelligence Act, imposes a duty of reasonable care to avoid algorithmic discrimination on both developers and deployers of high-risk AI systems, requires impact assessments and consumer notice, gives affected individuals a right to human review, and requires notifying the Attorney General within 90 days of discovering algorithmic discrimination. Its effective date moved to 30 June 2026 under SB 25B-004, signed in August 2025. If you sell into consequential-decision contexts in the US, that law reaches you regardless of where you are incorporated.

The second force is failure rate. Stanford's AI Index recorded 362 AI incidents in 2025, a 55% rise on 2024, alongside a familiar gap: having a responsible AI policy is now common, operationalizing it is not.

The third force is the boring one. Ownership is thin. McKinsey's 2025 State of AI survey, covering 1,491 respondents across 101 nations, found the CEO oversees AI governance at 28% of AI-using organizations and the board at 17%. Everywhere else, governance sits below the level that can stop a project, and that single fact predicts most of what goes wrong later.

The seven components of an AI governance framework

Strip away the diagrams and every workable framework contains the same seven parts. Each one produces something you can hand to an auditor.

The order matters more than the list. Policy without tiering applies the same rules to a document summarizer and a credit decision, which either strangles the first or under-governs the second. Tiering without an inventory classifies the systems you know about. Gates without documentation produce approvals nobody can reconstruct six months later, which is the exact failure an auditor is looking for.

How to tier AI risk before you govern anything

Risk tiering is the first real piece of work, and it is where most frameworks are vaguest. The EU AI Act settles the legal floor for you with four tiers: prohibited practices under Article 5, high-risk systems classified under Article 6 by reference to Annex I and Annex III, systems carrying transparency duties under Article 50, and everything else. Annex III is the list to read first, because it names the stand-alone use cases that make a system high-risk: biometrics, critical infrastructure, education, employment and worker management, access to essential public and private services including creditworthiness, law enforcement, migration and border control, and administration of justice.

That gives you a legal classification. It does not give you an operating one, because most internal AI never touches Annex III and still needs a rule. Here is the rubric we use, with thresholds written down so the answer does not depend on who is asking.

Two rules keep this honest. Tier on the consequence of being wrong, not on the sophistication of the model, because a regex that denies loans is higher risk than a transformer that suggests meeting times. And tier the use case rather than the model, since the same foundation model lands in three different tiers depending on where its output goes.

The unpleasant discovery at this stage is usually scope. Ask a 200-person company to list its AI systems and you get five. Ask again after checking single sign-on logs, expense reports for AI subscriptions, browser extension telemetry and the imports in your own codebase, and you get thirty. Shadow AI is not a discipline problem. It is what happens when a governance process is slower than a corporate credit card.

Who owns what in an AI governance framework

Governance fails on ownership more often than on any technical cause, and the failure is usually generosity. Everyone is consulted, so nobody is accountable. Split it four ways and keep the split visible.

The executive sponsor is the person who can stop the work without asking anyone. If nobody in the room has that authority, the gate is decorative and every system will proceed to production regardless of what the evidence says. The model owner is one human with a name, not a team and not a rota, and the register row is invalid without one. When someone changes role, their systems get reassigned in the same week or they get switched off.

Notice what is missing from that table: an AI governance committee that owns everything. Committees are useful for setting the risk appetite and reviewing the high tier once a quarter. They are useless as an accountable party, because a regulator asking who approved this cannot be handed a distribution list. Keep the committee advisory and put individual names on decisions.

Governance also sits alongside delivery rather than above it. A function that reviews every request individually becomes a queue, and a queue with a two-week wait is the reason teams start building things nobody registers. What works is setting the rules once per tier, letting the minimal and limited tiers proceed against a checklist, and reserving named human review for the high tier where an error is expensive.

McKinsey's State of AI work found the change most correlated with bottom-line impact was redesigning workflows rather than layering AI on top of existing ones, and only about a fifth of adopters had done it. Redesigning a workflow requires authority over how people work, which is an ownership question before it is a technical one.

The approval gates in an AI governance framework

Gates are what turn a framework into an operating model. A gate is a moment when someone with authority looks at evidence and says continue or stop. Three properties make one real: it is binary, so "mostly" fails; it is evidenced, so the answer points at a measurement rather than at confidence; and it has one named owner, because a gate owned by a committee opens by default.

Gate three is the one that carries real weight. A system arrives at it with a measured baseline captured before the pilot ran, an evaluation harness that turns quality into a number, an impact assessment for anything in the high tier, and a written answer to what the system may do alone versus what needs a human. Absent any of those, the correct decision is to send it back, and a framework that has never sent anything back is not being run.

Gate six is the one almost nobody builds. Models get replaced, teams reorganize, and the old endpoint keeps serving traffic to an integration everybody forgot. Decommissioning is a governance event with data-retention consequences, not a cleanup ticket.

The model inventory an AI governance framework runs on

The inventory is the spine of the framework. Everything else is a column on it. Build it as a real register with mandatory fields rather than a spreadsheet of names, because the fields are what make it auditable.

Per system, the high tier gets a dossier on top of the register row. A model card describing intended use, out-of-scope use, training data at the level of description you can legally publish, evaluation results by segment, and known limitations. An impact assessment, which for a public-sector deployer of an Annex III system is a legal requirement under Article 27 of the AI Act and for everyone else is the document that proves you thought about who gets hurt. ISO/IEC 42005:2025 is the standard that tells you how to structure one, and it is worth reading before you invent a template.

The EU AI Act names most of these artifacts directly for high-risk systems: a risk management system running across the lifecycle under Article 9, data governance under Article 10, technical documentation under Article 11, automatic logging under Article 12, instructions for use under Article 13, human oversight under Article 14, accuracy and robustness and cybersecurity under Article 15, and a quality management system under Article 17. Deployers pick up their own duties under Article 26. If you build the dossier above, you have produced most of what those articles ask for, whether or not the law reaches you.

Monitoring, incidents, and the audit trail

An AI system in production degrades in ways a health check will not catch. Uptime is fine, latency is fine, and the answers have been getting worse for six weeks because the input distribution moved. Monitoring has to cover quality as well as availability.

What an AI governance framework monitors

Four signals are worth instrumenting from day one. Output quality against a fixed evaluation set on a schedule, so degradation is a number rather than a complaint. Input drift, because the data changing is the leading indicator. Cost per outcome, which moves fast on token-priced systems and is the metric finance will ask for. And human override rate, the cheapest trust signal you will ever get: when people start overriding a system on a third of cases, something changed and nobody filed a ticket.

What counts as an AI incident, and when you have to report it

Incidents need a definition before they need a process. The AI Act gives you one worth borrowing: Article 3 defines a serious incident as one leading to death or serious harm to health, serious and irreversible disruption to critical infrastructure, non-negligible infringement of fundamental rights obligations under Union law, or serious harm to property or the environment. Article 73 then attaches deadlines. Providers of high-risk systems report to the market surveillance authority immediately once a causal link is established or reasonably likely, and in any event within 15 days of becoming aware. Two days where the incident involves widespread infringement or serious disruption to critical infrastructure. Ten days where someone died. Article 72 requires a post-market monitoring plan that runs continuously rather than a review that happens when someone remembers.

Below that legal line, define your own severity tiers and the response each triggers. Most organizations discover their first AI incident has no owner, no severity, no page, and no communication path, because the incident process was written for outages. Add the AI failure modes to the existing runbook rather than writing a parallel one that nobody reads at 2am.

The audit trail

Logs of inputs, outputs, model version, configuration and human overrides, retained long enough to reconstruct a decision someone contests months later. Article 12 requires logging capability by design for high-risk systems, and retrofitting it after launch costs roughly twice what building it in would have.

Human oversight requirements that actually hold

Human oversight is the most commonly claimed control and the most commonly fake one. Article 14 of the AI Act sets a real bar: the system must be designed so a person can understand its behavior, monitor it in operation, interpret its output correctly, decide not to use it, and intervene or stop it. Adding a confirm button clears none of that.

Oversight that holds has four properties. The reviewer sees the information needed to disagree, which means the model's uncertainty and the main factors behind the output rather than a bare recommendation. The reviewer has the authority and the time to disagree, which is a staffing decision more than a design one. Overrides are logged and counted, so somebody can notice when the rate goes to zero. And automation bias is designed against, because a reviewer approving 500 recommendations a day is a rubber stamp with a payroll number, and the AI Act names this failure explicitly.

Decide the oversight mode per tier and write it in the register. Human in the loop, where a person approves every action before it takes effect. Human on the loop, where the system acts and a person monitors and can intervene. Human in command, where the system runs autonomously and a person holds the ability to shut it down. Agentic systems that chain tool calls need this decided at the level of the individual tool permission rather than the workflow, and the evidence that any of it works comes from evaluating the agent rather than from watching a demo.

Third-party and vendor model governance

Most of the AI in a mid-sized organization was not built there. It arrived inside a CRM, a recruiting tool, a support platform or an API call, and it is governed by whoever signed that contract, which is to say nobody.

Third-party governance has three parts. Procurement due diligence, which is a short standing questionnaire rather than an ad-hoc email: which model, hosted where, trained on what, is our data used for training, what is the evaluation evidence, what happens on model deprecation, which sub-processors touch the data, and can we get logs. Contract terms, where three clauses do most of the work: notice before a material model change, indemnity for training-data intellectual property claims, and an audit or evidence right proportionate to the risk tier. Continuous review, because the vendor who answered honestly in March swapped the underlying model in July.

The case that catches people is the AI feature added to software you already run. A tool you procured in 2023 as a document store ships an AI assistant in a routine release, and now a system in your minimal tier is reading everything and summarizing it somewhere. Governance has to include a rule for this: any new AI capability in an existing vendor product enters at intake like anything else, and someone has to be watching release notes for it to be caught.

Where AI is being integrated into systems you already run, which is the practical shape most of it takes, the governance work and the engineering work are the same work. That is one reason AI integration is easier to govern than a greenfield build: the surrounding controls already exist and you are extending them.

Mapping an AI governance framework to the EU AI Act, NIST and ISO 42001

The three reference frameworks are usually presented as alternatives. They are not. One is law, one is a certifiable management system, one is a voluntary vocabulary, and a single set of controls can satisfy all three.

The EU AI Act sets the legal floor

The EU AI Act is binding, structured around the four risk tiers, and it tells you what you must produce for high-risk systems. Penalties under Article 99 run to 35 million euro or 7% of worldwide turnover for prohibited practices, 15 million euro or 3% for most other obligations including the high-risk requirements and the general-purpose AI (GPAI) duties, and 7.5 million euro or 1% for supplying misleading information to authorities. Conformity for high-risk systems is demonstrated through a conformity assessment against those articles, which is why the technical documentation matters more than the policy.

NIST AI RMF gives your governance framework its vocabulary

The NIST AI Risk Management Framework, published as NIST AI 100-1 in January 2023, is explicitly voluntary and organizes work around four functions: GOVERN, MAP, MEASURE and MANAGE, across nineteen categories. GOVERN is cross-cutting and shapes the other three. It also names seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. The Generative AI Profile, NIST AI 600-1, published July 2024, adds twelve risks specific to generative systems including confabulation, data privacy, information security, intellectual property and harmful bias. If your governance answers have to satisfy a regulator or a customer's security team, this is the vocabulary they already know.

ISO/IEC 42001 is the one you can certify against

ISO/IEC 42001:2023 defines an AI management system in clauses 4 to 10, using the same Annex SL structure as ISO 27001, so an organization with an existing information security management system reuses most of the machinery. Annex A supplies 38 controls grouped into nine control objectives covering AI policy, internal organization, resources, impact assessment, the AI system lifecycle, data, information for interested parties, responsible use and third-party relationships. You select from it based on your risk and impact assessments and record the choices in a Statement of Applicability. Certification runs a stage 1 documentation audit, a stage 2 implementation audit, annual surveillance and recertification on a three-year cycle. ISO/IEC 23894:2023 gives the AI risk management method that sits underneath it.

Build the left-hand column once. Map it three ways. What you must not do is run three programs, because the artifacts overlap almost entirely and the duplicated effort is exactly the overhead that makes governance unpopular internally.

How AI governance matures alongside AI adoption

Governance designed for twenty systems will stop the first one from ever shipping, and governance designed for one pilot collapses at twenty. Both failures are common, and both come from copying a framework built for a different stage. The controls have to track the capability.

Stage one is where the honest look happens: whether data, infrastructure, skills, governance and use-case clarity can carry a model to production at all. Score each from one to three, treat a hesitant "sort of" as a one, and take the minimum rather than the average. A company scoring three across four dimensions and one on data is not 75% ready. It is blocked on data. If that answer has to survive scrutiny from people who do not report to you, the formal version is our AI readiness assessment.

Stage four is the one nobody budgets for, and it is a governance stage as much as an engineering one. The second use case only costs less than the first if the first left reusable guardrails, an evaluation harness and an approval pattern behind it. When project one is priced as a one-off, none of that gets built, and system ten carries the same governance cost as system one. Cost per outcome across successive use cases is the most honest measure of AI ROI we know, and it is also the clearest signal that your governance is reusable rather than bespoke. The mechanics of getting a working pilot to survive real load are covered in taking an AI implementation from pilot to production.

The failure modes an AI governance framework has to survive

Frameworks are judged by the failures they catch. These are the ones we see repeatedly, and none of them is a technology problem.

Two deserve elaboration because they are the expensive ones.

The review board as a queue starts as prudence and ends as a bottleneck. Every request gets individual scrutiny, the queue grows, and delivery teams learn that the way to ship is to not call it AI. You end up with worse risk exposure than having no governance at all, because now the systems are hidden as well as ungoverned. The fix is structural, not cultural: set the rules once per tier and audit compliance afterwards rather than approving each request in advance.

Governance theater is harder to spot because it looks like success. There is a policy, a committee, a slide with four pillars on it, and no evidence anywhere that a system was ever changed or stopped because of it. The diagnostic question is short. Name the last AI system this framework blocked, delayed or modified, and show the record. If nobody can answer, what you have is documentation.

A 30/60/90 plan to stand up an AI governance framework

A framework you cannot start on Monday is a diagram. Here is the shape of the first quarter, which is roughly the shape of the roadmap we hand back after an assessment.

Days 1 to 30: find out what you actually have. Build the inventory before writing a word of policy, and build it from evidence rather than from asking. Single sign-on logs, expense reports filtered for AI subscriptions, an import scan across your repositories, and a short conversation with each team lead. Name the executive sponsor and confirm they can stop work. Draft the risk-tier rubric with thresholds, then classify everything you found. The number of systems will surprise you, and the classification argument is the useful part.

Days 31 to 60: write the policy and build one gate. The policy is short and states what is permitted, restricted and forbidden per tier, with a named exception path. Then implement exactly one gate end to end, which should be intake, because it is the cheapest and it stops the inventory going stale the moment you finish it. Assign a model owner to every live system and fix the register rows that have none. Pick your reference framework at this point: the AI Act if it reaches you, ISO/IEC 42001 if a customer wants a certificate, NIST otherwise.

Days 61 to 90: run a real gate and prove it works. Take one high-tier system through the full pre-launch gate with the evidence pack: evaluation results against a baseline, impact assessment, model card, human oversight design, rollback plan. Hold the review, make an actual decision, minute it. Then run one incident tabletop against a plausible failure and find out how long it takes you to answer who owns this, what did it do, where are the logs. That exercise finds more gaps than a maturity assessment does, and it costs an afternoon.

One closing note on where this comes from, since it shapes the advice. We made a deliberate bet on building a senior, AI-native practice whose point is taking AI to production rather than leaving it in pilots, and governance is the part that decides whether a system is still running usefully a year later. The organizations that get value from AI are not the ones with the thickest policy. They are the ones who classified their use cases honestly, put one name against each system, built gates that occasionally say no, and kept the evidence.