AI Governance Checklist

An AI governance checklist is a short operating document that says which AI systems your company uses, who owns each one, what each system may do, how its work is checked, and what happens when it gets something wrong. You do not need a committee before you can begin. You need an inventory, a named owner, clear approval rules, and records you can inspect.

Problem: AI has entered the business through a dozen side doors. Sales uses it to draft outreach. Finance uses it to explain variances. Someone built an internal assistant over a weekend. Nobody can produce a complete list, and the first governance meeting starts with a blank spreadsheet.

Quick Win: Write down every live AI use case this week and assign one person who can stop each one. Then apply the checklist below. The US National Institute of Standards and Technology, NIST, organizes AI risk work into four useful jobs: govern, map, measure, and manage (NIST AI Risk Management Framework Playbook). That is a much better starting point than a 60-page policy nobody can use.

Governance starts with the use case

"We use Claude" is not an inventory item. Neither is "the marketing team uses AI."

A real inventory names the job:

• Draft first-pass answers to security questionnaires.
• Rank inbound inquiries for a salesperson to review.
• Summarize customer calls and suggest the next action.
• Compare invoice records and flag likely exceptions.
• Produce a weekly management report from approved data.

The model matters, but the job matters more. The same model can be low-risk when it summarizes an internal meeting and much more serious when it ranks job candidates, recommends credit decisions, or sends a message under your company's name.

This is why NIST tells organizations to map the context before measuring the risk. Its generative AI profile says risks can arise during design, deployment, day-to-day operation, and retirement. It also says the right controls vary by use case and by the people involved (NIST Generative AI Profile). A generic "responsible AI" statement cannot do that work for you.

For each system, write one sentence that begins: "This exists to..." If the sentence says "help the team with AI," the purpose is still too vague.

The checklist

Use one row per AI system. "Unknown" is an acceptable first answer. An empty cell is not.

This table is deliberately plain. Governance fails when the document looks impressive but does not settle an argument on Tuesday morning.

Imagine the sales assistant suggests sending a discount to a customer. The checklist should answer, without a meeting:

1. Is it allowed to recommend discounts?
2. Can it send the message itself?
3. Which data supported the recommendation?
4. Who approves it?
5. Where is that approval recorded?
6. Who stops the workflow if it starts suggesting the wrong terms?

If those answers live only in the builder's head, the company does not govern the system. It merely trusts the builder.

Give one person the stop button

Shared responsibility usually means no responsibility.

The process owner should own the AI outcome. A head of sales owns a prospecting workflow. A finance leader owns an invoice-review workflow. Legal and security can define constraints. An engineer can keep the system running. Neither should quietly become accountable for the business decision.

The owner needs three things:

• Enough knowledge to understand what the system is doing.
• Access to the evidence behind important outputs.
• Authority to pause the system without waiting for a steering committee.

The third item is where governance gets real. A person who is "responsible" but cannot stop an automated send, payment, rejection, or publication is a spectator.

For high-risk AI systems covered by the EU AI Act, Article 26 says deployers must assign human oversight to people with the necessary competence, training, authority, and support. It also sets duties around monitoring, relevant input data, incident reporting, and keeping system-generated logs under the deployer's control for at least six months, subject to other applicable law (EU AI Act, Article 26).

Your system may not fall into that category. The operating lesson still holds: the reviewer needs authority, not just a checkbox.

Put approval where the damage happens

Requiring a person to approve everything sounds safe. It often produces a queue nobody reads.

Approval belongs immediately before an action that is hard to reverse or expensive to get wrong. Sending a customer email, changing a price, rejecting an applicant, approving a payment, publishing a claim, or writing to an official record deserves a clear gate.

Low-stakes work can use lighter checks. A draft saved for review is not the same as a message sent to 5,000 customers. A private summary is not the same as a decision placed in an employee file.

Use four approval levels:

Start new workflows at observe, recommend, or draft. Move to action only after the lower level has produced enough reviewed evidence. "The demo looked good" is not evidence.

Human review also needs a usable shape. Show the reviewer the source material, the proposed action, the reason, and what will happen after approval. Do not hand someone a polished answer and ask them to detect an invisible mistake.

Test the job, not the model

General model benchmarks tell you very little about whether your invoice workflow handles partial payments or whether your proposal system uses the current liability clause.

Build a small test set from the work the company already sees:

• Normal cases the system should handle easily.
• Awkward cases that caused mistakes before.
• Cases where the correct answer is to stop and ask a person.
• Inputs that are incomplete, contradictory, or malicious.
• A few old examples with known good outcomes.

