Articles 20 and 21 AI Act corrective actions and evidence

What AI Act Article 20 corrective actions require from providers

If a provider has found, or has reason to consider, that a high-risk AI system does not conform to the AI Act, Article 20 requires the provider to act immediately: bring the system into conformity, or withdraw, disable or recall it. The provider must also inform its distributors and, where applicable, deployers, the authorised representative and importers. If the system presents a risk within the meaning of Article 79(1), the provider must also investigate the causes immediately, with the reporting deployer where applicable, and inform the competent market surveillance authorities and any notified body that issued a certificate for the system.

The hard part is rarely the legal wording. It is speed and proof of sequence. Within a short window, the provider has to show when it first had reason to believe the system was non-conforming, what it decided and why, which parties were told and when, and what was changed or withdrawn. Your incident and ticketing records need to capture those timestamps without reconstruction later. Confirm with your counsel how your organization will judge the moment of "reason to consider", and set who has authority to order a disable or recall before an incident happens, not during one.

Article 21 adds a separate duty: on reasoned request, a provider must give a competent authority all information and documentation demonstrating conformity, in an official EU language the authority can easily understand, and must give access to automatically generated logs under its control. Information obtained is subject to the confidentiality rules of Article 78. Prepare a request-handling procedure now: who receives the request, how it is logged, how translations are produced and who signs off on what is released. Open-source case and helpdesk tools can hold those records, but the content must come from your own technical file and logs.

Which providers, roles and systems AI Act Article 20 corrective actions reach

Article 20 duties fall on the provider of a high-risk system, wherever it is established, and reach a chain of parties the provider must inform. Who carries the duty, which systems are in scope and a few scoping facts decide who must be told, who investigates and which authority receives the report.

The provider that carries the duty

Article 20 binds the provider, meaning the party that develops a high-risk system or has it developed and places it on the market or puts it into service under its own name. Ownership of the duty does not move to the company that deploys or integrates the system unless the roles change under Article 25. Confirm in writing which legal entity is the provider for each system in your inventory, because that entity signs the corrective action record and answers authority requests under Article 21.

Non-EU providers under Article 2

Article 2 applies the Act to non-EU providers whose AI output is used in the EU, so a provider established outside the Union can owe Article 20 duties. Such a provider must also appoint an EU authorised representative under Article 22, and that representative is one of the parties that must be informed when a system is withdrawn or recalled. Check whether your output reaches EU users, and map the contact chain for notices before a problem occurs.

Parties the provider must inform

Article 20(1) requires the provider to inform distributors and, where applicable, deployers, the authorised representative and importers when it takes corrective action on a non-conforming system. Each of these parties needs a named contact, a notice route and a record of delivery. Gaps in this distribution list are a common reason a corrective action is documented but not actually communicated, so keep the list current with every contract that moves the system through the value chain.

Annex III and Annex I systems on the market

Article 20 reaches high-risk systems under both routes: Annex III use cases such as employment, credit scoring or education, and Annex I products covered by sectoral Union harmonisation law. The duty applies to systems that are placed on the market or put into service, so a system still in internal testing sits outside the corrective action trigger. Dates matter for planning: as amended in 2026, Annex III high-risk rules apply from 2 December 2027 and Annex I product rules from 2 August 2028.

Notified body certificates change the notice list

If a notified body issued a certificate for the system, Article 20(2) requires the provider to inform that notified body when the system presents a risk under Article 79(1). Systems assessed under internal control, which covers most Annex III systems, have no certificate-holding body to notify, so the notice list is shorter. Confirm the conformity assessment route for each system with the Article 43 record before you draft the notification plan, since the route determines which parties must be contacted.

Deployer reporting and the investigation duty

When a system presents a risk under Article 79(1), the provider must investigate the causes immediately and do so with the reporting deployer where one is involved. A deployer that reports a risk therefore starts a joint fact-finding exercise, not a one-way complaint. Define in the deployer agreement who collects logs, who runs the investigation and who signs the findings, because these roles decide who holds the evidence that Article 21 may require the provider to produce.

Own-model systems and the 2026 authority split

Under Article 75(1) as amended in 2026, the AI Office is exclusively competent for AI systems built on a provider's own general-purpose model, and for AI in very large online platforms and search engines. Other high-risk systems are overseen by national market surveillance authorities. Establish early whether a system depends on your own general-purpose model, because that fact determines which authority receives the Article 20(2) notice and the Article 21 documentation requests.

How a provider runs a corrective action from first signal to closure

This sequence takes a high-risk AI system from the first sign of non-conformity or risk to a documented, verified closure. Each step produces a record that shows an assessor the provider acted promptly, informed the right parties and fixed the cause.

