AI production assurance
Handle change, incident and recovery
Retain the chronology and versions, contain the effect, qualify the duties and demonstrate that recovery does not reintroduce the risk.
Continuity
A change and an incident share the same evidence question
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.
Change
Qualify the effect before authorising release
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.
Detection
Open one chronology from the first signal
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.
Preservation
Protect people without erasing the cause
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.
Qualification
Separate operational handling from regulatory qualification
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.
Correction
Connect the cause, action and regression test
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
Treat recovery as a new production decision
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.
Minimum recovery conditions
| 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 |
Version
- Question
- What exactly returns to service?
- Evidence
- Reconciled manifest and configuration
Risk
- Question
- Has the cause been treated or contained?
- Evidence
- Analysis, correction and compensating controls
Test
- Question
- Are the service and its limits verified?
- Evidence
- Results, population and regression test
Authority
- Question
- Who accepts the residual risk?
- Evidence
- Dated decision and recovery scope
Closure
Retain a record that allows the reasoning to be replayed
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.
Sources and references
- EU AI Act — consolidated text, Articles 9, 26, 72 and 73 (new tab)
Continuous risk management, deployer duties, post-market monitoring and serious-incident reporting.
- NIST AI 800-4 — Challenges to the Monitoring of Deployed AI Systems (new tab)
Monitoring categories and measurement challenges for AI systems in real-world operating conditions.
- NIST AI RMF 1.0 (new tab)
Govern, map, measure and manage the risks of an AI system.
- ANSSI — Generative AI system security (new tab)
Architecture, lifecycle, dependencies, pre-production tests and logging.
Frequently asked questions
Should the system be corrected before logs are preserved?
People and service must be protected immediately while useful facts are retained. Premature modification can prevent the cause from being established.
Is every internal incident a serious incident under the EU AI Act?
No. Regulatory qualification depends on the Regulation’s criteria, the entity’s role, the system and the observed facts.
Who authorises recovery?
The authority named before the incident, on the basis of the version, test results, limitations and residual risk.
Incident and recovery
Can you reconstruct the last recovery decision?
Present the chronology and version concerned. We assess whether the record actually demonstrates control of the return to service.