AI Governance Framework: What It Is, Which Rules Apply, and How to Build One

Last reviewed 10 September 2026 against the AI Act as amended by the Digital Omnibus on AI.

Most companies write their first AI governance framework in a hurry, because somebody outside the company asked for one.

A customer's legal team adds an AI clause to a renewal. An insurer sends a questionnaire. A board member reads something over the weekend. A document nobody needed last quarter is due on Friday.

The rushed version has a predictable shape. Three pages of principles, a commitment to responsible AI, and not one sentence telling a single person what they may do on Monday morning. It passes the review. It is never read again.

A governance framework is the set of rules deciding who may do what with AI, and what happens when something goes wrong. This page covers what goes into one, which regulations might actually apply to you, and how to write a first version this week.

It is free and complete: nothing to download, no email required to read it. At the end there is a builder that writes the version specific to your company, if you want it.

One thing to say plainly, once: this is not legal advice. It is the structure a conversation with your counsel or your auditor should start from, instead of a blank page.

What an AI governance framework actually is

An AI governance framework is the written answer to three questions. Which AI work carries which level of risk. Who is allowed to approve each level. How often that gets reviewed.

That is the whole thing. Everything else in a governance document is detail hanging off those three answers.

Test it against a real Tuesday. Someone in marketing wants to paste a customer list into a chatbot to draft segment messaging. A framework that works tells them in under a minute whether that is allowed, and if not, who to ask. A framework that does not work offers a paragraph on the company's commitment to data stewardship, so they make the call themselves and nobody ever finds out.

What decides it is whether the document resolves a specific question for a specific person on a specific day.

Governance is also not AI ethics. Ethics is the set of principles you hold. Governance is the machinery that makes them happen: thresholds, named approvers, logs and review dates. A principle only becomes a control when somebody has to act on it.

Why you are being asked for one now

Three things changed at once, and none of them were the technology.

The law now has dates on it

The EU AI Act entered into force on 1 August 2024 and applies in stages:

• 2 February 2025: the banned practices, and the duty on providers and deployers to support AI literacy among staff working with AI. The Digital Omnibus softened this in July 2026, from guaranteeing a level of literacy to taking measures to build it.
• 2 August 2025: obligations on general-purpose AI models, national authorities and penalties.
• 2 August 2026: general application, including the transparency rules. If you build or deploy a system that talks to people, or you publish synthetic images, audio or video, this is the date that reaches you.
• 2 December 2026: the deadline for systems already on the market before August to meet the synthetic content transparency rules. The prohibitions on AI generating non-consensual intimate imagery and child sexual abuse material also start on this date.
• 2 December 2027: obligations on standalone high-risk systems under Annex III.
• 2 August 2028: obligations on high-risk AI embedded in regulated products under Annex I.

Those last two dates moved. Annex III was 2 August 2026 and Annex I was 2 August 2027, until the Digital Omnibus on AI entered into force on 27 July 2026. A compliance plan written a year ago is aimed at a deadline that no longer exists, and the obligations that did not move are now the closest ones.

Worth knowing how easy this is to get wrong: the Commission's own AI Act Service Desk still publishes the pre-amendment text of Article 113 and says so on the page. If the official legal text has not caught up, most secondary sources have not either.

The Act also reaches companies outside the EU. It applies where the output is used, not where the company is registered.

Your customers got there first

Procurement moves faster than legislation. AI clauses appeared in enterprise renewals long before any of the above was enforceable, and they ask concrete questions. Which models touch our data. Does our data train them. Who reviews the output before it reaches a customer. Can you send us the policy.

A vendor who cannot answer in writing loses the renewal to one who can. That is a commercial deadline, and it usually lands sooner than a legal one.

Auditors started asking

No standard added AI criteria. SOC 2 still runs on the Trust Services Criteria from 2017, whose 2022 revision updated the points of focus rather than the criteria themselves. What changed is what auditors ask for inside them: which third-party models you call, what your vendor assessment says, what your logs capture, who signed off on a model reaching production. The standard did not move. The evidence expected under it did.

