The One-Page AI Governance Framework (Even in Regulated Industries)

What is an AI governance framework? Five decisions on one page

Picture a fifty-page AI policy landing in every inbox on a Monday. By Friday, a sales rep pastes a customer list into a free chatbot to tidy it up. The rule against that sat on page 31.

Nobody read page 31. Nobody ever does.

An AI governance framework is the short set of written rules for how your company uses AI. Ours fits on one page and holds five decisions. This guide shows you how to write it, test it and keep it alive.

Long policies feel safe to the people who write them. Our take: most are written to protect the author, not to guide the reader.

Write five decisions, not fifty pages

Governance is five decisions. Make each one once, in plain words, and most future questions answer themselves.

Data decides what may go into which tool. We sort it into three colors, covered next.

Access decides which roles use which tools. Our default: read widely, write narrowly, log every write. A write is any action that sends, posts, edits, deletes or spends.

Checks means every AI workflow that touches a customer names its check and how often it runs. No check, no customers.

Spend is a cap per team and per workflow, seen every week. A runaway bill is a governance problem before it is a finance problem.

Owner means a named person answers for every AI output. No orphan automations.

Why one page? A list people actually use has to be short.

Atul Gawande reports aviation's rules for checklists in The Checklist Manifesto, and they fit here. Five to nine items. Plain words in the reader's own language, on one page.

Aircraft makers also print a date on every checklist, because each one is expected to change. Your page needs one too.

Fifty pages is not thorough. It is unread.

Sort your data into three colors, and keep strict rules where red data lives

Data comes first. Every other rule on the page leans on it.

Green is anything you would print on a flyer: public pages, live ads, general research. Any approved AI tool may use it.

Yellow is internal: drafts, plans, sales notes without names. It goes only into business AI accounts whose contract keeps your data out of training.

Red is data that can hurt a person or break a law if it gets out. Customer names with health, money or card details, passwords, contracts. It stays in systems you control, or it goes out masked.

Masking means swapping the sensitive part for a placeholder before it leaves. The tool sends [PHONE NUMBER] instead of the number. When the answer comes back, it swaps the real one in.

Chip Huyen lays out this pattern in AI Engineering. She also names the three ordinary ways private data reaches an outside model.

Someone pastes it into a prompt. A builder writes it into an app's standing instructions. Or a connected tool pulls it from a database and hands it over.

Pasting is the famous one. Samsung staff put company secrets into a public chatbot, and the company banned the tool. A ban is what you get when nobody wrote the colors down first.

Strict rules belong only where red data lives. The Team Topologies authors make this case for software. Card-data rules should cover the one part that handles cards, not the whole system.

Splitting that part off shrinks what auditors must inspect. We apply the same logic to AI work. Fence the red workflows tightly and let the green ones move.

One color for everything puts red rules on green work. People will route around that by lunch.

Replace the AI risk heat map with ten numbers

Most AI governance templates include a risk heat map: likelihood 1 to 5, impact 1 to 5, a colored grid. It looks rigorous. It isn't.

Douglas Hubbard and Richard Seiersen collect the evidence in How to Measure Anything in Cybersecurity Risk. In one study, people read the phrase "very likely" as anything from 43 to 99 percent. Even with written definitions, 58 percent of answers broke the guideline.

Scores bunch up, too. In about 2,000 risk scores from five companies, 76 percent landed on a 3 or a 4. The five-by-five grid was really a two-by-two.

The grid also distorts what it shows. One study gave risk matrix designs a distortion score, and the average was above 100. For scale, the chart Edward Tufte famously called a whopping lie scored only 14.8.

So what goes in its place? Ten rows, each with two numbers.

For each AI risk, write the chance it happens at least once in the next 12 months. Then write a cost range: a low number you are 95 percent sure the cost will exceed, and a high number you are 95 percent sure it will stay under.

Now compute the expected yearly loss. The book's shortcut: chance times (0.65 times the low plus 0.35 times the high). Sort the rows by it and fix the top ones first.

For example, say there is a 30 percent chance a staff member pastes customer data into an unapproved tool. The cost would run $20,000 to $400,000. That row's expected loss is $45,900 a year.

Controls earn their place with the same math. Return on control is the loss a control removes, divided by its cost, minus one.

Example: say business AI accounts plus masking cut that 30 percent chance in half, for $5,000 a year. The return is 359 percent. Not bad for $5,000.

Overkill? The book puts a first pass at an hour or two. The heat map took a meeting and told you nothing.

Approve AI changes with a second person and a log, not a committee

The reflex in a nervous company is an AI review board. Every new use waits for the monthly meeting.

The Accelerate research team compared approval styles across the software teams in their surveys. When an outside body approved every change, teams shipped slower and recovered from outages slower. The approvals did not lower the share of changes that broke something.

Slower, and no safer. Peer review did better. That finding is about software; applying it to AI is our reading.

