AI Governance Framework: What It Is and How to Build It

An AI governance framework is the system that keeps a company's AI use visible and controlled: a named owner, a register of the AI systems in use, rules of use, decision thresholds and a recurring review. It is a way of working, not a document, and a small company can set one up in a few working days.

Most companies now have an answer to "do you use AI?". Far fewer have an answer to "who decides what your AI is allowed to do?". That second question is what an AI governance framework exists to answer - and in 2026 it stopped being optional homework. McKinsey's State of AI trust research (surveyed December 2025 to January 2026, around 500 organizations) found that only about a third of organizations reach solid maturity in AI governance. The rest run AI on defaults and good intentions.

This guide explains what a governance framework actually is, how it differs from an AI policy, where NIST AI RMF, ISO/IEC 42001 and the EU AI Act fit, and how to build a working version without a compliance department. Written for companies that use AI in daily work, not for enterprises with a dozen committees.

Updated: October 2026. We clarified the wording of the AI Act Article 4 duty: today it is a duty to promote AI literacy.

What is an AI governance framework?

An AI governance framework is the system a company uses to keep AI use visible and controlled: who is accountable, which tools are approved, how risks get checked, and when a human steps in. It is not a single document. It is a small set of roles, rules and recurring reviews that stays alive as tools and models change. Standards like NIST AI RMF and ISO/IEC 42001 describe how to structure one; regulation like the EU AI Act increasingly assumes you already have one.

The simplest test of whether you have a framework: when an AI tool in your company does something unexpected, does everyone know who handles it? If the honest answer is "we'd figure it out", you have AI adoption without AI governance. That combination is common - IBM's Institute for Business Value study (June 2026) found two-thirds of CIOs and CTOs are held accountable for AI systems they do not fully control. Accountability without control is exactly the gap a framework closes.

Why isn't an AI policy enough?

A policy is a document; a framework is a system. The policy tells people what is allowed. The framework makes sure someone owns the answer when reality moves - a new tool shows up, a model update changes behavior, an agent gets access to the calendar. Documents age quietly. Systems have a review rhythm, so they notice.

A useful way to see the difference: the policy is one of the framework's parts, not the other way around. We covered what goes into the document itself in what an AI policy should include - rules of use, data boundaries, approved tools. A framework wraps that document in four more things the document cannot do for itself: an owner, a register of what is actually in use, decision thresholds, and a recurring review.

Companies that stop at the policy usually discover the gap the same way: the document says "employees may use approved AI tools", and nobody can list which tools are actually in use. The list is the framework's job, not the policy's.

NIST AI RMF, ISO 42001, EU AI Act - what's the difference?

NIST AI RMF is a free, voluntary method for thinking about AI risk; ISO/IEC 42001 is a management standard you can get certified against; the EU AI Act is binding law. The first tells you how to think, the second how to prove it, the third what you must do. They get mixed up constantly, and they are three different kinds of thing:

The NIST AI Risk Management Framework is the best free starting point: it will not tell you what to build, but its four functions are a complete list of what a framework has to handle - set governance, know your systems, check them, act on what you find. NIST also published a dedicated Generative AI Profile in 2024 for the risks specific to tools like chat assistants.

ISO/IEC 42001 matters when someone asks you to prove it. Certification means an external auditor checks your AI management system against the standard's requirements. For most companies under a few hundred people it is a later step, not the first one - worth knowing it exists, because enterprise procurement teams have started asking.

The EU AI Act is not a framework and does not certify anything - it assumes you can answer framework-type questions. Its duty to promote AI literacy (Article 4) has applied since February 2025, and August 2, 2026 was the regulation's main application date, which brought the transparency rules of Article 50: people interacting with an AI system have to know it is one. We broke down what applies to whom in our EU AI Act guide. The through-line: every one of these obligations is easy if you know what AI you run and who owns it, and awkward if you do not.

How do the four NIST AI RMF functions map to a small company?

Govern, Map, Measure and Manage - four questions about your AI in the order a company can actually answer them: who is accountable, what do we run, how do we check it, and what do we do about what we find. NIST released AI RMF 1.0 in January 2023 and treats Govern as cross-cutting - it sits inside the other three rather than next to them. The vocabulary sounds institutional. The content maps cleanly onto the five elements of a working framework described below:

What the mapping is good for: when a client or an auditor asks which framework you follow, "our setup answers the four NIST functions" is a truthful answer backed by a register and a review date, rather than a certificate you do not have. Borrow the four questions, keep your own words.

What does AI risk management look like if you buy AI instead of building it?

Four risks carry almost all the weight for a company that buys models rather than trains them: data leaving through a tool nobody registered, an action taken on a wrong output, a vendor changing terms or model behaviour underneath you, and the obligations you hold as a deployer even though someone else built the system. There is no official list of AI risk types, so treat that as our reading of what applies, not a standard.

The register and the thresholds do most of the work here. A risk you wrote down has an owner and a line someone decided in advance; a risk sitting in a private chat tab has neither. NIST puts third-party and supply-chain risk inside the Govern function for the same reason - for most companies the AI risk is somebody else's system running inside your process. An AI audit is what you run when writing it down stops being enough, usually once an agent touches customer data.

