The update passed testing. The business problem started afterwards.

On Monday, a customer support team approves an update to its AI assistant. The vendor has released a newer model, and the engineering team has tested a sample of customer queries. The responses look good. The update is deployed.

By Wednesday, the support manager notices something small but frustrating. The assistant is still answering questions correctly, but it has become less consistent about when to escalate a complaint to a human. A few cases that previously reached an experienced agent are now receiving confident, incomplete answers. Nobody has reported a major incident. There is no obvious outage. The dashboard is green.

The team investigates. Was the model changed? Was the prompt adjusted? Did the evaluation set cover these kinds of complaints? Did the escalation rule change, or did the model simply start interpreting the same instructions differently? The answers are spread across release notes, test results, application code and conversations between the people who worked on the update.

The original approval was genuine. The testing happened. The problem is that the organization treated evidence that the update worked on a sample of cases as evidence that it would continue to behave appropriately in the business process.

That is a much larger claim. AI systems can change through model updates, prompt edits, new retrieval sources, revised tools, altered workflows or changes to the data they receive. Some changes improve performance. Others introduce new failure modes, and many do both: an update can make a system better at the task it was optimized for while making it worse at a less visible responsibility, such as recognizing uncertainty or escalating an exception.

The operational question is therefore not simply whether an AI update passed testing. It is: 

Whether the organization has enough evidence to trust the changed system for the job it is about to do.

Why a technically successful update can still be a business regression

Traditional software releases often have clear expected behavior. A test can check whether a function returns the right value, an API responds as expected or a transaction follows a defined rule. AI systems introduce another layer of difficulty: the output can change even when the system remains technically available and the answer appears plausible.

Imagine an AI assistant used by an Indian financial-services company to help classify customer complaints. The team evaluates the update on a set of routine queries and finds that it produces cleaner summaries. That is a real improvement. But the assistant is also expected to recognize complaints that require escalation, preserve important details and avoid presenting uncertain interpretations as established facts.

A test focused on summary quality may not reveal that the updated system now misses a particular class of escalation. The model has not necessarily become worse overall. It may have improved on the measure the team chose while regressing on a requirement the team did not adequately test.

This is why aggregate accuracy can be reassuring in the wrong way. A single score can hide a change in the distribution of errors, particularly when the most consequential cases are relatively uncommon. A small number of missed exceptions may matter more to the business than a broad improvement in routine responses.

The same problem appears outside customer support. An AI system that extracts fields from invoices may become more efficient while handling unusual tax treatments less reliably. A procurement assistant may produce better summaries while overlooking a contractual condition. A manufacturing assistant may answer routine maintenance questions well while becoming less cautious when a sensor reading falls outside the expected range. These are illustrative scenarios, but they share a common structure: the measure of improvement does not fully represent the consequences of failure.

The risk is not limited to changes made by the internal engineering team. A vendor may update a hosted model, a retrieval source may change, or a prompt may be adjusted to improve one workflow. Even if each change is reasonable, the organization still needs to establish whether the resulting system remains suitable for its intended use.

The important point is not that every update is dangerous. It is that an update can affect business outcomes in ways that ordinary availability monitoring or a single performance metric will not necessarily reveal.

The approval belongs to a particular version of the system, not to the idea of using AI

A common organizational mistake is to treat approval as a permanent property of a use case: 

We approved the customer support assistant, so changes to it can follow the normal release process.

But the decision to use a system was made under particular assumptions. The model behaved in a certain way, the prompts set certain boundaries, the data sources had particular characteristics, and the workflow included specific checks. If one of those assumptions changes, the original decision may still be valid, but it should not be treated as automatically valid.

This does not mean every update requires a fresh committee meeting. Correcting a typo in a user-facing label should not be treated like changing the model used to recommend a loan decision. The purpose of change management is to distinguish changes that leave the relevant risk assumptions intact from changes that could invalidate them.

NIST's AI Risk Management Framework supports this lifecycle view. Its Manage function calls for post-deployment monitoring, testing in conditions similar to the deployment context, tracking system changes and maintaining version history. It also encourages organizations to document how updates are tested and deployed, and to consider the consequences of bypassing or deactivating system components. These are voluntary framework resources, not a universal legal checklist, but they provide a useful foundation for a disciplined release process.

A practical way to apply this is to connect three things that are often separated: 

• What the team expected the system to do. 
• What it tested before the update.
• What the updated system actually did.

If those three cannot be compared, the release decision rests on confidence rather than evidence.

The BASE framework: Four checks before an AI update goes live

A release review should not become a bureaucratic exercise that treats every change as equally risky. 

The goal is to make a defensible decision without slowing routine improvements unnecessarily.

Use BASE to organize the decision: Baseline, Assess, Stress-test, Establish the decision.

B: Baseline the behavior

Before changing the system, establish what it is expected to do in its current role. Record the behaviors that matter to the business, not just the output quality that is easiest to measure.

For a customer support assistant, this could include answering routine questions accurately, escalating particular complaints, preserving important details and acknowledging when it lacks enough information. Include examples where the correct response is to ask for clarification, abstain or hand the case to a human.

The baseline gives the team something meaningful to compare against. Without it, an update can appear successful simply because the team has no reliable record of how the previous version handled difficult cases.

