A Practical AI Governance Checklist for Mid-Market Companies

The short version

A workable AI governance checklist for a mid-market company covers eight areas: an inventory of AI systems, risk classification, data handling rules, human oversight, evaluation and monitoring, vendor due diligence, incident response, and documented accountability. It should fit in a handful of pages and be enforced through the procurement and deployment process rather than a policy nobody reads.

Why mid-market governance is different

Enterprises staff dedicated AI risk teams. Mid-market companies do not, and copying an enterprise framework produces a document that stalls delivery without reducing risk. The goal is proportionality: enough control to satisfy customers, insurers and regulators, applied at the moments where decisions are actually made.

The checklist

1. Inventory

• Every AI system in use, including embedded vendor features and shadow tools.
• Owner, purpose, data touched, model provider, deployment date.
• Reviewed quarterly; new entries created at procurement, not after launch.

2. Risk classification

Classify each system by consequence, not by technology. A three-tier scheme is usually enough: low (internal productivity, reversible), medium (customer-facing, reversible), high (affects employment, credit, health, safety, legal rights, or moves money). Controls scale with tier. High-tier systems require documented human review and a named accountable executive.

3. Data handling

• What data may enter a prompt, and what may never (personal data categories, secrets, client-confidential material).
• Retention and training terms with each provider — confirm in writing that inputs are not used for training where required.
• Residency requirements per jurisdiction, and how they are enforced technically.
• Redaction or tokenisation at the boundary where feasible.

4. Human oversight

Define for each system: which actions are automatic, which require approval, and who has the authority to stop it. Oversight must be meaningful — a reviewer with time, information and the practical ability to disagree. Rubber-stamp approval is worse than none because it manufactures a false record.

5. Evaluation and monitoring

• A test set per system, refreshed as the domain changes.
• Pre-deployment evaluation with a documented pass threshold.
• Production monitoring: quality sampling, error and escalation rates, cost, latency, drift.
• Bias testing where outputs affect people differently by group.

6. Vendor due diligence

Ask every vendor: which models sit underneath, where data is processed, what the retention and training terms are, how they evaluate quality, what their incident notification commitment is, and what happens to your data on exit. Record the answers in the inventory.

7. Incident response

Define what counts as an AI incident (harmful output, data exposure, sustained quality failure, unauthorised autonomous action), who is notified within what window, how a system is disabled, and how affected parties are informed. Run one tabletop exercise a year.

8. Accountability and records

One accountable executive overall, one owner per system, decisions and exceptions recorded with dates. Keep evaluation results, incident records and vendor terms for the retention period your sector requires.

Mapping to external frameworks

This checklist maps cleanly onto the NIST AI Risk Management Framework functions (govern, map, measure, manage) and onto the risk-tiering logic of the EU AI Act. If you operate in the EU or sell to EU customers, confirm whether any system falls into a high-risk category under the Act, since that carries specific documentation, logging and human-oversight obligations. ISO/IEC 42001 provides a certifiable management-system structure if a customer contractually requires one.

Implementation sequence

1. Weeks 1–2: build the inventory, including shadow AI discovered through expense and SSO logs.
2. Weeks 3–4: classify by tier and identify anything high-tier running without oversight.
3. Weeks 5–8: write the data-handling rules and embed the checklist into procurement and deployment gates.
4. Quarter two: stand up evaluation and monitoring for medium and high-tier systems; run the first incident tabletop.

What to avoid

A twenty-page policy with no owner. Blanket bans that drive usage underground. Governance applied only to new projects while existing tools go unreviewed. Approval processes so slow that teams route around them — the fastest way to lose visibility entirely.

One-page summary to circulate

Inventory maintained quarterly. Three risk tiers with proportional controls. Explicit data rules. Named oversight per system. Evaluation before launch, monitoring after. Vendor terms recorded. Incident process rehearsed. One accountable executive. That is a defensible programme, and most mid-market companies can reach it in a quarter.