Building an AI Governance Framework: A Working Checklist

Every AI governance framework we've reviewed has the same three sections: a policy statement, a risk classification scheme, and an approval workflow. Almost none of them survive the first time someone in product ships a model without asking first — because the framework was built to satisfy an audit, not to change how decisions actually get made.

This guide is the order we'd actually build things in, based on what tends to break first.

Start with an inventory, not a policy

You cannot govern what you cannot see. Before writing a single policy line, get a real answer to: where is AI already running in this company? Not "where did we approve AI" — where is it actually running, including the marketing team's ChatGPT-drafted copy, the vendor-embedded recommendation engine nobody reviewed, and the fraud model that predates the governance program entirely.

A workable inventory captures, per system:

• What it does and what decision it influences (or makes outright)
• Who owns it — a name, not a department
• What data it touches, and whether any of that data is regulated (health, credit, employment, biometric)
• Whether a human can override its output before that output affects someone, and whether anyone actually does

If this inventory takes less than two weeks to build, it's incomplete. Shadow AI — tools adopted by individual teams without going through procurement — is the norm, not the exception, and it's usually where the real exposure lives.

Classify risk by consequence, not by technology

The instinct is to classify systems by what kind of AI they use (generative, predictive, computer vision). That's the wrong axis. Classify by what happens if the system is wrong.

A useful three-tier split:

1. Consequential — the system's output materially affects a person's access to employment, credit, housing, healthcare, or legal standing. This is where the EU AI Act's "high-risk" category and most U.S. state laws concentrate their requirements, and it's where your governance effort should concentrate too.
2. Operational — the system affects internal efficiency or customer experience but doesn't determine access to something consequential. A support-ticket triage model. An internal search tool.
3. Exploratory — pilots, prototypes, anything not yet in production with real users.

Most frameworks try to apply one review process to all three tiers and it collapses under its own weight — either the consequential systems get a review that's too light, or the exploratory ones get bottlenecked behind a process built for the consequential tier. Match the rigor to the tier.

Assign accountability before you assign process

A governance framework with no named accountable owner per system is a framework that will be blamed on "the process" when something goes wrong, and processes cannot be held accountable. For every consequential system, you need one person whose job description would credibly include "explain this system's behavior to a regulator." That's rarely the engineer who built it and rarely the executive sponsor — it's usually a product or risk owner who sits close enough to the system to actually know it, and senior enough to stop its deployment.

Build the review gate at the point of no return, not at the point of ideation

The most common governance failure isn't a missing policy — it's a review gate placed too late to matter. If your AI review happens after a system has already been built, integrated, and demoed to a customer, the review is theater; killing the project at that point is organizationally almost impossible. The gate has to sit before the point where reversing course becomes expensive: before procurement signs a vendor contract, before the model goes into a production data pipeline, before it's in front of a real user.

What a credible framework produces, on paper

When this is working, you should be able to hand a regulator, an auditor, or an enterprise customer's security team three things without scrambling:

• A current systems inventory with risk tier and named owner per system
• Evidence that the consequential-tier systems went through a documented pre-deployment review, including what was checked and who signed off
• A record of how the framework itself gets updated when a new regulation (or a new internal incident) changes what "consequential" means

If any of those three would take more than a day to assemble, the framework exists on paper more than it exists in practice — and that gap is exactly what shows up during due diligence, an incident investigation, or a regulator's first request for documentation.

Related reading

This piece is the entry point into our governance coverage. From here:

• If you're specifically dealing with the EU AI Act's classification rules, see our explainer on high-risk system classification.
• If you need the vocabulary first, our AI governance glossary entry defines the term the way regulators use it, not the way vendors market it.