A: Assess what the change could affect

Identify what is changing and which assumptions might no longer hold. Is the team replacing the model, modifying a prompt, adding a retrieval source, connecting a new tool or changing the workflow in which the system operates?

The size of a technical change is not necessarily a good measure of its importance. A small prompt edit can change how a system handles uncertainty, while a substantial infrastructure change may leave the relevant behavior untouched.

For each change, ask which business outcomes, data boundaries, permissions, human checks or previous risk decisions could be affected. This determines how much testing and review the update needs. A cosmetic change may require routine verification; a change that affects consequential decisions or enables new actions may require broader evaluation and explicit approval.

S: Stress-test the changed system

Run the updated system against representative examples from the baseline, including difficult cases and important exceptions. Compare the results rather than relying on a single aggregate score.

Look for regressions as well as improvements. Has escalation become less reliable? Does the system omit details that previously mattered? Does it sound more confident when the available information is incomplete? Are errors concentrated in particular document types, customer situations or edge cases?

Then test the system inside the workflow where it will actually be used. A model may produce a good answer while the surrounding application handles it incorrectly. A changed output format might break a downstream parser, or a new retrieval source might introduce information that the workflow was not designed to handle. Include the tools, integrations and human review steps that influence the final outcome.

The purpose is not to prove that every possible failure has been eliminated. It is to look deliberately for the failures that could make this particular update unacceptable.

E: Establish the release decision

Define the release criteria before testing begins. Specify which results permit deployment, which require further investigation and which should stop the release. Record the version tested, material findings, unresolved limitations and the person authorized to accept the remaining risk.

 If a consequential regression appears, the team must choose deliberately: hold the release, narrow the system's use, add human review or proceed with documented limitations and appropriate monitoring. The decision should reflect the potential harm and available alternatives, not simply the overall test score.

BASE does not certify an AI update as safe. It makes the evidence and reasoning behind the release decision visible, testable and accountable.

What happens when the evidence is inconclusive?

The hardest decisions arise when an update improves overall performance but weakens a behavior that matters. An assistant might produce better responses for most customers while becoming less reliable at recognizing complaints that require human intervention.

In such cases, the organization needs a clear way to manage uncertainty. If the regression could cause material harm, holding the release may be appropriate. If the risk can be contained, the team might narrow the system's permitted use or retain additional human review while gathering evidence. Proceeding with a known limitation should require explicit acceptance by the person authorized to make that decision.

The same discipline applies after deployment. Define which production signals should trigger investigation, restriction or rollback, and who has authority to act. Confirm that rollback is technically possible and that an alternative process can keep essential operations running. Reverting a model alone may not restore the earlier system if prompts, integrations or data sources have also changed.

NIST's AI Risk Management Framework supports this lifecycle approach through post-deployment monitoring, incident response, recovery and change management. The aim is not to eliminate all uncertainty before release. It is to understand the uncertainty that remains and establish what would cause the organization to reconsider its decision.

A release review your team can run this week

Choose one AI system that affects customers, money, sensitive information or a consequential internal decision. Take its next planned update, or review a recent one, and run it through BASE.

• Baseline: Can the team show what the current system is expected to do, including critical exceptions?
• Assess: Can it explain what the update changes and which assumptions or controls may be affected?
• Stress-test: Is there evidence comparing the old and new versions on representative cases and the complete workflow?
• Establish the decision: Are the release criteria, authorized decision-maker and response to unacceptable results clearly documented?

For each stage, distinguish verified evidence from assumptions. Assign an owner to each material gap and determine what must be resolved before proceeding. Not every unknown should block a release, but consequential uncertainty should never be mistaken for proof that the update is acceptable.

The exercise also creates a useful link to Your AI Has Git. Your Governance Doesn't. Version history shows what changed in a technical artifact. A release review establishes what was tested, which risks were reconsidered and who accepted the result. A commit record alone cannot answer those questions.

From approving an AI system to assuring its behavior over time

An AI approval is not a promise that the system will remain suitable forever. It is a decision made using the evidence available about a particular system, in a particular context, with particular limitations. Change that context and the organization may need to revisit the decision.

This is why testing, monitoring, traceability and governance should not operate as disconnected activities. A test result needs to inform a release decision. The decision needs an accountable owner. Material limitations need to be visible to the people operating the system. And when production evidence contradicts the original assumptions, the organization needs a way to turn that discovery into corrective action and verify that the action was completed.

KlaritiQ is designed to support this assurance work by connecting assessments, risks, decisions, accountable owners, corrective actions and supporting evidence. It does not independently certify an AI update as safe, replace technical evaluation or automatically control a production release. The purpose is to make the reasoning and follow-through around a change easier to coordinate, track and substantiate.

A testing tool can tell you how a version performed against a test set. A release process determines whether that evidence is sufficient for the business to proceed. Ongoing assurance helps establish whether the decision still holds as the system, its context and the available evidence evolve.

The next time a team says an AI update has passed testing, ask one further question: 

Passed testing for what, and what would have to change before that approval no longer holds?

If the answer is clear, the organization has a basis for making and revisiting its release decision. If the answer is simply that the system still works, it may have verified availability without verifying the behavior the business actually depends on.

That is the difference between shipping an AI update and managing the consequences of changing an AI system.