Corrective Actions a Provider Must Take When a High-Risk AI System Stops Conforming Under the EU AI Act

What triggers the duty and what the provider can do

The trigger is knowledge-based. The provider does not need a formal finding from an authority. If it 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, the obligation to act applies. A post-market monitoring signal, a deployer report or an internal test result can each start the clock.

The Regulation lists four responses: take the corrective actions needed to bring the system into conformity, withdraw it, disable it, or recall it. They are framed as alternatives, to be used 'as appropriate', and the action must be taken immediately. The text does not draw fine distinctions between withdrawal, disabling and recall, so internal procedures should not claim distinctions the Regulation does not make. What a compliance function can do is require a documented decision for each affected system: which response was chosen, why, by whom and when.

The consequences of inaction are concrete. If adequate corrective action is not taken within the applicable period, the market surveillance authority must take appropriate provisional measures to prohibit or restrict the system, or to withdraw or recall it. A provider that does not bring the system into compliance in time is also exposed to fines under Article 99.

Who must be told, and what they must be told

There are two distinct notification audiences. The first is the supply chain. The provider must inform the distributors of the system concerned and, where applicable, deployers, the authorised representative and importers. This duty attaches to non-conformity itself, whether or not a regulator is involved.

The second is the authorities. Where the system presents a risk within the meaning of Article 79(1) and the provider becomes aware of it, the provider must inform the competent market surveillance authorities and, where applicable, the notified body. The report must cover, in particular, the nature of the non-compliance and any relevant corrective action taken. Serious incidents carry a separate reporting duty to the market surveillance authorities of the Member State where the incident occurred.

The practical implication is that notification routes must exist before they are needed. A current list of distributors, deployers, importers and the authorised representative, with a named owner and a tested channel for each, is a precondition for acting immediately. The same applies to the authority-facing contacts.

Evidence, documentation and retention

Authorities will assess both whether the provider acted and how quickly. For ten years after the system is placed on the market or put into service, the provider must keep documentation at the disposal of national competent authorities. That includes documentation on the quality management system referred to in Article 17. The corrective-action decision record, the notification trail and the investigation findings belong in that file.

Logs are covered separately. Providers must keep the logs referred to in Article 12(1) that the system generates automatically, to the extent those logs are under their control. Retention must suit the intended purpose and be at least six months, unless Union or national law, notably on personal data protection, provides otherwise. Two points follow. First, a provider should know precisely which logs it controls and which sit only with deployers. Second, retention periods should be checked against any longer legal requirement.

The period between the onset of non-conformity and the completed corrective action is the hardest to evidence. A provider needs to show what the system did during that window, not only that a fix was eventually shipped. Post-market monitoring outputs and automatically generated logs are the natural inputs.

Where runtime enforcement fits, and where it does not

Most of this process is organizational. Deciding that a system is non-conforming, choosing between conforming, withdrawing, disabling or recalling, notifying parties, investigating causes and cooperating with authorities are duties of the provider. No tool satisfies them alone, and runtime enforcement does not restore conformity by itself.

What runtime enforcement can offer is interim containment while remediation proceeds. Trussed enforces policy in the execution path, at the level of individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. During a non-conformity window, a provider could use that to constrain what a system is permitted to do per interaction while a fix is built. Whether such constraints amount to 'disabling' the system under the Regulation is a legal judgment for the provider and its counsel. They are best documented internally as interim containment support, not as a regulatory requirement.

The same enforcement produces audit-ready evidence mapped to the EU AI Act, recording what the system was allowed to do and what happened at each decision point. This can supplement the provider's own logs and post-market monitoring records as evidence of system behaviour during the window. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, which matters when retention must be reconciled with data protection law. It does not provide model lineage, dataset provenance or end-to-end workflow tracing, and it does not replace the notification and investigation duties above.