The rules that might apply to you

This is the part most governance content skips, and it is the part a leader looking at the subject for the first time actually wants. Each regime below gets the same three lines: who it covers, what it wants, and what it does not do.

GDPR

Who it covers. Anyone processing the personal data of people in the EU or the UK, wherever the company itself sits.

What it wants. A lawful basis, a purpose declared up front, no more data than that purpose needs, and a real answer when somebody asks what you hold on them. Two parts bite hardest on AI. Article 22 gives people a right not to be subject to a purely automated decision with legal or similarly significant effects, which is why a human review step in a hiring, credit or pricing workflow is a legal control rather than a courtesy. And a data protection impact assessment is required before high-risk processing starts, not written up afterwards.

What it does not do. GDPR says nothing about model quality, bias testing, or whether the output is any good. It is a data law. A model can be entirely compliant and still be confidently wrong.

Worth knowing: GDPR has not been amended for AI. The European Commission proposed changes in November 2025 that would have let AI providers rely on legitimate interest for training data. The AI half of that package is in force. The data half, which is the half that touches GDPR, is still in negotiation. Plan against the GDPR you have.

The EU AI Act

Who it covers. Providers and deployers of AI systems placed on the EU market, or whose output is used in the EU. Being registered elsewhere is not an exemption.

What it wants. It sorts systems by risk rather than by sector. A short list of practices is banned outright. A defined set of high-risk uses, including AI in employment, credit, education, essential services and critical infrastructure, carries the heavy obligations: risk management, data governance, logging, human oversight, technical documentation, conformity assessment.

Below that sit the Article 50 transparency duties, and they land differently depending on your role. A provider of a system that talks to people has to disclose that it is a machine. A provider of a system generating synthetic audio, image, video or text has to mark the output in a machine-readable way. A deployer has to disclose a deepfake, and has to disclose AI-generated text published to inform the public on a matter of public interest, unless a person took editorial responsibility for it. Everything else the Act leaves alone.

What it does not do. It is not a data protection law and it does not replace GDPR. If your system touches personal data you answer to both. It also does not decide whether your AI is a good idea. It decides how much process you owe before you ship it.

The practical read for most companies: you are probably not high-risk, and some part of Article 50 probably reaches you. Which part depends on whether you built the system or bought it, and that is the first thing to establish with counsel. Those duties applied from 2 August 2026 and are the cheapest obligations in the Act to meet, and the easiest to forget.

HIPAA

Who it covers. US healthcare providers, health plans, clearinghouses, and their business associates. Build software touching protected health information for a covered entity and you are a business associate, in scope.

What it wants. The Privacy Rule limits what you may disclose. The Security Rule requires administrative, physical and technical safeguards, with a risk analysis behind them. For AI the sharp edge is the business associate agreement. Sending protected health information to a model provider is a disclosure, and it needs an agreement in place before it happens, not after. Most general consumer AI tools will not sign one.

What it does not do. It says nothing about clinical accuracy or model validation. HIPAA governs the flow of the data, not the quality of the inference.

Worth knowing: the Security Rule update proposed in January 2025 is still a proposal. HHS moved it to its long-term agenda, with July 2027 as the anticipated date for final action. The rule you comply with today is the one from 2013.

SOC 2

Who it covers. Nobody, legally. SOC 2 is not a regulation. It is an attestation your customers ask for, and increasingly a condition of the contract.

What it wants. That you describe your own controls across the criteria you select, and that an auditor tests whether they actually operated over a period. Security is mandatory. Availability, confidentiality, processing integrity and privacy are chosen.

What it does not do. It does not certify your AI. Looking at the AICPA's SOC suite, there is no AI module and no AI criteria. What it does is pull your AI controls into the same evidence discipline as everything else: model lineage, a vendor assessment per third-party model, logs with personal data redacted before they are written, and an approval record for anything in production.

