How to build an AI policy for a small business

What is an AI policy?

An AI policy is a short company document that tells employees which artificial intelligence tools they may use, for which tasks, with which information, and what has to happen before an AI-assisted output is used. In a small business it is usually a few pages long and owned by a founder, an operations lead or whoever already looks after data and contracts.

The phrase covers several documents that people often blur together. An acceptable use policy is the rulebook employees follow day to day. A generative AI policy deals with tools that produce text, images or code, and the risks that come with generated content. A governance framework is the management layer behind both: who approves a tool, who keeps the register, how often decisions are reviewed. Most companies under 200 people can hold all three in one document, provided each part is clearly labelled.

This guide covers the decisions every artificial intelligence policy needs, with example clauses for a fictional company. It is general information, not legal advice. Laws on data protection, employment and consumer protection differ by country and sector, so ask a qualified adviser to review the version you adopt.

What should a small-company AI policy do?

A useful policy helps someone decide what to do before they put information into a tool or use its output. It should identify approved services, suitable tasks, information boundaries, review responsibilities and an escalation route. A list of warnings without those practical decisions leaves employees guessing, and people who are guessing either stop using the tools or use them quietly.

Start with the workflows people actually have. A draft invitation built from public facts needs different controls from a summary of confidential client material. For each workflow, write down the purpose, the source material, the intended reader and the consequence of an error. That context is a better starting point than treating every use of AI as identical.

A good test is whether a new starter could answer three questions after reading it: which account do I use, what must I never paste in, and who do I ask. If the document cannot answer those, it is not yet doing its job, however thorough it looks.

Does a small business legally need an AI policy?

In most places there is no general law that says every small business must have a document called an AI policy, but existing obligations still apply to how staff use AI. Data protection law, confidentiality terms in client contracts, employment law and advertising rules do not stop applying because a tool produced the draft. A policy is the practical way to show staff how those existing duties apply to their AI use.

In the UK, the Information Commissioner's Office publishes guidance on AI and data protection and a risk toolkit for organisations. Both pages currently say the guidance is under review following the Data (Use and Access) Act, so check the live status before relying on any detail. In the EU, Article 4 of the AI Act on AI literacy has applied since 2 February 2025 to providers and deployers of AI systems. The European Commission's AI literacy Q&A says there is no one-size-fits-all approach, that certificates are not required and that an internal record of training is enough. It also gives the example of staff using a chat assistant for ad copy or translation, who should be informed about specific risks such as hallucination.

If you sell into the EU, employ people there or handle personal data about EU residents, take advice on what applies to you. The point for this guide is narrower: a written policy plus practical training is a reasonable way to show that people were told what the risks are and how to handle them.

Who needs to own the decisions?

Name one policy owner and the people who can approve tools and sensitive workflows. In a 12-person company that may be the founder for everything. In an 80-person company it might be the operations lead for tools, the person responsible for data protection for personal information and department heads for output review in their area. Employees need one place to send a question the policy does not cover.

The NIST AI RMF Playbook's Govern material discusses defined roles and responsibilities, AI risk training for personnel and lines of communication. The structure here is an operational adaptation for a small team. Using these headings does not make a policy compliant with any law or endorsed by NIST.

Write the owner's name and a backup into the policy itself, not just a job title. In small companies, titles change faster than documents, and an escalation route that points at a role nobody holds is no route at all.

How should you record approved tools?

Record the exact service, plan and permitted use, because a brand name alone hides important differences. A personal consumer account, a company business workspace and an API integration of the same product can have different terms on retention, training and administrator control. Record the relevant settings and terms rather than assume one statement applies to every version.

Ask separately about model training, retention, access, processing locations and deletion. A no-training statement does not establish zero storage or permission to upload a client document. As one example of how vendors describe this, Microsoft's documentation for Copilot Chat used by organisations says prompts and responses are covered by its data protection addendum and are not used to train foundation models, and that the specific controls vary by subscription plan. That is the kind of plan-specific statement to record, with the date you checked it.

Give each approval an owner and a review date so the list can change when the service or the workflow changes. The governance framework guide shows a register format that fits on one page.

What can employees paste into an AI tool?

There is no universal answer independent of the tool, the data and the company's obligations, so the policy has to give one for your context. Start by sorting information into a few plain classes: public, internal, confidential business or client material, and personal information. Then say, for each approved tool, which classes are allowed. Removing a name does not by itself make a document anonymous or authorised for upload.

The UK National Cyber Security Centre's guidance on large language models is blunt on the general point: a query is visible to the organisation providing the model, and it recommends not including sensitive information in queries to public models and reading the terms of use and privacy policy before asking sensitive questions. Your policy can turn that into specific instructions for the accounts you have approved.

Give employees concrete examples of allowed and restricted material for each approved workflow. Use fictional or explicitly approved low-risk data in training. If the answer is unclear, staff should pause and contact the named owner rather than improvise a privacy judgement in the middle of a task.

What should happen before an output is used?

