A practical AI policy for a small UK business

Start with the work your team actually does

The first line of an AI policy should describe the purpose in ordinary language. For example: ‘We may use approved AI tools to help draft, summarise, classify and find patterns in business information. A named person remains responsible for the final decision or communication.’

That wording is deliberately unglamorous. It keeps attention on the work rather than on a particular vendor, and it gives a new starter enough context to make a sensible choice. If your business has a real use case—turning meeting notes into actions, drafting a first response to an enquiry or comparing recurring reports—name it.

Draw a clear line around sensitive information

Most small-business AI risk is not mysterious. It comes from putting the wrong information into the wrong service without checking how it will be handled. Your policy should give people a simple stop-and-check rule before they paste anything into a tool.

As a default, keep special-category personal data, passwords, payment details, confidential client material, unannounced commercial information and anything covered by a contract or non-disclosure agreement out of general-purpose tools. If the work genuinely needs that information, stop and ask the person responsible for data protection and the supplier relationship.

The Information Commissioner’s Office makes the wider point clearly: the organisation remains accountable for how personal data is used in an AI system, and the right assessment depends on the specific use case. Record what information is used, why it is needed, who can access the output and how long it is kept.

Make human review specific, not ceremonial

‘Human in the loop’ is not a control if nobody knows what they are meant to check. For each approved use, say what the reviewer is accountable for: factual accuracy, tone, calculations, confidentiality, legal or contractual commitments, and whether the output is suitable for the audience.

A person reviewing an AI-drafted customer email should read the whole email, check names and dates against the source record, remove unsupported promises and make sure it sounds like the business. The review should be proportionate to the consequence of being wrong.

Choose tools with a short procurement checklist

You do not need to become a software assessor, but you do need enough information to make a defensible choice. Ask the supplier how prompts and uploaded files are stored, whether they are used to improve the service, where the data is processed, how access is controlled, how accounts are recovered and what happens when you leave.

Also check the practical fit: can the business use named accounts rather than a shared login, can an administrator remove access when someone leaves, and can you export or delete the information you have put into the service? If the answer is unclear, keep the tool away from confidential work until the question is resolved.

The National Cyber Security Centre’s guidance for small organisations is a useful companion here. Protecting accounts, keeping devices and software updated, preparing for incidents and having reliable backups still matter when AI is added to the workflow. AI does not replace those foundations.

• Approved purpose: the job the tool may help with.
• Approved information: the classes of data that may and may not be entered.
• Named owner: the person who reviews use and handles questions.
• Access: how accounts, permissions and leavers are managed.
• Exit plan: how business information is removed or recovered if the tool is retired.

Roll it out in 30 days, not all at once

Week one is for choosing one low-risk, repeatable task and writing down the current process. Measure something simple: time to produce the first draft, number of corrections, response time or the amount of rework. Do not start by trying to measure every possible benefit.

In week two, let two or three people test the workflow using examples that are safe to share. Ask them to record where the output is useful, where it is wrong and where the instructions are ambiguous. The purpose is to improve the process, not to prove that AI is clever.

In weeks three and four, decide whether to keep, change or stop the experiment. Compare the result with the baseline, note any new risks and update the policy with one or two examples. If it does not work, stopping is a good outcome: you have prevented a weak process becoming institutional habit.

The one-page version

If you need a starting point, put this on one page and discuss it with the team: ‘We use approved AI tools to assist with defined business tasks. We do not enter confidential or personal information unless the use has been assessed and approved. AI output is a draft or aid, not an authority. A named person checks material before it affects a customer, colleague, supplier or business decision. We report mistakes, unexpected outputs and suspected data exposure promptly.’

Then add the name of the owner, the approved tools and the date you will review the policy. That is enough to create a common operating position while your understanding grows. The policy should change as the work changes; it should not become another document nobody opens.

Sources and further guidance

This article is practical guidance, not legal advice. For a current view of your obligations, use the source material below and take advice for higher-risk processing or contractual situations.

• ICO: accountability and governance implications of AI
• NCSC: advice for small and medium-sized organisations