AAMI CR34971 Explained: AI Risk Management for Medical Devices

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:

Extend the existing hazard analysis with the CR34971 categories that apply to your device. If a category does not apply, document why.
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.
Keep one residual risk evaluation that covers AI and non-AI risks together.
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.
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 cybersecurity attacks and testing fit

CR34971 is a safety risk-management report. It flags adversarial inputs, supply-chain integrity, and model-pipeline risks as hazards, but it does not enumerate attacks or specify tests. Those live in cybersecurity artifacts under Section 524B, not in the risk file. Use CR34971 to name the hazard categories; use the sources below to build the attack catalog and the test plan that mitigates them.

Where the AI threats that should be tested are defined:

FDA final premarket cybersecurity guidance (February 3, 2026) and Section 524B of the FD&C Act - require a threat model covering the full attack surface, including ML components, with test evidence traceable to each threat. See our 524B AI threats breakdown for the seven AI-specific threats FDA reviewers now look for.
FDA, AI-Enabled Device Software Functions (Draft, January 2025) - names adversarial inputs, data and model poisoning, model inversion and extraction, and supply-chain integrity of models and datasets as expected threat-model inputs.
NIST AI 100-2 E2023, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - the canonical attack taxonomy: evasion, poisoning, privacy (membership inference, model inversion, extraction), and abuse.
NIST AI RMF 1.0 and the Generative AI Profile (NIST AI 600-1) - governance and testing expectations, including prompt injection and GenAI-specific abuse for LLM-backed SaMD.
MITRE ATLAS - adversary tactics, techniques, and procedures against ML systems; used to design red-team scenarios.
OWASP Machine Learning Top 10 and OWASP LLM Top 10 - practitioner attack lists for structuring test cases (adversarial examples, model theft, training-data poisoning, prompt injection, insecure output handling).
AAMI TIR57 and ANSI/AAMI SW96 - the security risk-management frame FDA reviewers use to grade the threat model and its test evidence.
ISO/IEC 27090 (AI security guidance) and ISO/IEC 23894 (AI risk management) - international companions.

What the corresponding testing looks like (defined in your threat model and pen-test scope, not in CR34971): adversarial robustness testing, data-poisoning simulation, membership-inference and model-inversion tests, model-extraction rate-limit tests, prompt-injection and jailbreak suites for LLM-backed devices, stratified subgroup performance validation, drift-monitor validation, signed-model and signed-dataset supply-chain verification, and MLOps pipeline pen testing (training infrastructure, model registry, feature store). For the reviewer-ready threat model those tests trace back to, see the FDA-grade threat model template.

Where to go next

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)