Every AI-assisted output needs a check that matches how it will be used, and the policy should say who does it. A draft email may need a read-through against the supplied facts. A numerical explanation needs an independent calculation. A statement about law, health, money or safety needs a qualified reviewer. The policy should preserve existing approvals rather than imply that AI assistance makes them unnecessary.

Ask employees to keep the generated draft separate from the version approved for use. For important work, keep enough of a review trail to show which source was used, what changed and who made the final decision. A fluent answer, or a model's own reassurance that it is correct, is not independent verification.

Be explicit about decisions that stay with people. A common example clause: AI tools may help draft or summarise, but they must not be the basis for a decision about hiring, pay, performance, credit or a customer complaint without a named person reviewing the underlying information.

What does a finished policy look like for a real-sized team?

Here is a worked example for a fictional 25-person marketing agency, Harbour Lane Studio. Its staff use a company business workspace of a chat assistant and the AI features in its office suite. Some people also had personal accounts. The founder is the policy owner and the head of client services approves anything involving client material.

Sample clause, approved tools: "Use only the Harbour Lane business workspace of [assistant] and the AI features in our office suite, signed in with your company account. Do not use personal accounts for any company or client work."

Sample clause, information: "You may use public and internal information in approved tools. Do not enter client files, client pricing or anything marked confidential unless the head of client services has approved that client and task in the register. Never enter personal information about candidates, staff or customers."

Sample clause, review: "Before AI-assisted work goes to a client, the account lead checks every factual claim against the brief or a named source and removes any statistic, result or endorsement that cannot be traced. AI-assisted work is held to the same standard as any other draft."

Sample clause, escalation: "If you are unsure, stop and ask [founder name], or [backup name] if they are away. If you think restricted information went into the wrong tool, tell them the same day. You will not be penalised for reporting promptly."

Harbour Lane then tested the policy on one real task, a campaign summary built from a client brief, before asking anyone to sign it. The test showed one gap: nobody knew whether a client's brand guide counted as confidential. The founder added a line to the register rather than leaving each account lead to decide.

How should the policy handle uncertainty and mistakes?

The policy should give a clear route to report an accidental disclosure, an unsupported output or a workflow that no longer fits its approval, and it should make reporting safe. Staff need to know what to stop, whom to contact and which evidence to keep for the responsible person. Do not invent a generic incident procedure that conflicts with the one you already have for data or security problems; point to it.

Try a short tabletop exercise before adopting the policy: someone has pasted a restricted document into an unapproved personal account. Can the employee find the reporting route? Does the owner know which service and account were used and what the provider's deletion options are? Use the gaps to improve the actual procedure with the right reviewers.

How do you make sure people can actually follow it?

A signed acknowledgement shows someone received the policy; it does not show they can apply it. People learn a boundary by practising it on a realistic task: deciding what to leave out of a prompt, checking a generated claim against its source, and explaining the edit they made. That is also what the European Commission's Q&A describes when it talks about informing staff of specific risks for the work they do.

Walk the team through one allowed example, one restricted example and one uncertain case from your own work. Ask each person to explain the difference and find the escalation route. Then return to the policy and add the examples that made decisions clearer.

Tosheo.ai is being built for that practice step. At launch, a manager is planned to pick roles and the AI tools the team uses, each learner takes a short diagnostic, and lessons end with a hands-on task in a real tool graded against a visible rubric. Managers are planned to see skill progress and completion, not raw chat logs. It does not write or enforce your policy; it is meant to help people practise the habits a policy asks for.

How do you keep the policy useful?

Review the policy whenever tools, plans, contracts or workflows change, and on a fixed date at least once a year. Ask employees which decisions remain hard to make. A policy that nobody can apply needs clearer examples or a better escalation route, not another acknowledgement checkbox.

Keep a version date and a change note at the top so people know which rule is current. When a vendor changes its terms or a client adds an AI clause to a contract, update the register entry and tell the people affected, rather than waiting for the annual review.

When is this guide not the right answer?

This approach is designed for teams of roughly 5 to 200 people using off-the-shelf AI assistants for everyday knowledge work. It is not enough on its own if you build or sell AI systems, make automated decisions about people, work in a heavily regulated sector such as healthcare, financial advice or legal services, or have client contracts with specific AI terms. In those cases you need a qualified legal and data-protection review, and possibly a formal risk assessment, before the policy is finalised.

It is also not a substitute for an information-security programme. If your company has no basic rules for passwords, device security or data classification, fix those first; an AI policy built on top of nothing will not hold.

Sources and scope

NIST AI RMF Playbook: Govern, checked 16 October 2026 ↗

ICO, Guidance on AI and data protection (under review), checked 16 October 2026 ↗

ICO, AI and data protection risk toolkit (under review), checked 16 October 2026 ↗

European Commission, AI Literacy - Questions and Answers, last updated 27 July 2026 ↗

NCSC, ChatGPT and large language models: what's the risk?, 14 March 2023 ↗

Microsoft Learn, Enterprise data protection in Microsoft Copilot and Copilot Chat, checked 16 October 2026 ↗