Practical AI for UK small business: a controlled pilot blueprint

Short version

Start with one task that someone can check. An AI assistant might prepare a draft reply, organise a messy note or find a passage in an approved guide. It should not quietly become the person who approves refunds, changes bank details or makes sensitive decisions.

Write down how the task works today, what a good result looks like and what must never happen. Try the assistant on a small, deliberately awkward set of examples. Count checking time, corrections and running costs as well as generation speed.

Keep source material current, access limited and a named person responsible for release. When the evidence is missing, the assistant should say so. Expand only after the small trial earns its place.

The longer guide below gives you a practical pilot blueprint, a worked cost example and a downloadable worksheet. These are AAG's methods and illustrations, not promised savings or evidence of a completed client deployment.

Download the AI pilot worksheet

Start with a task you can describe without saying AI

A small business rarely needs artificial intelligence in the abstract. It needs an enquiry answered, an incomplete record identified, a collection of documents sorted or an employee helped through an unfamiliar procedure. The useful starting sentence is therefore practical: “Our coordinator spends too long finding the right service information before replying.” That sentence names a job, a person and a difficulty. It is a better foundation than buying a chatbot and looking for somewhere to put it.

Watch several real examples of the task before designing anything. Where does the request arrive? Which information is consulted? What is copied? What judgement is needed? What happens when something is missing? The quiet delays between these steps can matter more than the writing itself. An assistant that drafts a paragraph quickly may add little value if the team still spends ten minutes locating the correct account.

This guide offers a proposed approach for an ordinary small-business pilot. It is not an assurance that AI suits every operation. The boundaries, numerical examples and acceptance rules below are AAG's original planning material. Adapt them to the consequences of mistakes in your own service.

Choose the smallest useful first job

Look for a recurring task with a recognisable input, a limited set of useful outputs and a person who can tell whether the result is correct. Drafting a reply from an approved service sheet can fit. So can turning a staff member's unstructured note into a proposed checklist, provided the original remains available. A good first job should be easy to reverse and should not need broad access to unrelated records.

Some problems need ordinary software instead. If a date plus nine months gives the required result, use a date calculation. If every completed form goes to the same inbox, use a routing rule. Adding a language model to a fixed rule creates another place for errors, expense and uncertainty without necessarily helping the person doing the work.

Write down three candidates, then compare them against four questions: does this happen often, can we inspect the answer, can we keep the consequences small, and do we have the right information? A task that scores well on the first question but badly on the others may be a poor pilot. The decision should remain understandable to someone who has never read an AI product brochure.

Separate drafting from deciding and doing

“Help with customer messages” hides several different permissions. Reading an approved public price list is one permission. Reading a customer's private record is another. Drafting a suggested answer is different again from sending it. Changing a booking, issuing a refund or creating a contractual commitment adds further consequences. Treat each step as a deliberate design choice.

For a first pilot, a useful boundary is that the assistant prepares a candidate response and a named employee decides whether it is suitable. The interface should show that it is a draft, identify the material used and give the reviewer an ordinary way to edit or reject it. Avoid a design in which approval is merely the fastest button to press.

Consider an invented property-maintenance enquiry. An assistant might identify that the customer is reporting a leak and prepare a request for the missing location. It should not infer an unreported safety condition, promise an attendance time or authorise expenditure. Those decisions need the business's actual procedures and appropriate people. Writing down the exclusions prevents a convenient feature from slowly acquiring authority nobody consciously granted.

Build a small, accountable source collection

Begin with a limited pack of material you are authorised to use: a current service description, approved contact details, the steps staff should follow and answers to frequent operational questions. Give each item an owner and an effective date. Decide which document wins when two disagree. If nobody can resolve that question, the model cannot resolve it reliably on the business's behalf.

The foundational retrieval-augmented generation research by Patrick Lewis and colleagues combined generation with access to retrieved material. Its technical experiments are evidence about particular research tasks, not proof that any commercial knowledge assistant will answer correctly. In a practical business tool, retrieval can help place relevant information beside a question, but it does not turn that information into a guarantee.

Our proposed source register records a title, owner, approval date, next review date and allowed audience. Public opening hours and staff-only escalation instructions should not share the same permissions simply because they sit in the same folder. When a document is retired, remove it from the active collection and check that the assistant no longer relies on it.

Make an answer easy to inspect

A useful answer should expose its footing. If the assistant says a service includes something, the reviewer should be able to open the relevant source passage. If the source does not contain the requested information, the tool should show that limitation and suggest a next step. A fluent paragraph with an unexplained confidence score is usually harder to assess than a short draft with visible evidence.

Separate supported facts from suggested wording. For example, the system could display the current opening hours as a source-backed field and place the proposed greeting in an editable draft. This makes it easier to notice when the facts have changed while the writing style remains plausible. It also helps a busy reviewer spend attention where a mistake would matter.