What is AI compliance, and how is it different from governance?

AI compliance is proof that your use of AI meets the rules that apply to you today - the EU AI Act, GDPR, sector regulation, the contracts you signed with clients. AI governance is the system that keeps you compliant after things change. Compliance is a snapshot; governance is the mechanism that takes the next one.

The distinction matters because the ground moves. A model update changes what a tool does with your data. A new hire connects a tool nobody registered. The Digital Omnibus rewrites an article you built a process around. A company that only "did compliance" in March has no way of knowing whether it is still compliant in September. A company with a framework has a named owner, a register and a review date, so the question gets asked on schedule instead of by a regulator.

In practice, the smallest working AI compliance setup is the framework's five elements applied once: an inventory of the tools in use, a written AI policy, one named risk owner, a review of the vendors that see client data, and an AI audit of any system that talks to customers or touches personal data. For the legal side, what the EU AI Act actually requires from a small business covers the obligations one by one; for the audit itself, see AI Trust Layer.

What does a working framework contain?

Five elements: a named owner, a register of the AI systems in use, rules of use, decision thresholds, and a recurring review. Everything else in the enterprise playbooks - AI councils, ethics boards, model risk committees - is scale, not substance.

1. An owner. One named person accountable for AI in the company. Not a committee: in a 20-200 person company, a committee is how a topic becomes nobody's job. In McKinsey's State of AI survey (March 2025), 28% of organizations using AI said the CEO personally oversees AI governance - in a small company that is often the honest answer, because the CEO is the one signing off on tools anyway.

2. A register. A list of every AI system in use - including the ones employees brought in themselves - with what data each one touches and what it can do. This is the element that finds AI tools outside the company's control, and it overlaps almost entirely with what the EU AI Act expects you to know about your own systems. Where employee tools send data is its own topic - we mapped it in where your company data goes when using AI.

3. Rules of use. The AI policy - the document. Which tools are approved, what data may go into them, what must never. This is the part most companies already have, and the part that does the least on its own.

4. Decision thresholds. For each system: what it does autonomously, what needs human approval, what it must not do at all. This is where human oversight stops being a principle and becomes configuration.

5. A review rhythm. A recurring look - quarterly is realistic - at the register, the thresholds and the incidents since last time. Models update, tools change terms, employees adopt new ones. A framework without a review date is a policy with extra steps. When the stakes rise - an agent touching customer data, a client asking for assurance - the review becomes an external AI audit, which tests the system the way an attacker would rather than taking the register's word for it.

How do AI agents change governance?

They raise the stakes from wrong answers to wrong actions. A chatbot that fails gives someone bad text. An AI agent that fails sends the email, books the slot, changes the record - the failure executes. That is why element four, decision thresholds, moves from the appendix to the center of the framework the moment agents show up: which actions run automatically, which wait for approval, which are off the table entirely stops being philosophy and becomes literal configuration in the agent's setup.

The data says this is where governance is weakest. In McKinsey's 2026 trust research, agentic AI governance scores lag behind data and technology capabilities in every region surveyed. Companies got good at deploying agents faster than at deciding what agents may do - and the gap is widest exactly where the consequences are largest.

If you are choosing or deploying agents right now, set the thresholds before go-live, not after the first incident. It is a one-page exercise: list the agent's possible actions, mark each as auto / approval / never. An agent vendor who cannot implement that list is telling you something important. We write that list before any internal agent goes live, and onboarding your team on how to approve, correct and reject its work is part of the build. This list, not a fixed ratio, is what makes the 30% rule in AI real.

What does an AI governance framework look like for a small business?

The same five elements, a tenth of the apparatus: one owner instead of a council, three documents instead of a management system, and days of internal work instead of a budget line. The framework guides from large cloud and data platforms assume a risk function, a legal team and a product to enforce policy in. Read them for the vocabulary, not the org chart.

The owner is someone who already decides. In a company of 10-200 people, whoever approves the tool spend is the de facto owner of AI risk. Writing that name down changes nothing about the workload and everything about who answers when a tool misbehaves.

The minimum document set is three files. A one-page policy, a register (tool, owner, data it touches, what it may do), and a threshold sheet for anything that acts on its own. A spreadsheet is a legitimate register. Anything past those three is documentation you will not keep current.

The cost is time, not licences. A few working days in the first month, then roughly an hour a quarter to review.

What to skip. Ethics boards, model cards and bias-testing pipelines for models you did not train, multi-tier risk taxonomies copied from an enterprise template, and ISO 42001 certification before a client asks for it. None of them are wrong; they describe a company that builds its own models. You buy yours, so the job is knowing which ones you run, what they touch and where the line sits.

What does an AI governance framework template look like?

Three files: a register of the AI systems in use, a threshold sheet for anything that acts on its own, and a one-page policy. The two tables below are the structure - copy the columns into a spreadsheet and fill them in this afternoon. The example rows are there to show the level of detail, not to be kept. The third file we published separately as a free AI policy template. That is the whole documentation set; anything beyond it is paperwork you will not keep current.

