For small teams. The non-bureaucratic version of governance — the disciplines that fit on one page, get followed in practice, and stop the headlines you don't want to read.
Most AI governance writing is for enterprises with compliance teams. This volume is for the founders, ops leads, and CTO-of-three-people running real AI systems with no formal programme. The good news: a small team can have excellent governance — if it's the right kind.
Governance is what lets a small team trust the system it built. Without it, every Friday is a quiet risk; with it, every Friday is a working week.
A large company that screws up has lawyers, PR, insurance. A small company that screws up has a Tuesday. The asymmetry is the reason small teams should be more, not less, deliberate — though their governance looks different.
You can answer five questions, by close of business, on demand:
You have something a Fortune 500 doesn't: every person involved fits in one meeting. Governance can be a 20-minute weekly review, a one-page policy, and a Slack channel — not a department.
The other side of the coin: there is no one whose job it is to ask "are we sure?" Pre-commit to that role for someone — yourself, the CTO, a contractor. The role gets harder to add the longer you wait.
Governance for a small team is not "we built a compliance programme." It is "one person owns the answers to the five questions, and the system was designed so those answers are findable."
A small team's governance is small, fast, and real. A large team's is large, slow, and on paper. Yours can be better — and is, if you build it.
Pick the person who owns the five answers. Add a recurring 20-minute weekly review to the calendar. The role isn't a job change; it's a remit. Without it, no one's it.
Two disciplines that sound boring and are. Both can be implemented in one focused day each. Both pay back for the life of the system. Both are the difference between a small AI deployment and a small AI incident.
"Just feed the whole customer record into the prompt" is the line that ends in a privacy review. Pull only what the task needs; the discipline of scoping is part of the system.
Different regions have different rules — GDPR (EU), CCPA (California), HIPAA (US health), etc. You don't need to be a lawyer; you do need to know which regimes you're under. Talk to one once a year.
PII protection isn't a feature you add. It is a default the system inherits from the way you designed it.
Day 1: connector audit + scope reduction. Day 2: PII inventory + redaction pass. By Monday you have a more defensible system than 80% of companies your size.
If something goes wrong, the audit log is the only record. If it isn't there — to you, to your auditor, or to a court — it didn't happen. Building it first is not paranoia; it is the simplest single decision that turns AI from "story I tell" into "thing I can defend."
Pick a real action that happened in production last week. Try to answer: "What did the system do? In what order? Why? What returned what? Who could have seen this happen?" If it takes more than 5 minutes, your logging needs work.
The same logs that satisfy auditors are the logs that let you debug at 2 a.m. when something fires that shouldn't have. Build them once; use them twice.
Detailed logs help governance. They also concentrate PII. Resolve the tension by structured redaction: store PII fields as hashed IDs; resolve to the real value only when authorised. Logs stay useful; PII stays minimal.
An untouched log is a kept promise. A missing one is a story you'll regret telling.
Make them this week. A simple append-only table in your existing database, with the eight columns above, beats nothing by infinity. Fancy can come later.
The single most effective governance move is to design the system so a human signs off on every consequential action — until you have evidence they don't need to. This is not a feature. It is the architecture.
Draft is shown to a human; human approves; action fires. Default for: customer-facing communications, money movement, public posts, contracts.
Approval surface shows: what's about to happen, the chosen rule, a one-tap revoke.
The system acts; a human reviews a sample after the fact. For: high-volume / low-risk work — classification, summarising, drafting internal notes.
Sampling rate calibrated to stakes. Lower it as evidence accumulates.
Most runs go through unattended; the model self-flags low-confidence or rule-conflict situations to a human. The mature shape, earned over time.
Define what "flag" means before going live. Tune flag rate from a known baseline.
Independent of patterns 1–3. A single, known action that stops all AI activity. Drill it quarterly. If you've never tested it, you don't have one.
Document. Practice. Make sure two people on the team know how to use it.
40 drafts a day; reviewer rubber-stamps; bad one slips through. Now you have the worst of both worlds.
Cut to one gate per workflow, late. Pair with confidence flagging.
When in doubt about whether to add a gate, add it. Removing it later is one PR. Adding one after an incident is a quarter.
"We don't need a gate here" is something you earn with data, not something you assume on day one.
Approval gates are not bureaucracy. They are the design pattern that makes AI shippable. Build them in from the start; remove them with evidence.
A template you can adapt today, tape to the wall, and actually follow. Long policies don't get read; this one fits. Customise the placeholders to your team; revisit quarterly.
1 · What we use AI for. [Draft customer-facing copy, summarise meetings, triage support tickets, draft internal documents, code assistance.] All other uses require a 1-on-1 with [the AI lead] before proceeding.
2 · What we don't use AI for. Final decisions on hiring, firing, pricing, or legal matters. Generation of content presented as not-AI when it is. Anything involving customer PII without an explicit data flow design.
3 · Approval. Anything sent to a customer, posted publicly, or paid is reviewed by a human first. Internal-only outputs may be sampled. Exception-only review allowed only after 10 clean supervised runs.
4 · Data. No customer PII in prompts unless the task requires it. No client data shared with third-party AI services without a DPA. PII in logs is redacted at write time. Retention: [12 months default; per-category exceptions listed].
5 · Tools. Only AI providers approved in [registry]. New providers added after [the AI lead]'s review of security, DPA, and pricing. MCP connectors scoped to least privilege; quarterly review.
6 · Audit. Every consequential action logged with timestamp, actor, action, inputs (redacted), outputs (redacted), result. Logs append-only, queryable, retained per policy.
7 · Incidents. If something goes wrong, post to [#ai-incidents] within 1 hour. Owner: [name]. Kill switch: [link to the documented procedure].
8 · Review. This policy is read by every new hire on day 1. Reviewed by the team quarterly. Revised based on incidents and changes in regulation.
Signed: [the AI lead], [the CEO]. Last updated: [date].
AI Safety & Governance for Small Teams · The Operator's Library · No. 10. Next: Vol. 11 — The One-Person AI-Native Business.
Scope the access. Log the actions. Gate the consequential. Drill the kill switch.
— END · OPERATOR'S LIBRARY NO. 10