EU AI Act Article 20: Corrective Actions and the Duty of Information

What Article 20 Covers

Article 20 of Regulation (EU) 2024/1689 governs what happens when things go wrong after a high-risk AI system is on the market. It imposes two linked duties on providers: a duty to act and a duty to inform. Both are triggered not only by confirmed non-conformity but already when the 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.

That trigger standard matters. A provider cannot wait for definitive proof or for a regulator to knock. Internal test results, post-market monitoring signals under Article 72, deployer complaints or log analysis under Article 12 that point to non-conformity are enough to activate Article 20.

The Duty to Act: The Menu of Corrective Actions

Once triggered, the provider must immediately take the necessary corrective actions to, as appropriate:

• Bring the system into conformity, for example through a fix, retraining, reconfiguration or updated instructions for use.
• Withdraw it, meaning prevent further making available of the system on the market.
• Disable it, which is a remedy specific to software-based products: switching off or deactivating the system in the field.
• Recall it, meaning aim at achieving the return of a system already made available to deployers.

The words as appropriate signal proportionality: the chosen measure must match the seriousness and nature of the non-conformity. A documentation defect may be cured by correction; a system producing discriminatory outputs in a protected context may require disabling while the cause is investigated.

The Duty to Inform the Value Chain

Article 20(1) also requires the provider to inform the distributors of the high-risk AI system concerned and, where applicable, the deployers, the authorised representative and importers accordingly. The information duty runs down the value chain so that every operator who could still be making the system available, or relying on it operationally, learns of the problem and of the corrective action taken.

This mirrors the upstream duties on other operators: importers under Article 23 and distributors under Article 24 must inform the provider when they identify non-conformity or risk, and deployers under Article 26(5) must inform the provider or distributor and the relevant market surveillance authority when they have reason to consider that use in accordance with the instructions may result in a risk under Article 79(1).

When the System Presents a Risk: Investigation and Authority Notification

Article 20(2) adds an escalation layer. Where the high-risk AI system presents a risk within the meaning of Article 79(1), that is, a risk to the health or safety or to the fundamental rights of persons, and the provider becomes aware of that risk, it shall immediately investigate the causes, in collaboration with the reporting deployer where applicable, and inform the market surveillance authorities competent for the system concerned and, where applicable, the notified body that issued a certificate for it, in particular of the nature of the non-compliance and of any relevant corrective action taken.

In risk cases the audience therefore widens from the commercial chain to the regulator and the notified body, and a causal investigation becomes mandatory. Where the situation also meets the definition of a serious incident in Article 3(49), the reporting regime of Article 73 applies with its strict deadlines of up to fifteen days, ten days for deaths, and two days for widespread infringements or serious irreversible disruption of critical infrastructure.

How to Implement Article 20 in Practice

1. Define non-conformity triggers in the quality management system under Article 17, which must include procedures for managing modifications and for communication with authorities and operators.
2. Build a corrective action procedure with severity classification, decision criteria for correct, withdraw, disable or recall, named decision-makers and target timelines consistent with the word immediately.
3. Maintain a value-chain contact register: current distributors, importers, the authorised representative and deployer contacts, so notifications do not stall on missing addresses.
4. Engineer for remote remediation. The disable remedy presupposes technical capability: feature flags, kill switches, version rollback and forced-update mechanisms should exist before they are needed.
5. Document everything: the signal, the assessment, the decision, the notifications and the verification that the corrective action worked. These records belong in the Article 18 retention set.
6. Rehearse with a tabletop exercise, including the handoff to Article 73 serious incident reporting.

A Concrete Example

A provider of a high-risk credit scoring system notices through post-market monitoring that a model update has materially degraded accuracy for applicants with thin credit files, contradicting the accuracy declared under Articles 13 and 15. The provider rolls back the model version the same week, informs its distributors and bank deployers of the issue and the rollback, and assesses whether the degradation created a risk to fundamental rights. Concluding that affected scores could have produced unjustified rejections, it informs the competent market surveillance authorities of the non-compliance and the corrective action, and works with deployers to identify affected decisions.

How Article 20 Connects to Other Provisions

Article 20 is listed among the provider obligations via Article 16(j) context and operates alongside Article 21, which obliges providers to supply information and documentation to competent authorities on reasoned request. It consumes signals from Articles 12 and 72, escalates into Article 73 for serious incidents, and interlocks with the parallel duties of importers, distributors and deployers in Articles 23, 24 and 26. In enforcement, Articles 79 to 83 give market surveillance authorities the power to require corrective actions, restrict or withdraw systems where operators do not act on their own.

Actions to Take Before August 2, 2026

Providers should not wait for the application date to build their corrective action machinery, because the underlying capabilities, remote disablement, version rollback, monitoring and value-chain contact management, take engineering time. A provider that can detect, decide, act and notify within days will satisfy Article 20 with far less disruption than one improvising during its first field incident. This article provides general information about Regulation (EU) 2024/1689 and is not advice on any specific incident.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.