EU AI Act Art.9 Risk Controls: Implementing Mitigation Measures for High-Risk AI Systems

Post #1465 in the sota.io EU AI Act Risk Management Series (RMS-2026 #3/5)

You have identified your failure modes. You have mapped foreseeable misuse scenarios. Now comes the hard part: implementing controls that actually work — and documenting them in a way that survives conformity assessment.

EU AI Act Art.9 requires high-risk AI system providers to establish risk management measures that are proportionate, documented, and continuously monitored. The August 2, 2026 deadline is approaching. This guide walks you through what "adequate risk controls" look like in practice for SaaS providers building high-risk AI.

What Art.9 Actually Requires from Risk Controls

The EU AI Act's risk management system under Art.9 is iterative and lifecycle-spanning. Risk controls are not a one-time checklist — they are an ongoing programme that must evolve as your system changes and as new risks emerge.

Art.9 requires that your risk management system include appropriate measures to:

• Eliminate or reduce risks to an acceptable level for the intended use
• Implement testing and monitoring to verify controls remain effective
• Communicate residual risks that cannot be eliminated to deployers
• Document all control decisions in your technical documentation (Annex IV)

The key regulatory expectation: controls must be designed before deployment, validated through testing, and updated when the risk profile changes.

The Three-Layer Control Architecture

For SaaS providers, effective Art.9 risk controls operate at three layers. You need all three — any single layer alone will not satisfy regulatory expectations.

Layer 1: Technical Controls (Built-in Safety)

Technical controls are the first line of defence. They must be embedded in the system itself, not tacked on as an afterthought.

Output constraints and guardrails

Your AI system should enforce hard limits on outputs that could cause harm. For a high-risk AI system used in employment decisions, this might mean:

class HighRiskOutputValidator:
    def validate_decision(self, ai_output: dict) -> ValidationResult:
        # Hard constraints — cannot be overridden
        if ai_output.get("confidence") < self.MIN_CONFIDENCE_THRESHOLD:
            return ValidationResult(
                action="REQUIRE_HUMAN_REVIEW",
                reason="Confidence below threshold",
                risk_flag=True
            )
        
        if self.detect_prohibited_attribute_proxy(ai_output):
            return ValidationResult(
                action="BLOCK",
                reason="Potential protected attribute proxy detected",
                risk_flag=True,
                requires_audit_log=True
            )
        
        return ValidationResult(action="PROCEED", risk_flag=False)
    
    def detect_prohibited_attribute_proxy(self, output: dict) -> bool:
        # Statistical parity check across protected group proxies
        return self.fairness_monitor.check_disparate_impact(output)

Input validation and adversarial robustness

High-risk AI systems must be robust to manipulation. Implement:

• Input sanitisation that detects potential adversarial inputs
• Anomaly detection for out-of-distribution queries
• Rate limiting and pattern detection for systematic probing attempts
• Data drift monitoring to catch distribution shift early

Confidence and uncertainty quantification

Your system must communicate its uncertainty. A high-risk AI that returns binary decisions without confidence scores fails the Art.9 requirement for human oversight support (see Art.14).

class UncertaintyQuantifier:
    def predict_with_uncertainty(self, inputs: np.ndarray) -> PredictionResult:
        # Monte Carlo dropout or ensemble methods
        predictions = [self.model(inputs, training=True) for _ in range(self.N_SAMPLES)]
        
        mean_pred = np.mean(predictions, axis=0)
        epistemic_uncertainty = np.var(predictions, axis=0)
        
        return PredictionResult(
            prediction=mean_pred,
            uncertainty=epistemic_uncertainty,
            requires_human_review=(epistemic_uncertainty > self.UNCERTAINTY_THRESHOLD)
        )

Layer 2: Procedural Controls (Human Oversight and Process Gates)

Art.14 of the EU AI Act requires that high-risk AI systems be designed to allow human oversight. Your risk controls must enable — not hinder — this oversight.

Human-in-the-loop gates

Define explicit trigger conditions for mandatory human review:

Decision logging and audit trails

Every decision made by a high-risk AI system must be traceable. Your audit log must capture:

• The input data used (or a reference to it with privacy controls applied)
• The model version and configuration at decision time
• The output and confidence level
• Whether human review was triggered and the outcome
• The timestamp and the identity of any human reviewer

This is not optional. Art.13 (transparency) and Annex IV (technical documentation) both require this traceability.

Escalation and override procedures

Define clear escalation paths in your operational documentation:

# High-Risk AI Escalation Matrix

## Level 1 — Automated Flag
Trigger: Uncertainty > 0.3, or fairness metric outside bounds
Action: Output held, case queued for human review
SLA: Review within 2 business hours
Documentation: Auto-generated review request with risk rationale

## Level 2 — Supervisor Escalation  
Trigger: Pattern of Level 1 flags (>5 in 1 hour), or any case involving a legally protected class decision
Action: Supervisor notified, processing paused for affected cohort
SLA: Supervisor review within 30 minutes
Documentation: Cohort analysis report required

## Level 3 — System Suspension
Trigger: Sustained performance degradation, confirmed bias event, or security incident
Action: Full system suspension, incident response activated
SLA: Immediate — no processing until root cause confirmed
Documentation: Full incident report per CRA Art.14 / EU AI Act Art.73 requirements