Log the trigger and classify it
Open a corrective action case as soon as the provider considers, or has reason to consider, that a high-risk system is non-conforming. Record the source of the signal, such as a internal test, a customer complaint, a post-market monitoring finding or a serious incident report, and the date it was received. Decide in writing whether the trigger is non-conformity under Article 20(1) or a risk under Article 79(1), since the second route adds investigation and authority notification duties. The output is a dated triage decision signed by a named accountable owner, held in your ticketing or case system.
Contain the system and choose the action
Under Article 20(1), bring the system into conformity, or withdraw, disable or recall it. Choose the action that matches the risk, record the reasons and the scope affected, including the versions, deployed instances and markets involved. Confirm with engineering that the action has taken effect, for example by checking that a disabled endpoint no longer serves outputs. The output is a containment record with the chosen action, the instances affected and evidence that the action was executed.
Notify distributors, deployers, importers and the representative
Inform distributors and, where applicable, deployers, the authorised representative and importers that the system is being corrected, withdrawn, disabled or recalled. Use a written notice that states the non-conformity, the required action and the contact point. Keep a notification log with recipient, channel, date, and acknowledgement. Where a party does not acknowledge the notice, record the follow-up attempts. The output is a notification log that shows every required party was told and when.
Investigate the root cause
Where the system presents a risk under Article 79(1), investigate its causes immediately, working with the reporting deployer where applicable. Reconstruct the timeline from the automatically generated logs under your control, the data and model versions, the test records and the quality management records. Separate the direct trigger from contributing causes such as data quality, design choices or gaps in human oversight instructions. The output is a root-cause report with evidence references that a reviewer can follow back to source records.
Inform market surveillance authorities and the notified body
Inform the competent market surveillance authorities for the system's markets, and any notified body that issued a certificate for it, once the risk is confirmed. Give the facts known at that point, the containment action taken and the investigation status. Update the notice as the investigation progresses. Confirm with your legal or compliance lead which authorities apply, since the answer depends on where the system is placed on the market. The output is a dated authority and notified body notification file with copies of what was sent and any replies received.
Correct the system and verify the fix
Implement the corrective change in the system, its documentation and its quality management processes, then test that the fix resolves the root cause and does not introduce a new non-conformity. Update the technical documentation and risk management records, and roll the change out to all affected instances. Record who approved the change and the test results. The output is a verification report that links the root cause to the specific change and to the test evidence that shows it works.
Close the case and file the records
Close the case only when the containment, notifications, investigation, authority communication and verified correction are all recorded and reviewed. Confirm that affected parties have acknowledged the final outcome and that any follow-up requests have been answered. Store the complete case file where it can be retrieved for authority requests under Article 21, which asks for documentation in an official EU language the authority can easily understand. The output is a signed closure record with the full case file indexed and retained.

How providers answer authority requests for documentation and logs under Article 21

Article 21 is a separate duty from Article 20. Article 20 covers what a provider does on its own initiative when it finds a high-risk system non-conforming or risky. Article 21 applies when a competent authority asks. On a reasoned request, the provider must hand over all information and documentation that demonstrates the system conforms, and it must do so in an official EU language the authority can easily understand. The request arrives on the authority's timetable, so the provider's documentation, translations and log exports need to be ready before the request is made. A provider that has to start translating its technical file or writing an export script after the letter arrives has little room to meet the authority's deadline.

The second duty is access to logs. Under Article 21(2), the provider must give authorities access to the automatically generated logs that remain under its control. Logs are only useful if the provider can find them, filter them to the relevant period and version, and show their integrity. Decide now which log stores fall under the provider's control, who can export them, and in what format they will be delivered. Test the export on a sample case so the team knows how long it takes. Where logs sit in a self-hosted platform, confirm with the platform team that retention and access controls match what Article 19 requires.

Article 21(3) makes the information obtained subject to the confidentiality rules of Article 78. The provider should therefore mark what it sends, limit who on the team can prepare the response, and record each disclosure. Ask counsel which EU language and file format each relevant market surveillance authority expects, and whether a translation must be certified. Write these answers into the response procedure now, with named owners for documentation, translation, log extraction and legal review. The aim is a response that can be assembled from prepared material rather than built from scratch under pressure.

How an assessor tests Article 20 and Article 21 corrective actions

This table compares each Article 20 and Article 21 duty by how an independent assessor or authority samples it, the evidence requested and the findings that appear most often. Read each row as a sampling plan: the assessor picks real corrective events and requests the records behind them, so the records must exist for every event, not only for the ones the provider chose to show.