Need separation of duties for an auditor? The same team describes two mechanisms that satisfy it. First, someone who did not build the change reviews it and records the approval in a system of record.

Second, changes reach the live system only through one logged path. For an AI workflow, the record can be a ticket, a pull request or the change log on the page itself.

The auditor sees who changed what, when, and who said yes. No meeting required.

A few actions still need a human click every time, like a database command that deletes records. Our list: anything that messages customers, moves money, deletes or edits records, publishes in public, or changes who has access.

How to build an AI policy nobody follows, in four easy steps:

1. Form a committee that meets once a month.

2. Write fifty pages so every risk is covered somewhere.

3. Score every risk red, amber or green, then argue about amber.

4. Ban the tools. Act surprised when people switch to personal accounts.

The research team has a name for this: risk management theater. Boxes get ticked so someone can say they followed the process. It feels safe, and it is bullshit with a calendar invite.

Govern each AI workflow with four lines that live next to it

The page governs the company. Each automation needs its own copy of the rules, written where it runs.

Picture an automation that runs at 3 in the morning. "A human owns every output" means nothing to it unless the owner's name sits in its file.

This is what people mean by AI workflow governance, or governance as code. Four lines at the top of every workflow:

Scope says what starts it, which data color it may touch, and what it may never touch.

Limits are the spend cap, rate limit and blocked actions. They are enforced outside the AI model, so they hold even when the model misbehaves.

Check says how output is reviewed, and how often. A sampled review every Friday counts; "we look at it sometimes" does not.

Owner and off switch means one named person, and a way to stop it in under a minute. Someone has actually practiced pressing it.

Then track two numbers on every guardrail. The violation rate is the share of bad requests that got through. The false refusal rate is the share of fine requests it blocked.

Why both? A guardrail that refuses everything scores zero violations and helps nobody. We score every guardrail this way.

The four lines live in the agent harness, the code that runs the workflow. See also how to evaluate AI agents and how to control AI spend.

A rule that is not in the file does not exist at 3 in the morning.

How do regulated industries govern AI without stalling?

They start where no regulated data lives, and they reuse the controls they already have.

Healthcare, finance, insurance and law flip the question. Not "can we use AI?" but "which workflows hold no regulated data at all?"

Marketing drafts and research summaries usually qualify. That green zone needs no regulator conversation.

For the red zone, your compliance machinery is the asset. The access controls, logs and reviews that govern people extend to machine work.

Regulated firms are not doomed to be slow, either. In the Accelerate data, highly regulated companies showed up among high, medium and low performers alike.

Build controls into the platform once. A small US government team called 18F built a hosting platform that covered 269 of the 325 security controls a moderate-impact federal system needs. Systems on it went live in weeks instead of months.

Then govern like a building inspector. Gawande describes inspectors who do not redo the engineering. They have builders sign that the right checks are in place, then spend their own time on the riskiest work.

For AI, each team signs off on its four lines. The page owner spends review time on the side projects nobody approved. More on AI in law and accounting firms.

One rule holds everywhere: a named human owns every consequential output, and the log can prove who.

The NIST AI Risk Management Framework sorts the work into govern, map, measure and manage. The EU AI Act sorts AI uses by risk and puts most of its duties on a short list of high-risk uses. Dates and details change, so they live in the box below.

Regulators do not ask that AI be absent. They ask that accountability be present.

Review the page every quarter, and sooner when the evidence changes

A governance page that never changes is already wrong. The tools change every few months.

In Thinking in Systems, Donella Meadows holds up the Montreal Protocol as a rule built to learn. Signed in 1987 to protect the ozone layer, it set targets for cutting the worst chemicals. It also required monitoring and a meeting to revise the schedule.

The damage turned out worse than anyone expected. So in 1990, three years later, that meeting sped up the schedule and added chemicals.

Copy that shape. Our page carries a review date, an owner, and three triggers for an early review: an incident, a new tool or data connection, or a new legal deadline.

When people work around a rule, treat it as feedback, not defiance. A rule everyone dodges is usually a bad rule.

Publish the page. Name the owner. Date it.

If staff already use AI on personal accounts, start with guardrails for shadow AI. If nobody can say who the owner is, read who should own AI.

Write your one-page AI governance framework with AI

Paste the prompt below into your preferred AI. It asks about your company, your data, your tools and your rules, one question at a time.

It drafts the five decisions, the three colors, a ten-row risk list and the four lines for your riskiest workflow. It never invents a chance or a cost. It asks you.

It is not legal advice. If you build a high-risk system under the EU rules, take the draft to counsel.

Do three things this week

1. Run the prompt and print the page.

2. Pick the one workflow that touches red data. Write its four lines and name its owner.

3. Retire the heat map. Give each risk a chance and a cost range instead.

Next, give each workflow a written brief with an AI agent job spec. Rolling out coding tools? Read AI coding agents for enterprise teams.

Remember page 31? On a one-page policy, there is no page 31.

Fifty pages is a filing cabinet. One page people read is a seatbelt.