Is your small or medium business ready to implement AI?

For most UK small businesses, AI means software that drafts, summarises, extracts or suggests. In practice that usually comes in one of three forms:

A helper (often called a copilot) inside software you already use, such as your email or office suite. Workflow automation, where an AI step sits inside an existing process. A small custom job that connects to an AI service through an API (a connection between two pieces of software).

It does not mean building or training your own large AI models. That's a different game with different costs. Most SMBs start with a helper inside tools they already pay for. Custom builds usually come later, if at all.

Quick check: Can you say which of the three types your idea is?

Readiness is about your business facts, not how impressive the tool is. The useful question is: are we ready to try this one job safely?

That breaks down into seven practical areas: what you're trying, your logins and tools, who runs and checks the work, whether the data is OK to use, how you'll measure and stop, whether you could leave the tool, and whether the money and sponsorship make sense.

For each area, be honest. If you don't know, count it as a gap for now. Guessing high hides the problems that tend to bite in week two. Gaps are normal. They're a to-do list, not a verdict on your business.

Quick check: For your chosen job, can you name the owner, the data it uses, and how you'd turn it off?

Because vague ideas like “use AI more” lead to messy trials and nothing you can measure. Five half-started experiments usually produce no clear result and use up everyone's time.

One job, written in one sentence, keeps everyone honest about what you're testing. A good example: “Draft first replies to routine customer email enquiries so the office team spends less time typing.” A bad one: “Be more productive with AI.”

If you have several ideas, list up to three and pick one for now. You can come back to the others once the first trial has told you something real.

Quick check: Is your job written in one sentence, with who benefits?

Today's tools are useful for first drafts, summaries, pulling details out of documents, and suggesting options. That's routine work where a person can quickly check the result.

They are weaker where accuracy really matters and nobody checks: facts about specific customers, figures, legal or financial wording, or anything sent out automatically. They can sound confident while being wrong.

A sensible rule: let AI draft or suggest, and keep a human in charge of anything customer-facing or sensitive. Write down what must never go out without a person looking at it.

Quick check: Have you written down what must never go out without a human check?

A first trial (a pilot) should be short and time-boxed, often two to six weeks, with a clear end date and a success bar agreed at the start. It isn't a company-wide rollout.

Open-ended pilots rarely end. They drift on, the tool stays switched on, and nobody makes a decision. A dated window with a pass-or-fail threshold forces one. For example: “Four weeks; succeed if average handling time drops on our sample set without a drop in quality.”

Put a check-in around week two and a reassessment date in the diary when you start, not afterwards.

Quick check: Is there an end date and a success bar in the diary?

Yes, sometimes. AI tools can produce plausible-sounding answers that are simply wrong or invented. That isn't a rare bug. It's how these tools behave, so plan for it.

The fix isn't becoming an AI expert. It's making sure the person who reviews the output already knows what “right” looks like for this job, whether that's invoices, quotes, job notes or customer emails. If nobody can tell good from bad, errors will reach customers or records.

Also decide how you'd spot and correct a mistake about a real customer or member of staff. Waiting for complaints isn't a plan.

Quick check: Can the reviewer spot a wrong answer in this job's content today?

Demos show the best case: clean data, a tidy mailbox, a practised presenter. Your Monday has half-finished threads, typos, scanned paperwork and busy staff.

Treat the demo as a vendor claim, not proof. Separate “what they promise” from “what we can check ourselves”, and write a short verify-before-you-buy list. Then test on a small sample of your own real (and suitably trimmed) material.

Before a pilot goes wider, run a simple acceptance check: try around ten real examples, score them, and decide pass or fail.

Quick check: What would you see in your own files in week one that proves this works?

Treat any payback figure with care. It quietly assumes two things: that you measured how the job performs today, and that you can keep using the tool on the same terms.

If there's no before-number, every after-story is a sales story. And if the vendor changes its price, suspends your account, or you can't take your work elsewhere, the savings can vanish.

That's why the SovereignBase approach checks data and “can we leave?” questions before looking at return on investment. Positive payback assumes you can keep going, and that's unproven until you've tested turning it off and taking your work with you.

Quick check: Would the savings survive if you had to switch provider next quarter?

“The directors are supportive” isn't sponsorship. You need names.

A sponsor is the person who can say yes or no to the money and to people's time. Without one, pilots drift and nobody protects the diary slots.

