Scaling AI in BFSI With Trust and Quality [Testμ 2026]

Beyond the Pilot Stage

AI is moving out of experimentation and into real business process across lending, underwriting, fraud detection, customer service, claims, software engineering and operations. Increasingly it is agentic, taking action rather than making recommendations.

A mistake in this sector is not a bad search result. It reaches clients directly and carries reputational risk for the firm, and every AI decision has to stand up to customers, regulators, auditors and internal risk organisations.

His framing of the real question is what makes the panel worth watching. Deploying AI is the easy version. Scaling it while holding trust and quality, when the systems are probabilistic, adaptive and non-deterministic, is the hard one.

From Control to Governance

Anand Moorthy answered the opening question by tracing where quality has already been. Looking back 20 to 25 years, he reads it as one discipline passing through four stages.

• Control - what can you control, is it in or out, and can you detect it on time.
• Assurance - structured practices for fixing in time and preventing in time.
• Automation - and over the last decade, AI under other names, including self-healing, learning and predictive analytics.
• Governance - where he sees the next stage, because something has to govern the systems that learn.

His argument for governance as the future rests on domain expertise. Having LLMs that learn and feed results back into the system leaves open who governs that, and what is right in a given domain is what predicts where the future goes.

Pilots Stall on Trust

Eshwar Pastapur declined to manufacture a production success story he had not lived through, and answered from two years of conversations with CIOs, technology executives and insurance leaders instead.

What those conversations reveal is boards applying pressure to do something in AI, and a great many pilots starting as a result. Deploying in production turns out to be a different matter.

The technology is not usually what stops the project. Trust is, and it decomposes into four questions: can you trust the answer, can you explain it, can you audit it, and what happens when it is wrong.

He reframed the whole discussion around that. The interesting question is not why companies have not deployed AI in production, but what prevents pilots from becoming production systems, and that is where quality engineering has a role.

Letting Go of One Right Answer

Traditional testing assumes a binary. You run the test and it either works or it does not, while an AI system can produce different answers, sometimes confidently producing a wrong one and sometimes producing a different answer that is still right.

The first thing to let go of, in Eshwar Pastapur’s account, is the idea that quality means getting exactly the same answer. Ask an AI system to summarise a claim file twice and you get two different summaries, both good.

The question that replaces it is whether the output is accurate, grounded in the right information, consistent, explainable and appropriate for the business decision being made.

He added one more test that is easy to leave off the list. Is it legally permissible.

An answer can be technically reasonable and statistically defensible while violating an underwriting rule, treating a customer unfairly, or running foul of regulation. The company is held accountable for all of it, which makes the test environment the place to find out.

From Test Automation to Trust Automation

The changes he wants in testing follow from that. Adversarial scenarios and bias testing come first, and behind them sits a test he singled out as the important one: whether the AI knows when it does not know.

That is where hallucinations enter, and a system that cannot signal its own uncertainty gives you nothing to act on.

His name for the shift is trust automation, replacing test automation as the thing the industry is wired for. It stops being a checkbox and becomes a question of whether you can trust the system you are about to put into production, and trust is earned rather than given.

Human in the Loop

Brianna Elsass took the placement question back to the old diagram of requirements going in and a product coming out. Every product development cycle contains a translation, between two people, or two AI agents, or an agent and a person.

Her approach is to name the critical moments in that cycle where human eyes get inserted, rather than reviewing at the end.

• Customer experience - is the feature meeting the objective of the experience being built?
• Code standards - does the code match the standards and the guardrails set around the product systems?
• Style guide - does the output match what the brand and company voice are trying to do?

Those checkpoints let a team course correct while the work is moving instead of after it lands. In a highly regulated industry, she is clear that nothing has reached the point of being hands-off and eyes-off.

Both of the other panellists agreed the human stays. The expectation is that the role evolves as confidence grows, not that it disappears.

The Multi-Dimensional Scorecard

Once multiple outcomes are acceptable, pass and fail turn grey, and the moderator pressed on what the acceptance criteria become and how you train the evaluator to hold a consistent bar.

Brianna Elsass’s answer was that it depends on the scenario, and she defended that rather than apologising for it. Client conversations in banking are situationally dependent, so AI might drive background reporting and feed in insights while the person who knows the relationship reacts in real time and picks the better of two good responses.

On the testing side she pointed at guardrails: accessibility testing on feature sets, style guides matching what is needed, and a judgment about what serves the brand and what the customer subset needs the product to do.

Anand Moorthy put the structural version of the same point. The deterministic world was one-dimensional, pass or fail, and what replaces it is a multi-dimensional scorecard applied along the whole workflow.

His reason for spanning the workflow is that an AI decision has upstream and downstream impact. Capturing that, and reporting it, is part of the scorecard rather than a separate exercise.

Domain Knowledge as the Edge

Anand Moorthy’s position is that deep domain knowledge becomes the tester’s advantage. A tester cannot only be a tester, because understanding the business gets more critical as the systems get less predictable.

Brian Corkery pushed on what that implies for shift-left. If domain understanding is the differentiator, the movement may not be toward development at all, but toward the end user and the business user as the first line of testing.