Duty	Test approach and evidence requested	Common findings
Corrective action decision record	Assessor samples non-conformity events and asks for the dated decision to bring into conformity, withdraw, disable or recall, with the reasoning and the person who approved it.	Decisions recorded only as ticket closures with no reasoning; no timestamp showing action was immediate after the provider had reason to consider the system non-conforming.
Notification trail to distributors, deployers, importers and authorised representative	Assessor traces each sampled event to outgoing notices, checks recipients against the supply chain record, and compares send dates with the decision date.	Notices sent to some parties but not all; no record of the importer or authorised representative; notices sent weeks after the decision.
Notification to market surveillance authorities and notified bodies	Where the system presents a risk under Article 79(1), assessor asks for the authority notice, the list of notified bodies that issued a certificate, and proof each was informed.	No check of whether a certificate exists for the system; notified body omitted; authority notice lacks the causes of the risk.
Root-cause investigation for risk cases	Assessor asks for the investigation file, the start time, the involvement of the reporting deployer, and evidence that the causes were identified and recorded.	Investigation opened but not started immediately; deployer not engaged; closed with a cause that does not match the logs or test results.
Response to an Article 21 request: language and completeness	Assessor issues a reasoned request and checks the response for conformity documentation in an official EU language the authority can easily understand, against a list of required items.	Documents supplied in English only without a usable translation; missing sections; response assembled after the deadline the authority set.
Response to an Article 21 request: log access	Assessor checks that automatically generated logs under the provider's control were provided in a readable, complete and time-bounded extract, with the method of export documented.	Logs held by a hosting or cloud layer the provider does not control, with no explanation; partial log exports; no record of who ran the export.
Response to an Article 21 request: confidentiality handling	Assessor reviews how information was marked, who had access, and whether handling followed the confidentiality rules that apply under Article 78 and Article 21(3).	No classification of the material supplied; shared with third parties without a record; confidentiality marking applied inconsistently.

Evidence that passes an Article 20 and 21 review and how to keep it current

An assessor reviewing Articles 20 and 21 will look for proof that corrective action happened fast, that the right parties were told, and that authority requests were answered accurately. Each artifact below supports one of those tests, and each needs a routine that keeps it accurate between audits.

Corrective action procedure with decision thresholds

This written procedure sets out when the provider must bring a high-risk system into conformity, withdraw, disable or recall it under Article 20(1). It should define who decides, which signals trigger a review, and how fast each step must start. Check that thresholds are written as observable conditions, not judgment calls. Keep it current by running a tabletop exercise with engineering, legal and the quality function at least once per year and after any change to the system's risk profile.

Timestamped incident and case record

A case record shows when a non-conformity or risk was first considered, who reviewed it, and what was done at each step. Assessors compare these timestamps against the requirement to act immediately, so gaps between detection and first action need a written explanation. A case management tool such as DFIR-IRIS can hold assets, tasks and evidence in one record with a full audit trail. Confirm that edits to closed cases are logged and that the clock on each case cannot be silently reset.

Notification register by recipient class

Article 20 names several recipients: distributors, deployers where applicable, the authorised representative, importers, market surveillance authorities and any notified body that issued a certificate. The register should list each class, the contact, the channel used, the date sent and the content sent. Review it after every system change, change of distributor or change of notified body, because a stale contact list is a common reason notices go astray. Ask the vendor or your own legal team to confirm which recipients apply to your product chain.

Root-cause investigation report

Where a system presents a risk under Article 79(1), Article 20(2) requires an immediate investigation of causes, carried out with the reporting deployer where applicable. The report should separate facts, hypotheses tested, the root cause, affected populations and the fix verified after release. Keep original logs and evidence unaltered during the investigation. Refresh the report template after each incident and file lessons into the quality management system so the next investigation starts from a tested method.

Request-handling procedure with translation and log extraction

Article 21(1) requires documentation demonstrating conformity to be provided on reasoned request, in an official EU language the authority can easily understand. Article 21(2) requires access to logs under the provider's control. The procedure should assign an owner, set a response path for translation, and define how logs are extracted with integrity checks. Confirm with counsel which languages your markets require and test the procedure with a mock request each year.

Access and confidentiality record for released information

Article 21(3) subjects information obtained by authorities to the confidentiality rules of Article 78, so the provider should record what it released, to whom, under which request and with which markings. This record shows that disclosures were limited to what was asked and that sensitive material such as trade secrets was flagged. Review access permissions to the request folder quarterly and after staff changes, and record each release in the same ticketing or case system used for other authority contacts.

