Governance programmes are good at producing findings. An assessment raises eleven, a test raises four, monitoring raises two a month, and an internal audit raises a schedule. Six months later somebody asks how many are closed, and the answer involves a spreadsheet, several definitions of closed, and a long column of items marked accepted.
That column is where most remediation programmes actually fail. Not because acceptance is wrong, but because it has quietly become a backlog state rather than a decision. Nobody chose to accept those risks. They aged into acceptance.
This guide is about closing the loop properly. It covers the four corrective actions the EU AI Act names and the word it attaches to them, why acceptance has to be a decision with an owner and a standard, the mitigation hierarchy most remediation skips, who has to be told, and what closure should actually mean. It sits alongside our guide to AI incident response, which owns the incident path, and this guide covers the ordinary case that is not an incident.
The hierarchy most remediation skips
- 01Eliminate or reduce by designChange the system so the failure cannot occur, or occurs far less often
- 02Mitigation and controlA guardrail, a threshold, a constraint, a second check that runs automatically
- 03Information and trainingDocument the limitation, warn the user, train the reviewer
Findings are cheap, closure is not
The asymmetry is structural. Producing a finding takes one person with a method and some time. Closing it takes engineering capacity owned by someone else, prioritised against their roadmap, with no deadline that anyone outside governance recognises.
So findings accumulate at the rate the assessment programme generates them and close at the rate the business can absorb them, and the gap between those two rates is the backlog. Every governance function discovers this, and the common responses make it worse: more findings, more detailed findings, or a tracker with more fields.
What actually changes the picture is narrowing what counts as a finding, making each one carry a specific required action rather than an observation, and making acceptance expensive enough that it is chosen rather than defaulted into. The AI Act turns out to be unusually helpful on all three, because it describes the loop concretely rather than in principles.
The four actions the Act names
Article 20 covers what a provider must do when a high risk system it has placed on the market is not in conformity. The trigger is low: the provider "considers or has reason to consider" that the system does not conform. Not knows. Has reason to consider.
From there the duty is to "immediately take the necessary corrective actions to bring that system into conformity", or "to withdraw it, to disable it, or to recall it, as appropriate". Four named actions, and a word attached to all of them.
-
Bring it into conformityFix it in place. The default assumption in most internal processes, and the one that takes longest, which is why the other three exist.
-
Withdraw itStop making it available. In an internal context, the equivalent is removing the system from the use it was deployed for while the question is resolved.
-
Disable itTurn it off, or turn off the capability at issue, without removing it. The action most internal processes do not have a defined route for, and often the proportionate one.
-
Recall itReach the copies already out there. In an internal context this maps to the outputs and decisions already produced, which is the part teams forget: a system can be fixed while its past outputs remain in force.
The useful discipline here is the menu, not the law. Most internal remediation processes have exactly one option, which is fix it, and one escalation, which is fix it faster. Having four named actions forces a different question at triage: not how long will the fix take, but what should happen to the system in the meantime. "Disable the feature while we investigate" is frequently the right answer and is rarely on the form.
The last action deserves its own note. Recall maps internally to the question nobody asks: what about the decisions this system already made. If a model was misclassifying applicants for three months, fixing the model does not address the applicants. Whether past outputs need review is a separate decision from whether the system needs fixing, and it should appear as its own item rather than being folded into the fix.
Acceptance is a decision, not a state
Risk acceptance is legitimate and necessary. No system has zero residual risk and a programme that refuses to accept any will simply stop being consulted. The problem is not acceptance. It is acceptance by default.
Article 9 gives a standard worth borrowing regardless of whether the Act applies. It requires that the residual risk of each individual hazard, and the overall residual risk of the system, be judged acceptable. Two features of that are useful.
It is a judgement, which means somebody makes it. A judgement has an author. A backlog state does not. The single highest return change available to most remediation processes is requiring a named person at an appropriate level to accept each residual risk explicitly, with a reason, rather than allowing items to reach acceptance by ageing.
The overall figure is assessed separately. Each hazard's residual risk is judged, and so is the system's overall residual risk. That catches the accumulation problem: twelve individually acceptable acceptances on one system can add up to a system nobody would approve today. Reviewing acceptances per system rather than per finding is what surfaces it.
Article 9 also frames the whole exercise as "a continuous iterative process planned and run throughout the entire lifecycle", requiring regular systematic review and updating. An acceptance is therefore provisional by construction. It should carry a review date, and the review should be a real event rather than a field that expires silently.
The hierarchy most remediation skips
Article 9(5) sets out how risk management measures should work, and the ordering is the interesting part. Measures should eliminate or reduce risk through design where technically feasible, then add mitigation and control measures where the risk cannot be eliminated, then provide information and training to deployers.
That is a hierarchy, and most remediation inverts it. The fastest response to a finding is usually documentation: add a warning to the interface, note the limitation in the user guide, brief the reviewers. Those are the third tier. They are legitimate and they are the weakest of the three, because they transfer the burden to a person who may be busy, inexperienced or absent.
| Tier | What it looks like | Why it ranks where it does |
|---|---|---|
| Eliminate or reduce by design | Change the system so the failure cannot occur, or occurs far less | Does not depend on anyone behaving correctly afterwards. Most expensive, most durable |
| Mitigation and control | Add a guardrail, a threshold, a constraint, a second check that runs automatically | Still operates without human attention, but can be misconfigured or switched off |
| Information and training | Document the limitation, warn the user, train the reviewer | Depends entirely on a person noticing and acting. Cheapest, weakest, and the most common response to a finding |
The practical use of the hierarchy is as a challenge at review. Where a proposed remediation sits in the third tier, the question is whether the first two were considered and rejected, and why. Often they were not considered at all, because the third tier is what the team could do without a roadmap conversation.
Who has to be told
Internal remediation processes tend to treat notification as an afterthought: the finding owner knows, the governance team knows, and anyone else finds out if they ask. Article 20 is explicit in a way that is worth copying.
When corrective action is taken, the provider must inform the distributors of the system, and where applicable the deployers, the authorised representative and the importers. Where the system presents a risk within the meaning of Article 79(1) and the provider becomes aware of it, the duties escalate: the provider must "immediately investigate the causes", in collaboration with the reporting deployer where applicable, inform the market surveillance authorities of the non compliance and of any corrective action taken, and inform the notified body that issued the certificate where applicable.
Translated to an internal programme, that is a notification list keyed to the finding rather than to the team. Who relies on this system's output. Who else deployed the same component. Who signed the approval that this finding contradicts. Who would have to disclose it externally if it got worse. Deciding that list when the finding is raised costs minutes; reconstructing it during an escalation costs a day and usually misses someone.
Note also the phrase "immediately investigate the causes". Investigation and remediation are separate obligations. A programme that jumps to the fix without establishing the cause will fix the instance and leave the class, which is how the same finding appears on three systems over eighteen months.
What closure should mean
-
Every finding carries a required action, not an observation"Input validation is weak" is an observation. "Add length and type validation to the three endpoints listed, or disable free text input on them" is an action somebody can complete and someone else can verify. Findings written as observations are the ones that age.
-
The owner is a person who can authorise the workAssigning a finding to a team is assigning it to nobody. Assigning it to an engineer who cannot change the roadmap produces a finding that is actively worked on and never finished. The owner should be whoever can decide that this gets done.
-
Decide the interim state at triageFor each finding, what happens to the system while the fix is pending: nothing, disable the feature, restrict the population, add a manual check. The four actions in Article 20 are the menu. Leaving this undecided means the default is always nothing.
-
Closure requires verification by someone other than the fixerThe person who did the work is the worst placed to confirm it worked. Verification does not have to be heavy, and it does have to be independent and recorded, because closure without verification is a claim.
-
Re-test against the thing that found itArticle 9 requires testing against "prior defined metrics and probabilistic thresholds". If a finding came from a test, closure means that test now passes, run again, with the result stored. If it came from monitoring, the signal should return to baseline. Closure asserted without the original detector being re-run is unverified.
-
Feed the cause back, not just the fixWhere the investigation found a cause that could affect other systems, that is its own finding against the class. This is the step that reduces future volume, and it is the first one dropped when the backlog is large, which is exactly backwards.
Each of those produces an artefact, and the artefacts are evidence. Our guide to audit ready evidence covers where they need to live so that a closure can be reproduced a year later, which is when somebody will ask.
The trade-offs nobody puts on the slide
Making acceptance expensive slows things down, on purpose. Requiring a named senior acceptance with a reason and a review date adds friction to the path of least resistance. That is the entire point, and it will be experienced as bureaucracy by people who were previously able to let items age. Expect that, and make the acceptance form short so the friction is in the signature rather than the paperwork.
Independent verification costs capacity you do not have. It is the step most often cut, and cutting it converts a remediation programme into a reporting programme. A proportionate compromise is verification scaled to the finding's severity, with sampling at the lower end rather than verification of everything or nothing.
Disabling a feature has a business cost somebody will contest. Having disable as a named option is only useful if the governance function can actually invoke it, which is an authority question rather than a process one. If the answer is that nobody can require a feature to be turned off, that is worth establishing before the first case rather than during it.
Cause analysis competes directly with throughput. Investigating causes finds more findings, which lengthens the backlog before it shortens it. It is the right investment and it looks like the wrong one for a quarter or two, which is a thing to say in advance rather than defend later.
Frequently asked questions
Where this leaves you
The reason remediation programmes stall is rarely that the findings were wrong. It is that a finding is a statement and a closure is a transaction between two teams with different priorities, and nothing in a tracker resolves that asymmetry. The things that do are unglamorous: findings written as required actions, owners who can authorise work, an interim decision taken at triage rather than deferred, verification by somebody else, and acceptance that costs a signature from a person senior enough to feel it.
The Act's contribution here is mostly a vocabulary. Four actions instead of one. Immediately attached to the investigation as well as the fix. A residual risk that somebody judges acceptable, per hazard and overall. A hierarchy that puts design above documentation. None of that is novel as safety engineering, and most AI governance programmes have not yet imported it.
Where a governance platform fits. The work happens in engineering backlogs and the verification happens in test suites. What has no natural home is the thread: which finding came from which assessment against which policy version, what interim action was taken, who accepted what residual risk and until when, what verified the closure, and whether the cause was fed back as its own finding. Holding that across a portfolio, and producing it when an auditor asks how a finding was closed, is what a platform such as Holistic AI is built to carry. The fix happens elsewhere. The register is what shows it finished.
