AIG-043 AI Non-Conformity Corrective Action and Authority Cooperation
Description
Where a deployed AI system is found not to conform with the requirements applicable to it, a case record exists naming the corrective action taken from bringing the system into conformity, withdrawing it, disabling it and recalling it, the date each action took effect and the investigation of the causes, carried out with the deployer that reported it where there was one. The same record shows which of the distributors, deployers, importers, authorised representatives and certifying bodies for that system were informed of the non-conformity and of the action, with the date each was informed. Where the system presents a risk to health, safety or fundamental rights, the record also shows that the competent market surveillance authority was informed of the nature of the non-conformity and of the action taken. A register of reasoned requests from competent authorities records, for each request, the information and documentation demonstrating conformity that was produced, the official language the authority named, the access given to the system's automatically generated logs and the date of each. The route by which those logs are made available to an authority is documented and can be exercised without altering them.
Rationale
A finding of non-conformity arrives by several routes: post-market monitoring, a deployer's report, an authority's own finding or an internal review. What is judged afterwards is what followed the finding, which is why the artefact is a case record rather than a procedure. Under the EU AI Act the corrective action set and the duty to inform the distribution chain are Article 20, which also requires the causes to be investigated with the reporting deployer and the market surveillance authority and any certifying body to be informed where the system presents a risk within the meaning of Article 79(1). Cooperation on a reasoned request is Article 21: the conformity file in an official language the Member State indicates and access to the automatically generated logs of Article 12(1) so far as they are under the provider's control. Article 26(12) puts the same cooperation duty on deployers, which is why the request register serves both seats. Article 53(3) puts a wider cooperation duty on a provider of a general-purpose AI model, covering participation in an authority-led investigation as well as responding to information requests; only the request half is here. The GPAI seat belongs to the GPAI provider bundle. Two practical constraints decide whether this control passes. The notification list has to be current before it is needed, because the duty is measured in hours rather than weeks. The language condition is the one most often missed: decide in advance whether translation is held ready or procured against a deadline. For a service provider, disabling is usually a feature flag or a model rollback and needs a tested route rather than an improvised one. Provider seat (ADR-031), with the Article 26(12) deployer cooperation duty satisfied by the same register.
Applicability (9 profiles)
Condition: ai_risk_class in high-risk-annex-iii
Art.20 and Art.21 bind providers of high-risk systems. The Art.53.5 cooperation duty on general-purpose model providers belongs to the gpai-model-provider profile.
Condition: ai_risk_class in high-risk-annex-iii
Corrective action and the authority request register are the provider's (Art.20, 21). The deployer reports non-conformity to the provider (Art.26.4), acts on a withdrawal, disablement or recall notice and produces the logs it holds to a competent authority on request.
Art.53(3) puts a cooperation duty on a general-purpose model provider: responding to information requests and taking part in an authority-led investigation. The request register here serves it; the mapping note records that the investigation half is not written into the control.
The base makes this conditional on the risk class. Here the class is settled by the profile's facets. Art.20 fixes the trigger at the point the provider considers or has reason to consider a system it placed on the market is not in conformity, requires the corrective action immediately and names who is told, the distributors and, where applicable, the deployers, the authorised representative and the importers; where the system presents a risk within the meaning of Art.79(1) the market surveillance authorities of the Member States where it was made available are told as well. Art.21 fixes the content of the answer to a reasoned request: all the information and documentation needed to demonstrate conformity with Section 2, in an official Union language the Member State concerned indicates, plus access to the Art.12(1) automatically generated logs to the extent they are under the provider's control, with what the authority receives held under the Art.78 confidentiality obligations. The language requirement is the item most often missed, because it makes a conformity file a translation problem. The Art.53(3) arm for general-purpose model providers stays with gpai-model-provider.
The base conditions this row on the risk class; here the class is settled by the profile's facets, so the row is required and the condition goes. Corrective action and the authority request register under Art.20 and Art.21 stay the provider's. Three parts are this seat's and bind both of them: non-conformity is reported to the provider under Art.26(5), a withdrawal, disablement or recall notice is acted on and under Art.26(12) the logs the deployer holds are produced to a competent authority on request without being altered. The route by which those logs are produced is documented, because at a public body the request can arrive through its own supervisory chain as well as from the market surveillance authority.
Condition: ai_risk_class in high-risk-annex-iii
Art.20 and Art.21 bind providers of high-risk systems. The Art.53.5 cooperation duty on general-purpose model providers belongs to the gpai-model-provider profile.
Condition: ai_risk_class in high-risk-annex-iii
Art.20 and Art.21 bind providers of high-risk systems. The Art.53.5 cooperation duty on general-purpose model providers belongs to the gpai-model-provider profile.
Condition: ai_risk_class in high-risk-annex-iii
Art.20 and Art.21 bind providers of high-risk systems. The Art.53.5 cooperation duty on general-purpose model providers belongs to the gpai-model-provider profile.
Condition: ai_risk_class in high-risk-annex-iii
Art.20 and Art.21 bind providers of high-risk systems. The Art.53.5 cooperation duty on general-purpose model providers belongs to the gpai-model-provider profile.
Framework Mappings (6)
| EU-AI-Art.16.6 | Provider Obligations — Corrective Action and Authority Cooperation | full |
| EU-AI-Art.20 | Provider Obligations — Corrective Actions and Duty of Information | full |
| EU-AI-Art.21 | Provider Obligations — Cooperation with Competent Authorities | full |
| EU-AI-Art.53.5 | GPAI Model Obligations — Regulatory Cooperation | partial |
| COP-S-4.2 | Proceeding or not proceeding based on systemic risk acceptance determination | informative |
| COP-S-9 | Serious incident reporting | informative |
Evidence (3)
Non-conformity case record for a named AI system, showing the finding, the corrective action taken and the date it took effect, the investigation of the causes and each party informed with the date it was informed.
Example: Non-conformity case NC-2026-002, Claims Triage Engine v4, opened 11 May 2026 on a deployer report, disabled by feature flag the same day and brought into conformity on 2 June 2026, with the notification log at appendix A.
Test: Verify: (1) a case record exists for every non-conformity finding raised in the period, drawn from the monitoring, deployer report and incident triage routes rather than from the corrective action register alone, (2) each record names which of the four corrective actions was taken and the date it took effect, (3) each record carries the investigation of the causes and names the deployer that took part where the finding came from a deployer, (4) each record lists the parties informed against the current distribution list for that system, with a date against each, (5) any case where the system presented a risk to health, safety or fundamental rights shows the notification to the competent market surveillance authority and to any certifying body, (6) a finding closed without one of the four actions carries a recorded reason.
Register of reasoned requests from competent authorities, showing for each request the system it concerned, what was produced, the official language it was produced in, the log access given and the dates.
Example: Authority request register, extract of 30 June 2026, three requests across two systems with the response packs and the language of each.
Test: Verify: (1) every request received in the period appears in the register, cross-checked against the correspondence held by the owner of authority contact named in INC-010, (2) each entry names the documentation produced and resolves to an artefact that still exists, (3) each entry records the official language the authority named and the language the response was produced in, with a recorded reason where the two differ, (4) each entry records whether log access was requested and, where it was, what was given and on what date, (5) the elapsed time from request to response is recorded for each entry, (6) an empty register for the period is corroborated by the correspondence record rather than accepted on assertion.
Walkthrough of the log access route on a named production AI system, producing the automatically generated logs for a stated period to the point at which they would be handed to an authority.
Example: Walkthrough note, 14 August 2026: logs for AI Underwriting Assistant v3 extracted for 1 to 31 July, produced in 40 minutes by the named owner of the route.
Test: Verify: (1) the route is documented and names the role that can run it, (2) the walkthrough produces the logs for the requested period rather than a sample or a dashboard view, (3) the extraction leaves the source logs unchanged, checked against the integrity mechanism in MON-002, (4) the period requested is inside the retention the system's logs are held for, (5) the extraction is itself recorded as an access to the log store, (6) a system in the AI system inventory with no working route is reported as a gap.
Questions (2)
Is there a defined route for handling an AI system found not to conform with the requirements applicable to it?
Answer yes where the route is written down and has an owner, whether or not it has been used. A general product defect or bug process counts only where it names the corrective actions available and the parties outside the organisation who have to be told; Q2 captures which parts are present.
Which of the following does your non-conformity and authority cooperation handling cover?
Options are grouped, the four corrective actions first, then the notification duties, then the authority request route. Tick an option only where the route exists for a named system rather than as a general intention. The two authority request options are the ones an organisation that has never had a request tends to leave untested. They are also the ones with a deadline attached when a request arrives.