AI Governance Checklist for Small Teams

An employee pastes a client contract into ChatGPT to summarize it. No rule said not to. The prompt leaves the building, sits on an external server, and feeds into model training. The founder finds out three weeks later, issues a ban on all AI tools, and loses the productivity gains the team had built over two months. The ban is the second mistake.

The ban is not the safe option

When founders respond to an AI misuse incident with a blanket prohibition, employees do not stop using AI tools. The research on this is consistent: rigid or overly restrictive rules push staff toward unapproved tools and toward hiding their AI use entirely. The founder ends up with no visibility into how decisions are actually being made. A written policy with four specific controls produces a different organizational condition — employees know what is expected, know who to ask when uncertain, and have a path to raise concerns without concealing what they are doing.

Four controls that close most of the exposure

The NIST AI Risk Management Framework's Govern and Manage functions identify organizational culture, policies, roles, and accountability structures as the primary mechanisms for reducing AI risk — not prohibition. For a small team, that translates to four written controls.

Name the approved tools. Write down which public AI tools employees are permitted to use for which tasks. ChatGPT for drafting marketing copy: permitted. ChatGPT for summarizing client contracts: not permitted. The list does not need to be exhaustive on day one. It needs to exist.

Draw a hard data boundary. Public AI tools store prompts on external servers and feed that data into model training. Any data you would not post publicly belongs in a separate category: client names, contract terms, source code, financial records, employee information. Write the boundary down. The boundary does not need to be a legal document. One paragraph works.

Require output verification before any output drives a decision. AI-generated content contains errors that look authoritative. The verification step does not need to be elaborate — cross-check any factual claim against a primary source before acting on it. The step needs to be written down and assigned to a specific person, not left as a general expectation.

Name one escalation owner. One person whose job it is to field questions about whether a specific use case is within bounds. Not a committee. One person. Employees who are uncertain about a use case need a path that does not require them to either guess or hide what they are doing.

Written rules don't stop a prompt from leaving the building

The strongest objection to this approach is accurate: a written policy without technical enforcement is a paper record that an employee was told what not to do. When someone pastes a client contract into ChatGPT in violation of a clearly written data boundary rule, the prompt still leaves the building. The policy documents intent. It does not change the outcome.

That objection compares a lightweight written policy against a fully instrumented compliance program with vendor screening, model-selection controls, and monitoring infrastructure. The research compares it against the actual alternative for resource-constrained teams, which is no policy at all. Without formal guidelines, employees develop informal, inconsistent mitigation habits. Founders react to incidents with ad hoc bans after exposure has already occurred. The stricter camp's requirements — cross-functional steering groups, meta-agents for monitoring AI behavior — presuppose infrastructure these teams do not have. Treating those controls as the minimum threshold for meaningful governance eliminates governance as a practical option for the organizations that need it most.

One genuine limit remains: the research does not contain compliance audit data showing that employees at small companies follow written AI policies at measurable rates. The enforcement gap is real. A written policy reduces the probability of accidental misuse by employees who did not know the boundary existed. It does not reduce the probability of deliberate misuse by employees who choose to ignore it.

Start with the data boundary

Of the four controls, the data boundary produces the most immediate risk reduction. Most exposure incidents trace back to employees not knowing which data is off-limits — not to tool failures or vendor negligence. Write the boundary first, share it with the team this week, and name the escalation owner at the same time. The acceptable-use list and output verification steps can follow. The sequence matters less than getting the boundary written and in front of the people who need to see it.