Guide · Governance, policy and return on investment
AI pilot: how to run a 90-day workplace AI pilot
A workplace AI pilot is a small, time-boxed test of one AI idea on real work. Choose a repeated task, measure it first, and agree a stop rule before you start. Run it for about 90 days, compare cost per finished task, then decide to scale, change or stop, with a named owner.
By Andrew Ward, Founder of ScorchsoftChecked 12 minute read
In short
- Pick one repeated task where a person is the glue between systems, not the most exciting idea.
- Take a baseline before anything changes: time, errors, cost and one outcome.
- Write the stop rule on day one: “If this measure isn’t this much better by day 60, we stop.”
- Name the person who carries the outcome, and agree the controls (approved tools, named users, a person’s sign-off) first.
- Scaling needs permission, data access, governance and an owner, not just a good result.
Written for: Team leaders, operations managers and owners in UK organisations planning their first AI pilot or proof of concept.
What is a workplace AI pilot?
A workplace AI pilot is a planned trial of one AI idea, on real work, with a small group, for a fixed time, measured against how the work went before. It ends in a decision: scale it, change it and test again, or stop.
This guide is about piloting AI tools and workflows at work in UK organisations, not about pilots who fly aircraft, and it doesn’t cover procurement, building software or data protection in detail. A proof of concept asks a narrower question, “can this be done at all?”, often on sample data in a week or two. A pilot asks “does it work here, for these people, at a cost worth paying?”, so it runs on real tasks for long enough to see the checking, the rework and the novelty wearing off.
The AI Stairway™ course calls this a 90-day test: a small, measured trial of one AI idea, with a baseline, a measure and a stop rule. Module 10 teaches it in full; this guide gives you the shape and a plan you can copy.
Also called
AI proof of concept (PoC), AI trial, AI experiment, AI test-and-learn, AI pilot programme.
How do you choose which AI idea to pilot?
Choose work that repeats, where improvement would matter, where you can get evidence and where someone wants it better. Repeated glue work, where a person copies between systems, is often the best start. Sometimes a better form or plain automation beats AI.
| Test | Ask | A fail looks like |
|---|---|---|
| It repeats | Does this happen every week, or more often? | An annual report, a one-off project. |
| Improvement would matter | Would faster, cheaper or more accurate work change something people care about? | A task nobody minds and no client notices. |
| Useful evidence is available | Can we time it, count errors or see an outcome, before and after? | “Staff will feel more confident”, with nothing to count. |
| Someone wants to improve it | Is there a person who does this work and wants it better? | An idea imposed from above on a team that didn’t ask. |
Glue work is a good hunting ground: the copying, re-keying and chasing a person does because two systems don’t talk. It repeats, it’s measurable and the people doing it usually want it gone. Module 8 teaches how to map it.
A non-AI answer counts as a win
If the tests point to a clearer form, a changed process or ordinary automation, do that. The point of choosing carefully is to fix the work, not to use AI.
What should you measure before and during the pilot?
Measure a baseline before you change anything, then the same things during the pilot: minutes per task, errors and rework, cost per finished task (the course calls it cost per task), including checking time, and one outcome people care about.
- Time per finished task, including preparing, checking and fixing, not just the first draft.
- Errors and rework: how many needed fixing, and how long that took.
- Cost per finished task: people’s time at an agreed rate, plus the AI’s usage and licence share.
- One outcome: late returns, complaints, days to close, errors found later.
- Where the time goes: speed one step up and another often becomes the slowest.
Don’t use logins, prompts or how much people “like it” as the measure. Liking it is worth knowing; it isn’t evidence that the work got better. Our AI ROI guide works the cost per finished task sum through with a full example.
What is a stop rule, and why set it first?
A stop rule is a rule, set before a test starts, that says when to stop if it isn’t working. Setting it first keeps you honest: once people have put effort into a pilot, it is much harder to agree what failure looks like.
Write it as one sentence: “If [measure] isn’t [better by this much] by day 60, we stop.” For example: “If cost per finished chaser isn’t at least 10% lower, with late returns no higher, by day 60, we stop.” Add a safety stop too: “If anything confidential goes to an unapproved tool, or a wrong figure reaches a client, we pause at once.”
A stopped pilot is a result, not a failure. It saves the cost of rolling out something that doesn’t pay, and tells you what to try next. A test without a stop rule tends to run forever.
What does a 90-day AI pilot plan look like?
Ninety days gives two weeks to decide and measure, about six weeks of controlled use with a checkpoint at day 60 against the stop rule, and a final month to gather evidence and decide. Copy the plan below and change the dates.
Step 1: Days 1 to 14: decide and take the baseline
Run the four tests on your shortlist and pick one idea. Name the owner. Time 20 to 30 real tasks, count rework, note one outcome, and date it. Write the stop rule and the safety stop. Agree the controls: which approved tool, which named users, which data may go in (your tramlines), and a person’s sign-off before anything leaves the organisation. If personal data goes in, ask your data protection lead whether a DPIA is needed. Tell the team what is being measured and why: the process, not the people.
Step 2: Days 15 to 30: start small, under control
Two to five people use the AI way on the real task. Keep a simple log: minutes to prepare, check and fix, and anything that went wrong. Hold a short weekly check-in. Fix the instructions, not the people, when something goes wrong.
Step 3: Days 31 to 60: run it as normal work
Let the novelty wear off. Keep logging. Look for where the time has moved, and which rules need more than an instruction to hold: a rule that must hold every time usually needs a permission or code, not a prompt (Module 9 covers which rules need code).
Step 4: Day 60: checkpoint against the stop rule
Compare cost per finished task and the outcome with the baseline. If the stop rule is hit, stop and write down what you learned. If not, carry on, change one thing at most, and say so.
Step 5: Days 61 to 90: gather the evidence and decide
Finish the measures, ask the users what would break at scale, and list what scaling would need. The owner recommends one of three calls, scale, change and test again, or stop, with the evidence, to whoever decides.
Ninety days is a working length, not a magic number. For comparison, the UK government’s cross-government Copilot experiment ran for three months, from 30 September to 31 December 2024, across 12 organisations (Government Digital Service, published 2 June 2025).
What does a pilot verdict look like in practice?
In the invented example below, the pilot speeds the work up but hits its stop rule, because checking eats the saving. The test stops as agreed, and since most errors have one fixable cause, the verdict is “change and test again”, with a new stop rule.
Darren Lowe, payroll and bookkeeping senior at a 40-person accountancy practice, pilots an approved AI tool that suggests expense codes. Gareth Bennett, the practice manager, owns the decision. The baseline and the stop rule were set in week one. By day 60, coding time is down by a third, but one code in ten is wrong, and finding and fixing them takes longer than the time saved. The first test stops, as its rule says. Looking closer, nine wrong codes in ten come from one supplier’s invoices. Darren and Gareth fix how those invoices come in and start a new test, with a fresh baseline and its own stop rule. Everyone and every figure here is invented.
| Call | When it’s right | Watch for |
|---|---|---|
| Scale | Measured against the baseline, cheaper per finished task, and nothing important missed. | Keep the check and the owner as it grows. |
| Change and test again | The saving is eaten by errors or checking, but the cause can be found and fixed. | Change one thing, and reset the stop rule. |
| Stop | No baseline, nothing measured, or checking costs more than it saves with no fixable cause. | Write down what you learned. A clean stop is a good result. |
Who should own an AI pilot?
One named person who carries the outcome of the work being tested: usually the team leader for that process, not IT and not the AI champion. They own the stop rule, the measures and the recommendation.
The course’s line is “AI touches tasks. People carry outcomes.” In a pilot that means the person who answers for the chasers going out or the payroll being right also answers for the test. IT, data protection and an AI champion support them; they don’t replace them.
- Owner: carries the outcome, holds the stop rule, makes the recommendation.
- Users: two to five people who do the work and log it honestly.
- Checker: whoever reviews outputs before they take effect, named by role.
- Sponsor: the person who gives time, permission and data access, and takes the decision at day 90.
Give the pilot team what it needs: time to log, permission to use an approved tool, and access to the data the task needs. Managers’ signals matter: the Department for Business and Trade’s Copilot evaluation (UK government, 1,000 licences, published August 2025) reported, anecdotally, that people were less likely to use the tool when colleagues and line managers were hesitant about it.
What does it take to scale an AI pilot?
Scaling needs four organisational conditions: permission to use the tool for that work, access to the data, governance that says what goes where and who checks, and a named owner. It also needs the build and upkeep to cost less than the return.
| Condition | In place when… | Often missing because… |
|---|---|---|
| Permission | The tool is approved for this work, through your trust check or equivalent. | The pilot ran on a personal account or a free trial; our shadow AI guide covers why that happens. |
| Data access | The workflow can reach the systems and data it needs, with the right permissions. | Someone copied data in by hand during the pilot. |
| Governance | Rules say what data goes where, who checks what, and how problems are reported. | The pilot’s rules lived in one person’s head. |
| An owner | A named person carries the outcome and looks after it when the model or the rules change. | The enthusiast who ran the pilot moved on. |
A workflow that works for one team usually needs more to run across the organisation: software around the AI step, checks that hold every time, and someone to maintain it. That might be a feature of a tool you already have, a no-code automation, or software built for you. Weigh that cost against the return per task times the people who will use it. That weighing is Scorchsoft’s practice from software projects, not research.
Economists make a similar point about new technology in general: Brynjolfsson, Rock and Syverson (American Economic Journal: Macroeconomics, 2021) argue that general purpose technologies such as AI “enable and require significant complementary investments”, in processes and people as well as tools. Toyota describes the same order in its production system: first try doing the work “thoroughly by hand”, improve it, then build it into the machine.
Why do AI pilots stall?
Pilots often stall for ordinary reasons: no baseline, so nothing can be shown; no stop rule, so nothing ends; no owner; or a pilot that worked by hand but has no route to permission, data access and upkeep. These are problems of set-up, which a 90-day plan is built to catch.
Forecasters expect a lot of cancellations. Gartner, an analyst firm, predicted in June 2025 that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. It is a forecast about one kind of project, not data, but the reasons it gives are the ones a baseline, a stop rule and an owner bring to light early.
Training is part of it too. The Office for National Statistics found that only 11% of UK businesses with 10 or more employees reported that more than half their workforce had received AI-related training (Business Insights and Conditions Survey, June 2026, published 20 July 2026). A pilot team that hasn’t been shown how to use and check the tool will produce a test of the training, not of the idea.
The one thing not to do
Don’t scale a pilot because people enjoyed it. “Everyone loved it and it felt faster” is a reason to measure, not a result.
What should be on a pilot checklist?
Before day one, a pilot needs one idea, a named owner, a dated baseline, a stop rule and a safety stop, approved tools and data rules, a checker, a log, and day-60 and day-90 dates. If anything is missing, fix that first.
90-day AI pilot checklist (copy it)
- One idea, chosen with the four tests, written in one line.
- A named owner who carries the outcome of this work.
- A dated baseline: minutes per task, rework, cost per finished task, one outcome.
- A stop rule and a safety stop, written down and agreed.
- An approved tool, named users, and what data may and may not go in.
- A person checks before anything leaves the organisation or affects a person.
- A simple log, and a weekly 15-minute check-in.
- A day-60 checkpoint and a day-90 decision date in the sponsor’s diary.
- What the saved time will be used for.
- What scaling would need: permission, data access, governance, an owner.
If you can’t tick a line, the AI readiness assessment can help you see what’s missing. For the rules a pilot should sit inside, see our AI governance guide. To see where a measured workflow sits in a wider climb, the AI maturity model guide sets out the AI Stairway™ to Success, Scorchsoft’s own model.
Questions people ask
What is the difference between an AI pilot and a proof of concept?
A proof of concept checks whether something can be done at all, often on sample data in a week or two. A pilot tests whether it works on real tasks, with real people, at a cost worth paying, over long enough to see checking and rework, usually 60 to 90 days.
How long should an AI pilot last?
Long enough for the novelty to wear off and rework to show, short enough to keep the question sharp. Ninety days, with a checkpoint at day 60, suits most single-task pilots.
How many people should be in an AI pilot?
Usually two to five people who do the work every week, plus an owner and a checker. Enough to see variation, few enough to log carefully.
What if the pilot is stopped?
Write down what you learned and why it stopped, and share it. A clean stop based on evidence saves money and makes the next idea easier to choose. It is a result.
Can we pilot AI with personal accounts?
It’s better not to. Pilot on an approved tool with work data rules agreed, so a good result can scale without starting again. Our shadow AI guide covers why people use personal accounts and what to offer instead.
Training for the whole team
The AI Stairway™ gives everyone the same careful habits, then helps your team agree its rules and test one AI idea properly. Everyone can start with the free introductory module.
AI training for teamsSources
Every figure on this page comes from one of these. Links open in a new tab.
- Microsoft 365 Copilot Experiment: Cross-Government Findings Report (opens in a new tab). Government Digital Service, 2 June 2025.
- M365 Copilot evaluation (opens in a new tab). Department for Business and Trade, August 2025.
- Artificial intelligence in UK businesses: 2023 to 2026 (opens in a new tab). Office for National Statistics, 20 July 2026.
- Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (press release; a forecast) (opens in a new tab). Gartner, 25 June 2025.
- The Productivity J-Curve: How Intangibles Complement General Purpose Technologies (Brynjolfsson, Rock and Syverson) (opens in a new tab). National Bureau of Economic Research, working paper 25148; published in American Economic Journal: Macroeconomics 13(1), 2018, revised 2020; journal 2021.
- Toyota Production System (opens in a new tab). Toyota Motor Corporation, read 29 October 2026.