EU AI Act Article 20: The Provider's Duty to Take Corrective Actions

Your post-market monitoring flags that a high-risk system you placed on the market last quarter is mis-scoring one group of users. You do not yet have a regulator's letter, a lawsuit, or a confirmed harm. Article 20 of Regulation (EU) 2024/1689 says that does not matter: the moment you have reason to consider the system is not in conformity, the corrective-action duty is already live.

This guide covers the operative duty for providers of high-risk AI systems — the trigger, the four remedies, who you must inform, and how Article 20 differs clock-for-clock from the Article 73 serious-incident duty.

---

What Article 20 actually requires

Article 20(1) reads in plain terms: where a provider 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, it must immediately take the necessary corrective actions to bring that system into conformity, withdraw it, disable it or recall it, as appropriate. It must also inform the relevant actors down the supply chain.

Article 20 sits in Chapter III, Section 3, alongside the rest of the obligations that apply to providers and other actors. It is one of the thirteen provider obligations cross-referenced in Article 16 — but where Article 16 lists corrective action in a single line, Article 20 is the standalone operative duty that says what "corrective action" actually means.

Two things define the standard. First, the duty attaches to your own knowledge or reasonable suspicion of non-conformity — not to a regulator first ordering you to act. Second, the article has two limbs that run together: the duty to act on the system, and the duty to inform the supply chain and, where a risk arises, the authorities. Neither limb is optional, and neither waits for the other.

---

The trigger: "has reason to consider" non-conformity

The trigger for Article 20 is non-conformity with the Regulation — not a harm event. A system is non-conforming when it fails any Section 2 requirement (the data, documentation, transparency, oversight, accuracy and robustness duties in Articles 8 to 15), carries a missing or false EU declaration of conformity under Article 47, or breaches any other applicable requirement. No one needs to be injured for the duty to bite.

A deliberately low evidentiary bar

The phrase "considers or has reason to consider" is broad on purpose. It captures reasonable suspicion, not proven fact. That suspicion commonly surfaces through your Article 72 post-market monitoring data, structured feedback from deployers, your own internal testing, or an authority's preliminary inquiry. You do not get to wait for certainty: a credible signal that the system may be non-conforming is enough to put you on notice.

"Immediately" means no grace period to start

Article 20 uses the word immediately. Once you are on notice, the corrective-action duty is live — there is no investigation window during which the clock is paused. You may still need to investigate causes (and Article 20(2) expressly requires that where a risk is present), but investigation and corrective action proceed in parallel; the duty to begin acting does not wait for the post-mortem to finish.

Note the practical timing. The stand-alone high-risk obligations in Annex III only begin to apply once Article 6(2) bites. The statute originally read 2 August 2026; the Digital Omnibus — adopted by the European Parliament on 16 June 2026 and by the Council on 29 June 2026 — defers that to 2 December 2027, pending Official Journal publication as a formality. Plan against 2 December 2027. Once your system is in scope and on the market, Article 20 applies to it in full.

---

The four corrective-action options

Article 20(1) sets out four graduated remedies. You choose the one proportionate to the non-conformity:

• Bring into conformity — fix the defect and re-verify that the system now meets the requirement it failed.
• Withdraw — stop any further supply of the system to the market.
• Disable — render an in-service system inoperative so it cannot continue producing non-conforming outputs.
• Recall — retrieve units already in the hands of deployers.

"Withdrawal" and "recall" are defined terms in Article 3: withdrawal stops further market supply going forward, while recall reaches back for units already made available. The distinction matters because the two measures have different operational footprints — a withdrawal is a supply decision, a recall is a retrieval operation involving every deployer that holds the system.

"As appropriate" is a proportionality test

The remedy must match the severity and reach of the problem. A minor documentation gap — a missing field in the Annex IV file — may be cured by correction alone. A system actively infringing fundamental rights may need to be disabled or recalled while you fix it. You are expected to choose, document the choice, and be able to justify it later.

A substantial fix can re-open the conformity assessment

If the corrective fix is significant enough to change the system's conformity profile, it may itself amount to a substantial modification — and Article 43 then requires the conformity assessment to be repeated, for most Annex III systems via the Annex VI internal-control procedure, with the Annex IV technical file updated. A minor correction that does not affect conformity does not re-open the assessment, but you should record why you concluded it was not substantial.