Layer 3: Organisational Controls (Governance and Training)

Technical and procedural controls fail without organisational backing. Art.9's iterative requirement means someone must own the risk management process — and that ownership must be documented.

Risk control ownership

Assign explicit ownership for each control in your risk register:

risk_controls:
  - control_id: RC-001
    risk_addressed: "Model bias in recruitment scoring"
    control_type: technical
    description: "Fairness monitoring with demographic parity check"
    owner: ml-platform-team
    review_frequency: monthly
    last_reviewed: 2026-05-15
    effectiveness_evidence:
      - quarterly_bias_audit_2026_q1.pdf
      - fairness_metrics_dashboard_link
    residual_risk_level: LOW
    
  - control_id: RC-002
    risk_addressed: "Overreliance on AI output by human reviewers"
    control_type: procedural
    description: "Mandatory independent assessment for borderline cases"
    owner: hr-operations-team
    review_frequency: quarterly
    last_reviewed: 2026-04-01
    effectiveness_evidence:
      - reviewer_decision_log_analysis_q1_2026.pdf
    residual_risk_level: MEDIUM
    marxs_note: "Training refresher scheduled 2026-07-01"

Training and competency requirements

Art.9 implicitly requires that people who operate high-risk AI systems are competent. Document:

• Initial training curriculum and completion records
• Ongoing competency assessments
• Escalation decision training (when to override, when to escalate)
• Update training when the model or use case changes

Change management controls

Every change to a high-risk AI system requires a risk re-evaluation. Establish a change management gate:

1. Proposed change submitted with risk impact assessment
2. Risk owner reviews impact on existing controls
3. Testing validates controls remain effective after change
4. Sign-off before deployment
5. Post-deployment monitoring period defined

Documenting Controls for Conformity Assessment

Your risk controls must appear in your technical documentation (Annex IV). Regulators and conformity assessment bodies will look for:

Control-to-risk mapping: Each identified risk must have at least one control. Risks with only partial mitigation must document the residual risk level.

Evidence of effectiveness: Controls are not just described — they must be validated. Testing results, audit outputs, and monitoring metrics are your evidence.

Residual risk statement: After controls are applied, what risk remains? This residual risk must be:

• Formally accepted by your organisation
• Communicated to deployers via your instructions for use (Art.13)
• Re-evaluated whenever the system or context changes

Review schedule: Controls must be reviewed at defined intervals. Monthly for high-severity risks, quarterly for medium, annually for low — is a reasonable starting structure.

Structuring Your Risk Control Register

Here is the minimum viable structure for an Art.9-compliant risk control register:

# High-Risk AI System — Risk Control Register
**System:** [System name and version]
**Last reviewed:** [Date]
**Next review due:** [Date]
**Owner:** [Risk management owner]

## Control Summary

| Control ID | Risk ID | Control Type | Effectiveness | Residual Risk | Review Date |
|------------|---------|--------------|---------------|---------------|-------------|
| RC-001 | R-003 | Technical | Validated | LOW | 2026-09-01 |
| RC-002 | R-007 | Procedural | Validated | MEDIUM | 2026-07-01 |
| RC-003 | R-011 | Organisational | Partially validated | HIGH | 2026-06-15 |

## Control Details

### RC-001: Fairness Monitoring System
**Addresses risk:** R-003 — Discriminatory output in recruitment scoring
**Control description:** Automated demographic parity check on every batch output...
**Implementation evidence:** [Link to test results]
**Residual risk:** Intersectional bias remains possible with small subgroup sample sizes. Monitored via monthly bias audit.
**Communicating residual risk to deployers:** Included in Section 4.2 of System Instructions.

[Continue for each control...]

What Happens If Your Controls Are Insufficient?

Conformity assessment (Art.43) evaluates whether your risk management system adequately addresses the identified risks. Insufficient controls can result in:

• Conformity assessment failure — the system cannot be placed on the market
• Notified body requirements — some high-risk categories require third-party assessment
• Market surveillance action — post-market, national authorities can withdraw systems

The standard is proportionality: controls must be adequate for the severity and probability of the identified risks. A low-probability, low-severity risk does not require the same control investment as a high-probability, high-severity risk.

The Residual Risk Conversation

Not every risk can be eliminated. Art.9 acknowledges this: some residual risk is acceptable if:

1. You have applied all technically and economically feasible controls
2. The residual risk has been formally assessed and accepted
3. The residual risk is disclosed to deployers in your documentation
4. The residual risk is monitored and triggers system re-evaluation if it materialises

The mistake providers make is treating "residual risk" as a way to avoid implementing controls. Regulators will scrutinise whether the decision to accept residual risk was genuine or whether adequate controls were simply not implemented.

Next in the Series

This post covered implementing risk controls and mitigation measures. The next post in the EU AI Act RMS series covers testing and validation requirements under Art.9 — how to design a testing programme that satisfies regulatory expectations, and what test evidence survives conformity assessment scrutiny.

For EU-hosted infrastructure with built-in compliance controls, explore sota.io — the EU-native managed PaaS with no CLOUD Act exposure.

EU AI Act Art.9 compliance deadline: August 2, 2026. Infrastructure sovereignty starts with where your data lives.