AI Trust and Governance in QE: Who Signs Off [Testμ 2026]

Two Decades of Predictable Systems

Two decades ago a tester asked for a requirements document, the specs, and the user flow diagrams, and generally got them. Everything needed to design a test existed on paper before the first case was written.

The systems behaved accordingly. As Harleen Bedi put it, a plus b would always produce c, so a defect found once and fixed once stayed fixed.

The third condition is the one that sounds strangest now. Testing cycles sometimes ran to six months, which left room to write every case by hand and, in many cases, not to automate at all.

The signal at the end of that process was unambiguous. A large block of tests had run, the possible defects had been found, and the team could say go ahead and release.

The Shifts That Came Before AI

Two changes had already reshaped that picture before AI entered the conversation, and Harleen Bedi was careful to separate them from what came later.

Agile compressed the window. Six-month cycles shrank, the go or no-go call stopped being a single event, and in some organisations releases moved to an hourly cadence.

Architecture changed the shape of the work. Her first testing job was a monolithic desktop application; distributed service-based systems made it impossible to sign anything off without checking that every integration still held.

Testing became a matter of running hypotheses about what happened to a system and what happened to its integrations. That is the state AI arrived into.

Three Dimensions AI Added

On top of that ecosystem, she called out three additions that changed how her teams report defects and how they decide testing is finished.

• The systems are no longer deterministic - a traditional test case cannot assert what the model will return, and a bug fixed once is not fixed for good. An AI system will drift without anyone changing a line of the application.
• The tests are written by AI - her own team now writes most of its tests with AI, which turns coverage into something that has to be proved rather than counted.
• The blast radius is unpredictable - a defect used to be localised to a module or an application. When decisions are made autonomously, the impact of a failure that is not caught early multiplies in ways nobody can map in advance.

Each of the three attacks a different part of the old method. The first breaks the assertion, the second breaks the evidence, and the third breaks the containment assumption that made a localised defect tolerable.

Coverage Is No Longer the Benchmark

The consequence lands on the number quality teams have reported for years. Coverage used to be the proud claim, and 100 percent was the answer that closed the conversation.

It is no longer the benchmark or even the question, in her account, because a percentage of a deterministic surface says nothing about a system that changes on its own.

The claim being made has shifted from a measurement to a property of the pipeline. Trust is the thing being asserted, and it has to be rebuilt continuously rather than certified once.

Who Actually Signs Off?

Manish put the awkward version of the question directly. Quality has always been a gate with a person putting their hand up to say it has been tested and is good to go, so what happens when the agent doing the testing is the thing whose boundaries nobody knows?

Her answer does not move the accountability anywhere.

That is what makes the governance layer necessary rather than decorative. If the person signing cannot be replaced by the system, they need something to sign against.

The Governance Layer

She described the layer at three levels, built on top of the testing rather than beside it.

• Criteria and thresholds - identifying what exactly is being tested, what a failure means, and what thresholds the system is being held to, before anything is delegated.
• Traceability - being able to show why certain decisions were made by AI, why it wrote the tests it wrote, and why it marked a given result as passed.
• Post-production observability - watching for drift after release, on the assumption that drift cannot be prevented, only found and fixed quickly.

The third item moves the QE remit past the release. Her framing is that no team can build a system guaranteed not to drift, so the governance question becomes how fast a drift can be identified and how fast it can be fixed.

Manish added the artifact most teams overlook. The prompts used to generate a test are evidence in the same way the test case and its result are, and they need to feed back into the governance layer rather than disappear into a session history.

Will AI Replace QE?

If AI writes the tests, runs them, and decides the coverage, the obvious follow-up is what the QE function is for. She called it her favourite question, and not because it is new.

Every shift in the industry produces it. When agile arrived, the same prediction went around that QE would be obsolete because developers would test everything themselves.

Her answer draws on having stayed relevant across those decades rather than on optimism. Understanding the tools and the models is the foundation, not the differentiator, and the differentiator is where a tester creates a niche on top of it.

Two Opportunities for Testers

The first is domain knowledge, and she made the case with a familiar experiment. Give a model a default prompt with no functional understanding behind it and everyone already knows the quality of the test cases that come back.

Someone has to supply the missing context, and the people holding it are the domain experts and functional testers who learned the system over years. Augmenting AI with that context across test cases, scripts and test data is what keeps them relevant.

