AI can now automate nearly everything in customer operations at a bank or fintech: frontline support, lending, onboarding, KYC. That breadth is exactly why so many teams don't know where to start, and the ones who have started often can't say whether it's working. 75% of UK financial services firms are already using AI, according to the Bank of England and FCA's latest survey, yet Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, and one of the three reasons it names is inadequate risk controls.
You don't need an AI strategy for everything at once. You need a few core use cases, a way to measure them properly, and a path to expand. The best first use case is usually a narrow, high-volume process where the manual pain is obvious. Outbound collections calls for accounts in early arrears, disputes, and document verification for KYC are all examples of clearly scoped use cases where the impact is measurable and ROI is clear. For a full set of use cases, check out our guide to AI use cases in banking.
After you’ve landed on a use case, a few critical steps can be the difference between a failed pilot and launching to production.
Why evaluating an AI agent is different from evaluating traditional software
An AI agent can't be tested the way traditional software is tested. Software either works or it doesn't, and once a test passes it stays passed. An AI agent phrases every conversation differently, meets customers who behave in ways nobody scripted, and changes behaviour whenever its knowledge, procedures, or underlying models change. One passed test tells you almost nothing.
There are two more problems to plan around. The first is that vendor demos prove very little, because a demo is a rehearsed conversation on the agent's best behaviour (we've written before about how to evaluate AI agent demos). The second is that offline testing, however thorough, mostly catches things that are broken. The difference between two competent AI agents is closer to 10% than 50%, and a difference that size only becomes visible in live conversations at volume.
Neither is an argument against testing. They are the reason evaluation happens in stages: prove safety before launch, prove quality during a controlled ramp, then keep checking both for as long as the agent is live.
Step 1: Bring in the right stakeholders early
In financial services, an AI agent evaluation is never one team's decision. Risk, compliance, information security, and legal each hold a veto, and if the first time they see the agent is at the sign-off meeting, they have every reason to say no. In the deployments that reach production, the teams who approve the launch also help design the evaluation, so testing produces the evidence each of them needs.
Four teams need to be involved before the first test:
Operations: This team is responsible for the outcome. They set the day-one scope, build the scorecard, and decide what the agent has to prove to move forward
QA: They validate the scorecard and run the reviews, so the quality bar belongs to your team rather than the vendor
Risk and compliance: Ask them what evidence they need to approve the launch. Many committees are approving a customer-facing AI agent for the first time and have no formal criteria yet, so agree the criteria up front rather than discovering the bar at the end
Information security and legal: Run the security review and data agreements in parallel with offline testing. Offline testing works on mock or anonymised data, so neither workstream needs to wait for the other
We cover the internal sell in more depth in our guide to deploying AI agents in banking.
Step 2: Determine your success criteria
One of the most critical errors we see in early AI agent evaluations is that teams don’t codify what success looks like ahead of time. In fact, the FCA found that only 34% of firms say they have complete understanding of the AI they use. But you can close that gap with three steps:
1.) Build your scorecard: Decide how conversations will be graded, and use that single rubric everywhere: in pre-production testing, during the ramp, and in ongoing QA. The strongest version is the scorecard your QA team already uses for human agents. This makes the comparison objective, and it answers the question your risk committee will actually ask: is the agent measurably better than the team we have today?
2.) Write your acceptance criteria: Agree on the numbers you need to hit before launch, before you start the project. For frontline AI use cases, this is typically a minimum QA pass rate and CSAT score. Teams who skip this step end up renegotiating what success means after every test cycle.
3.) Determine your severity scale, because not all failures are equal: There are several root causes behind an undesirable AI reply, and most often it's a matter of missing context or information rather than anything more alarming. What matters is quantifying each failure's impact. The enterprise financial services companies we work with run internal quality assurance reviews that score conversation outcomes on a high, medium, and low risk scale and set benchmarks for expected behaviour, sometimes setting the bar for the AI agent higher than for their human agents.
Step 3: Build confidence with pre-production testing
With the scorecard agreed, pre-production testing becomes systematic rather than improvised. Four mechanisms do most of the work.
Test cases with success criteria: a test case seeds a conversation with a scenario, states what the agent must and must not do, runs the agent, and records a pass or fail. A separate evaluation system, fully independent of the agent being tested, grades each result, so the agent never marks its own homework. A synthetic customer plays the other side of the conversation, which means the same approach works for voice: the test simulates the agent's decisions and replies without needing to place a call. Test cases are named after real failure scenarios, and the success criteria are written in plain English.
Pre-built suites, extended with your own scenarios: our agents come with test suites compiled from production deployments and the edge cases we've seen in the market. The lending suite, for example, covers scenarios like a customer disclosing financial vulnerability, a third party answering the call, and a customer suspecting the call is a scam. From that base, you add your own test cases to stress-test the agent against your policies, your customer segments, and your risk scenarios.
Mocked data for regulated flows: the riskiest journeys, like identity verification and one-time passcodes, are exactly the ones you can't rehearse on real accounts. Testing them against mocked data allows the agent to run the full flow, including the failure paths, without touching a real customer record.
Batch testing against your own history: running the agent against a set of your historical conversations produces a resolved, handed off, and failed breakdown across hundreds of cases at once. It's the fastest way to see how the agent performs on your actual contact mix rather than on invented scenarios, and it turns re-testing after a change from a week of manual work into minutes. Morse shows what iterating on procedures is worth: 50% of inquiries resolved out of the box on day one, rising to 78% after adding customer data and scenario-specific procedures.
The final pre-production step is red teaming: put your own team in front of the agent and ask them to break it with profanity, prompt injection, impossible requests, and angry customers. For voice specifically, our voice AI testing guide covers the 40 most common failure scenarios worth running. Every failure your team finds here is one a customer never sees.
One European bank we work with took this a step further. Their team built an adversarial test set of their own from public toxicity and bias benchmarks, defined the expected outcome for every case, and ran the whole set through the platform's test cases, reviewing the results against their own expectations. The detail worth copying is the expected outcome per test: for many adversarial inputs the correct behaviour is handing off to a human, so their tests count a handoff as a pass.
Step 4: Make your go-live decision based on evidence
The go-live decision has a common failure mode: teams keep testing and fixing until nothing ever launches. The discipline that prevents it is working backwards from day one. Decide which use cases are in scope for launch, rank them by risk, and point the testing effort at that scope. A password reset procedure and a bereavement conversation don't carry the same risk, so they shouldn't compete for the same testing attention on the same timeline.
Your governance forum needs a pack: the test plan, the scenarios it covered, the results, and a link to the real conversation behind every single test. When each claim in the sign-off document can be traced to an actual transcript, a risk committee is auditing evidence rather than taking a vendor's word. This is the well-trodden path with our banking customers, and it's also how the agent's own guardrails get signed off: the pack shows the vulnerability handoff firing, the complaints detection firing, and the prompt injection attempt failing.
Step 5: Gradually ramp to full production traffic in stages
Every bank and high-stakes financial services company we've partnered with has adopted the same risk management strategy: they don't expect the AI agent to be good at everything from the beginning. Instead, they make a ramp-up plan with us, built on one principle: it is better for the AI agent to hand off something it cannot do than to fudge the outcome. Sometimes that means lower resolution numbers with high quality outcomes, rather than high resolution numbers that mask hidden failures.
Handoff quality deserves a place on the scorecard in its own right, and consumers agree: in a March 2026 TD Bank survey, 81% of customers said they want some level of human involvement available when they contact their bank for support. In practice this control is fine-grained: our agent's behaviour can be configured at the customer intent level, so each customer journey gets its own risk posture.
One of our US customers, a consumer investing platform, ran this playbook end to end. The agent went live on 50 email tickets a day with 100% human QA on every conversation. Once the QA pass rate held, volume stepped up to 25% of email traffic, then 50%, then 100%, five weeks after day one. Across the entire ramp they never rolled back once.
The mechanics that make a ramp work, drawn from deployments like this one:
Start small enough to review everything: the first live batches should be small enough that a human reviews every single conversation, typically 10 to 20 a day
Gate volume on the QA pass rate: step up only when quality holds at the bar you agreed, and our customers typically hold that bar at 95% or higher
Taper the QA sampling as volume grows: from reviewing 100% of conversations, to 50%, to an ongoing sample, earning each reduction with the data from the last stage
Ramp fast enough to learn: a slow ramp never produces enough conversations to measure anything. After 100 to 200 reviewed conversations you know what you have, and the right response to good results is more volume
Step 6: Continuously monitor and evaluate post-go-live
At full volume, no team can read every conversation. Evaluation has to become something that runs continuously alongside the agent.
SteadyPay's collections deployment shows what that looks like. They started, as everyone should, with a handful of calls reviewed individually, and now run at tens of thousands of calls a month. At that scale, a QA and compliance agent reviews every conversation against a set of named checks: dispute handling, misrepresentation, missing mandatory disclosures, payment pressure, and the rest of the conduct list a collections operation answers for, each with a full audit trail. Conversations that fail a check are flagged for human review, which inverts the QA burden: every conversation gets checked, and humans review only the flagged exceptions.
Two more practices matter after launch:
Regression testing on every change: the pre-production test suite doesn't retire at launch. Whenever a procedure, knowledge source, or model changes, the suite re-runs and confirms that everything that passed still passes, in minutes rather than days
Gradual rollout for changes, too: significant changes go live the way the agent itself did, to a slice of conversations first, with results compared before the change reaches everyone
Five mistakes we see in AI agent evaluations
Grading conversations with an LLM and no agreed rubric: ask a language model to find mistakes in a transcript and it will find some, whether or not they matter. LLM-assisted review works only after both sides converge on one scorecard with defined severity levels.
Running generic AI benchmarks against a scoped agent: off-the-shelf toxicity and jailbreak test sets are built for general-purpose chatbots. Run against a scoped support agent, most items would simply be handed off to a human, which the benchmark scores as a failure. Test the agent you're deploying, in the scope it will operate.
Waiting for perfect before going live: the fastest route to confidence is a small, fully reviewed live batch, because it shrinks the consequences of any failure to a handful of conversations you're watching closely. Waiting longer only postpones the learning.
Testing everything instead of the day-one scope: breadth feels rigorous, but it spreads attention thin, and edge cases multiply faster than fixes. Go deep on the launch scope first, then widen as the scope expands.
Keeping a human approving every reply, forever: it feels like the safest option. Our founding team built a
reply-suggestion tool during their years running AI at Monzo, and it was right about 90% of the time. That was exactly the problem: reviewers learned to click accept, quality drifted, and efficiency barely moved. Human review belongs at the checkpoints, the flagged exceptions, and specific high-risk actions inside a conversation, rather than on every reply.
What this looks like with Gradient Labs
Everything above is the method we run with our own customers. From kickoff to production, the work falls into three phases, with a dedicated AI delivery lead and weekly checkpoints throughout.
Pre-pilot (kickoff to week 3): we build the business case with you, agree the success criteria (the scorecard, the acceptance numbers, and the severity scale), and take the agent through your legal, risk, and compliance review. Security and legal validation runs in parallel with onboarding mapping, which is what keeps this phase in weeks rather than quarters.
Pilot (go-live from week 3, up to 45 days): we connect the integrations the use case needs, load your knowledge and procedures, and stress test the agent against your policies and risk scenarios before it meets a customer. Then the ramp begins: live volume starts small with every conversation reviewed, and grows only as the QA pass rate holds. The evidence pack builds as the pilot runs, so the sign-off conversation at the end is short.
Production: the QA and compliance checks keep running on every conversation, the test suite re-runs on every change, and we work with you on optimisation and expansion into further use cases, with the same guardrails and audit trail carrying over to each one.
None of this needs your team to write code or staff an AI engineering function: an operations lead working with our delivery team runs it. The commitment is contractual too: once we've scoped a use case together, we guarantee the deployment, and if we don't deliver what we agreed, you get your money back.
Evaluating an AI agent with confidence
Every bank is under pressure to put AI to work. But what was lauded as an achievement six months ago is quickly becoming the baseline. It's not enough to simply launch an internal AI copilot, you need to prove its value.
The hardest challenge for an ops leader now is choosing which processes to automate that will prove real value, without putting compliance or CSAT at risk. Getting a project like that over the line, and seeing real ROI, comes down to proving the agent works to the people who sign it off, on evidence they can check for themselves.
That is what a good evaluation gives you, and testing is the part that carries it, from catching the problems before a customer does, to earning each step up in volume, to proving the agent stays safe long after it goes live. If you follow this guide, you'll be much closer to a launch you can stand behind, and to an AI project that makes it all the way into production.
To see the method run on your own use case, from the test suite to the compliance checks on every conversation, book a demo.
Emma Martin is the Head of Marketing at Gradient Labs. Prior to Gradient Labs, she held global marketing leadership roles at Bluecore (acquired by Insider One), Mastercard, and startups on the fronteir of conversational AI. She writes about the intersection of AI, automation and customer experience in financial services.