---

The duty to inform: the chain, and the authorities

The second limb of Article 20(1) is the duty to inform. When you take corrective action, you must inform the distributors of the high-risk AI system and, where applicable, the deployers, the authorised representative, and the importers accordingly. This chain notification is mandatory — it does not depend on the system presenting a risk.

Article 20(2) adds a conditional escalation. Where the high-risk AI system presents a risk within the meaning of Article 79(1) and you become aware of that risk, you must immediately investigate the causes — in cooperation with the reporting deployer where relevant — and inform the market surveillance authorities competent for that system, and any notified body that issued a certificate for it.

The risk condition in Article 79(1) is the gate to authority involvement: it covers high-risk systems presenting a risk to health, safety or fundamental rights and triggers the market-surveillance procedure for AI presenting a risk.

---

Article 20 vs Article 73: two triggers, two clocks

Providers routinely conflate these duties. They are different.

Article 20 is triggered by non-conformity — a state of the system. Article 73 is triggered by a serious incident as defined in Article 3(49) — a harm event. Different facts switch each one on.

The clocks differ too. Article 20 says immediately, with no fixed day-count. Article 73 imposes hard deadlines: 15 days generally, 10 days where a person has died, and 2 days for a serious incident involving critical infrastructure or a widespread fundamental-rights disruption.

They overlap. A serious incident very often reveals non-conformity, so a single event can fire both duties at once: the Article 73 report to the authority on the harm, plus the Article 20 corrective action and chain notification on the underlying defect. Neither substitutes for the other — reporting an incident under Article 73 does not discharge your Article 20 duty to fix and inform, and vice versa. And both are distinct from the brief listing in Article 16(j)/(k), which merely cross-references the standalone duty set out here.

---

Worked example: non-conformity discovered post-launch

Lumen Talent GmbH, a 60-person German HR-tech provider, places a CV-screening system on the market under its own name. The system filters applications and evaluates candidates, so it is high-risk under Annex III, point 4(a) (recruitment).

The trigger. Routine Article 72 post-market monitoring shows the model systematically under-ranks candidates from one protected group. Lumen now has reason to consider that the data-governance requirement of Article 10 is breached — the system is not in conformity. No candidate has yet filed a complaint; the monitoring signal alone makes the Article 20 duty live.

The action. Lumen immediately disables the affected ranking feature so it stops producing skewed shortlists, then brings the dataset and model back into conformity. Because the remediation materially changes the model, Lumen treats it as a substantial modification and re-runs the Annex VI internal-control conformity assessment under Article 43, updating the Annex IV technical file.

Inform the chain. Lumen notifies its distributors and the employer-deployers using the tool. Because a discriminatory ranking system presents a risk to fundamental rights within the meaning of Article 79(1), Lumen also informs the competent market surveillance authority and documents the full sequence — what was found, which remedy was chosen, when each party was told.

The exposure. Failing to take required corrective action is a breach of a provider obligation under Article 99(4): fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. As an SME, Lumen would fall under Article 99(6), which caps the fine at the lower of the percentage or the fixed amount. Giving the authority incorrect or misleading information would separately attract the Article 99(5) tier of up to €7.5 million or 1% of turnover.

---

How Confir helps providers operationalise Article 20

Confir's AIGM assessment area — governance and post-market monitoring — maps Articles 9, 72 and 73, surfacing the non-conformity signals that make the Article 20 duty live in the first place. If your monitoring data shows a drift like Lumen's, the finding is captured rather than buried.

The assessment logic is deterministic and rule-based — no model inference, no hallucination. The same intake produces the same non-conformity determination and the same recommended corrective-action category every time, with the rule that fired visible for review. That reproducibility is what lets you defend a determination to an authority.

Confir keeps a structured corrective-action and notification log: what was found, which of the four remedies was chosen, when the chain — distributors, deployers, importers, authorised representative — was informed, and any authority notification under Article 20(2). The outputs align to the Annex IV technical-file update that a substantial corrective fix requires, keeping the documentation current for a later review.

---

Related guides

• Article 73 serious-incident reporting
• the full Article 16 provider obligations
• Article 72 post-market monitoring
• market surveillance authority
• incident reporting workflows