AI governance checklist

You do not have AI governance because a policy exists. You have it when a named person can answer, this week, what is running, what data it touches, who owns it, and what happens when it fails.

This is a checklist, not a framework essay. Use it as a pass/fail. If an item is missing, do not call the program governed. Map the same items lightly to the NIST AI Risk Management Framework: GOVERN and MAP are inventory, owners, data classes, and risk tiers. MEASURE is eval and logging. MANAGE is the incident path and the review cadence. You do not need a 40-page mapping document to start. You need the artifacts below.

If the four readiness gaps on common AI readiness gaps are still open — no source of record, no baseline, no named user, no allow list — fix those first. The checklist assumes you are past the slide deck.

You cannot govern what you have not inventoried

Start with a living register, not a one-time spreadsheet. Every production model, agent, embedded copilot, and vendor feature that calls a model belongs on it. A chatbot in a help-desk product counts. So does a summarizer inside a contract tool. If it can see company data or write a decision, it is in scope.

The inventory is governed when you can answer yes to all of these:

• Every sanctioned AI system has a row: name, purpose, environment (dev, staging, prod).
• Every row has a last-reviewed date that is not older than the review cadence.
• Shadow tools discovered in the last quarter are either listed or explicitly closed.
• Retired systems are marked retired, not deleted, so an auditor can see the history.
• Someone can produce the list in under a day without pinging five teams.

A living model inventory is the artifact that survives a vendor change and a staff change. Owner, data class, risk tier, and last eval live on the same row. If those fields are empty, you have a catalog, not governance.

Every system has one owner who can say stop

A steering committee is not an owner. The owner is the person who can take the system offline, approve a data class change, and sit in the incident call. Dual ownership (business plus engineering) is fine. Zero ownership is not.

Mark yes only if:

• Each inventory row names a person, not a department.
• That person knows they are the owner and can name a deputy.
• There is a written rule for what happens when the owner leaves.
• Low-risk changes can be approved by the owner in days, not months.
• High-risk changes require a second pair of eyes from security or legal, named in advance.

Without an owner, GOVERN in NIST AI RMF is a slogan. Approvals stall on low-risk internal summaries and leak on unsanctioned tools. The paved road has to be faster than the dirt path or people will keep using the dirt path.

Data classes and an approved-tool list exist in writing

Governance fails in the same place every time: someone pastes a customer record into a public chatbot because nobody said which tools and which data are allowed. Write the two lists this week. Enforce them later. Do not wait for a gateway build to publish the first rules.

Data classes, at minimum:

• Public or already-external material (marketing copy, published policies).
• Internal non-sensitive (org charts, process docs without customer data).
• Confidential business (financials, unreleased product, legal strategy).
• Restricted (customer PII, health, payment, credentials, unique identifiers that can re-identify a person).

Approved-tool list, at minimum:

• Named tools employees may use, with the data classes each tool may see.
• Named tools that are banned for company work, including personal accounts of otherwise-approved products.
• A path to request a new tool that does not take a quarter.
• A rule that "the vendor says they do not train on our data" is not enough; you still need a contract, a tenant, and logs.

Yes/no:

• Can an employee find both lists without asking Slack?
• Does restricted data have a hard no for public models, including "just this once"?
• Is there a person who updates the lists when a vendor changes terms?

The lists are MAP work. They also prevent the most common leak. The rest of the checklist is how you enforce them.

Risk tiers decide how heavy the controls are

Treat every use case as one of a few tiers. Three is enough for most companies: low (internal draft, no customer data, human reads the output), medium (internal decision support, some confidential data, human still signs), high (customer-facing, restricted data, or a write-back into a system of record).

Yes/no for the tiering scheme:

• Every inventory row has a tier, assigned with a written rubric, not a vibe.
• The rubric uses data class, user, blast radius, and whether the model can write, not just "how important the project is."
• Low-risk work is allowed on a short path: approved tool, logged, owner named.
• High-risk work is blocked from personal ChatGPT and from any path without a gateway, eval, and a human in the loop on write-backs.
• Changing a tier requires the owner plus security, and the change is recorded.

This is the light NIST mapping: MAP puts the system on a tier; MEASURE and MANAGE scale with the tier. Proportionate controls are the difference between a freeze and a paved road. If everything is "high," teams will route around you. If nothing is high, you will learn the hard way on a customer file.

A gateway and logs sit in front of model calls

A policy PDF cannot see a prompt. A secure AI gateway can. The gateway is the governed entry point for LLM usage: logging, PII redaction, cost controls, and the allow/deny rules applied on the request, not in a wiki.

You may not need a full gateway on day one for a single low-risk pilot. You do need one before you claim the company is governed. Until then, be honest: some use is inventoried; it is not controlled.

Yes/no:

• Production prompts and completions for sanctioned tools pass through a path you operate or contractually control.
• Logs retain who called, which model, which data class was declared, and whether redaction fired — retained long enough for an incident review.
• Restricted data is redacted or blocked before it leaves your tenancy.
• Cost and rate limits exist so a runaway agent is an operations event, not a surprise invoice.
• Security can pull last week's traffic without asking the vendor for a favor.

Logging is MEASURE. If you cannot reconstruct a bad answer, you cannot manage it.

Eval exists before promote, and an incident path exists after

"We tested it and it looked good" is not eval. Eval is a written set of cases, a pass bar, and a record attached to the inventory row. The cases should include the ugly ones: stale policy, conflicting sources, a prompt that tries to extract data, a user who pastes PII.

Yes/no for eval:

• High-risk systems have a held-out set that is run before every promotion.
• Medium-risk systems have at least a smoke set and a named reviewer.
• Low-risk systems have a recorded spot-check, not nothing.
• Failures block promote. They do not get a meeting and a "ship anyway" with no note.
• Drift or a policy change triggers a re-run, not a hope that last quarter's score still holds.

Yes/no for incidents:

• There is a written path: who is paged, what gets shut off, who talks to the customer or regulator.
• "The model was wrong" and "data left the tenancy" are both in scope, with different severity.
• A post-incident note updates the inventory and the eval set.
• People know the path exists because it was used in a drill, not only filed in a handbook.

MEASURE without MANAGE is a dashboard. MANAGE without MEASURE is a blame session.

Review cadence is on the calendar, not in the policy

Governance dies when the first project ends. Operationalize means a recurring review: inventory stale rows, tiers that no longer match the data, eval that has not been re-run, tools that employees adopted without asking.

Yes/no:

• A cadence is published (monthly for high-risk, quarterly for the rest is a workable default).
• The meeting has a list, not a slide about "AI strategy."
• No-shows have a deputy. The review happens even if the sponsor is out.
• Outcomes are written back to the inventory: keep, restrict, retire.
• Training is short and tied to the allow/deny list, not a lunch-and-learn about the future of work.

That is the last NIST loop: GOVERN sets the cadence; MAP and MEASURE feed it; MANAGE acts.

If you can mark yes on inventory, owners, data classes, approved tools, risk tiers, gateway and logs, eval, incident path, and cadence, you may call AI governed. If you cannot, you have homework. The method is the same one we use in delivery: discover what is actually running, risk-tier it, implement guardrails in your environment, then operationalize so the checklist still passes next quarter.

The fastest way to see which items you are missing is a short score, not another workshop. Take the 3-minute AI readiness assessment.