AI Governance for Mid-Market Companies

Large enterprises can staff an AI governance committee. Mid-market companies cannot, and they should not try. What they need is a process that produces a handful of decisions reliably, with the minimum number of people required to make them.

Governance is not a policy document

Most first attempts at AI governance produce a policy. It gets written, circulated, approved, and then nothing changes, because a policy does not answer the question someone faces on a Tuesday afternoon: can I use this tool for this task, or not?

A working process answers that question quickly and leaves a record of the answer.

The five decisions a governance process must produce

If your process reliably produces these five decisions, it is doing its job. If it produces four, you have a gap that will surface at the least convenient moment.

1. What may use AI, and what may not. A short, specific list beats a principle. "Customer support triage: yes. Employment decisions: no. Anything involving protected health information: only through the reviewed system." People need to be able to classify their own situation without asking.

2. Who approves a new use. Name the role, not the department. One approver with a clear mandate is better than a committee that meets monthly, because the committee becomes the reason nothing ships.

3. What evidence is retained. For each system: what it does, what data it touches, the model or vendor behind it, who owns it, and what testing was done. One page per system. This is what makes an audit a retrieval exercise rather than a reconstruction.

4. What happens when it fails. Escalation path, who can pause the system, and what the interim process is while it is paused. An AI system without a defined failure path becomes an incident with no procedure.

5. Who can switch it off. One named person, plus a deputy. This is the decision most often missing and the one that matters most in practice.

Right-sized for a mid-market company

A workable structure is three roles, not a committee: an accountable owner for AI overall, an approver per business area, and a technical reviewer who checks the systems rather than the intentions. Those can be three people. In a smaller company, they can be two.

The failure mode to avoid is the governance body that has authority but no delivery responsibility. It will optimise for caution, and your AI programme will stall in review.

The register: every AI system, one page each

Start an inventory even if it is incomplete. Include the vendor tools people are already using on their own, because those are the ones that will surprise you. Software that reads documents and produces summaries is processing company data whether or not it went through procurement.

Each entry needs: what it does, what data it sees, who owns it, which model or vendor, what review exists, and when it was last checked. One page, updated when things change. An imperfect register that exists outperforms a perfect one that is still being designed.

Human review is an engineering control, not a promise

If a governance document says sensitive outputs are reviewed by a human, that review has to exist in the system: a queue, an assignment, a record of who approved what and when. A review step that lives only in a policy is not a control, because nobody can demonstrate it happened.

This is also the fastest way to find out that a promised review step was never going to be sustainable. Better to learn that in design than in an audit.

What auditors actually ask for

In practice, the questions are mundane and specific. Which systems use AI? What data do they process? Who approved them? What testing was performed, and when? What was the outcome of the last review? Who can turn it off?

A company with a register, named owners, and a failure procedure can answer all six in an afternoon. A company with a beautifully written policy and no register cannot answer the first one.