Worth knowing, and it is the unsatisfying part: SOC 2 tells a customer you do what you said you do. It says nothing about whether what you said was enough.

ISO/IEC 42001

Who it covers. Anyone who chooses it. Published in December 2023, it is the first international management system standard for AI, and 42001:2023 is still the current edition.

What it wants. The same shape as ISO 27001, applied to AI. A defined scope, an AI policy, named roles, a risk assessment, controls, internal audit, management review, continual improvement. It is certifiable through a stage one and stage two audit, valid three years with annual surveillance.

What it does not do. It does not make you compliant with anything. It is a management system, not a legal standard. It also does not tell you what your risk appetite should be. It tells you to have one, write it down, and act consistently with it.

Worth knowing: it keeps turning up in enterprise security questionnaires ahead of any legal requirement to hold it, because it is the closest thing to a shared language between a buyer's security team and a seller's engineers.

The NIST AI Risk Management Framework

Who it covers. Nobody, by force. It is voluntary, American in origin, and used everywhere as a structure.

What it wants. Nothing. It is a framework, not a requirement. It sorts the work into four functions. Govern is the culture and the accountability. Map is understanding the context and what could go wrong in it. Measure is testing and tracking. Manage is acting on what you found.

What it does not do. It will not satisfy a regulator on its own and there is nothing to certify against. Its value is as a table of contents. If you do not know what a governance programme is supposed to contain, this tells you, and it does not charge you.

Worth knowing: AI RMF 1.0 was released in January 2023, and the Generative AI Profile, NIST AI 600-1, followed in July 2024 with more than two hundred suggested actions specific to generative systems. That profile is the more useful of the two, because it is the one written after generative AI reached everybody's desk. NIST is revising 1.0 under the White House AI Action Plan.

The layer people forget: US state law

Colorado passed the first broad state AI law in May 2024, then rewrote it before it ever took effect. Enforcement stopped first. xAI sued in the US District Court for the District of Colorado on 9 April 2026, the Department of Justice filed a companion complaint on 24 April, and later that month a magistrate judge entered a stipulated order under which the state attorney general agreed not to enforce the law until fourteen days after the court rules on xAI's preliminary injunction motion. The original 30 June 2026 effective date passed with nothing in force. SB 26-189, signed on 14 May 2026, then replaced it with a narrower disclosure regime starting 1 January 2027, and both xAI and the Department of Justice are expected to challenge that too.

Worth being precise about what happened there, because it is widely described loosely: no court has ruled the law unconstitutional. Enforcement is paused by agreement between the parties while the challenge proceeds.

Texas went the other way, with the Responsible Artificial Intelligence Governance Act live since 1 January 2026. There is no private right of action: the attorney general is the sole civil enforcer, with sector regulators able to sanction licensees on referral. Its core prohibitions, discrimination included, require proven intent, though the disclosure and government-use provisions do not.

The pattern matters more than either statute. State AI law is written, amended and delayed faster than most compliance calendars can track. A framework hardcoding one jurisdiction's rules ages badly. A framework naming an owner whose job is to watch for changes does not.

The four parts every framework has

Whatever regime you answer to, and whether you write three pages or thirty, a governance framework that works contains the same four things. The quickest way to see why each exists is to look at what happens without it.

1. Risk tiering

What it is. A small number of levels, each with real examples from your own business, and a different amount of process attached to each.

Three tiers is usually enough. Low is internal, reversible, and read by a person before it goes anywhere: an internal summary, tidying up notes, a first draft nobody else sees. Medium reaches a customer or touches personal data but stays reviewable: a drafted support reply, a marketing email. High affects somebody's money, employment, health or legal standing, or runs with no person in the loop.

Without it. Every AI question becomes a bespoke escalation. Either everything is treated as dangerous, so the sensible uses get blocked and people route around the policy privately, or nothing is, and a hiring screen ships with the same review as a meeting summary.

The examples are the part that matters. A tier with a definition and no examples gets argued about. A tier with five examples from your own company gets used.