Test missing, old and contradictory documents deliberately. Ask what happens when two price sheets have different dates, when the relevant paragraph is absent, and when the retrieved document mentions another company. The desired behaviour is a useful pause or escalation. Filling the gap with a confident guess should count as a failure, even when the guess happens to look reasonable.

Open full-size graphic

Original AAG schematic. It describes a proposed design, not a diagram of an existing customer system.

Decide what information is allowed into the pilot

A business task can contain personal information even when the team describes it as “just a message”. Names, telephone numbers, addresses, account references and free-text complaints can reveal more than the task requires. For an early trial, use invented examples or appropriately cleared material whenever that can answer the design question. Remove irrelevant detail before it reaches a provider.

The ICO's AI and data-protection guidance addresses matters including accountability, transparency, lawfulness, accuracy, security and individual rights. The ICO currently flags that guidance for review following the Data (Use and Access) Act. Check the current guidance for the actual processing you propose; a generic AI checklist is not a substitute for that assessment.

Our practical procurement questions are concrete: which organisation receives the information, where can authorised users see it, what is retained, what may be used for service improvement, and how is it deleted? Record the applicable service terms and settings. Do not assume a consumer account and a business service have identical arrangements. If those answers are unclear, keep sensitive information outside the trial.

Put boundaries outside the model

An instruction saying “never disclose confidential information” is useful wording, but it is not an access-control system. A tool should receive only the records its user is allowed to see. It should not be given a general company credential merely because that makes integration easier. A reviewer needs to know which actions are technically possible as well as which are discouraged in the prompt.

The NCSC's explanation of prompt injection highlights that models do not enforce a robust boundary between instructions and untrusted material in the way ordinary database defences can. Its design implication is to reduce the impact of a manipulated model through controls around the application. No wording can justify treating an incoming document as trusted authority.

For our proposed pilot, an attached customer document is evidence to inspect, not a source of new system instructions. Keep external sending, payments and destructive changes outside the assistant's permissions. Test an example document that asks it to ignore the task or expose another record. The important result is that the application prevents a forbidden action, not simply that one demonstration produces a polite refusal.

Build a test set that resembles an inconvenient Tuesday

A polished demonstration often uses the questions its designer expects. Real work includes fragments, spelling mistakes, several requests in one message, missing attachments and people using old product names. Construct a test collection before improving the prompt repeatedly. Otherwise it is too easy to celebrate the examples the system has effectively rehearsed.

For a low-consequence drafting pilot, an illustrative starting set might contain thirty ordinary cases, ten ambiguous cases and ten cases that should be refused or escalated. These numbers are a planning example, not a validated minimum for production. Higher-risk uses require a more demanding assessment. Keep a separate set of unfamiliar examples for the final check.

For each case, record the allowed source, required facts, unacceptable claims and expected next action. Ask a reviewer to score those points rather than simply choosing whether the answer “looks good”. Retain failures. A prompt change that fixes one example can damage another. When the source pack, model or integration changes, rerun the relevant cases instead of assuming the previous result still applies.

Measure the whole job

Count the time from starting the task to a usable result. Include retrieving information, reading the draft, checking sources, correcting mistakes and completing the handover. If the assistant generates an answer in five seconds but creates three minutes of checking, those three minutes belong in the calculation. People experience the full workflow, not the model's response timer.

Quality needs more than one number. Track factual errors, missing required points, unnecessary escalations and cases where escalation was needed but did not happen. A short answer can be accurate yet unhelpful. A complete answer can still reveal information to the wrong person. Keep serious failures visible rather than averaging them away inside a generally positive score.

Compare similar task types and conditions. A batch of easy enquiries processed on a quiet morning is not a fair match for complicated complaints handled during a busy afternoon. Where practical, compare the same anonymised examples through both approaches and vary the order. Ask staff what became easier and what became more tiring. The tool should earn its place through useful completed work.

A worked example with the arithmetic visible

Imagine a small service office processing 120 suitable enquiries each month. Assume the current preparation and checking time averages eight minutes. That is 960 minutes, or sixteen hours. In an invented pilot, assisted preparation and checking average five minutes, producing 600 minutes, or ten hours. The difference is six hours. These are illustrative inputs, not AAG customer measurements.

Now include operation. Suppose reviewing the source pack takes two hours per month. Net released time is therefore four hours. If the business uses an illustrative staff-cost assumption of £22 per hour, that time has a planning value of £88. With an assumed monthly software cost of £35, the remaining amount is £53 before setup costs, tax effects or other overheads. Released time is not automatically extra revenue or a cash saving.

If setup takes six hours valued at the same £22, the illustrative setup cost is £132. Dividing by £53 gives roughly two and a half months of steady-state contribution to recover that amount, if every assumption holds. If monthly maintenance rises to five hours, only one hour remains, worth £22 against £35 of software. The same attractive demonstration would then fail this narrow financial test.