What meeting Article 20 and 21 costs in money and effort

This table lists the cost components of meeting Articles 20 and 21, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote so that licence spend, build effort and ongoing upkeep are priced separately. No figures are stated because none are supplied for this topic.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Tooling and licences	Software vendors or none for self-hosted open source	Licences recur, open-source tooling carries no licence fee	Number of tools in scope; self-hosting removes licence spend but not hosting or administration
Engineering to build logging and case tracking	Implementation partner or internal platform team	One-time build, then recurring upkeep	Number of high-risk systems, log sources and integrations with SIEM, ticketing and case tools
Legal review of notification templates	External counsel or internal legal	One-time for templates, recurring on each change	Number of authorities and jurisdictions, and how often guidance or templates change
Translation into an official EU language	Certified translators or internal bilingual staff	Recurring per document update	Volume of technical documentation, number of languages and frequency of revisions
External review or testing of corrective processes	Independent reviewer or security testing provider	Periodic, often tied to a release or incident	System criticality, change frequency and whether the review covers the full chain of notification
Auditor sampling and evidence requests	Independent auditor or assessor	Per assessment cycle	Number of systems sampled, quality of case records and how quickly logs can be produced
Distributor and deployer coordination	Internal staff, legal or partner time	Recurring with each new distributor, deployer or importer	Count of downstream parties, contract terms and how notifications are routed
Log retention and storage	Cloud or data center provider, or internal infrastructure	Recurring	Log volume, retention period under the provider's control and the need for fast retrieval

Which self-hosted open-source tools support Article 20 and 21 evidence

Articles 20 and 21 generate three kinds of record: corrective action and recall decisions, notifications to authorities and partners, and documentation and log access produced on request. The four tools below each cover one of these records, but none of them is certified for AI Act compliance and none replaces the provider's own quality management system. Confirm fit with your own environment before you rely on them.

Case records for investigations

DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. Its timeline view can document how a non-conforming or risk-presenting system was investigated under Article 20(2). Evidence entries are logged with SHA-256 verification and chain of custody, which helps show what was collected and when. Check whether your investigation procedure fits the case model before you adopt it.

Corrective action tickets and changes

The GLPI Assistance module lets teams create, follow and process tickets, problems and changes following ITIL practices. A corrective action such as withdrawal, disabling or recall can be tracked as a change with an owner, a status history and a closure record. Use it to show that corrective steps were taken and completed. Confirm that your change approval workflow matches the decision rights in your quality management system.

Notification log for authorities

Zammad consolidates customer communication from email, chat, telephone and social media into one ticket system. Used as a notification log, it can hold the dated record of messages to distributors, deployers, importers, the authorised representative and market surveillance authorities. A complete log supports proof of duty of information. Confirm that your retention settings keep notification records for the period your legal team requires.

Framework assessments and evidence mapping

CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, NIS2 and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. It can track the evidence behind Article 21 requests, such as documentation and log access, alongside controls from other frameworks you already follow. Note that the mapping is a tool feature, not a legal determination of AI Act equivalence. Verify any AI Act content in the tool against the regulation text yourself, since none is supplied as a ready mapping.

Who does what: the provider's team, an implementation partner and the auditor

The provider owns every decision that Articles 20 and 21 place on it. Someone with authority inside the organization must decide whether a high-risk system is non-conforming, whether it presents a risk under Article 79(1), whether it is brought into conformity, withdrawn, disabled or recalled, and who is told. The same owners sign the notifications to distributors, importers, deployers, the authorised representative, market surveillance authorities and any notified body, and they take the legal positions and the answers given to authorities. These calls cannot be delegated to a vendor, because the organization is the party the authority will hold to account.

Conformity decisions: A named accountable owner records why the system is or is not considered non-conforming, with the date and the information relied on.
Withdrawal and recall authority: The owner who can stop distribution or disable the system is named in advance, with a documented path to do so quickly.
Notifications and legal positions: Legal and compliance sign the wording of each notice and every statement to an authority.
Answers to authority requests: The provider decides what documentation is supplied in an official EU language, and under what confidentiality terms.

Confirm with your legal counsel which internal role holds each of these decisions and whether your contracts with importers, distributors and deployers already set out notification duties.

Questions buyers ask about Article 20 and 21 effort, timing and outside help

How much effort does preparing an Article 20 corrective action take?

The effort depends less on the act of withdrawing or recalling a system than on whether the provider can do it quickly. Article 20(1) requires a provider that considers, or has reason to consider, a high-risk system non-conforming to act immediately, so the work is front-loaded into preparation: a documented procedure, a named owner, a list of every distributor, importer, deployer and authorised representative to notify, and a tested way to disable or pull a system from each deployment. Most of the cost is one-time design work, with recurring effort in keeping contact lists and version records current. Ask any partner to scope the procedure, the notification register and a tabletop exercise as separate deliverables.