2. Decision rights

What it is. A table saying who can approve what. The person who decides, not the people consulted.

Low tier: the team lead, or nobody, because it is allowed by default. Medium: a named owner, in writing, once per workflow rather than once per use. High: a small standing group with the authority to say no, and a documented reason on the record either way.

Without it. Two failure modes, both common. Either every decision funnels to one overloaded person and the queue becomes the reason people stop asking, or nobody owns it and each team quietly makes its own call. The second is worse, because it looks like nothing is happening.

The test is whether the table names roles that actually exist. “The AI governance committee” is not an answer if there is no committee.

3. A review rhythm

What it is. Dates, in a calendar, with an owner attached to each.

Two clocks run here. The register of what is actually in use should be current monthly, because that is how fast new tools appear and how fast a free trial becomes a production dependency. The framework itself is worth revisiting quarterly, after any incident, and after any change in what you are legally exposed to.

Without it. The framework describes a company that no longer exists. Somebody wrote it when the team had one AI tool. Eighteen months later there are eleven, four of them paid for on personal cards, and the document still lists one.

4. An escalation path

What it is. What a person does when something goes wrong, written for the person it goes wrong to.

It needs four things. Who to tell. How fast. What to preserve. And who decides whether to switch the system off. That last one is most often left out, and it is the only one that matters at two in the morning.

Without it. The first incident gets handled by whoever noticed it, on their own judgment, under time pressure, with no authority to stop anything. That failure shows up in a customer's inbox rather than in an audit.

The same four parts, written for your company

You now know what goes into a framework. The next question is what yours should say, and that turns on things a template cannot know: which regimes you actually answer to, how sensitive your data is, how far into production you already are, and who owns AI decisions today.

The AI Governance Framework Builder asks eight questions and writes it. About five minutes, and what comes back is risk tiers with examples from your industry, a decision-rights matrix, review cadences, a committee charter and escalation paths, in a document you can take into a board meeting.

Who should own it

The honest answer depends on size, and most governance advice hides that, because most governance advice is written by and for large organisations.

Under fifty people. One person, part time, with the authority to say no. Usually an operations, finance or technology lead. A committee at this size is three people meeting about a decision one of them could have made alone.

Fifty to five hundred. One named owner plus a standing group of three or four meeting quarterly: risk or legal, technology, and whichever function has the most AI in production. The owner does the work between meetings. The group exists so the owner is not carrying the decision alone.

Above five hundred, or in a regulated sector. A formal committee with a board sponsor, a charter, minutes and a route to the board. Here the paperwork is the point, because the organisation is too large for the decisions to sit in one person's head.

Two things hold at every size. It is rarely a good fit for IT alone, because the hardest calls are commercial and legal: whether you may put customer data into a vendor's model is a contract question with a technical component. And whoever owns it needs the authority to stop something. An owner who can only recommend is a reviewer. The role works only if a no is a no.

What a working framework looks like

A filed framework and a working one are usually the same length. The differences are small, and every one of them is about whether a specific person can act on a specific day.

A filed framework:

• Opens with principles and a statement of commitment.
• Defines risk in the abstract.
• Names committees rather than people.
• Has no dates in it.
• Lives somewhere you have to request access to.
• Was last edited on the day it was approved.

A working framework:

• Opens with what you may and may not do.
• Defines risk with examples from your own business.
• Names roles that exist, and the people holding them.
• Carries a review date and an owner on the front page.
• Is one link, findable by search, in the place people already work.
• Has an edit history, because things changed and it changed with them.

The reliable test costs nothing. Ask three people at random what they are allowed to put into a chatbot. If you get three different answers, the problem is distribution rather than the document.

How to start this week

You do not need to buy anything, and you do not need a committee to begin.