The second is trust itself. Building evals, understanding how they are constructed, and being able to construct a governance layer is a skill set she expects to become a job category, given the market forming around AI trust and AI governance.

Simplified, she sees two layers of work running side by side:

• Traditional testing, augmented - functional, performance and security work on applications that will not vanish overnight, with AI doing much of the labour and the tester adding domain context on top.
• Evals and governance - building the evaluation layer, understanding how governance works, and being the custodian of quality in a context that has changed underneath the role.

Her conclusion on the fear was blunt. There is more than enough for quality engineers to do.

Manish agreed from what he sees in the market, and sharpened the point with volume. A simple prompt can produce a hundred thousand lines of code whose boundary conditions nobody has examined, which makes testing more relevant rather than less.

Evidence Customers Now Accept

Asked what constitutes evidence for a customer to say everything is good to go, she started with what used to count. A one-time sign-off against a coverage number and zero defects in pre-production was the shape of it.

She was careful to frame where the industry actually stands. Infusing AI into the business side of applications is still early, and much of it has yet to reach production at scale.

What has changed is receptiveness. Customers understand the governance argument better than they did, so the guardrails around putting something into production are being rewritten alongside it.

The evidence her teams now build toward is a system that identifies drift early and signals it. That is what a release is defended with, rather than a coverage figure captured before the code shipped.

From Rigid Gates to Pipeline Controls

Her description of the old quality gate is worth quoting for how it felt to work under. The primary focus was to make sure nothing went through the gate and everything was controlled before it.

It slowed the whole organisation down. Everybody was busy fixing, everybody was anxious about letting anything through, and being handed a checklist after finishing a piece of code produced resistance rather than quality.

The replacement is not a softer gate but a different placement. Checks and balances are built into the pipeline so they run as the code runs, and the engineer knows up front what will be checked instead of meeting it at the end.

The risk posture moved with it. Customers are now willing to take a calculated risk on the condition that they find out fast and can fix it very quickly, or switch off the components causing the problem.

Q & A Session

The last part of the session turned to the technical decisions QE leaders are making right now.

• Are we letting agents decide the technology, languages and frameworks and abstracting it to a prompt layer, or do we still standardise on certain frameworks for testing?

  Harleen Bedi: Enterprises standardise. There are more model and framework options than anyone can count, so organisations run a due-diligence exercise against risk appetite, budget and other factors, pick a set for the whole enterprise, and use that same set for testing. She named Anthropic, Google and AWS as examples of the choice being made at that level. Within QE, the strategy has three parts. Assess the existing tool set and decide which tools are still relevant in the AI era, what ROI they return, and whether their new AI capabilities fit the current ecosystem. Embed AI-native tools where the market already offers them, because building from the ground up costs far more. And build only the additional capability that plugs into the ecosystem, which is why most customers she works with are building enterprise-grade internal platforms with base models, a context layer and an agent control plane, then telling each sub-organisation to build its agents and onboard them there for consistency of framework and governance. She deliberately named no testing tools while making the point.

• Agents are becoming services alongside APIs and endpoints, with voice and other interaction points. How should a QE start thinking about testing applications in that context?

  Harleen Bedi: With a multi-layer approach, and against a backdrop where very few enterprises are building AI-native applications because they cannot discard the legacy systems these things are being built around.

  • Business assurance - testing as the end user, who does not care which agents were involved and only cares whether they got what they came for. This layer needs deliberate data variants and data sets to cover the scenarios.
  • Responsible AI - checking fairness, ethics and any underlying bias, where open source and commercial tools are already plug and play.
  • Security and red teaming - threat modelling, prompt poisoning and jailbreak attempts, because the threat surface multiplies once AI is in the system.
  • Agentic efficacy - asked to book travel, an agent has multiple tools it could call and multiple paths it could take. The question is whether it took the shortest or best path and whether it called the tool it was supposed to call.

  The user only sees the output, so the quality team has to see the path. Load and stress testing and integration testing continue as before, on top of these layers.

Manish closed with a comment he flagged as deliberately provocative, that this is the best time to be a tester and probably the worst time to be a developer. Legacy applications being AI-enabled need one kind of testing and agentic applications need another, and the expanse of work is immense.

Harleen Bedi’s closing remark returned to where the session began. Whenever a decision has to be made, it is made by humans, AI will not own it, and that is what gives testers a role in the years ahead.

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.