1. The AI system register

One row per system, including the ones that arrived without a decision. The Status column is what turns a list into governance - it records that someone looked.

2. The threshold sheet

One row per action the system can take, not per system. Three settings only: auto, approval, never. Anything you cannot place is a sign the action was never specified clearly enough to configure.

3. The quarterly review agenda

An hour, five points, one named person running it. The output column matters more than the meeting: a review that changes nothing on paper did not happen.

Implementation is mostly the first pass: the register takes an afternoon of asking, the thresholds take a conversation per system that acts, and the policy is the file you already have or the template above. If you add a fourth file, make it a one-line log of who reviewed what and when. That log is the difference between a framework you have and a framework you can show.

How do you build a framework without a compliance department?

Start from the five elements and treat it as days of work, not months.

Week one: owner and register. Name the owner. Then inventory - ask every team what AI tools they actually use, including personal accounts. The first register is usually a spreadsheet and usually a surprise. Amnesty helps: the goal is a complete list, not a list of culprits.

Week two: rules and thresholds. Write or update the policy against the real register, not the imagined one. Then set thresholds for anything that acts - agents, automations, anything with access to mail, calendars or customer data.

Week three: rhythm and proof. Put the quarterly review in the calendar with the owner's name on it. Document the AI training people get - under the AI Act's Article 4 the duty to promote AI literacy already applies, and documented training plus a register are the kind of evidence that works in your favor if a regulator ever asks (Article 99(7)); the Act also caps SME fines at the lower of the two calculation methods (Article 99(6)), a detail written for exactly the companies this guide is for.

Cost, honestly: the framework itself is internal working time - realistically a few working days spread over a month. Paid help makes sense at two points: an external audit when you need the system tested rather than described, and ISO 42001 certification when a client contract demands it - a separate project measured in months, not days, which is why it is a milestone, not a starting point.

This order - visibility first, certification later - is the same logic we build into AI Trust Layer: make what the AI does visible and bounded first, because every later step depends on it.

Frequently asked questions

Is an AI governance framework required by law?

Not as such - no law says "you must have a framework". The EU AI Act requires pieces of one: knowing your systems, transparency toward users, promoting AI literacy for staff. A framework is the practical way to keep those obligations covered instead of rediscovering them one by one.

What is the difference between an AI governance framework and an AI policy?

The policy is a document with rules; the framework is the system around it - owner, register, decision thresholds, review rhythm. The policy is one of the framework's five elements. A policy without the other four goes out of date without anyone noticing.

NIST AI RMF or ISO 42001 - which should a smaller company use?

NIST AI RMF first: it is free and works as a checklist of questions your setup should answer. ISO/IEC 42001 is a certifiable management standard - relevant when an enterprise client or regulator asks for proof, not on day one.

What are the four functions of the NIST AI RMF?

Govern, Map, Measure and Manage: who is accountable, which AI systems you run, how you test and monitor them, and what you do about the risks you find. NIST released the framework as AI RMF 1.0 in January 2023 and it is free to use.

What are the four pillars of AI governance?

There is no official list, and that is worth saying plainly: sources count four, five or six pillars and none of those counts is a standard. NIST works in four functions - Govern, Map, Measure, Manage. We work in five elements: owner, register, rules, thresholds, review. ISO/IEC 42001 uses a management-system structure instead. Pick one and stay with it. The count matters far less than whether a named person owns the result.

How long does it take to set up?

The working minimum - owner, register, rules, thresholds, review date - is days of internal work spread over a few weeks. ISO 42001 certification is a separate project measured in months.

Who should own AI governance in a small team?

One named person close to daily operations - often the CEO in practice, sometimes the person who runs tooling. What matters is that the name is written down. "IT handles it" is how it becomes nobody's job.

Does a 20-person company need an AI governance framework?

Yes, but the version that fits is small: a named owner, a register of the tools in use, one page of rules, thresholds for anything that acts on its own, and a date to look again. At 20 people the risk is rarely a rogue model. It is that six people use six tools nobody listed, and no one can say which client data has already left the building.

Does a framework cover the ChatGPT accounts employees already use?

Yes - that is largely the point. The register captures tools people actually use, including private accounts, and the rules say what may go into them - and where that data actually ends up is worth knowing before you write those rules.

Is AI compliance the same as the EU AI Act?

No. The AI Act is one obligation among several. AI compliance also covers GDPR when personal data goes into a tool, the confidentiality clauses in your client contracts, sector rules (finance, health, legal) and the terms of the AI vendors you use. A company can satisfy Art. 4 of the AI Act and still be in breach of GDPR because an employee pasted a client file into a free ChatGPT account.

What is the smallest working AI compliance setup for a small business?

Five things, each written down: an inventory of the AI tools actually in use (private accounts included), a short usage policy, one named person who owns AI risk, a check of which vendors see client data and under what terms, and an audit of any AI system that faces customers or processes personal data. That is a few days of work for a company with under 50 people, and it is the baseline the framework then keeps current.