EU AI Act Article 20: Corrective Actions and Recall

A provider learns that a high-risk AI system already on the market does not — or may not — conform to Regulation (EU) 2024/1689. What now? Article 20 answers in one word: immediately. The provider must act without waiting for an authority to tell it to, and must pull the right lever from a defined set: bring the system into conformity, withdraw it, disable it, or recall it — and then tell everyone down the chain who needs to know.

This is the provider's self-policing duty. It sits between two neighbours: Article 72 post-market monitoring, which is how you find out, and Article 73 serious-incident reporting, which is how you escalate. Article 20 is the action you take in the middle.

Stand-alone high-risk systems must meet these obligations from 2 December 2027 under Regulation (EU) 2026/1744, the Digital Omnibus on AI — published in the Official Journal on 24 July 2026 and in force since 27 July 2026 (Annex I product-embedded systems from 2 August 2028). The Annex III date was originally 2 August 2026.

---

What Article 20 Requires

Article 20 applies to a provider that considers, or has reason to consider, that a high-risk AI system it has placed on the market or put into service is not in conformity with the Regulation. The trigger is not certainty — a reasonable basis for concern is enough.

On that trigger, the provider must immediately:

1. Take the necessary corrective actions — choose the proportionate response:
   • bring the system into conformity (a fix, retraining, a configuration change);
   • withdraw it — remove it from the market so it is no longer made available;
   • disable it — stop it functioning where withdrawal is impractical;
   • recall it — bring deployed copies back from the field.
2. Inform the relevant operators — the distributors of the system, and where applicable the deployers, the authorised representative, and the importers.

"Withdraw", "disable" and "recall" are not interchangeable. Withdrawal stops further supply; recall reverses supply already made; disabling neutralises a system you cannot physically retrieve — increasingly the realistic option for cloud-delivered AI.

---

When the Risk Touches Fundamental Rights — Notify the Authority

Article 20(1) handles the supply-chain notification. Article 20(2) widens the circle: where the system presents a risk within the meaning of Article 79(1) and the provider becomes aware of it, the provider must immediately investigate the causes — with the reporting deployer, where applicable — and inform the competent market surveillance authority and, where applicable, the notified body that certified the system, of the non-compliance and any corrective action taken. Where a serious incident has occurred, it also follows Article 73. This is where Article 20 hands off to the Article 79 procedure for AI systems presenting a risk — the authority's process for evaluating, and if needed compelling, corrective action across a member state or the whole Union.

The sequence in practice: monitor (Article 72) → identify non-conformity → act and inform the chain (Article 20) → if a serious incident, report it (Article 73) → if the authority engages, the Article 79 procedure runs.

---

How Article 20 Connects to Its Neighbours

• Article 72 — post-market monitoring. Providers must run a documented monitoring system that actively collects performance data once a high-risk system is live. It is the early-warning radar; Article 20 is what you do when the radar pings. A monitoring plan is part of the Annex IV technical documentation and must exist before launch.
• Article 73 — serious-incident reporting. Where a high-risk system causes or contributes to death, serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment, the provider reports to the market surveillance authority within strict deadlines. Article 73 is escalation; Article 20 is remediation. A single event often triggers both.
• Article 79 — non-conforming system procedure. When a market surveillance authority has sufficient reason to consider a system presents a risk, it evaluates the system and can require the operator to take corrective action, restrict it, withdraw it, or recall it. Article 20's voluntary action and Article 79's compelled action are the two halves of the same enforcement logic — and doing Article 20 well is the best way to avoid Article 79 being done to you.

---

Worked Example

Selvanta Analytics OÜ (a fictional Estonian provider, ~45 employees, ~€6M turnover) ships a high-risk creditworthiness model (Annex III point 5(b)) to lenders across the EU. Its Article 72 monitoring detects that, after a data-source change, the model's error rate for one applicant segment has drifted well outside the validated range — a likely breach of the Article 15 accuracy requirement.

• Article 20 triggers: Selvanta now has reason to consider the live system non-conforming. It must act immediately.
• Chosen action: because the model runs as a hosted API the lenders call, Selvanta disables the affected scoring path and reverts to the last validated version while it retrains — withdrawal of an API is impractical, disabling is the proportionate lever.
• Inform the chain: it notifies the deployer-lenders and its EU distributors, with the scope and the fix timeline.
• Authority + incident: no death or serious harm has occurred, so Article 73 is not triggered, but the fundamental-rights dimension of credit scoring means the drift presents a risk, so Selvanta informs the relevant market surveillance authority of the non-conformity and the corrective action (Article 20(2)).
• Exposure: failing to act under Article 20 sits in the €15M or 3% tier (Article 99(4)); under Article 99(6) a company Selvanta's size pays the lower of the percentage or the fixed amount. Acting promptly and documenting it is also the strongest mitigation if an authority later reviews the file.

The verdict: the fine ceiling is real, but the operational point is sharper — a provider that cannot move from "we noticed a problem" to "we disabled it and told the chain" within days does not have an Article 20 process; it has a liability.

---

How Confir Helps

Confir keeps an org-wide register of every AI system with its role and classification, and runs the governance and post-market-monitoring assessment that feeds an Article 20 response — the corrective-action record, the supply-chain notification list, and the link to Article 72 monitoring and Article 73 reporting. The engine is rule-based and deterministic: the same non-conformity facts produce the same required-action checklist every time, with the rule that fired shown in plain English.

---

Related guides

• Provider obligations checklist (Article 16)
• Post-market monitoring explained (Article 72)
• Serious incident reporting (Article 73)
• Article 20 corrective actions in the text
• Substantial modification (Article 3(23))