When to Re-run AI Safety Tests
The "small UI change" is usually a new function. Some re-runs are triggered by no code change at all. Four routes by which safety evidence expires, and what each one obliges you to do.
Safety evidence has a shelf life, and nobody watches the date
An AI system is evaluated properly once, before launch. Then it changes every week for three years, the threat landscape changes underneath it, and the population using it changes around it. The original evidence quietly stops describing reality, and no single event announces the moment it does.
Two questions get confused here, and separating them is the whole point of this document.
The first question is which changes require a re-run. The honest answer is: more than teams assume, and the exemption is narrower than it looks. Genuinely inert changes exist, logging, monitoring, internal tooling, a refactor with no reachable behavioural surface, and treating those as safety-relevant is how a control becomes theatre. But the category is small, and one thing that does not belong in it is the change most often placed there.
The "small UI change" is the standing trap. It arrives labelled cosmetic and it usually is not. Most of the time it is not adding a button, it is adding a function, and the function is what reaches the model. A new field, a new upload, a new export, a raised limit: each one is a new path into the system. The engineer offering the reassurance is answering whether the change breaks the product, which is a different question from whether it moves the model's behaviour, and it has a different expert.
Where a change touches functionality or any user interaction path, test. Reassurance is an input to that decision, never a substitute for it.
Testing here means the paths a user can actually take, not the ones the interface offers. That includes modifying client-side code in the browser, replaying requests, and calling the endpoint directly. Anything enforced only in the browser is not enforced.
The second question is the one that gets missed entirely. Safety evidence also expires when nothing in your codebase has changed at all. A new jailbreak family is published. Your user base shifts from internal staff to the public. A peer firm suffers an incident in a mode you never tested. Your retrieval corpus refreshes. In each case the system is byte-for-byte identical and the evidence is worth less than it was yesterday.
Evidence is a claim about a specific artefact, facing a specific threat landscape, serving a specific population, at a specific time. Change any of the four and re-open the claim.
Those four variables give four routes by which evidence expires. Route A is the one most organisations have some process for. Routes B, C and D are the ones that are almost universally unmanaged, and they are where incidents come from.
The artefact moved
Something in the system changed. Weights, prompt, tools, scaffolding, serving stack.
Trigger: a change requestThe world moved
New attack classes, regulatory change, peer incidents, shifting threat interest.
Trigger: external eventThe exposure moved
New users, new geographies, new integrations, new scale, refreshed data.
Trigger: a business decisionProduction spoke
An incident, a near-miss, monitoring drift, a red team or bounty finding.
Trigger: a signalUnderneath all four sits a scheduled backstop, covered in Section 07, for the drift that no trigger ever names.
The two ways organisations fail at this
Re-test everything
The full suite runs on every change. It is slow and expensive, delivery pressure builds, and teams route around it within weeks. The control exists in the policy and not in the process.
Re-test on change only
A tidy change-triggered process that is blind to Routes B, C and D. The system passes every gate it has, and is tested against a world that stopped existing two years ago.
How this guide works
What good looks like. A decision reached in under fifteen minutes, testing effort proportionate to the risk, and a one-paragraph record that still makes sense to someone reading it eighteen months later.
Scope and ownership
The engineer supplies evidence. The gate holder decides. Whoever made the change does not sign off on their own change. Where the two disagree, the decision escalates to the accountable executive for the system, and the default while unresolved is to test.
Routes B and C need an owner too. They are not triggered by a pull request, so nothing raises them automatically. Assign them explicitly, or they will not fire.
The three test tiers
Every route below terminates in one of three tiers. Each must be materially cheaper than the one above it. Durations are the targets this guide assumes; measure your own and hold to the ratios.
| Tier | What it is | Target |
|---|---|---|
| Smoke test | A small fixed set of known-critical probes. Same set every time. Pass or fail, no interpretation required.Cheap enough that nobody is tempted to skip it | Under 30 min |
| Focused regression | The subset covering the capability areas in question, plus the standing safety-critical set.Same working day, no overnight wait | 2 to 6 hours |
| Full regression | The complete safety suite, including adversarial and red team cases.Planned, not spontaneous | Overnight |
The ratios matter more than the absolute times. If focused regression costs nearly as much as full regression, the middle tier has no purpose and people will either run everything or skip everything. A tier that is not materially cheaper than the one above it is not a tier.
The artefact moved
Triggered by a change request. The system serving traffic is no longer the system you tested.
Classify the change
Did the change touch any of the following?
- Model weights, fine-tuning, RL, continued training
- System prompt or instruction layer
- Tool schemas or tool availability
- Agent scaffolding, planning loop, orchestration
- Memory, retrieval, context construction
- Permissions, credentials, scope of action
- Any new or altered function a user can reach
High-consequence branch
Request three things from the engineer, in writing: the exact change, why they believe it is safety-neutral, and before-and-after results on the safety regression suite. Then route on the evidence, not the reasoning.
| Evidence provided | Action |
|---|---|
| No credible before-and-after numbers | Focused regression. Reasoning is not a substitute for results, however senior the person offering it. |
| Before-and-after supplied, but self-reported and not reproducible | Treat as no evidence. Focused regression. A result you cannot re-run yourself is a claim, not a measurement. |
| Before-and-after reproducible on the gate holder's own run, no meaningful change | Smoke test, then deploy with heightened monitoring for 14 days or two release cycles, whichever is longer. |
| Anything worse, ambiguous, or not understood | Full focused regression. Escalate if the cause is not identified. |
What counts as a meaningful change
| Limb | Trigger |
|---|---|
| Aggregate movement | Degradation beyond 2 percentage points on overall safety pass rate, measured against your suite's known run-to-run variance. |
| Critical category failure | Any single failure in a critical category, regardless of how the aggregate moved. |
The second limb matters more than the first. Aggregate pass rates average over thousands of confident predictions and will comfortably hide a handful of tipped decisions. The failures that matter tend to be exactly those tipped cases, sitting close to a decision boundary, and they do not move an average.
Lower-consequence branch
| Situation | Action |
|---|---|
| High-stakes system: agents taking real actions, sensitive data, regulated decisions, or in scope as high-risk under the EU AI Act | Treat as high-consequence. Evidence plus at least a smoke test. |
| Low-stakes chat, no conditional case applies | Smoke test. The classification is what earns the lighter tier, not the explanation attached to it. |
| No behavioural surface whatsoever | Logging, monitoring, internal tooling, infrastructure with no inference path change and no new user-reachable action. Classify, record, close. This exemption is narrow by design, and does not extend to UI. |
Conditional cases: not automatically low-consequence
These are the ones that get misclassified, because risk intuition tracks visibility rather than effect.
| Change | Why it is not cosmetic |
|---|---|
| Quantization or precision reduction | Your evidence is about the full-precision model and does not transfer automatically. This is a change-control point rather than a claim that safety degrades: after quantizing, you no longer know whether it has. Treat as high-consequence on any high-stakes system, and at 4-bit or below in all cases. |
| Distillation, pruning, compression | Same reasoning. A smaller model derived from a tested one is not a tested model. |
| Serving stack changes | Inference engine, kernel implementation, KV cache quantization, batching strategy. All can alter output distributions with no weight change at all. |
| Decoding parameters | Temperature, top-p, sampling method. Low-risk in isolation, but they shift precisely the near-boundary predictions where safety-relevant decisions sit. |
| Third-party model version bumps | Including silent ones. If you cannot establish whether you are notified, assume you are not, and monitor accordingly. |
| User interface changes | Rarely cosmetic in practice. A new button is almost always a new function, and the function is what reaches the model. Test every path the user can now actually take, including anything reachable by modifying client-side code in the browser. Client-side controls are presentation, not enforcement. |
| Suite changes | New tests or altered scoring mean your baseline is no longer comparable. Re-baseline before the next comparison, or every subsequent decision rests on a false delta. |
If the artefact serving traffic is not bit-identical to the artefact you tested, the burden sits with whoever claims they are equivalent.
On the "small change" assertion
The most common input to this gate is an engineer saying a change is too small to matter. It is offered in good faith and it is frequently wrong, because the engineer is assessing whether the change breaks the product, not whether it moves the model's behaviour. Those are different questions and they have different experts.
Reassurance and testing are not alternatives. Accept the engineer's account of what changed. Do not accept their conclusion about what it implies. Where the two are in tension, the default is to test: an unnecessary focused regression costs hours, and an untested regression costs an incident.
Test what the user can do, not what the interface offers. The tested surface is every path reachable by a real user, including paths reachable by editing client-side code, replaying requests, or calling the endpoint directly. Anything enforced only in the browser is not enforced.
The world moved
Triggered by an external event. Your system is unchanged; the thing it is being measured against is not.
A passing test tells you the system resists the attacks in your suite. It says nothing about attacks invented after the suite was written. This route exists because a suite is a snapshot of adversary capability at the moment it was authored, and adversary capability does not hold still.
| Trigger | Action | Timeframe |
|---|---|---|
| New attack class published | Jailbreak family, prompt injection vector, agent hijacking technique, tool-poisoning method. Add representative cases to the suite, then focused regression against them.Passing a suite that never contained the attack proves nothing | 30 days high-stakes: 10 days |
| Regulatory or standards change | New EU AI Act obligation taking effect, updated regulator guidance, revised ISO/IEC 42001 or NIST AI RMF control. Gap-assess first, then focused regression against whatever the change touches. | Before the obligation date |
| Peer incident | A comparable system fails publicly in a mode you have never tested. Probe for the same mode in yours before concluding you are unaffected. | 10 working days |
| Threat profile shift | Your sector, client base, or organisation becomes a target it previously was not. Full regression plus a red team refresh scoped to the new adversary. | Next quarter |
| Base model disclosure | The provider of your underlying model publishes a vulnerability, safety finding, or evaluation update. Assess applicability, then focused regression if it applies. | 30 days |
This route needs a named owner and an inbound feed. Nothing raises it automatically. Someone must be watching published research, regulator output, provider disclosures, and sector incidents, with a standing obligation to open a ticket. Without that, Route B never fires and its absence looks exactly like compliance.
The exposure moved
Triggered by a business decision. Same system, same threat landscape, different population and different consequences.
This is the route most often missed, because the decisions that trigger it are commercial rather than technical and never reach an engineering gate. A system evaluated for a hundred internal users is not evaluated for a hundred thousand public ones, even though not a line of it has changed.
| Trigger | Action | Tier |
|---|---|---|
| New user population | Internal to external, new geography, new language, or any possibility of minors in the user base. Evaluate against the new population's risks, not the old one's.Language change is not a translation problem, safety behaviour varies by language | Full |
| New use case | Whether launched deliberately or emerging organically from user behaviour. Focused regression scoped to the new use, plus a review of whether the original risk assessment still describes the system. | Focused |
| New integration | Especially where output now feeds an actuating system, a payment path, or a decision with legal effect. The consequence of a failure has changed even if its likelihood has not. | Full |
| Retrieval corpus or knowledge base refresh | Same model, materially different inputs. Focused regression plus poisoning and exfiltration probes against the new corpus. | Focused |
| Scale increase | An order of magnitude in traffic. Rare failure modes become routine ones at volume, and a 0.01% failure rate is a different proposition at ten million requests. | Focused |
| Autonomy increase | Human-in-the-loop moving to human-on-the-loop, or approval thresholds being raised. The control you were relying on has been removed. | Full |
Wire this into commercial approval, not engineering approval. Route C triggers sit in product, sales, and expansion decisions. If the only gate is a pull request, none of them will ever be caught.
Production spoke
Triggered by a signal from the live system. Something has already happened, and the question is how far it extends.
| Trigger | Action | Timeframe |
|---|---|---|
| Incident or near-miss | Full regression, plus a new permanent test case reproducing the failure. A near-miss is treated identically to an incident: the difference between them is usually luck. | Immediate |
| Monitoring drift | Refusal rate, escalation rate, or output-length distributions moving outside expected bounds with no known cause. Investigate first, then focused regression. | 5 working days |
| Complaint or escalation cluster | Several users reporting the same behaviour. Treat the pattern as a finding even where each individual report looks minor. | 10 working days |
| Red team or bug bounty finding | Focused regression on the affected capability, then add to the permanent suite. | 10 working days |
| Finding on a sibling system | Any system sharing the same base model, prompt library, or scaffolding. The finding is presumed to apply until tested otherwise. | 30 days |
Routes A to C ask whether evidence still holds. Route D already knows it does not. The only open question is scope.
Material change: the underlying test
The routes above are shortcuts. The question underneath all of them is whether a change is material, and it is worth stating what that means, because a version number moving is not by itself an answer.
There is no regulatory definition to fall back on. The UK AI Safety Institute has published the closest thing to authoritative guidance, and it is explicitly framed as an evolving position rather than a standard. AISI describes itself as a supplementary layer of oversight rather than a regulator, and does not intend its evaluations as safe or unsafe stamps. Nobody has issued a quantitative threshold, so anyone claiming one is inventing it.
What AISI actually says
AISI identifies three classes of trigger for re-testing.
| Class | Examples given |
|---|---|
| Exceeding previous state of the art | Detected during training or deployment via general capability benchmarks. |
| Significant system changes post-deployment | Significant model updates or system feature releases; novel tools linked to the model such as web search or links to other software; fine-tuning for specific domains; longer context windows; novel methods to elicit capabilities, such as making a fine-tuning API available. |
| Significant external developments | Third-party research and development that lets users elicit new capabilities, such as the release of new agent frameworks, or the discovery of new methods to elicit capabilities or circumvent safeguards. |
The second component matters more than the list. AISI ties the significance of a change to capability thresholds: capabilities indicative of potentially severe risks that should trigger mitigation. The question is not how large the technical change was, but whether it could move the system closer to, or across, a relevant threshold.
A change is material where it could reasonably alter the system's risk profile, capabilities, safeguards, exposure, or pathways to harm sufficiently that the conclusions of the previous evaluation may no longer remain valid.
Attribution note. The definition above is T3's operationalisation of AISI's approach for enterprise use. It is not an AISI quotation and AISI has not endorsed it. The three trigger classes and their examples are drawn from AISI's published guidance on evaluating frontier AI systems.
The eight assessment dimensions
Assess a change against each. If none could invalidate the previous risk conclusions, record "no material change, no re-test required" and close. If one could, route to targeted or full re-testing depending on which risks are affected.
| Dimension | The question |
|---|---|
| Model and capability | Could the system now do something it previously could not, or do it materially better? |
| Tools and integrations | Has the system gained a new action, data source, or connection to other software? |
| Fine-tuning and data | Have the weights or the training or retrieval data changed? |
| System and prompt configuration | Has the instruction layer, context construction, or decoding configuration moved? |
| Safeguards | Has any guardrail, classifier, filter, or refusal behaviour been altered, weakened, or removed? |
| Autonomy and permissions | Can the system act further, faster, or with less human confirmation than before? |
| Deployment context | Has the user population, geography, scale, or downstream consequence of a failure changed? |
| New attack techniques | Has anything external emerged that makes a previously hard capability or bypass easier to reach? |
A version number alone is not a trigger. Nor is its absence a defence. The dimensions above, not the release label, determine whether prior evidence still holds.
Proportionate testing depth
AISI's approach also supports escalating effort rather than applying one level to everything, which maps directly onto the three tiers in Section 01.
| Signal | Response |
|---|---|
| No dimension could invalidate prior conclusions | Record the assessment. No re-test. |
| Lighter automated evaluation identifies a concern | Focused regression on the affected capability. |
| Evidence of a relevant capability increase | Full regression. |
| Significant capability jump, or concerning findings | Intensive expert red teaming. |
The backstop: scheduled re-testing
The four routes above are all trigger-driven, and every trigger depends on someone noticing something. Scheduled re-testing catches what nobody noticed. It is the only route that cannot be forgotten, because it does not rely on recognition.
| System class | Cadence | Tier |
|---|---|---|
| High-stakes: agentic, regulated decisions, sensitive data, EU AI Act high-risk | Quarterly | Full regression, with red team refresh every other cycle |
| Standard production systems | Annually | Full regression |
| Any system, on top of the above | Event-driven | Before audit, certification, or a material commercial commitment. At the close of any heightened-monitoring window. |
Treat a long gap between scheduled runs as itself a finding. If a system has gone a full cycle with no Route A, B, C or D trigger, either it is genuinely static or your triggers are not firing. The second is far more common than the first.
Final gate: always
Regardless of route or outcome.
- Record the decision. Which route fired, what was tested, or why testing was not required, and who decided. One paragraph. An undocumented skip is indistinguishable from an oversight after the fact.
- Enable heightened monitoring wherever a lighter tier was chosen, for the stated period.
- Add every failure discovered to the permanent regression suite, then re-baseline. The suite only ever grows. This is the mechanism by which the process improves rather than merely repeats.
- Review trigger performance quarterly. Count how often each route fired. A route that has never fired is not evidence of a stable system, it is evidence of a broken trigger.
Summary
The exemption is narrow. No behavioural surface and no user-reachable function. A UI change almost never qualifies.
Not every re-run follows a change. Three of the four routes fire while the code sits still.
Route on evidence, not reasoning. "It's only a small change" is an input to the decision, never the decision.
Test the reachable surface, not the intended one. Client-side controls are presentation, not enforcement.
A route that never fires is a broken trigger, not a stable system.
Leave a Reply