A demo proves a workflow can work. Go-live needs proof that it does, on your cases, at your volumes, measured against the process it replaces. Here’s how to test an AI workflow before you switch it on, and the four gates we’d want it to pass before anyone relies on it.
Series – this is part 3 of 4 in Pilot to Production, our practical guide to getting an AI workflow live and keeping it there. Part 1: The AI Pilot That Reaches Production Is the One Nobody Wants to Demo. Part 2: The Pilot Worked. Now Build It Like Someone Will Rely on It. Part 4: Your AI Workflow Is Live. Who’s Watching It, and What Comes Second?
On 19 October the Financial Conduct Authority published what it had learned from watching firms put AI to work, drawing on its supervisory work and its AI Lab initiatives, including AI Live Testing. Its good-practice list reads like a go-live checklist. “Piloting lower-risk use cases before full deployment.” “Stress-testing AI tools before deployment.” And “structured challenge, testing and sign-off before deployment”, where firms “involved staff from areas across the business in testing and sign-off” and “formal evaluation, clear accountability and executive approval helped identify and mitigate risks before launching new AI systems.”
The poor practice is just as useful. The FCA flagged “overreliance on untested vendor assurances”, and described one firm where “retrofitting governance after deployment proved difficult and left gaps in accountability.” The paper sets no new rules, and its examples are anonymised and drawn from financial services. The method works well beyond banking.
Proof before launch is cheaper than governance retrofitted after it.
Gate One: Agree What Good Enough Means
Write the acceptance criteria before anyone runs a test. Once the results are in, every threshold starts to look negotiable.
The bar is today’s process, measured honestly. If people currently get 4% of invoice exceptions wrong, a workflow that gets 2% wrong is an improvement, even though it isn’t perfect. Some errors don’t trade off against anything, though. Paying the wrong supplier, or sending one customer’s details to another, should have a threshold of zero, and a single failure should stop the rollout.
| Measure | How it’s tested | Example: supplier invoice exceptions |
|---|---|---|
| Quality | Outputs scored against the labelled test set and the quality bar from part 1 | At least as accurate as today’s 96% |
| Unacceptable errors | Named failure types counted separately from the overall score | Zero payments to the wrong supplier |
| Escalation rate | Share of cases the workflow hands to a person | No more than one in five in the first month |
| Speed | Time from arrival to a decision a person can approve | Same working day |
| Cost per outcome | Full cost divided by accepted outcomes | Below today’s cost per exception |
| Sign-off | Who accepts the evidence | AP lead, finance risk, security, the run team |
Measure it against the process it replaces, not against perfection. But set some errors at zero.
Gate Two: Pass the Test Set
In part 2 we started a test set during the build. Now it has to earn its keep. A good one holds the boring majority, the cases the workflow will see every day, and the nasty edges, labelled by the people who do the work rather than the people who built the tool. Keep a slice back that the build team has never seen, so you’re not just testing whether they’ve learned the answers. It’s less common than it should be: in LangChain’s survey of more than 1,300 people building AI agents, just over half (52.4%) said they run offline evaluations on test sets.
Then run it again on every change: a new model version, a new prompt, a new source document. A workflow that passed in October can fail in December because its supplier updated the model, and a test set you re-run every time is the cheapest way to catch it. In the Bank of England and FCA’s 2026 survey, only 48% of firms said they always regression-test high-materiality updates to vendor models or their guardrails, and 25% always or usually let those updates go straight into production. Only 48 firms answered that question, so treat the numbers with care. The direction is hard to miss.
Gate Three: Run It in the Shadow
A test set is still a sample. Before the workflow acts on anything, run it alongside the current process for a few weeks on live volumes. It makes its decisions, nobody acts on them, and you compare them with what people actually did.
The FCA’s paper describes a firm doing exactly this with affordability assessments, where “staff made the decisions while the system was being established.” Its reviewers “assessed each case without being shown the AI’s proposed outcome, allowing the firm to compare independent human and AI judgements and reduce the risk that reviewers would defer automatically to the system.” Hiding the AI’s answer matters. People shown a suggestion tend to agree with it, and then the comparison tells you nothing.
The disagreements are where the value is. Some will be the workflow’s mistakes, and they go into the test set. Some will turn out to be the person’s mistake, which is useful evidence for the business case. And some will show that the process nobody wrote down is different from the one everybody thought they had. Find that out during a shadow run rather than after go-live.
A shadow run is the only test that uses next month’s cases instead of last month’s.
Gate Four: Switch It On in Stages, With a Rollback You’ve Used
Start with a slice: one team, one region, or one in ten cases. Watch the measures from gate one daily, widen the slice when they hold, and agree in advance what pulls it back.
Test the rollback before you need it. Actually switch the workflow off, run the manual process for an afternoon, and switch it back on. If the team that used to do the work has been redeployed, or nobody remembers how the old process worked, you don’t have a rollback. You have a plan to have one. Most regulated firms at least write it down: 73% of the firms answering that Bank of England question always or usually have defined rollback plans for problematic vendor updates. Whether anyone has rehearsed them is another question.
Who Signs It Off
Four people should sign before go-live: the business owner, who answers for the outcome; risk or compliance, who check the zero-tolerance errors and the audit trail; security, who check the identity, access, and guardrails from part 2; and whoever will run it, who confirm they can monitor it, switch it off, and fall back. Give them one evidence pack: the criteria, the test results, the shadow-run comparison, and the rollback test.
Signing it off isn’t the end of the job. Part 4 covers what happens next: who watches the workflow once it’s live, how you’ll know when its quality starts to slip, and how to make the second workflow faster than the first.
Q&A: Testing an AI Workflow Before Go-Live
How do you test an AI workflow before go-live?
Agree acceptance criteria first, then pass four gates: score it against a labelled test set of real cases, run it in shadow alongside the current process on live volumes, switch it on in stages, and prove the rollback works before you widen it.
How accurate does an AI workflow need to be?
At least as accurate as the process it replaces, measured honestly, rather than perfect. Some errors, such as paying the wrong supplier or exposing personal data, should have a threshold of zero, with a single failure enough to stop the rollout.
What is shadow mode for AI?
Running the AI workflow alongside the current process on live work without acting on its decisions, then comparing its outputs with what people actually did. It tests the workflow on new cases and shows where it, or the existing process, gets things wrong.
What is an AI evaluation set?
A collection of real cases with the answers they should produce, labelled by the people who do the work. It’s used to score a workflow before go-live and re-run on every change to the model, prompt, or data, so regressions are caught early.
Who should sign off an AI workflow for production?
The business owner who answers for the outcome, risk or compliance, security, and the team that will run it. Each signs against the same evidence pack: acceptance criteria, test results, the shadow-run comparison, and a rollback test.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we help organisations prove AI works before they rely on it. Our AI Use Case Factory builds the evaluation and A/B testing that validates each use case against real outcomes, and our Onboarding & Assurance Audit sets an SLA baseline against how a system actually behaves and names the gaps a risk function would flag, whether we built it or someone else did.
If you’re preparing a workflow for go-live, our free Generative AI Implementation Playbook covers evaluation frameworks, output validation and grounding, A/B testing for generative outputs, and the governance checkpoints we’d place before anything goes live.