Can a provider handle Article 20 and 21 without outside help?

Yes, a provider can own these duties internally, because the Act places them on the provider, not on a consultant. Outside help is typically useful for preparing the procedure, building the traceable link between a non-conformity, the decision taken and the notifications sent, and testing the process before an incident. An implementation partner can prepare systems, logs and evidence, but it cannot decide that a system conforms, and it cannot issue reports. Independent auditors and certification bodies handle the independent assessment side. Decide early which tasks stay in-house, especially the legal judgment about whether a system is non-conforming.

What does Article 20 require from engineering and legal teams?

Engineering owns the technical ability to act, and legal owns the judgment and the notifications. Engineering needs to show it can bring a system into conformity, withdraw it, disable it or recall it, and that it can trace which versions are deployed where. Legal and compliance need to define the threshold for when a provider has reason to consider a system non-conforming, decide which parties must be informed, and approve the wording of those notices. Where a system presents a risk under Article 79(1), Article 20(2) adds a duty to investigate the causes immediately, so engineering must be able to preserve evidence while the investigation runs. Agree these responsibilities in writing before an incident.

How fast must a corrective action move in practice?

Article 20 uses the word immediately, and the Act does not set a number of hours or days for corrective action under this article. Treat immediately as the design target: the procedure should let a responsible person decide and start containment within a time the organization can defend to a regulator. Serious incident reporting under Article 73 has its own deadlines, which a separate page covers, so do not assume they apply here. Confirm with counsel how your national market surveillance authority reads the word in practice, and record the time from first awareness to containment in every case so you can show what happened.

What changes for non-EU providers and importers under Articles 20 and 21?

The core duties do not change: a non-EU provider placing a high-risk system on the EU market must still take corrective action, inform the parties in the value chain and answer authority requests. The practical difference is who receives the information. Article 20 names importers and the authorised representative, so a non-EU provider must have working contact channels with its EU importer and its appointed representative, and the representative must be able to produce documentation quickly. Confirm the mandate, the contact chain and the language of documents before you need them. Importers have their own duties under Article 23, so agree who does what in the contract.

What does an authority request under Article 21 involve day to day?

An authority request under Article 21 usually means assembling documentation that shows conformity, giving access to automatically generated logs under the provider's control, and answering in an official EU language the authority can easily understand. Article 21(3) applies the confidentiality rules of Article 78 to what the authority receives. Practically, teams need an indexed evidence store, a log retrieval process that does not alter records, and a named person who handles correspondence. Self-hosted helpdesk and case tools can record each request, track deadlines and preserve chain of custody. Ask any implementation partner to demonstrate a sample request end to end before the first real one.

How DeployOpen prepares corrective action and authority response evidence

DeployOpen works with the provider's own team to prepare the systems, records and evidence needed to act on non-conforming or risky high-risk AI systems and to answer authority requests. The provider keeps ownership of its decisions, its legal position and its communications with authorities, while DeployOpen implements the self-hosted tooling that makes those steps traceable.

How we scope

Agree a written scope that names the high-risk systems, the teams that hold corrective action authority, and the authorities and notified bodies the provider must contact.
Map the provider's existing incident, complaint and change processes to the Article 20 and Article 21 steps they must trigger.
Confirm with the provider's counsel which information already exists, where logs sit under provider control, and which language requests must be answered in.

How we build

Configure a case management platform so each non-conformity or risk investigation is recorded with assets, tasks, evidence and a full audit trail.
Set up a ticketing workflow for corrective actions, withdrawal, disablement and recall tasks, with owners, status tracking and change records.
Prepare a documented request-handling procedure for authority requests, covering documentation retrieval, log export and confidentiality marking under Article 78.

How we hand over

Deliver a written runbook that sets out each trigger, decision point and notification step for the provider's staff.
Provide exported case records, evidence logs with SHA-256 verification and chain-of-custody entries, and generated investigation reports.
Hand over the configuration, access model and test records so the provider's team can operate and audit the workflow without DeployOpen.

How we support

Run a walkthrough of a tabletop scenario, such as an illustrative recall decision, so the provider's team can rehearse the steps.
Offer ongoing support, upgrades and testing as a retainer after handover, when the scope calls for it.
Confirm with the provider's auditor or competent authority which documents and formats they expect, since DeployOpen prepares evidence but does not issue reports or certifications.