Anand Moorthy accepted the framing. Wearing a tester’s hat means knowing the business you are in, whether that is an airline or a bank, and knowing as an end user where the fault is likely to appear.

Testing Autonomy, Not Intelligence

Agentic AI moves the panel from systems that suggest to systems that reason, call APIs, access systems and act on behalf of a customer or an employee. Eshwar Pastapur named the change in what gets tested: testing intelligence becomes testing autonomy.

Testing autonomy means testing the entire journey. If an agent runs a set of steps, the ordering has to be verified, because a misstep early carries implications far downstream.

His claims example is the one that makes the stakes concrete. An agent retrieves the policy, checks coverage and calculates, and then decides whether to deny the claim.

Autonomy, on his account, is earned the same way trust is. Start with something low risk such as summarising claim files with a human still in the loop, then graduate to letting the agent decide while someone else verifies, and keep going until you are comfortable releasing it.

Production is not the end of that work. Behaviour depends on data, so leaving a system alone for a couple of months surfaces drift, and the company remains accountable for what it does.

His closing instruction was to give all of it a great deal of thought before letting an agent touch customer bank accounts.

Testing as the Proving Ground

Crawl, walk, run is sound advice that collides with a business asking for returns on a near horizon, which is what the moderator put to Brianna Elsass as the scaling problem.

Her observation is that enterprises usually chase the biggest cost takeout first. The approach she prefers is accelerating the team, and she nominated testing as the place to start.

Automated test cases are rinse and repeat for most teams, so AI can execute the existing scripts and create new ones. From there the same acceleration pulls testing forward and makes it more frequent inside the development cycle, then extends into code and design generation.

The compounding effect is what she was after. More frequent interjection raises the effectiveness of the tool and the enterprise comfort level with AI at the same time, which is what earns permission to try riskier things later.

Brian Corkery added the structural case. Testing is a laboratory where you are not touching clients, and it is a standing bottleneck as code production rises, so relieving it proves the technology and removes a constraint at once.

Redefining the Engineer

The skills question came with a complication attached. Validation matters more than ever under human in the loop, while the generation now entering the pipeline has less of the discipline that came from binary testing, and the people who have it are cycling out.

Brianna Elsass expects the definition of an engineer to widen rather than narrow. AI removes friction and skill-set barriers that used to gate entry, and she has watched non-technical people become AI programmers and stewards of AI agents.

She has also seen far more women involved in AI coding and engineering than she saw historically, which she connected to having been one of the few women at many tables earlier in her career. Her read is that accessibility is what invites a broader set of skills to the table.

Anand Moorthy agreed the evolution moves toward intuitive knowledge rather than structural engineering, with domain, orchestration and in-depth analysis carrying more weight. Prompt engineering, in his framing, is softer and more intuitive than the strict rules and process of older engineering disciplines.

Eshwar Pastapur added the part that applies to people already in the roles. Anyone in a developer or tester seat has to unlearn before they learn, because it is a different muscle, and he tells leaders their talent pool needs training that starts by erasing the old model.

Brian Corkery’s summary was that firms retraining that muscle early will fail fast and succeed sooner, while the holdouts convinced the old way is the right way will not.

Governance Over Model Access

Asked what will matter more in three to five years, the quality of AI or an organisation’s ability to trust, test and govern it, Eshwar Pastapur went to velocity.

What differentiates a company is how fast it can deploy AI with confidence, which requires a ready talent pool, access to the right models, and in some cases a domain-specific language model of its own.

His sharper point is that model access stops being an advantage. Within months or a few years everyone has the best models available, so the differentiator becomes institutional capability and mindset for deploying solutions faster.

Anand Moorthy put governance at the centre of the same answer, and followed it to its uncomfortable conclusion.

AI can give you data, output and options. What it cannot substitute, in his view, is the repository of knowledge a mind holds, the analytical thinking on top of it, and the judgment and emotional read that decide what the outcome should be.

He also put a floor under all of it. Foundational governance and data strategy have to be in place and upgraded to what AI brings, because without them nothing else works.

Brianna Elsass, who lost connection during part of this exchange and rejoined, added a technology stack overhaul to the list. Deciding where AI belongs, where it should be customer-facing, and what existing technology needs restructuring is the work that makes the governance real.

Federal, State or EU

The last question went off script. Insurance is regulated at state level and banking at federal level, so the moderator asked whether the regulators have the capability to let firms spread their wings, or whether they become a governor on access to the technology.

Eshwar Pastapur took it from the insurance side. Insurers have handled state-specific regulation since the beginning, and his hope is that AI rules land federally rather than state by state, though he was careful to call it a hope rather than a prediction.

His read on the industry is that it has traditionally been late to adopt technology, with the largest carriers moving on AI while others are still working out what to do with their pilots. New entrants are changing that calculation, because lagging shows up in the combined ratio.

He pointed at the European Union as the model worth watching, since it is producing rules for the whole union rather than country by country.

Brianna Elsass agreed and traced the transmission path. Large global banks will be shaped by what the EU puts in place, banks borrow best practices from adjacent regulation such as personal data rules and accessibility requirements, and those become guardrails that trickle across the rest of the industry.

Anand Moorthy left the last word to the practitioners, with the observation that this is a new era and the answer will evolve as the industry moves through it.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.