Operationalising “As Far As Possible”

Article 9(4) requires that risks be eliminated or reduced “as far as possible through adequate design and development,” with any remaining residual risk judged acceptable in relation to the system’s intended purpose and the persons or groups of persons on whom it is intended to be used. This standard does not require zero residual risk; it requires evidence that the organisation has pursued risk reduction to the point where further reduction would be disproportionate, technically infeasible, or counterproductive.

For each risk above the acceptance threshold, the assessor documents the mitigations already implemented, the residual risk rating after those mitigations, the alternative mitigations considered and rejected, and the rationale for rejection. The rationale must be specific: “Too expensive” is insufficient without context on the cost relative to the system’s economic value and the severity of the risk. “Not technically feasible” requires the Technical SME to provide supporting evidence that the alternative was investigated. “Would degrade performance” must quantify the degradation and explain why the current performance level is necessary.

This structured approach creates a defensible record showing that the organisation genuinely pursued risk reduction, rather than accepting risk through inattention or convenience. The record is examined during conformity assessment and must withstand scrutiny.

Key outputs

• Documented risk reduction journey per risk above threshold
• Alternative mitigations considered with specific rejection rationale
• Evidence that reduction was pursued to the disproportionality boundary
• Module 6 AISDP evidence

Alternative Mitigations Considered & Rejection Rationale

For each risk where residual risk remains above the acceptance threshold after primary mitigations, the AI System Assessor documents the alternative mitigations that were considered and the rationale for their rejection. This documentation is distinct from the primary mitigation documentation; it specifically addresses what else could have been done and why it was not.

Each alternative mitigation entry records the proposed measure, its expected risk reduction effect, its cost (financial, performance, operational complexity), any adverse effects it would introduce (for example, a stricter input filter that reduces the system’s utility for legitimate users), and the specific reason for rejection. Rejection rationales must address cost, technical feasibility, and adverse effects substantively.

The alternative mitigations documentation is a direct response to the “as far as possible” standard. An assessor reviewing the AISDP should be able to see that the organisation explored multiple risk reduction options and made informed, defensible decisions about which to implement and which to reject.

Key outputs

• Per-risk documentation of alternative mitigations considered
• Rejection rationale addressing cost, feasibility, and adverse effects
• Defensible record of informed risk treatment decisions
• Module 6 AISDP evidence

Formal Risk Acceptance — Signed Attestation

Residual risk acceptance is a governance decision. Each acceptance is a formal determination, signed by the AI Governance Lead, confirming that the residual risk is proportionate to the system’s benefits and that no reasonably practicable further mitigation is available. The signed attestation is retained in the AISDP evidence pack.

The attestation records the risk identifier, the residual risk score (after mitigations), the mitigations in place, the alternative mitigations considered and rejected, and the AI Governance Lead’s determination that the residual level is acceptable. For risks with residual scores at or near the treatment threshold, the attestation should include a re-review trigger (for example, the residual risk will be reassessed if the deployment scale exceeds a specified level or if monitoring data indicates the risk is materialising at a higher rate than predicted).

The AI Governance Lead cannot delegate the risk acceptance decision to the development team. This separation of authority ensures that risk acceptance decisions are made with full organisational awareness of their implications.

Key outputs

• Signed risk acceptance attestation per residual risk above threshold
• Residual score, mitigations, alternatives considered, and determination
• Re-review triggers for borderline acceptances
• Module 6 AISDP evidence

Communicating Residual Risk to Deployers

Residual risks that deployers inherit must be communicated through the Instructions for Use (Module 8). The communication must be specific: stating that “the system has residual fairness risk” is inadequate. The deployer must know which subgroups are affected, the magnitude of the risk, the conditions under which the risk is most likely to materialise, and the compensating controls the deployer should apply.

For each residual risk communicated to deployers, the Instructions for Use should describe the risk in terms the deployer can understand (avoiding unnecessary jargon), specify the conditions or input characteristics that increase the risk’s likelihood, recommend specific compensating controls the deployer should implement, and state the monitoring or oversight measures the deployer should maintain.

The deployer-facing residual risk communication is subject to continuous monitoring through the post-market monitoring plan (Module 12). If monitoring data indicates that a residual risk is materialising at a higher rate than predicted, the communication may need updating and deployers notified of the change.

Key outputs

• Specific, actionable residual risk communication per risk
• Deployer-facing description, conditions, compensating controls, and monitoring guidance
• PMM-driven update triggers for residual risk communication
• Module 6 and Module 8 AISDP documentation

Periodic Residual Risk Review

Residual risk acceptability changes over time. A risk that was acceptable at deployment may become unacceptable if the deployment scale increases, exposing more affected persons. It may become unacceptable if the affected population changes, for instance when the system is deployed in a new jurisdiction with different demographic composition. New evidence may emerge, such as academic research identifying a failure mode not previously anticipated. The regulatory standard may tighten through new AI Office guidance.

The quarterly risk register review must re-assess residual risk acceptability, not merely confirm that the original acceptance remains on file. Each residual risk acceptance is re-examined in light of current monitoring data, current deployment context, and current regulatory expectations. If the re-assessment determines that a previously accepted residual risk is no longer acceptable, the risk is escalated for additional mitigation.

Trigger-based reassessment supplements the quarterly cadence. A serious incident, a substantial modification, or a significant change in the deployment context triggers an immediate re-examination of all affected residual risk acceptances.

Key outputs

• Quarterly re-assessment of residual risk acceptability
• Re-examination in light of current data, context, and regulatory expectations
• Escalation for additional mitigation when acceptability changes
• Module 6 AISDP documentation