Skip to content

EN 18286 clauses 9.6 and 9.7: serious incidents and non-compliance

These two clauses are the emergency machinery of EN 18286:2026, and they sit at organization level: the procedures live in the quality management system, while the detection signals arrive largely through the per-system post-market monitoring of clause 9.5. In Modulos they are carried by ORF-420 (reporting serious incidents) and ORF-421 (non-compliance and corrective action) in the OFF-19 template. Build the procedures before they are needed; both clauses assume they already exist when the event happens.

Clause 9.6 — Reporting serious incidents (ORF-420)

The trigger. Clause 9.6 screens on causation. Each serious incident gets investigated for evidence that the AI system caused it, or reasonably likely did, and the duty to report fires as soon as that causal link is established or plausible. The deadlines below count from the moment the provider becomes aware of the event.

The deadlines. Reports go to the competent authorities immediately, and at the latest within:

CaseDeadline
Serious incident involving critical infrastructure2 days
Death of a person10 days
All other serious incidents15 days

The clock starts when the provider becomes aware of the event. If the investigation is still open at the deadline, the provider may file what it has as a provisional report and complete it later; the option exists so that incompleteness is never a reason to miss the deadline.

The procedures (9.6.2). The reporting machinery is procedural, not ad hoc: documented procedures must be able to hit the 9.6.1 time scales, and they include a route for deployers to report serious incidents to the provider and to suspend use of the AI system. The standard recommends the procedures also cover the key internal contacts and escalation process, awareness of serious-incident risks among relevant personnel, the mechanics that make the time scales achievable, adequate resources for investigations and authority enquiries, detailed documented information on all serious incidents, their investigations, findings and the actions taken to restore compliance, the provider-deployer obligations that enable deployer reporting, and identification of all related in-scope AI systems that can produce the same incident.

Annex ZA position. Clauses 9.6.1 and 9.6.2.1 carry the Article 17(1)(i) row: procedures for reporting a serious incident in accordance with Article 73. The good-practice list in 9.6.2.2 sits outside the table, and no presumption is claimed for Article 73 itself.

In Modulos. The reused reporting-policy anchor is OCF-48; the overlay OCF-322 carries the explicit time scales, the provisional-report path, and the deployer-reporting and use-suspension evidence. A single event can also trigger the clause 9.7 machinery below; link the escalation paths.

Clause 9.7 — Non-compliance (ORF-421)

Vocabulary. Non-compliance is non-fulfilment of applicable regulatory requirements; the published standard replaced the draft's "nonconformity" term. The clause governs AI systems that are already on the market or in service.

Detection (9.7.1). The QMS needs a standing, documented route for finding out that an AI system already on the market or in service has fallen out of line with its regulatory requirements. In practice the signals arrive through post-market monitoring, complaints and support channels, internal reviews and authority contact; the implementation question is whether each of those sources actually feeds the route.

Response. The clause's duties sort into three tracks:

  • Scope and cause. Work out how far the problem reaches: its extent and severity, whether sister AI systems under the same quality management system share it, why it happened, and whether similar non-compliances exist or could arise. On that basis, judge what it takes to eliminate the causes so the problem neither recurs nor surfaces elsewhere.
  • Immediate disposition. Without delay, pick the appropriate corrective action from the remedial menu: bring the AI system into compliance, withdraw it, disable it, or recall it. Afterwards, confirm the chosen action actually worked.
  • Systemic follow-through. Read the accumulated non-compliance data for trends, systemic issues and emerging risks and decide whether preventive action is needed; change the quality management system, risk management system, AI system design, deployment conditions or operational controls where the analysis says so; and inform the deployers, distributors, authorized representatives and importers concerned.

The four remedial options have very different blast radius; the procedures should say what criteria drive the choice, who is authorized to decide, and how fast the decision can be taken for systems in active service.

AI system presenting a risk (9.7.2). A second detection duty covers AI systems presenting a risk, a legal concept the standard imports from Regulation (EU) 2019/1020, the EU market-surveillance regulation. The test it sets: does the harm the system could foreseeably do to people's health, safety or fundamental rights exceed what counts as reasonable and acceptable, given the intended purpose and the normal or reasonably foreseeable conditions of use? Duration of use belongs in that assessment, as do putting into service, installation and maintenance where relevant. When the threshold is met, the provider immediately investigates the causes, in collaboration with the reporting deployer where applicable, and informs the competent market surveillance authorities and, where applicable, the notified body that performed the conformity assessment, stating at least what the risk is and which corrective actions were taken.

Evidence (9.7.3). Documented evidence of the nature of the non-compliance, the subsequent actions, and the results of corrective action is retained.

Annex ZA position. Clause 9.7 sits inside the Article 17(1) first-sentence row; 9.7.1, 9.7.2.1 and 9.7.3 are listed on the quality-control row (c); and the notification duty 9.7.2.2 shares the Article 17(1)(j) communication row with clause 7.3.

In Modulos. The reused nonconformity-management anchor is OCF-10, which supplies the generic investigate-and-act policy; the overlay OCF-371 owns the EN-specific machinery: market detection procedures, the extent-and-severity and cause-elimination steps, the remedial menu, effectiveness review, trend analysis, operator information, the presenting-a-risk investigation with authority and notified-body notification, and the documented-evidence duty. The duty to inform interested parties of non-compliance, systems presenting a risk, and serious incidents under clause 7.3.2.2 is carried by OCF-11.

How the two clauses interlock

A serious incident is an event; a non-compliance is a state. One occurrence can be both: a serious incident whose investigation reveals that the system fails a regulatory requirement triggers the 9.6 reporting deadlines and the 9.7 corrective machinery in parallel, and an inadequate outcome feeds clause 10.1's duty to hold an additional management review whenever a serious-incident investigation finds the quality management system or its measures inadequate. Deployers appear in both clauses in both directions: as reporters (incident reporting, use suspension, risk feedback) and as recipients (operator information under 9.7.1, retirement and monitoring duties elsewhere in the standard).

Source attribution

EN 18286:2026, Artificial intelligence — Quality management system for EU AI Act regulatory purposes, clauses 9.6 and 9.7, restated in the documentation's own words with the Modulos template mapping as of templates 1.0.26. For conformity-assessment purposes, verify against the published standard.

Disclaimer

This page is for general informational purposes and does not constitute legal advice.