AI Risk Mitigation Strategies Under the EU AI Act
How Article 9(5) structures AI risk mitigation: eliminate by design, control, then disclose. Maps bias, drift, and security risks to specific Act controls.
Article 9(5) of Regulation (EU) 2024/1689 sets out an explicit mitigation priority order: first, eliminate or reduce risk through design as far as technically feasible; second, apply adequate mitigation and control measures where risk persists; third, provide information under Article 13 and ensure deployers have the literacy and oversight capacity required by Articles 4 and 14. What follows maps each tier to the technical and organisational controls the Act requires, links them to the five most common AI risk categories, and explains when residual risk is acceptable and how to document that judgment.
The Article 9(5) Mitigation Hierarchy
Article 9(5) draws directly from established product-safety law: risk is first designed out, then controlled, then disclosed. The order matters — you cannot substitute more warnings for less engineering.
Tier 1 — eliminate or reduce by design. At the design and development stage, ask whether the risk can be removed or reduced by technical means: dropping a sensitive input feature, constraining outputs to a bounded set, or narrowing the intended use to exclude high-harm scenarios. "As far as technically feasible" is not an escape clause. Choosing not to eliminate a risk requires documented justification.
Tier 2 — adequate mitigation and control measures. Where risk persists, apply technical controls — data quality governance (Article 10), accuracy, robustness and cybersecurity (Article 15), logging (Article 12) — alongside organisational controls: human oversight (Article 14), a quality management system (Article 17), post-market monitoring (Article 72), and incident reporting (Article 73).
Tier 3 — information and training. Residual risk that survives the first two tiers must be communicated to deployers via the instructions for use (Article 13). Deployers must ensure staff have sufficient AI literacy (Article 4) and that human oversight is actually exercised (Article 14). Issuing documentation without confirming that deployers can act on it does not discharge Tier 3.
Residual Risk: Acceptability and Documentation
Article 9(4) states that residual risk must be consistent with "the generally acknowledged state of the art." This is a comparative standard, not a zero-harm threshold. A credit-scoring model at a regional lender will carry some rate of false rejections; the question is whether the rate, and the error distribution across demographic groups, is within the range achievable by a competent provider using current best practice.
Acceptability must be judged and documented. The Article 11 technical documentation must include residual risk levels, the rationale for accepting them, and the monitoring triggers that would reopen the assessment. A judgment made at launch and never revisited is not compliant with Article 9(1)'s continuous-process requirement. Practical test: if you would be uncomfortable explaining the residual-risk level to the market-surveillance authority, the documentation is not adequate.
Technical Controls
Data quality (Article 10)
Bias, privacy leakage, and distributional shift often originate in training data. Article 10(3) requires training, validation, and testing datasets to be relevant, representative, free from errors, and complete for their intended purpose. Audit data sources for historical bias before training; document demographic coverage gaps; define validation cohorts that mirror the deployment population; maintain a data-lineage record that survives personnel changes. Data quality is a direct mitigation for bias, privacy, and drift — three of the five risk categories in the table below.
Accuracy, robustness, and cybersecurity (Article 15)
Article 15 requires high-risk systems to achieve appropriate accuracy, resilience against errors and inconsistencies (robustness), and protection against adversarial manipulation (cybersecurity). Concretely: test performance across demographic sub-populations before deployment; red-team the model against adversarial inputs and prompt-injection where applicable; implement model-versioning so a compromised or drifted model can be rolled back; monitor for data-poisoning vectors at inference time.
Article 15 testing is not a one-off gate. Results feed back into the ongoing Article 9 cycle.
Logging and traceability (Article 12)
Article 12 requires automatic logging of events relevant to detecting serious incidents and enabling post-market monitoring: reference periods of each use, the reference database used for verification (biometric systems), input data that led to a result, and natural persons involved. Providers retain automatically generated logs under their control for at least six months (Article 19); deployers retain their own logs for at least six months (Article 26).
Logging is both a deterrent against misuse and the evidentiary foundation for Article 73 incident response.
Organisational Controls
Human oversight (Article 14)
Article 14 is not a generic "keep a human in the loop" requirement. It specifies five capabilities that natural persons assigned to oversight must have: understand the system's capabilities and limitations; monitor operation for anomalies; interpret outputs correctly; intervene or override; and decide not to use the system in a given situation.
Those capabilities require active design work — explainability interfaces, confidence scores, override mechanisms, clear handoff protocols. If a deployer cannot realistically exercise oversight because the system is too opaque or the workflow too fast, the system's design is non-compliant.
Quality management system (Article 17)
Article 17 requires a documented quality management system covering all stages from design through post-market monitoring. Minimum elements include: a regulatory compliance strategy; design-control techniques; testing and examination before release; post-market monitoring procedures; incident reporting obligations; and responsibility assignments.
For a 40-person company this is not a consultant-drafted ISO 9001 programme. It is documented procedures, version control, clear ownership, and evidence of actual use — the record that would survive a market-surveillance inspection.
Post-market monitoring (Article 72)
Article 72 requires providers to collect and review performance data from deployed systems throughout their lifetime. The post-market monitoring plan — part of the technical documentation — must specify metrics, data sources, review intervals, and escalation thresholds. Define what "normal" looks like (accuracy band, fairness metrics), instrument the deployment to capture it, set alerts for deviations, and schedule periodic reviews.
Post-market monitoring closes the Article 9 loop: risks identified post-deployment feed back into the risk assessment and may trigger new mitigation measures or, in severe cases, market withdrawal.
Incident response (Article 73)
Article 73 requires providers to report serious incidents to the market-surveillance authority of the member state where the incident occurred. Timelines are strict: 15 days from awareness in general (Article 73(2)); 2 days for widespread infringement or serious and irreversible disruption to critical infrastructure (Article 73(3)); 10 days where a person has died (Article 73(4)). An incomplete initial report is permitted, then completed.
This is a compliance deadline issue. A provider that has not defined what constitutes a serious incident, who classifies it, and how it reaches the reporting team will miss these windows.
Five Common AI Risks Mapped to Controls
| Risk | Root causes | Technical controls | Organisational controls |
|---|---|---|---|
| Bias / discrimination | Non-representative training data; proxy variables; historical patterns | Art 10 data quality; sub-population accuracy testing (Art 15) | Art 14 oversight with override rights; Art 17 QMS fairness review gate |
| Hallucination / unreliability | Model confidence miscalibration; out-of-distribution inputs | Art 15 accuracy and robustness testing; confidence-score outputs | Art 14 human verification requirement; Art 12 logging of outputs for audit |
| Cybersecurity / adversarial attack | Model inversion; prompt injection; data poisoning | Art 15 adversarial robustness; model-versioning and rollback | Art 17 security review in QMS; Art 73 incident reporting for breaches |
| Model drift | Distribution shift between training and production; concept drift over time | Art 15 ongoing performance monitoring; Art 12 logging | Art 72 post-market monitoring plan; Art 9 continuous reassessment |
| Privacy / re-identification | Training on personal data; inference attacks; output leakage | Art 10 data minimisation and governance; Art 15 privacy-preserving design | Art 14 access controls; GDPR Article 35 DPIA where required |
The Article 9(5) hierarchy applies to each row: ask first whether the risk can be designed out (e.g. remove the proxy variable; train on synthetic data), then what controls reduce it, then what residual exposure must be disclosed.
How Confir Helps
Confir's risk register uses deterministic, rule-based logic to link each identified risk to the specific controls the Act requires. Log a risk in an employment-screening system and the register maps it to the Article 9(5) mitigation tier, flags the applicable Article 10, 12, 14, 15, or 72 controls, and tracks whether each has been documented. The same intake answers produce the same mapping every time — reproducible, explainable, audit-defensible. The AIGM assessment module prompts you to record the residual-risk acceptability judgment and the monitoring trigger that would reopen it.
Frequently Asked Questions
What does "as far as technically feasible" mean in Article 9(5)?
It is not a blanket permission to skip design-level mitigation. A provider choosing to accept a risk at Tier 1 rather than design it out must document why elimination or reduction was not technically feasible — specific constraints, tradeoffs with system performance, or the current state of the art in the domain. Regulators and notified bodies will scrutinise these justifications; a bare assertion of infeasibility will not hold.
Does Article 9 apply to deployers as well as providers?
Article 9 applies to providers (Article 16). Deployers operate under Article 26: follow the provider's instructions for use, ensure human oversight, monitor performance, and report incidents to the provider and, where required, to the authority. A deployer who substantially modifies a system or repurposes it becomes a provider under Article 25 and inherits the full Article 9 obligation.
When is residual risk acceptable under Article 9(4)?
When it is consistent with the generally acknowledged state of the art and has been documented with a reasoned judgment. Acceptability is not self-declared; it is a comparative assessment against what a competent provider using current methods could achieve. The judgment must sit in the technical documentation, be accessible to the market-surveillance authority, and be revisited when post-market monitoring data indicates material change.
How do the Article 73 incident reporting timelines work?
The general deadline is 15 days from awareness of a serious incident (Article 73(2)). Where there is a widespread infringement or serious and irreversible disruption of critical infrastructure, the window is 2 days (Article 73(3)). Where a person has died, it is 10 days (Article 73(4)). An incomplete initial report is permitted under Article 73(5), completed once more information is available. Providers should build the classification and escalation decision into their QMS before they need it.
What is the penalty exposure for failure to maintain an Article 9 risk management system?
Non-compliance with high-risk obligations falls under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Companies that qualify as SMEs or start-ups benefit from Article 99(6), which caps the fine at the lower of the percentage or fixed amount. Penalties under Article 99 apply from 2 August 2025 — the enforcement clock is already running.
Do the high-risk obligations apply from August 2026?
No. Under the Digital Omnibus agreed in May 2026, the application of high-risk obligations has been deferred. Stand-alone high-risk AI systems in the Annex III categories must comply from 2 December 2027. High-risk AI systems that are safety components of products covered by EU product law (Annex I) must comply from 2 August 2028. The original 2 August 2026 date has been deferred. The compliance window is longer — but the documentation alone takes months to assemble.
What is the difference between Article 9 risk management and a GDPR DPIA?
A GDPR Data Protection Impact Assessment (GDPR Article 35) addresses risks arising from data processing. Article 9 risk management covers health, safety, and fundamental rights risks from the system's behaviour — algorithmic bias, robustness failures, accuracy of decisions — extending well beyond data processing. The two overlap where the AI system processes personal data; a well-structured Article 9 plan can share inputs with a DPIA, but they serve different frameworks and cannot substitute for each other.
Related guides
- Article 9 risk management system requirements
- Article 15 accuracy, robustness and cybersecurity
- Article 6 high-risk AI classification criteria
- risk classification levels framework
- AI risk management implementation software
- risk classification decision tree tool
- EU AI Act compliance checklist
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →