AAMI CR34971 Explained: AI Risk Management for Medical Devices

Standards Explainer · Updated 2026 · 7 min read

AAMI CR34971:2023, Application of ISO 14971 to Machine Learning in Artificial Intelligence, is the standard FDA reviewers reach for when an AI/ML device's risk file looks like a generic ISO 14971 file with the word 'algorithm' search-and-replaced. This guide explains what CR34971 is, what it adds, and how to fold it into your existing risk management process without standing up a parallel system.

Talk to an AI/ML expert · AI/ML Medical Device Security Service →

What CR34971 is

CR34971 is a consensus report (the "CR") from AAMI, not a standard you certify against. It applies the ISO 14971 risk-management framework to the specific failure modes of machine-learning systems in medical devices. It does not replace ISO 14971 - it extends it with categories of harm and risk-control techniques that traditional risk management does not cover.

FDA's 2025 draft AI guidance explicitly references it. Notified bodies in the EU treat it as state of the art for AI/ML risk management under MDR.

What it adds beyond ISO 14971

ISO 14971 gives you the process: identify hazards, estimate and evaluate risks, control risks, evaluate residual risk, and feed postmarket back in. CR34971 populates that process with AI-specific hazard categories and AI-specific risk control techniques.

The AI-specific hazard categories CR34971 highlights:

• Data quality and representativeness - training data that does not reflect the deployed population.
• Dataset shift and concept drift - real-world inputs diverge from training distribution over time.
• Overfitting and underfitting - model fails to generalize.
• Continual / online learning instability - models that update in the field can drift in unsafe directions.
• Automation bias and over-reliance - users defer to model outputs inappropriately.
• Under-reliance and disuse - users ignore correct outputs because of low trust.
• Adversarial inputs - intentional manipulation of inputs to cause misclassification.
• Unintended subgroup disparities - performance varies by demographic, site, or device characteristics.
• Loss of explainability or interpretability - users cannot reason about the output.
• Pipeline and supply-chain integrity - training data, third-party models, and dependencies introduce risk.

How CR34971 changes the risk file

Practically, three sections of the risk management file get expanded:

Hazard analysis

Add the AI hazard categories above as inputs to your hazard identification, alongside the usual electrical, mechanical, biological, software, and cybersecurity sources. Each hazard category should yield specific hazardous situations relevant to your device.

Risk control

AI-specific controls live alongside traditional ones. Examples:

• Data quality: representativeness analysis, bias audits, dataset cards, multi-reader ground truth.
• Drift: postmarket monitoring of input and output distributions; subgroup performance dashboards; PCCP-driven retraining triggers.
• Adversarial inputs: adversarial testing during validation; input sanity checks at inference; anomaly detection.
• Automation bias: IFU language; training; UI design that surfaces uncertainty.
• Subgroup disparities: stratified validation; subgroup acceptance gates; transparency labeling.
• Pipeline integrity: signed datasets and models; reproducible training; supplier evaluation for third-party models; SBOM coverage of ML components.

Postmarket feedback

ISO 14971 already requires postmarket information to feed back into the risk file. CR34971 makes the AI-specific signals explicit: drift events, monitoring threshold breaches, subgroup performance changes, adversarial-incident reports, and outcomes from PCCP-driven retrains. These belong in the same postmarket surveillance system as adverse events.

Integrating CR34971 without doubling your work

Do not stand up a parallel "AI risk file." That guarantees inconsistency and gives you two artifacts to maintain. Instead:

1. Extend the existing hazard analysis with the CR34971 categories that apply to your device. If a category does not apply, document why.
2. Annotate AI-specific controls in the existing risk-control table with a flag (e.g., "AI-Risk") so they are searchable, but keep them in the same table.
3. Keep one residual risk evaluation that covers AI and non-AI risks together.
4. Tie the postmarket monitoring plan back to the risk file. Drift alerts and bias signals are not separate dashboards - they are inputs to the postmarket section of ISO 14971.
5. Reference CR34971 explicitly in the risk management plan. Reviewers want to see that you knew it existed and applied it.

How CR34971 connects to other AI deliverables

• PCCP - the modification protocol's acceptance criteria (subgroup performance bounds, drift triggers) come from the risk file's residual-risk thresholds. See the PCCP template.
• GMLP - principles 8 (clinically relevant testing) and 10 (deployed monitoring) cannot be satisfied without a risk file that names the relevant hazards. See the GMLP crosswalk.
• Cybersecurity - adversarial inputs, model inversion, and supply-chain hazards in CR34971 overlap with the AI threat model under Section 524B. Use one threat model and reference it from both files.
• Transparency labeling - user-facing limitations in the labeling come from residual risks in the risk file, not the marketing team.

Common gaps reviewers flag

• Risk file lists "algorithm error" as a single hazard with no decomposition.
• No representativeness analysis tied to a hazard.
• Bias treated as an ethics topic, not a safety hazard.
• Drift mentioned in the postmarket plan but not in the risk file.
• Adversarial inputs absent entirely.
• Third-party foundation models or APIs not represented as risk sources.

Where to go next

• FDA 2025 AI Guidance Decoded
• PCCP Template & Worked Example
• GMLP Crosswalk: 10 Principles to Engineering Controls
• AI/ML Medical Device Security Service

Sources

• AAMI CR34971:2023, Application of ISO 14971 to Machine Learning in Artificial Intelligence
• ISO 14971:2019, Medical devices - Application of risk management to medical devices
• FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft, January 2025)