Article 20: corrective actions and duty of information
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 must immediately take the necessary corrective actions and inform the distributors accordingly, and, where applicable, also the deployers, the authorised representative and the importers. Where that system also presents a risk within the meaning of Article 79(1), the provider must immediately investigate the causes and inform the competent market surveillance authorities and, where applicable, the notified body that issued a certificate under Article 44.
Paragraph 1.
Praxikon tracks Article 20: corrective actions and duty of information under the EU AI Act, checked against the official source on 14 August 2026, citing the source for every statement.
- Status
- Upcoming
- Application date
- 2 December 2027
- Version
- 1.0.0
- Last reviewed
- 14 August 2026
Review status: placed against the official source (14 August 2026). Next check due by 10 February 2027. The check date is the knowledge date of this version; no later recheck has been recorded.
From source to evidence
Why this obligation applies, what it asks of you, and what you show for it.
Applies
Upcoming · 2 December 2027
For whom
- Authorised representative
- Deployer
- Distributor
- and 2 more
What you do
Set up the procedure for corrective actions and notification
What you record
Record of corrective actions
Official source
Who this is relevant to
When this applies
Authorised representative
The authorised representative is the party located in the Union that, on the basis of a written mandate, performs and carries out the obligations and procedures of the Regulation on behalf of a provider established outside the EU. The definition in Article 3(5) already applies today, so the role can be determined now. The appointment duty itself starts on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route. From those dates, a third-country provider may not place a high-risk AI system on the Union market without an appointed representative.
Deployer
An organisation using an AI system under its authority, excluding personal non-professional use.
Distributor
You are a distributor if you make an AI system available on the Union market without being the provider or the importer. This catches resellers, systems integrators and managed service providers that pass on someone else's AI.
Importer
You are an importer as soon as you, from within the EU, first place an AI system on the Union market that bears the name or trade mark of a party established outside the EU. What counts is not your purchasing role but whose brand is on the system and who first brings it to market.
Provider of an AI system
A party that develops or has an AI system developed and places it on the market under its own name.
- 1Applies to providers of high-risk AI systems as soon as they consider, or have reason to consider, that a system they have placed on the market or put into service is not in conformity with this Regulation. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027. For systems embedded as a safety component in products covered by the Annex I harmonisation legislation (Article 6(1)) the date is 2 August 2028.
- 2The second layer in paragraph 2 is added only where the system presents a risk within the meaning of Article 79(1) and the provider becomes aware of that risk. The investigation of causes and the duty to inform the market surveillance authorities and, where applicable, the notified body that issued a certificate under Article 44, then come on top of the corrective actions under paragraph 1.
- 3The distributor, the importer and the deployer appear here as affected parties, but that is not their only possible position. Anyone who puts their name or trade mark on a high-risk system already placed on the market, who substantially modifies such a system, or who changes the intended purpose of a system not classified as high-risk so that it becomes high-risk, is considered a provider under Article 25(1) and is subject to the obligations of Article 16. Point (j) of that Article routes straight to Article 20, so this provision then becomes a duty of their own rather than a notification arriving from someone else. In the trade mark case this applies without prejudice to contractual arrangements allocating the obligations otherwise.
What the official source establishes
For the Annex III route this requirement applies from 2 December 2027; for high-risk AI in regulated products (Annex I) from 2 August 2028.
Our interpretation
The official source remains authoritative. This general interpretation is not legal advice.
This provision is rarely read as a procedure, and that is exactly where it goes wrong. Article 20 places four measures side by side that differ sharply in practice, and those four are not legally equivalent. Recall and withdrawal are defined in Article 3(16) and (17), and the knowledge base carries those terms separately; the difference between them is the point in the chain. Bringing a system into conformity is the patch. Disabling is the odd one out: it is practically the heaviest switch, because it stops a customer who is running the system, and it is at the same time the only one of the four the Regulation nowhere defines. Anyone who copies that word into a contract or procedure without deciding for themselves what it means leaves the heaviest measure the vaguest. The second half is the notification, and in practice that is what fails most often. Paragraph 1 asks you to reach your distributors and, where applicable, your deployers, authorised representatives and importers, which is only possible if you hold a current list of who runs the system in which version and through which contact you reach them. That list is not a by-product of your CRM: resale, white labelling and integration mean you have customers you do not know.
Paragraph 2 and Article 73 are often built as a single reporting channel, and that goes wrong in two ways. The trigger differs: Article 73 concerns a serious incident that has occurred, Article 20(2) a risk within the meaning of Article 79(1), that is, a risk to the health, safety or fundamental rights of persons. That is not a tidy split between past and future: a serious incident that has occurred usually also means the system presents a risk, so in practice both provisions often fire at the same time. Nor do the recipients differ entirely, because both routes run to market surveillance authorities. The difference sits in the detail: Article 73(1) points to the authorities of the Member States where the incident occurred, Article 20(2) to the authorities competent for the system concerned, and only Article 20(2) adds the notified body that issued a certificate under Article 44. Only Article 73, moreover, sets hard deadlines. So build one internal process with two exits, not two separate channels and not one channel that forgets the notified body.
Two things within this duty are unsettled. First, what "immediately" requires: Article 20 sets no period. The closest anchor in the Regulation is Article 73(2), which ties "immediately" to the moment the provider has established a causal link between the system and the incident, or the reasonable likelihood of such a link, with an outer limit of fifteen days after becoming aware. We read Article 20 in that light: act once the signal is confirmed, and not only after a full internal investigation has been completed, because paragraph 2 places the investigation of causes alongside the measures rather than before them. A defensible alternative reading is that a provider first has reasonable time to verify and that "immediately" only starts running once the non-conformity is established. Second, the threshold "reason to consider": it is nowhere settled whether a complaint from a deployer, a deviating test result or a signal from the post-market monitoring of Article 72 already meets it. Whoever records that themselves can later demonstrate the moment of becoming aware; whoever does not has to reconstruct it after the fact.
What you can do now
Write out the four measures in paragraph 1 as four concrete scenarios with an owner, a decision maker and a lead time, and decide for yourself what disabling means in your system, because the Regulation does not define that term. Test at least once whether you can actually disable or recall a system without needing a fresh decision to do so. Also keep a record, per system version, of who runs it and through which contact you reach that party, and record which signal meets the "reason to consider" threshold in your organisation, so that the moment of becoming aware is demonstrable rather than something reconstructed after the fact.
- 01
Set up the procedure for corrective actions and notification
Work out the four measures in paragraph 1 as scenarios with an owner and a lead time, keep a record per system version of who runs it and how you reach that party, and set out the route along which the investigation of causes, the notification to the market surveillance authorities and the message to the notified body run once paragraph 2 comes into play.
What to retain
Record of corrective actions
Per case: which signal came in and when, which system and which version it concerned, which measure was chosen and why, who decided on it, which parties were informed and when, and what the investigation of causes produced. This is the file that shows that "immediately" is a moment in your organisation rather than an estimate after the fact.
Control and reassessment
Escalation gate on a suspicion of non-conformity
The control that ensures a signal about possible non-conformity reaches an identifiable decision maker within a set period, that it is decided there whether paragraph 1 or also paragraph 2 comes into play and whether the reporting duty of Article 73 runs alongside it, and that the decision is recorded with a date instead of remaining in a support ticket.
Public tools
Full text of Article 20
The full legal text in the public AI Act Explorer.
Conditions and exceptions
- Article 20 is by definition about systems already placed on the market or put into service, and that is exactly the group covered by the transitional rule of Article 111(2). That provision was replaced by Article 1, point (39)(a), of Regulation (EU) 2026/1744 and now reads: without prejudice to the application of Article 5 as referred to in Article 113, third paragraph, point (a), this Regulation applies to operators of high-risk AI systems, other than the systems referred to in paragraph 1 of that Article, that have been placed on the market or put into service before the date of application of Chapter III referred to in Article 113, only if, as from that date, those systems are subject to significant changes in their designs. The cut-off is therefore no longer a fixed date in paragraph 2: the date of 2 August 2026 that stood there until that amendment has been removed, and the amended paragraph names no date of its own. The carve-out in paragraph 1 covers systems that are components of the large-scale IT systems listed in Annex X; paragraph 1 was not amended and keeps a cut-off of its own. For systems intended to be used by public authorities the reprieve in paragraph 2 does not hold: there, compliance with the requirements and obligations is due by 2 August 2030 in any event. Which date of application of Chapter III is the cut-off is an open point: the object on Article 111 reads it as route dependent, so 2 December 2027 for the Annex III route and 2 August 2028 for the Annex I route, and marks that reading expressly as preliminary. That question is carried there, not here.
Official sources and locators
EU Artificial Intelligence Act 2024/1689
European Parliament and Council | original-oj-2024-07-12
Source locator: Article 20(1)-(2)
Digital Omnibus on AI 2026/1744
European Parliament and Council | official-journal-2026-07-24
Source locator: Article 1, point (40)(b), of Regulation (EU) 2026/1744, replacing Article 113, third paragraph, point (c), of Regulation (EU) 2024/1689
EU Artificial Intelligence Act 2024/1689
European Parliament and Council | original-oj-2024-07-12
Source locator: Article 20(2), Article 73(1)-(2) and Article 79(1)
Referring to this object
Citation block
Copy this reference into your advice, article or file. The identifier, the version and the hash keep the statement findable later, even once the dataset has moved on.
Reference
Praxikon, "Article 20: corrective actions and duty of information", praxikon:eu:ai-act:obligation:article-20-corrective-actions@1.0.0, dataset praxikon:sys:registry:dataset:ai-act-implementation-graph 2.2.0 (schema 1.5.0), effective_at 2026-08-08T00:00:00.000Z, known_at 2026-08-14T00:00:00.000Z, sha256 3da4413e7f76d6cd26cf52cc894dc8b6637916ab4ed1d39776d4446a96c5232c, https://www.praxikon.com/en/verplichtingen/article-20-corrective-actions (https://www.praxikon.com/api/v1/obligations?id=praxikon%3Aeu%3Aai-act%3Aobligation%3Aarticle-20-corrective-actions&effective_at=2026-08-08&known_at=2026-08-14&lang=en, accessed 2026-09-15)
Short form
praxikon:eu:ai-act:obligation:article-20-corrective-actions@1.0.0 (sha256 3da4413e)
BibTeX
@misc{praxikon-eu-ai-act-obligation-article-20-corrective-actions-1-0-0,
author = {{Praxikon}},
title = {Article 20: corrective actions and duty of information},
year = {2026},
version = {1.0.0},
number = {praxikon:eu:ai-act:obligation:article-20-corrective-actions},
howpublished = {AI Act Change \& Evidence Graph, dataset 2.2.0, schema 1.5.0},
note = {effective_at 2026-08-08T00:00:00.000Z; known_at 2026-08-14T00:00:00.000Z; sha256 3da4413e7f76d6cd26cf52cc894dc8b6637916ab4ed1d39776d4446a96c5232c},
url = {https://www.praxikon.com/en/verplichtingen/article-20-corrective-actions},
urldate = {2026-09-15},
language = {en}
}CSL JSON
[
{
"id": "praxikon:eu:ai-act:obligation:article-20-corrective-actions@1.0.0",
"type": "dataset",
"title": "Article 20: corrective actions and duty of information",
"container-title": "AI Act Change & Evidence Graph",
"publisher": "Praxikon",
"version": "1.0.0",
"number": "praxikon:eu:ai-act:obligation:article-20-corrective-actions",
"URL": "https://www.praxikon.com/en/verplichtingen/article-20-corrective-actions",
"language": "en",
"issued": {
"date-parts": [
[
2026,
8,
14
]
]
},
"accessed": {
"date-parts": [
[
2026,
9,
15
]
]
},
"note": "dataset praxikon:sys:registry:dataset:ai-act-implementation-graph 2.2.0; schema 1.5.0; effective_at 2026-08-08T00:00:00.000Z; known_at 2026-08-14T00:00:00.000Z; sha256 3da4413e7f76d6cd26cf52cc894dc8b6637916ab4ed1d39776d4446a96c5232c; retrieved_from https://www.praxikon.com/api/v1/obligations?id=praxikon%3Aeu%3Aai-act%3Aobligation%3Aarticle-20-corrective-actions&effective_at=2026-08-08&known_at=2026-08-14&lang=en; licence https://www.praxikon.com/nl/legal/terms"
}
]How to verify a reference later is set out in the methodology. Terms
Version history
v1.0.0
8 August 2026
Article 20: corrective actions and duty of information
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 must immediately take the necessary corrective actions and inform the distributors accordingly, and, where applicable, also the deployers, the authorised representative and the importers. Where that system also presents a risk within the meaning of Article 79(1), the provider must immediately investigate the causes and inform the competent market surveillance authorities and, where applicable, the notified body that issued a certificate under Article 44.
Corrections to this obligation
No substantive correction to this object has been recorded.
Open the correction log
Help with implementation
Zahed Ashkara, jurist and freelance AI & Privacy Consultant, supports implementation with your team through Embed AI.
View AI governance at Embed AIFor AI agents and integrations
This page and the machine output derive from the same versioned object. Use the API for deterministic filters by role, topic and time.