Then define the pass condition before running the test. "Looks promising" is how pilots drift.

For an answer library, the condition might be: every factual statement must point to an approved source, and the system must refuse questions outside that library. For invoice review, it might be: no payment recommendation without a matching invoice, contract, and approval record.

NIST's generative AI profile focuses heavily on pre-deployment testing, ongoing evaluation, content provenance, and incident disclosure. It recommends evaluating risk-relevant capabilities before deployment and on an ongoing basis (NIST Generative AI Profile). "We tested it at launch" is not a lifetime pass.

Keep the failed examples. They are often more useful than the score because they show what control needs to change.

Keep a record you can actually inspect

A log is useful when it lets you reconstruct an important event.

For consequential actions, record:

• The input or a safe reference to it.
• The model and workflow version.
• The source material used.
• The output or recommended action.
• The person who approved, changed, or rejected it.
• The final action and time.
• Any error or complaint linked to it.

Do not collect everything forever by default. Logs can contain customer data, employee information, or confidential business material. Set access and retention rules with the people responsible for privacy and security.

The practical test is simple. If a customer challenges an AI-assisted decision three months later, can you explain what happened without asking the engineer to search raw server logs?

What the EU rules change in August 2026

The EU AI Act does not place every AI use into one bucket. Duties depend on the system, the use, the company's role, and the risk classification.

One date is immediate. The European Commission published its Article 50 guidance on 20 July 2026, and says the relevant transparency obligations start applying on 2 August 2026 (European Commission transparency guidance). Those rules concern certain systems that interact with people or create synthetic content.

Other high-risk rules follow a different timetable. The Commission's implementation page currently says rules for Annex III high-risk systems apply from 2 December 2027, while rules for high-risk systems embedded in regulated products apply from 2 August 2028 (EU AI Act implementation timeline).

Do not turn those dates into a blanket conclusion about your company. Classification needs legal analysis tied to the actual use case. The useful action now is to build the inventory. You cannot classify a system you have not found.

This article is an operating guide, not legal advice.

Where governance goes wrong

The first failure is policy without machinery. A document says "humans remain accountable," but nobody defines which human, what they see, or how they stop the workflow.

The second is governing vendors instead of uses. Procurement approves a model once, then teams use it for jobs with completely different consequences. Approval should follow the use case.

The third is the perfect-inventory trap. Teams spend months discovering every browser extension while the highest-risk workflow keeps running. Start with systems that contact people, move money, affect employment, publish claims, or write to official records.

The fourth is fake oversight. If one person receives 800 approvals every morning, the control exists only on paper. Reduce the volume, route exceptions, or move the system back from acting to drafting.

The fifth is silent change. A vendor updates a model, a data source changes, or somebody edits the instructions. The workflow still runs, but the test result no longer describes it. Put change triggers in writing and run the relevant tests again.

A sensible first month

Week one is discovery. List the live uses, name the owners, and pause anything nobody will own.

Week two is classification. Mark the data involved, the people affected, the action level, and the likely legal or contractual duties.

Week three is control design. Add approval gates, tests, logs, and the stop procedure.

Week four is the first review. Run the test set, inspect actual outputs, fix the weak points, and set the next review date.

This work should make the system easier to run, not bury it. If governance adds a meeting but leaves the risky action untouched, it has missed the point.

Related reading

• What an AI vendor can touch, including data access and ownership after handover
• Questions to ask before signing, for vendor and contract due diligence
• Why AI automation fails, for the operating problems that appear after the demo

Good governance is a working inventory, a real owner, evidence at the approval point, and a stop button that works. If you need the workflow itself installed with those controls built in, see how we approach department automation for recurring company work.

Frequently asked questions

Do we need an AI governance committee?

Not to begin. Start with an owner per system and a small cross-functional review for uses that touch sensitive data or consequential decisions. A committee can coordinate policy later. It should not replace the person accountable for the actual process.

How often should an AI system be reviewed?

Set a routine review based on the consequence of failure, then add event-driven reviews. A model change, new data source, expanded permission, new audience, serious error, or material workflow change should trigger a fresh check even if the calendar date has not arrived.

Is a human approval button enough?

No. The reviewer needs evidence, time, competence, and authority. If the system hides its sources or the person cannot reject the action, the button is decoration.

What is the first document we should create?

Create the inventory table. One row per use case, with the job, owner, data, action level, approval rule, latest test, and stop procedure. It exposes missing ownership faster than a general AI policy.