For safety and regulatory teams in the medical device software space, the question is no longer if the EU AI Act impacts your workflows, but how deeply. With the grace periods for high-risk AI systems now behind us, the focus is squarely on updating ISO 14971 SaMD technical files for the EU AI Act. This isn’t about Bolting on a few extra documents; it’s about re-architecting your risk management framework to speak the AI Act’s language while maintaining the clinical rigor that ISO 14971 provides.
The good news? ISO 14971’s philosophy of iterative risk control is entirely compatible with the AI Act’s lifecycle approach. The challenge is that AI introduces failure modes which traditional FMEA and fault tree analysis fail to capture adequately. Here’s a structured look at what needs to change in your technical documentation now.
Why the EU AI Act Demands a Risk File Evolution, Not a Revolution
The EU AI Act classifies most standalone SaMD with a medical purpose as “high-risk” under Annex I/III. When this happens, Technical Documentation requirements under Article 11 and Annex IV kick in. These requirements overlap heavily with the existing MDR/IVDR documentation, but they demand specific detail on data governance, algorithm robustness, and human oversight.
Your ISO 14971 risk file is the natural repository for this evidence. However, acting merely as a compliance checklist is insufficient. Regulators and Notified Bodies are now scrutinizing whether manufacturers have genuinely mapped AI-specific risks into the safety chain of the device. If your risk file could belong to a device from 2015, it will not pass the expanded scrutiny of the AI Act.
Core Updates to Your ISO 14971 SaMD Risk Management File
To align with the AI Act, your risk management process must explicitly address the unique characteristics of machine learning systems. This requires concrete changes to four core areas of your documentation.
1. Redefining the Scope and Intended Use Statement
Your intended use is the foundation of ISO 14971. But for AI-enabled SaMD, a generic intended purpose (“diagnosis of diabetic retinopathy”) is no longer sufficient. The EU AI Act demands explicit clarification of the operational environment and population.
You must update your intended use chapter to include:
- Technical performance thresholds: The intended use must define the constraints of the AI model (e.g., it applies only to images captured with a specific resolution, or within a specific epidemiological prevalence rate).
- Reasonably foreseeable misuse in an AI context: Document what happens if the clinician over-relies on the AI suggestion or uses the software in an off-label setting without the correct sensor inputs. These scenarios must be categorized as hazardous situations.
- Automation boundaries: Clearly define whether the software is decision-support or autonomous. This is critical for establishing the severity of potential harm in the risk file.
2. Identifying AI-Specific Hazards and Hazardous Situations
Traditional hazards like network failures or software bugs are covered by IEC 62304. The AI Act requires you to look beyond this. Your risk file must now include a new hazard category: algorithmic failure modes.
Consider adding these to your hazard identification matrix:
- Algorithmic Bias: The model consistently underpredicts risk for a specific demographic subgroup due to unrepresentative training data.
- Model Drift: The model’s real-world performance degrades over time, leading to delayed diagnosis as clinical practices change.
- Adversarial Inputs: Maliciously perturbed inputs (e.g., noise added to a medical image) cause the model to output an incorrect classification without any visible difference to the human eye.
- Automation Complacency: The clinical user fails to notice a product alert because the AI system has a false-negative loop that trains users to ignore alarms.
For each hazard, apply the ISO 14971 risk control measures. However, note that the probability of bias or drift cannot be calculated purely from historical data. You must combine clinical evaluation data with a robust technical evaluation of the AI’s confidence scores.
3. Integrating Data Governance and Data Quality
The EU AI Act Article 10 is arguably the most disruptive requirement for SaMD manufacturers. It mandates that training, validation, and testing data sets are relevant, representative, and free from errors. In the context of ISO 14971, this means data governance is no longer just a Data Science department issue—it is a risk control measure.
You must update your technical documentation to describe:
- Data Provenance & Labeling: Where did the data come from? How was the “ground truth” annotated? Your risk file must contain a traceable workflow from raw dataset to training dataset, including the tools and workflows used to clean it.
- Data Gap Analysis: How do you prove the dataset is representative of the intended use population? This is where you integrate statistical bias analysis directly into the risk management plan.
- Pre-processing and augmentation: Document every step of the data pipeline as a subsystem with its own set of requirements, analogous to how you’d treat a software module under IEC 62304.
4. Human Oversight as a Risk Control Measure
Article 14 requires that high-risk AI systems are designed to be overseen by natural persons. In ISO 14971 terms, human oversight is a control measure aimed at reducing residual risk. But you cannot simply list “clinician reviews the output” in an online file. The Al Act forces you to prove that human oversight is technically feasible.
Your technical file should now include specific usability engineering outputs (via IEC 62366-1) that demonstrate:
- The human-machine interface clearly indicates the AI’s confidence level and the rationale behind the recommendation.
- The interface allows the user to override, disregard, or correct the AI output.
- There is a mechanism for “disagreement” escalation between the clinician and the software, which is logged and reviewed.
Failing to include this data results in a gap between your usability engineering folder and your ISO 14971 risk file—a gap that is a common red flag during Annex IX audits.
Aligning Post-Market Surveillance (PMS) with AI Act Post-Market Monitoring (PMM)
Your existing PMS plan under the MDR focuses on collecting clinical experience and complaints. The EU AI Act introduces a related, but distinctly different, requirement: Post-Market Monitoring (PMM).
PMM is an active technical process. It obligates the manufacturer to systematically monitor the performance of the AI model itself. For your ISO 14971 SaMD technical files, this means updating the “ongoing risk-benefit analysis” section to include:
- Drift Metrics: What trigger thresholds are in place to detect when the model’s predictive accuracy is degrading? How often is this measured?
- Incident Reporting to Regulatory Systems: However, risk files should include a clear loop for Serious Incidents caused by algorithmic failures, ensuring the loop back to risk analysis is swift.
- Data from the Field: The PMS plan must dictate how the company obtains new data from users to continuously validate the AI model. This is a shift from passive complaint handling to active surveillance of the model’s decision boundaries.
Mapping Standards to Streamline the Update
Fortunately, you don’t need to invent a parallel process. The joint ISO/IEC 23053:2024 (Framework for AI Systems Using Machine Learning) provides an excellent gap-analysis tool. It establishes language for defining AI systems that translates smoothly into ISO 14971’s hazard controls. Additionally, ISO/TR 24291 relates specifically to the health software domain, providing guidance on the application of AI in the medical device industry.
When updating your technical documentation, map the AI Act’s technical documentation requirements in Annex IV (e.g., “Description of the AI system”, “Architecture and specifications”, “Data specification”) directly to your existing ISO 14971 risk tables. This mapping demonstrates to auditors that your risk management process encompasses the complete AI lifecycle.
Actionable Checklist for Your Documentation Team
To ensure your current documentation meets the standard, walk through your submission package and verify the following elements are present and updated:
- Intended Use: Define the specific clinical constraints and automation boundaries.
- Hazard Analysis: Include bias, drift, and adversarial attacks in your FMEA.
- Data Specification: Fully document dataset size, source, cleaning process, and labeling protocol.
- Model Evaluation: Use statistical test boundaries (AUC, sensitivity/specificity) as defined by the intended use.
- Human Oversight: Verify that usability engineering (IEC 62366) addresses Article 14 override and disengagement features.
- PMM Plan: Include a specific plan for monitoring model drift and data distribution changes during the product’s lifecycle.
- Annex IV Mapping: Clearly trace every line of the AI Act Annex IV requirements back to a specific section in your ISO 14971 risk file.
Conclusion
The EU AI Act transforms your ISO 14971 SaMD technical files from a retrospective record of safety into a living, forward-looking dossier demonstrating algorithmic rigor. By integrating AI lifecycle considerations into your risk management framework, you don’t just satisfy the European regulator; you build a more resilient safety case that anticipates and mitigates risks before they impact patient care. The work is significant, but the resulting clarity eliminates the ambiguity that has historically plagued SaMD development.
