AI production assurance
Retain the chronology and versions, contain the effect, qualify the duties and demonstrate that recovery does not reintroduce the risk.
In both cases, the organisation must establish which version was active, what varied, who was exposed, which action was taken and on which test the next step was authorised. Change anticipates this evidence; an incident reconstructs it under time pressure.
The change record describes its object, rationale, affected components, population, risks, tests and rollback. A seemingly minor modification can alter intended purpose, human interaction, logs or dependence on a third party.
The chronology retains the time, source, version, people informed, decisions and actions. It separates observed facts, hypotheses and information still missing. Clocks and identifiers must support reconciliation across distributed components.
Containment may require immediate suspension, but useful logs, configurations, inputs and outputs are preserved in accordance with applicable rights and retention periods. A correction that modifies the system before facts are retained can make the cause impossible to establish.
The team addresses harm and continuity immediately. In parallel, competent functions assess whether the criteria of a serious incident or another notification regime are met, by which actor and within what time. An internal label does not replace that qualification.
The correction addresses the established cause or explicitly contains uncertainty. The plan identifies affected versions, immediate measures, durable correction, tests, compensating controls and residual risk. A closed ticket without a test result is not evidence of closure.
Recovery requires a known state, a protocol fixed before testing, a representative population, success criteria and an empowered decision-maker. It may be progressive, segmented or subject to enhanced monitoring. The authority separately accepts any remaining reservations.
| Object | Question | Evidence |
|---|---|---|
| Version | What exactly returns to service? | Reconciled manifest and configuration |
| Risk | Has the cause been treated or contained? | Analysis, correction and compensating controls |
| Test | Are the service and its limits verified? | Results, population and regression test |
| Authority | Who accepts the residual risk? | Dated decision and recovery scope |
The final record contains the chronology, preserved evidence, qualification, notifications, causal analysis, corrections, test results and recovery authorisation. Lessons then amend the baseline, thresholds, procedures or architecture.
Primary sources
Last documentary review: 6 September 2026.
Continuous risk management, deployer duties, post-market monitoring and serious-incident reporting.
Monitoring categories and measurement challenges for AI systems in real-world operating conditions.
Govern, map, measure and manage the risks of an AI system.
Architecture, lifecycle, dependencies, pre-production tests and logging.
Before you write to us
People and service must be protected immediately while useful facts are retained. Premature modification can prevent the cause from being established.
No. Regulatory qualification depends on the Regulation’s criteria, the entity’s role, the system and the observed facts.
The authority named before the incident, on the basis of the version, test results, limitations and residual risk.
Incident and recovery
Present the chronology and version concerned. We assess whether the record actually demonstrates control of the return to service.
Review the record