Article 79
EU AI Act Article 79 — Procedure for AI Systems Presenting a Risk
Article 79 of Regulation (EU) 2024/1689 sets the procedure for AI systems presenting a risk at national level. Market surveillance powers, evaluation, corrective measures, and the link to serious-incident reporting.
Source: Regulation (EU) 2024/1689 on EUR-Lex · Last published 2026-04-28 · Draft pending human review
What Article 79 actually requires
Article 79 of Regulation (EU) 2024/1689 sets the procedure at national level for handling AI systems that present a risk. It is the operational backbone of EU AI Act market surveillance.
Reg text — Article 79(1): "AI systems presenting a risk shall be understood as a 'product presenting a risk' as defined in Article 3, point (19) of Regulation (EU) 2019/1020, insofar as they present risks to the health or safety, or to fundamental rights, of persons."
The procedure
When the market surveillance authority of a Member State has sufficient reason to consider that an AI system presents a risk, it carries out an evaluation against the requirements of the Regulation (Article 79(2)). If during the evaluation the authority finds the system does not comply, it requires the relevant operator (provider, deployer, importer, distributor, authorised representative) to take all appropriate corrective actions to bring the system into compliance, withdraw it from the market, or recall it within a prescribed period.
If the operator does not take adequate corrective action within the period, the authority takes all appropriate provisional measures to prohibit or restrict the AI system being made available on its national market or service, withdraw it, or recall it (Article 79(5)).
The authority informs the Commission and the other Member States without delay. Where there is disagreement, the Commission may take its own measures.
Severity classification — Article 3(49)
Article 3(49) defines a serious incident: any incident or malfunctioning of an AI system that directly or indirectly leads to:
- (a) the death of a person, or serious damage to a person's health;
- (b) a serious and irreversible disruption of the management or operation of critical infrastructure;
- (c) the infringement of obligations under Union law intended to protect fundamental rights;
- (d) serious damage to property or the environment.
Article 73 then sets reporting timelines:
- 15 days generally from the moment a serious incident is identified.
- 72 hours for incidents involving infringement of Union fundamental-rights law.
- 10 days for incidents involving the death of a person.
Who is covered
Providers, deployers, importers, distributors, and authorised representatives. Both Article 26(5) (deployers) and Article 73 (providers) trigger the Article 79 procedure.
What to do
- Maintain an internal severity-classification triage tree that maps observed events to Article 3(49) categories. Document the decision criteria.
- Bind the triage to a stop-the-line procedure: a designated decision-maker can halt deployment within hours, not days.
- Maintain a serious-incident register linked to your Article 9 risk register.
- Pre-prepare the Article 73 reporting forms for each Member State you operate in.
- Train staff on the 72h/10d/15d windows. Missing a 72-hour window because the responsible person was on leave is a material non-conformity.
Inline crosswalk
- ISO/IEC 42001:2023 Clause 10.2 — Nonconformity and corrective action.
- NIST AI RMF MANAGE 2.3 — Procedures to respond to and recover from a previously unknown risk.
- NIST AI RMF MANAGE 4.3 — Incidents and errors communicated to relevant AI Actors.
Common mistakes
- No documented severity-classification decision tree.
- No 24/7 on-call rotation; missing the 72h window.
- Reporting only to the home Member-State authority and missing other Member States where the system is in use.
- No internal record of the operator's view of the incident — what was investigated, what was concluded, what was changed.
Penalties
Failure to comply with Article 79 corrective measures is treated under Article 99 as non-compliance with the obligations of operators under Chapter III — up to €15 million or 3% of worldwide annual turnover.
Disclaimer. Reference; not legal advice. Verify with counsel. Reg text from Regulation (EU) 2024/1689.
Reference checklist
From the Governancer 30-item EU AI Act checklist. Each item joins to the ISO 42001 + NIST AI RMF crosswalk table below.
Article 72 · Starter tier · medium
Establish post-market monitoring plan
Collect and analyse data on system performance after deployment. Feeds into your Article 9 risk review.
Article 73 · Starter tier · low
Prepare serious incident reporting process
Report within 15 days to the market surveillance authority (72h for severe cases involving death or serious harm).
Article 79 · Pro tier · medium
Internal severity-classification procedure for AI incidents
Article 3(49) defines "serious incident" tiers. Your internal triage decides 72-hour vs 15-day reporting windows — write the decision tree down.
ISO 42001 + NIST AI RMF crosswalk
Pulled live from the Governancer crosswalk module. Mapping reference; not a substitute for ISO 42001 certification audit or NIST AI RMF self-attestation.
ISO/IEC 42001:2023
| Checklist item | ISO 42001 control | Rationale |
|---|---|---|
art72-monitoring | ISO/IEC 42001:2023 Clause 9.1 — Monitoring, measurement, analysis and evaluation | Article 72 post-market monitoring delivers operational evidence required by Clause 9.1. |
art72-monitoring | ISO/IEC 42001:2023 Annex A.6.2.8 — Operation and monitoring of AI systems | Continuous post-market monitoring is the lifecycle-control objective in Annex A.6.2.8. |
art73-incident | ISO/IEC 42001:2023 Clause 10.2 — Nonconformity and corrective action | A serious-incident reporting workflow is the corrective-action loop demanded by Clause 10.2. |
art79-severity-classification | ISO/IEC 42001:2023 Clause 10.2 — Nonconformity and corrective action | A documented severity-classification triage tree is the nonconformity decision-process required by Clause 10.2. |
NIST AI RMF 1.0
| Checklist item | NIST AI RMF subcategory | Rationale |
|---|---|---|
art72-monitoring | NIST AI RMF MEASURE 4.1 — Approaches and metrics for measurement of AI risks are followed; identified risks are tracked over time | Post-market monitoring is the over-time risk-tracking method MEASURE 4.1 requires. |
art72-monitoring | NIST AI RMF MANAGE 4.1 — Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI Actors | The Article 72 plan is the literal post-deployment monitoring plan demanded by MANAGE 4.1. |
art73-incident | NIST AI RMF MANAGE 4.3 — Incidents and errors are communicated to relevant AI Actors, including affected communities | Article 73 serious-incident reporting to authorities is the communication channel MANAGE 4.3 specifies. |
art79-severity-classification | NIST AI RMF MANAGE 2.3 — Procedures are followed to respond to and recover from a previously unknown risk when it is identified | A documented severity triage tree is the structured response/recover procedure MANAGE 2.3 expects. |
Related
Pro feature
Generate Article 11 with AI
LLM-assisted draft of all eight Annex IV sections, pre-filled from your system intake. 5 drafts/month on Pro.
Pro template
Download FRIA template
15-page Article 27 FRIA template (.docx) with the six elements pre-structured and a worked example.
Get the 30-item EU AI Act compliance checklist
Free PDF. No spam. Maps every Article and Annex IV section we ship to a ready-to-action checklist row.
Reference; not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text quoted from the Official Journal version of Regulation (EU) 2024/1689. Published by Agonist Development AB.