A process owner looks after the everyday process the AI job sits in, such as invoicing, enquiries or scheduling. That's not “whoever installed the tool”, and not “IT by default”. IT can switch a feature on, but it can't own whether enquiry drafts are actually better.

It can be the same person. It can be you. Just write the names down.

Quick check: Could you write down the sponsor's and process owner's names right now?

Before you start, write two or three kill criteria: plain reasons you would stop. For example: too many errors, no time saved after four weeks, staff won't use it, or personal data being shared unexpectedly.

Then name the kill-switch owner: one person with clear authority to order a stop when those criteria are hit. “Management” isn't a name.

Stopping isn't failure. It protects time and money, and it's how you avoid a weak tool becoming a permanent habit. The same person can own the criteria and the stop order.

Quick check: If a kill criterion were hit tomorrow, who would say “stop”?

Fewer than you might think, and mostly the ones they already use:

Spotting wrong answers. The person reviewing output needs to know the job well enough to catch mistakes.

Knowing what not to paste in. A short written rule: no passwords, no payment card details, no full customer exports, no sensitive HR notes.

Basic admin. Someone (a staff member, an IT support provider or a capable owner) who can change settings, manage access and turn the feature off.

A deputy. Someone who can review outputs and pause the trial when the owner is on holiday or off sick.

Quick check: Is your “do not paste” rule written down, not just said once?

Usually not for a first pilot. A bounded trial of a helper inside software you already use mostly needs a clear job, a named owner who knows the work, a basic admin, and someone to check the output.

What people do need is a little time: to learn the tool, agree the “do not paste” rule, and practise reviewing output on real examples. Plan that time properly rather than squeezing it into lunch breaks.

Specialist help becomes more relevant if you move to custom builds, connect AI to several systems, or handle higher-risk data. Even then, the business owner of the job stays the business owner.

Maybe, but check first. Personal data is anything that identifies a living person: names, emails, phone numbers, addresses, HR notes and similar. Under UK GDPR, the UK's data protection law, you need a valid reason (a “lawful basis”) for each way you use it.

Having data for one purpose doesn't automatically mean you can use it for a new AI job. Write one sentence: “We are allowed to use this data for this job because…; decided by…”. If you can't, get advice before any live pilot with personal data. Health and similar sensitive data carries extra risk.

The ICO (the UK regulator) publishes guidance on AI and data protection and a guide to lawful basis. This FAQ isn't legal advice.

Quick check: Can you finish the sentence “We are allowed because…”?

Usually to the vendor's computers. Most AI tools send what you type or upload to the provider's servers, where the AI processes it. Some features, such as web search, plug-ins or connections to your inbox or file storage, may send data along different routes.

You should know, on paper: which company processes it, where processing happens for the plan you actually pay for, and which features change that. A one-page note from the vendor's terms or admin console is enough to start.

When you connect AI to email, file storage or your customer database (CRM), check what it copies, where those copies live, and how they're deleted if you disconnect.

Quick check: Do you have a one-page note of where your prompts and files are processed?

Use as little as you can. A pilot doesn't need every live customer record. Smaller, trimmed or sample data reduces the harm if something goes wrong.

Start by listing the data the job needs: five to fifteen items, including anything staff might paste into a prompt. Then trim it down. Prefer last month's samples with names blanked out, or made-up examples, over today's full live inbox.

Decide who's allowed to see the AI's outputs too. Even one line, such as “only the accounts team and the named owner”, is better than “anyone in the company chat”.

Quick check: Is your pilot dataset smaller than your live data?

It can be. With personal accounts on free consumer apps, the business has no control over how prompts are kept or used. Customer details pasted into a free app on a staff phone are a common way for data to leak.

This is usually a habit, not bad intent, so the fix is simple and calm: agree which approved tool people may use on work accounts, and write a half-page rule on what must never be pasted into anything else.

Banning everything without offering an approved option tends to push use out of sight. Give people a sanctioned route instead.

Quick check: Do staff know which AI tool they're allowed to use for work?

Nothing fancy, but the basics matter on the systems this job touches:

Named accounts, not shared passwords. You need to know who did what.

MFA (multi-factor authentication): an extra login step, such as a code on your phone, on top of the password. “Most people have it somewhere” isn't enough. Check the email, file storage or CRM this job actually uses.

A named admin who can change settings and access. “Nobody knows the admin password” is a common trap.

