Your AI Policy Checklist for Safe Small Business Use

About half of small business founders pasted sensitive company information into a public AI chatbot in the past month. Roughly a quarter did it weekly. And approximately 90% of those same founders expressed concern that the data they entered might be used to train external models. Those three figures come from the same survey population. The same people doing the risky thing are the ones who know it is risky.

The absence of a rule is itself a decision

No written AI policy does not mean no AI use. It means use without any shared understanding of what is allowed. When an employee opens ChatGPT and pastes a client contract into it, they are not violating a rule. There is no rule. The founder who feared data leaks has produced a data leak by waiting.

A meta-analysis on privacy concern and AI adoption found a correlation of r = −0.32 between privacy worry and adoption intention. That finding is often read as a reason to delay. It is not. The same research shows that privacy concern suppresses structured adoption while ungoverned experimentation continues regardless. The people most worried about AI leaks are the ones least likely to write a policy, and the policy vacuum is what lets informal use run unchecked.

What a one-page policy actually needs to say

Three questions. Every employee needs an answer to all three before they touch an AI tool for work.

First, which data categories are off-limits? Client names, financial records, personal identifiers, contracts, and internal strategy documents belong on a short prohibited list. If the research does not supply this list for your industry, the test is simple: would you hand this document to a stranger on the street and trust them not to share it? If no, it stays out of the chatbot.

Second, which outputs require a human to review them before they leave the building? A meta-analysis on AI hallucinations documents that current models produce false or unsupported outputs in roughly 15 to 20% of responses, and those errors arrive in fluent, confident language that makes them hard to catch without domain knowledge. Drafting a legal clause, summarising a customer complaint for a formal response, writing anything that references a regulation or a figure: all of these require a named person to read and approve before sending. The policy should say who that person is.

Third, which tools are approved? Not "any AI tool you find useful." A specific approved list. Before a tool goes on that list, someone checks two things: whether the vendor's terms permit training on user inputs, and whether data retention can be disabled. This takes under an hour per tool. It is not a technical audit. It is reading a terms-of-service page with one question in mind.

The counterargument worth taking seriously

A reasonable objection runs like this: a weak policy creates documented awareness of the risk without actually controlling it. Under GDPR, that documentation of awareness without effective control is not a mitigating factor. It is evidence that the organisation knew and did not act adequately. A poorly written policy, on this view, worsens the legal position.

This objection is correct about poorly written policies. It does not follow that no policy is safer. The survey data shows that roughly 50% of founders already share sensitive data with public AI tools, with no contractual safeguards, no prohibited-data list, and no review requirement. Once data enters a public AI system in that state, there is no mechanism to recall it. The ungoverned baseline is already producing the outcome the objection attributes to a weak policy. A policy that names prohibited data categories and assigns review responsibility does not solve every failure mode. It changes the default for employees who are currently sharing data with nothing telling them not to.

What the checklist looks like

One page. Four sections.

Approved tools, listed by name. Prohibited data categories, listed specifically. Output review requirements, with a named role attached to each category. A process for requesting approval of a new tool, with a turnaround time.

Post it somewhere the team actually reads. Review it when you add a tool or change a data practice. The NIST AI Risk Management Framework and EU AI Act proportionality provisions both confirm that regulators do not expect small firms to produce enterprise-depth compliance documentation. They expect proportionate, documented effort. One page, updated when circumstances change, is proportionate effort.

The employee who opens a chatbot tomorrow will do something with it. The only question is whether they do it with a clear boundary in front of them or without one.