An AI governance
framework that people
actually follow.
Most AI policies are a page of prohibitions written by someone who has never used the tools, and everyone routes around them by lunchtime. A governance framework that works answers seven questions, names an owner for each, and stays short enough that a manager can hold it in their head.
Governance is a set of
decisions, not a document.
AI governance is how a company decides what its AI systems are allowed to do, who approves them, how they're monitored, and who answers when one of them is wrong. That's the whole scope. Everything else in a governance program is machinery for making those decisions consistently instead of one argument at a time.
The reason so many programs fail is a mismatch of scale. A company with two hundred employees adopts a framework designed for a bank, produces forty pages nobody reads, and ends up with less real control than it had before, because the sanctioned path is now so slow that everyone uses the unsanctioned one. AI governance for small business should fit on two pages and name three people.
This guide is the framework I use, written to be run without me. The engagement version maps it onto NIST AI RMF, ISO/IEC 42001 and the EU AI Act where a customer or a regulator requires it. Start with the seven decisions regardless. A company that can answer them has better governance than one holding a certification and no clear owner.
Also known as: AI governance framework for business, AI governance playbook, responsible AI policy, AI use policy, AI management system, AI risk framework.
Seven decisions.
Each with a named owner.
Write the answers down, publish them where people work, and revisit them quarterly. That is a governance program.
What data may go where
The single most consequential decision, and the one most policies fudge.
- →Classify data into three tiers, not seven. People remember three
- →Name which tools are approved for each tier, by name
- →State plainly whether vendors may train on your inputs
- →Say what happens with customer data you hold under contract
What AI may decide alone
Where the line sits between a system that recommends and a system that acts.
- →List the decisions that always require a human, and why
- →Define the confidence threshold for autonomous action, per workflow
- →Specify what an agent does when it isn't sure
- →Set spending and irreversibility limits on anything that acts
How a new use case gets approved
The path from idea to production, short enough that people use it.
- →One intake form, under ten questions
- →A fast lane for low-risk internal use, and a real review for the rest
- →A named approver with a response-time commitment
- →A register of what's approved, live, and retired
How quality is measured
Without this, governance is a set of opinions about systems nobody is scoring.
- →An evaluation set per production system, built from real cases
- →A scoring cadence and a threshold that triggers action
- →Drift monitoring, since model and vendor changes are outside your control
- →A named owner for each system's output quality
What happens when it's wrong
Decided in advance, because deciding it during an incident goes badly.
- →How an incident gets raised, and by whom
- →Who can switch a system off, and how fast
- →Customer notification thresholds, agreed with legal
- →A post-incident review that changes the system, not just the log
Who is accountable
One name per system, and one name for the program as a whole.
- →An accountable executive for AI overall
- →A business owner per production system
- →Where the CIO's authority ends and the AI owner's begins
- →What the board sees, and how often
What the rules are for everyone else
The employee-facing page, which is the only part most of the company will read.
- →The approved tools, listed by name and kept current
- →The three things never to paste into a chatbot
- →How to ask for something that isn't on the list
- →A stated position that using AI well is expected, not merely tolerated
Six AI risks worth
writing down.
The AI risks for business that I actually see cause damage, ranked by frequency rather than in the order the risk literature prefers.
Data leaving quietly
Employees pasting customer records, contracts or source code into consumer tools. The most common real incident by a wide margin.
Confidently wrong output
A system produces a plausible answer, someone acts on it, and nobody catches it because there was no review step and no evaluation.
Contractual breach
You promised a customer their data stays in a region or isn't processed by subprocessors. A vendor's default settings just broke that.
Vendor concentration
Your workflow depends on one model provider's pricing and availability, with no fallback and no way to switch quickly.
Cost drift
Usage grows, prompts get longer, and the monthly bill triples with nobody assigned to watch it. Boring, and it kills programs.
Regulatory exposure
Obligations under the EU AI Act, sector rules, or state privacy law that attach to a system you already deployed.
Who sits on an
AI governance team?
Smaller than you think. Four people is the right size for a mid-market company: an accountable executive who owns the program, someone from legal or compliance, someone from IT or security, and an operator from whichever part of the business uses AI most heavily. That last seat is the one companies leave out, and it's the one that keeps the policy connected to how work actually happens.
Meet monthly, not weekly, and give the meeting a fixed agenda: new use-case requests, the register of what's live, any quality or cost thresholds that were breached, and anything that changed externally. Thirty minutes is usually enough once the framework is written. A governance body that needs two hours a month is either doing the AI owner's job for them or has too many people in the room.
For a genuinely small business, under about fifty people, this is two people and a shared document. The AI governance team matters less than having a single accountable person, because the failure mode at that size is never insufficient process. It's that nobody owns it at all.
Where ISO 42001
and the rest fit.
AI compliance with ISO 42001 is the certifiable route. ISO/IEC 42001 is the management-system standard for AI, structured like ISO 27001: policy, roles, risk assessment, controls, internal audit, continual improvement. Certification is the whole reason to take it on. Pursue it when a customer, an insurer or a procurement process is asking for evidence rather than assurances. It tells you how to run a program, not what your AI should be allowed to do.
NIST AI RMF is a voluntary US framework organized around four functions: govern, map, measure and manage. It's free, sensible, and the best starting vocabulary for a company that wants structure without a certification project. Most of the seven decisions above map onto it cleanly.
The EU AI Act is law rather than a framework, and it reaches US and Canadian companies whose systems are used in the EU or whose outputs are. Obligations scale with risk classification, and the deadlines are staged. The practical move is to classify your systems early, because a system already in production is much more expensive to bring into compliance than one being designed. If any of these apply to you, that's the governance engagement rather than a self-serve framework.
None of this is legal advice. On regulatory obligations, get counsel who knows your sector and your jurisdictions.
A policy people route around is worse than no policy. It gives you the paperwork of control and none of the control.
About governance.
What should an AI governance framework include?
Seven decisions, each with a named owner: what data may go into which tools, what AI is allowed to decide without a human, how a new use case gets approved, how output quality is measured, what happens when a system is wrong, who is accountable overall and per system, and the short employee-facing rules. Everything else in a governance program exists to make those decisions consistently. If your framework runs to forty pages and doesn't clearly answer all seven, it's documentation rather than governance.
How does a small business do AI governance?
Two pages and two people. Classify your data into three tiers, name the approved tools per tier, list what always needs a human in the loop, and name one accountable person. Add a single-page intake for new use cases and review it monthly. That's a complete program at small scale. Adopting an enterprise framework at fifty employees produces documents nobody reads and less real control than the simple version.
Who should be on the AI governance team?
Four people at mid-market scale: an accountable executive owning the program, someone from legal or compliance, someone from IT or security, and an operator from the part of the business using AI most. The operator seat is the one most often skipped and the one that keeps the policy realistic. Meet monthly with a fixed agenda covering new requests, the live register, breached thresholds and external changes.
What are the biggest AI risks for a business?
In order of how often they actually cause harm: employees putting sensitive data into unapproved tools, confidently wrong output that nobody reviewed, breaking a commitment you made to a customer about their data, depending on a single model vendor with no fallback, cost drift as usage grows unwatched, and regulatory exposure on systems already in production. Notice that the first two are behavioral and are addressed by making the sanctioned path genuinely easier than the unsanctioned one.
Do we need ISO 42001 certification?
Only if someone is asking for it. ISO/IEC 42001 is the certifiable management-system standard for AI, and it's worth pursuing when customers, insurers or procurement want evidence rather than assurances, or when you sell into regulated buyers who have started asking. If nobody is asking, adopt the structure without the certification: run the seven decisions, keep a register, and build the evidence trail so certification later is a formality rather than a project.
How do we handle shadow AI without banning everything?
Banning drives it underground, which is strictly worse because you lose visibility along with the control. The approach that works is to make the sanctioned path faster than the unsanctioned one: provide good approved tools, publish the list by name, keep it current, and make the request process for something new take days rather than months. Then monitor the surface. Enforcement works when compliance is easy and fails when it isn't, and that's a design problem rather than a discipline problem.
Related paths.
AI Governance & Risk
The engagement: the framework built for your company and mapped to the standards that apply.
Who should own AI?
The accountability question, answered properly: CEO, CTO, CIO, or a seat of its own.
Chief AI Officer vs CIO
Where the two seats divide on data access, vendors and production operations.
Got a policy nobody
follows?
Send me what you have. I'll tell you which of the seven decisions it's actually making and which ones it's avoiding.