The NCSC's Small organisations guide to cyber security covers these foundations in plain terms.

Quick check: Is MFA switched on for every account this job touches?

AI features sometimes rewrite, move or sync files. If you can't restore the kind of data this job uses, a small mistake becomes a crisis. “We have backups” isn't the same as “we restored this kind of file recently and it worked”.

You also need a known way to switch the AI feature off or remove access quickly, without waiting days for a vendor support ticket. Ask your admin to show you the switch or the steps, and save a screenshot or short note.

Better still, practise it: turn the AI off for a few hours on a quiet day and check the work still gets done the old way.

Quick check: Has anyone actually tested the off switch?

Check before you rely on it. The practical tests are simple:

Export. Can you take your files, chat history, saved prompts and any custom assistants with you in a usable format, on the plan you actually pay for? Try a small export early.

Fallback. If the tool stopped today, could the job still be done another way? If it's the only path for important client or compliance work, that's a stop sign.

Second provider. Could the same job reach your quality bar on another provider for a week without rebuilding everything? Keeping your prompts and checklists in a folder you own makes this realistic.

Quick check: Have you tried exporting anything yet?

It helps with some questions, but it isn't an exit plan. “UK region” (or “UK/EU”) describes where data is stored or processed, sometimes only for certain plans or features. It says nothing about whether you can take your work elsewhere, keep trading if your account is suspended, or run the job without that vendor.

Check the claim against your actual plan, and ask which features, such as web search, send data on a different route. Then run the real tests: export, fallback, and a second provider.

The same goes for “open” models running on someone else's cloud. Useful, perhaps, but not an exit plan on their own.

Quick check: Would “UK region” help you if your account were locked tomorrow?

Blog posts and homepages change. The binding terms (the product terms and data processing agreement) are what count. Look for five things:

Training: can your data be used to improve their models, and can you opt out properly?
Retention: how long do they keep your data?
Sub-processors: which other companies handle it?
Suspension: can they switch you off, and on what terms?
Exit: what help do you get to take your data and leave?

If this feels out of your depth, ask someone qualified to check it against a simple checklist. Ignore the slogans.

Quick check: Have you read the terms for the plan you'd actually buy?

Licences are the visible part. Hours are the costs that quietly sink pilots.

A short 90-day cost sketch should include: seats or usage charges, setup time, training time, weekly hours for whoever reviews the AI output, admin time, and your own hours. Your time is a real cost even if no invoice arrives.

If review time isn't booked in the diary, you've budgeted hope, not resources. Seats without time usually end with an expensive feature nobody uses and a team that drifts back to the old way.

Also ask whether the job happens often enough to be worth it. Something you do twice a year rarely repays the setup.

Quick check: Are review hours in the diary, not just seats on the invoice?

Measure before you start. Pick one number for this job, such as minutes per invoice, rework on quotes or handling time per enquiry, and get a rough baseline. Timing five real jobs with a stopwatch is enough, and a range you trust (even give or take 30%) is fine.

Then ask: if this got 10–20% better, would it matter? At the end of the time box, compare against the baseline and your success bar.

Stop, or don't expand, if there's no named owner, the baseline can't be measured, the savings look negative, or payback is still unclear. Being willing to stop is a strength.

Quick check: Do you have a before-number for this job?

The result describes this one job, not your company's AI future.

GO: a scoped, time-boxed pilot is justified. You have a named owner, a metric, and no blockers on data or your ability to leave. Next: write a one-page pilot plan (job, time box, metric, checker, kill criteria, off switch, week-two check-in).

WAIT: promising, but conditions are missing. Next: list the top gaps with an owner and a done-by date, fix data and “can we leave?” gaps first, and re-score in 30 to 90 days.

NO: starting now would create avoidable risk. Next: fix foundations such as logins, owners and data permission before looking at any tools.

It's a structured self-check that takes about 25 to 30 minutes for one named job. You write the job in one sentence, name an owner, then score questions across the seven areas in this FAQ as 0 (we don't have this, or don't know), 1 (partly) or 2 (good enough for a bounded pilot).

The order matters. Data problems and “can we leave?” red flags are checked first and can block a GO on their own, whatever the averages or money maths say. Costs and sponsorship are soft signals: they prompt you to fill gaps, but never fail you alone.

You come away with GO, WAIT or NO, your weakest areas, and a short list of top gaps to fix.