Open full-size graphic

Original AAG calculation. Hours are compared on one common scale. No client performance is represented.

Define a decision before seeing the result

A pilot needs a clear ending. Decide in advance what would justify continuing, narrowing the task or stopping. For our example, the team might require correct source use, no unauthorised disclosures, correct escalation on the selected boundary cases and lower total effort after checking. Those are proposed acceptance categories, not a universal standard or certificate.

A single serious failure can matter more than several minutes saved. If the assistant sends information to the wrong person, the response should follow the business's incident procedure. If it merely produces an awkward sentence, the response may be an editing adjustment. A useful review distinguishes severity rather than treating every correction as equivalent.

The NIST AI Risk Management Framework is a voluntary framework for managing AI risk across design, development, use and evaluation. Its separate Generative AI Profile provides additional generative-AI considerations. Referencing these resources does not mean a small pilot is NIST certified, and AAG makes no such accreditation claim. They are starting points for accountable questions, not badges to add to a sales page.

Give people a usable fallback

The person operating the tool should know what to do when it is unavailable, obviously wrong or uncertain. A link to the original approved guide can be more valuable than an elaborate error screen. Preserve the normal method of completing the task during the pilot. A failed experiment should not leave staff unable to answer an ordinary customer.

Name a source owner, an operational owner and someone who can disable the integration. In a small company those roles may belong to the same person, but they remain separate responsibilities. Write down where issues are recorded and which changes require another check. Keep enough information to understand failures without retaining every customer message indefinitely for convenience.

The UK Government AI Playbook offers public-sector guidance on selecting, buying and deploying AI. It is not a private-business accreditation or a promise that a particular supplier is suitable. Our small-business adaptation is straightforward: someone must understand the task, own the result and be able to return to a working process.

Run the pilot in a manageable order

First, agree the task and exclusions with the person who actually does the work. Next, prepare the source pack and examples. Then run the assistant without letting it take external actions. Record results against the existing process. Only after reviewing those results should you decide whether a supervised live trial is appropriate.

During a limited live trial, look at a small sample regularly rather than waiting for a monthly headline. Check whether the examples remain representative and whether employees are bypassing the tool. Bypassing may reveal that it adds friction, lacks a needed source or is unsuitable for a particular type of request. Treat that feedback as useful design evidence rather than a failure to adopt technology.

At the end, retain a short decision record: the scope tested, dates, source version, outcomes, known limits and next owner. If you continue, state what changes are allowed without retesting. If you stop, remove unnecessary access and handle retained data according to the agreed process. A disciplined stop can be a successful pilot when it prevents a poor purchase from becoming a permanent dependency.

Questions worth answering before you buy

Ask a prospective supplier to demonstrate an awkward example from your proposed task, using material you are authorised to share. Ask to see what happens when the answer is absent, when two documents disagree and when a user lacks permission. A rehearsed happy path is useful for learning the interface, but it should not settle these questions.

Find out which parts you can change yourself, which require paid support and what happens if you leave. Can the source documents and evaluation records be exported? What service costs are predictable and which increase with usage? Who checks the tool after a model or provider change? A useful quotation should make the ongoing work visible as well as the initial build.

Our view is that practical AI earns trust by making a specific job clearer and easier to verify. Start where the evidence can be inspected, keep authority proportionate and judge the complete task. If a simpler form or ordinary automation solves the problem better, choose it. Explore our workflow automation service and business systems work for the wider process around the tool.

Download and use the worksheet

The AI pilot worksheet includes a scope page, source register, test-case prompts, time-and-cost calculation and a final decision record. Print it, or enter your notes and use your browser's Print to PDF to keep them. It does not transmit entered information or require an account. Closing or refreshing the page can lose entries that you have not printed.

The worksheet is original AAG educational material. It is not legal advice, a security certification or a completed risk assessment for your organisation. The examples deliberately use invented businesses and figures so no client's confidential information is exposed.

Sources and further reading

Reviewed on 13 October 2026. External findings and guidance are linked at the relevant point. The pilot method, worked examples, diagrams and worksheet are original Anglo Ascot Group analysis. Mentioning a source does not imply its authors endorse AAG.

• Patrick Lewis and colleagues, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. Foundational research, not a current product benchmark.
• Information Commissioner's Office, Guidance on AI and data protection, current page reviewed 13 October 2026; the ICO flags ongoing review.
• National Cyber Security Centre, Prompt injection is not SQL injection, 8 December 2025.
• NIST, AI Risk Management Framework, framework released 26 January 2023; current page reviewed 13 October 2026.
• Chloe Autio and colleagues, NIST, Generative Artificial Intelligence Profile, 26 July 2024.
• Government Digital Service, Artificial Intelligence Playbook for the UK Government, 10 February 2025.