The invoice-extraction workflow still has the same name. The prompt looks familiar. The dashboard is green. Yet the provider changed the model behind the endpoint, and three weeks later the finance team notices that credit notes are being treated differently.
Nothing dramatic happened at the moment of change. That is why model updates are easy to miss operationally. A workflow can keep running while the evidence that supported its release becomes stale.
The answer is not to freeze every model forever. It is to know which changes deserve a fresh test, who owns that decision, and how to step back when behaviour moves outside the accepted boundary.
If you cannot reconstruct the tested configuration, begin there before arguing about whether the new result is better.
Record the system, not only the prompt
A prompt is one part of an AI workflow. Output can also depend on model and version, provider settings, retrieval documents, tool permissions, pre-processing, post-processing, thresholds and the interface through which a person reviews the result.
For an invoice flow, the operating record might include:
- provider and model reference;
- extraction prompt and schema;
- supported document types and languages;
- tax and currency rules outside automation;
- confidence threshold and manual-review route;
- a dated regression set with expected fields;
- stop owner and rollback option.
If the provider uses a moving alias rather than a fixed version, record that too. The point is not false precision. It is the ability to explain what was actually tested and what may have changed.
Keep a small set of cases that matter
Teams often retest with easy examples because easy examples are available. Build the regression set from consequential variation instead.
For the finance workflow, include an ordinary invoice, a credit note, a duplicate, an image with poor contrast, a multi-page statement, mixed VAT treatment, a foreign currency, handwritten correction and a document that must be rejected. Remove personal or confidential data unless there is a justified, controlled reason to use it.
Each case needs an expected outcome and a review rule. “Looks right” is difficult to compare over time. “Supplier, invoice number, gross amount and currency match the approved record; VAT treatment remains for human review” is clearer.
Do not make the set so large that nobody runs it. Ten consequential cases run at every material change can be more protective than two hundred examples last opened before the pilot.
Decide what counts as a material change
A model replacement is an obvious trigger. Other triggers are quieter: prompt revision, retrieval update, new tool permission, different document population, interface redesign, confidence-threshold change, expanded user group or a new action the system can take.
The decision should be proportionate to consequence. A writing assistant used for private first drafts may need a light check. A workflow that influences payment, access, employment, safety or a customer record needs stronger evidence and specialist review.
NIST’s AI Risk Management Framework emphasises governance, context-relevant measurement and continuing management. NIST also says version 1.0 is under revision. That makes it useful as a living risk structure, not a static compliance seal.
The European Commission’s AI Act overview and timeline is relevant where the system falls within the Act and the organisation has an applicable role. The law may impose obligations that an internal regression set does not satisfy. Classification and legal duties need their own qualified assessment.
Make rollback an ordinary option
When a change fails, teams sometimes keep it live while debating whether the difference is statistically significant. A pre-agreed boundary reduces that pressure.
For the invoice workflow:
If any regression case creates an incorrect payable amount or routes a credit note as an invoice, pause automated entry. Keep extraction available only as a draft while finance reviews the change.
This does not assume one error makes a model broadly useless. It recognises that a specific failure has a high consequence in this workflow. The boundary belongs to the use, not to the model’s general benchmark score.
This recoverable release decision is one reason the AI Project Operating System exists: changes, evidence, decisions and owners stay attached to the project after the people and technology move on. It does not monitor a provider automatically or prove legal compliance.
Build the first regression set
Open one production AI workflow and list the components that can change without the user noticing. Choose five to ten cases whose failure would alter the decision to keep it live. Record the current result, owner and rollback boundary.
Then add a review trigger for model, prompt, retrieval, permission and population changes. If no one owns that trigger, the workflow is not being monitored; it is merely still running.
Sources and limits
- NIST: Artificial Intelligence Risk Management Framework — used for lifecycle governance, context, measurement and management. It is voluntary US guidance, is under revision, and does not certify a workflow or prescribe this regression set.
- European Commission: AI Act overview and timeline — used to keep current EU application points and role-dependent obligations visible. The overview is not a legal classification of the example; changes and implementing decisions must be checked.
Sources reviewed 7 September 2026. Recheck provider behaviour, applicable law and live guidance before a material release decision.