1. Write down what is already happening. One page: which AI tools are in use, by whom, paid for how, touching what data. This takes an afternoon of asking and the answer is always longer than expected.
2. Sort that list into three tiers, using the definitions above, with your own tools as the examples. Most of it will be low. The value is in finding the two or three things that are not.
3. Name one owner. One person, with the authority to say no, announced rather than assumed. Put their name at the top of the page.
4. Write the one rule people need most. For nearly every company that is the data rule: what may go into an AI tool, and what may never. Two lines, plain language, with examples on both sides.
5. Put a date on it. A review date and an owner on the front. Then send it to everybody, because a policy nobody has read is not a control.

That is a first framework. It is not complete and it is not meant to be. It is the version that changes what people do on Monday, which is more than most thirty-page documents manage.

Get the version written for your company

The five steps above give you a working draft. When you want the fuller version, the AI Governance Framework Builder writes it from eight questions about your organisation.

It asks about your size, your industry, the regimes you answer to, how heavily your team already works with AI, and who owns those decisions today. What comes back runs to roughly eight pages, and adds two sections this page has not covered: what to log and where to keep it, and a glossary of the terms your board will ask about.

It is free, and so is the page you have just read. The difference is that the builder's version is written for you.

If you would rather know where you stand before writing anything down, start with the AI Audit. If the question is sequencing rather than control, the AI Implementation Roadmap builds a 90-day plan. And if what you need first is the shorter document telling staff which tools they may work with, that is an acceptable use policy rather than a framework, and the AI Policy Generator writes one.

Governance is not the hard part of working with AI. Getting a team to the point where the framework has something to govern is. That is what The ADOPT Method™ is for.

Frequently asked questions

What is an AI governance framework?

An AI governance framework is the written answer to three questions: which AI work carries which level of risk, who may approve each level, and how often that gets reviewed. It is the machinery rather than the principles. A framework that works resolves a specific question for a specific person on a specific day, which is why risk tiers need examples from your own business rather than definitions in the abstract.

What should an AI governance framework include?

Four things, whatever your size or sector: risk tiering with real examples, a decision-rights table naming who approves what, a review rhythm with dates and owners, and an escalation path saying who can switch a system off. Larger organisations add a committee charter, a logging standard and a glossary. Everything else in a governance document is detail hanging off those four.

Who should own AI governance?

One named person with the authority to say no, supported by a small standing group rather than a large committee. Under fifty people that is usually one part-time owner. Between fifty and five hundred, an owner plus three or four people meeting quarterly. Above that, or in a regulated sector, a formal committee with a board sponsor. It is rarely a good fit for IT alone, because the hardest calls are commercial and legal rather than technical.

Does the EU AI Act apply to companies outside the EU?

Yes. It applies to providers and deployers placing AI systems on the EU market, and to those outside the EU whose system output is used inside it. For most non-EU companies the obligations that bite are the Article 50 transparency duties, which applied from 2 August 2026. Which of them applies depends on your role: a provider of a system that talks to people discloses that it is a machine and marks synthetic output in a machine-readable way, while a deployer discloses a deepfake and discloses AI-generated public-interest text that no person took editorial responsibility for.

When do the EU AI Act's high-risk rules apply?

They moved. Standalone high-risk systems under Annex III were due on 2 August 2026 and now apply from 2 December 2027. High-risk AI embedded in regulated products under Annex I was due on 2 August 2027 and now applies from 2 August 2028. Both changed when the Digital Omnibus on AI entered into force on 27 July 2026. What did take effect on 2 August 2026 as planned is the general application of the Act, including the transparency obligations.

Is an AI policy the same as an AI governance framework?

No, and confusing them wastes a lot of time. A policy tells staff what they may and may not do with the tools: which are approved, what may never go into them, when a person has to check the output. A framework is the layer above it, deciding how risk gets tiered, who approves what, and how the whole thing gets reviewed. Small organisations often need the policy first. Growing ones eventually need both, and the policy should read as though it came out of the framework.

If you take one thing from this page: do not start by writing principles. Start by writing down what your team is already doing, sort it into three tiers, and name the person who can say no.