Do you need to recertify after an AI agent incident?

Why this question comes up more than operators expect

Every certified agent will eventually be involved in some kind of incident. Article 73's serious incident reporting obligation attaches to the high risk regime, which for Annex III systems applies from 2 December 2027 after the AI Omnibus entered into force on 27 July 2026. Operators preparing for that date are already logging and escalating incidents formally rather than handling failures informally without a documented trail. As incident volume rises, the question this article addresses rises with it: if a certified agent fails, does that failure retroactively undermine the certification, and does the operator need to go back through assessment.

The honest answer requires separating two things that get conflated in the moment an incident happens. The first is whether the certification's underlying evaluation of the system and its governance was accurate. The second is whether an incident occurred at all. These are not the same question, and confusing them leads operators either to over-react, treating every incident as a certification failure, or to under-react, assuming certification means incidents cannot happen.

What certification actually claims

The Agent Certified methodology, described in full at methodology.html, scores a system across seven dimensions: trust and transparency, context and data governance, distribution control, product and performance reliability, governance, AI integration, and autonomy. The score is a structured judgement, made at a point in time, about the maturity of the system's design and the governance around it. It is not, and no serious certification framework claims to be, a warranty that the certified system will never produce a harmful output. AIUC-1, the closest US analogue, makes the same distinction explicit: its 5,000-plus adversarial simulations test resilience, not guarantee perfection.

What certification does claim, specifically, is that the governance dimension includes a functioning incident response process, that the trust and transparency dimension includes appropriate human oversight, and that the autonomy dimension reflects an honest account of what the system can do without human review. If an incident occurs and the operator's documented process catches it, contains it, and resolves it within the escalation path the certification evaluated, that sequence of events is the certification working as designed, not evidence against it.

The three conditions that actually trigger recertification

Three specific situations move an incident from a routine event into a recertification trigger, and the distinction matters because each implies a different underlying problem.

An undisclosed material change. If the system that caused the incident is not, in a meaningful sense, the same system that was certified, because the underlying model was swapped, the scope was extended, or a new tool integration was added without updating the certification file, the original score no longer describes the deployed system. This is the clearest and least ambiguous trigger, and it mirrors the logic covered in does certification transfer if you switch vendors on this site: certification attaches to a described system, not to a company name.

A control that failed when tested by the real incident. If the certification scored human oversight as present and functioning, and the incident reveals that the named reviewer was not actually monitoring outputs, or that the escalation path described in the operator file was never exercised in practice, the incident has falsified a specific finding in the original assessment. This is different from the system simply making an error; it is the governance layer around the system not matching what was represented.

A failure mode outside the assessed scope. Certification evaluates the system against defined use cases and a defined autonomy envelope, covered in depth in the autonomy envelope dimension guide on this site. An incident arising from the agent operating outside that envelope, for example taking an action category the original assessment did not evaluate because the operator had not deployed the agent for that purpose at the time, means the certification simply never covered the scenario that produced the incident, and the deployment has moved beyond what was certified.

Outside these three conditions, an incident that falls within the scope, the model, and the oversight structure the certification already evaluated, and that the operator's own documented process handled as designed, does not require recertification. It requires the incident report the operator's protocol already calls for, and, where the Article 73 threshold is met, notification to the relevant market surveillance authority.

Incident report versus recertification review

These are different documents built for different audiences and different purposes, and conflating them wastes effort in both directions. The incident report is internal-facing and regulator-facing: what happened, who was affected, what was done in response, and, where required, formal notification under Article 73 of Regulation (EU) 2024/1689. It draws on the same evidence discipline covered in what certification evidence deployers need now enforcement is live, and every operator, certified or not, needs this document for every qualifying incident.

A recertification review is a distinct, independent re-assessment by Agent Certified, triggered specifically when one of the three conditions above is present. It asks a narrower and more specific question than the original assessment did: given what the incident revealed, does the previously issued score still hold. In the large majority of cases, the review does not repeat all seven dimensions. It focuses on the dimension and the specific control the incident implicates, expanding to a fuller review only where the root cause turns out to be a governance gap that plausibly affects other dimensions as well, rather than an isolated control failure.

What a recertification review actually needs

Where a review is triggered, four categories of evidence make it efficient rather than a repeat of the original intake process from scratch.

The incident timeline and root cause. A clear account of what happened, when it was detected, and what the underlying cause was determined to be, distinct from the narrative account written for regulatory notification, though the two will overlap substantially.

The specific control or dimension implicated. A mapping between the incident's root cause and the specific element of the original seven-dimension assessment it calls into question, so the review can focus rather than starting from a blank evaluation.

Remediation already applied. What has changed since the incident, whether that is a new oversight assignment, a scope restriction, or a technical control added to prevent recurrence. A review that finds credible remediation already in place typically resolves faster and with a smaller score impact than one where the operator has not yet acted.

Confirmation of scope and configuration stability. Whether the certified system's scope, underlying model, or deployment configuration has changed since the original assessment, which determines whether the review is a narrow control re-check or effectively a fresh certification against a materially different system.

Operators who maintain the Article 26 operator file as an ongoing practice, rather than a one-time document produced at deployment, generally find this evidence already exists in usable form when an incident occurs, which is the same discipline this site has consistently recommended independent of any specific incident: the Agent Certified intake process is far faster against a maintained file than against one assembled for the first time under incident pressure.