AI and ISO 14971: What Belongs in Your Risk Management File (and What Doesn't)
Quick answer: ISO 14971's Risk Management File covers risk to patient and user safety from your medical device—not general business process risk. This creates two distinct questions manufacturers conflate: (1) if your DEVICE contains AI/ML (an algorithm that's part of the product), that's a product safety risk squarely inside ISO 14971's scope, and the technical report AAMI/BS 34971:2023 (soon supplemented by ISO/TS 24971-2) provides specific guidance on hazards like dataset shift, model drift, bias, and adversarial inputs [1, 2]. (2) If your TEAM uses AI tools internally (ChatGPT, Claude, or similar) to draft regulatory documentation, that's a process risk—it doesn't automatically belong in the Risk Management File unless an AI-introduced error could propagate into content that affects an actual safety determination (a missed hazard in your clinical evaluation, an inaccurate benefit-risk conclusion). Most manufacturers should manage internal AI tool risk through their quality management system's risk-based thinking and software validation procedures, and only cross-reference the Risk Management File when AI-assisted content directly feeds into a safety-relevant document.
Why This Distinction Actually Matters
"We use AI, so we need to update our risk management file" is a common but imprecise starting point. It conflates two categories of risk that require different documentation, different owners, and different regulatory hooks.
Category 1: AI as a device feature (product risk)
Your device includes an algorithm—a diagnostic AI, a dosing calculator, an image analysis tool—that is part of what you're selling and what FDA is clearing. This is unambiguously in scope for ISO 14971. The algorithm's failure modes are device hazards. This is what your existing Complizen Learn content on AI/ML SaMD, PCCP, and IMDRF risk categories already addresses in depth.
Category 2: AI as an internal tool (process risk)
Your regulatory affairs team uses a generative AI tool to help draft sections of a submission, summarize literature, or organize a risk analysis narrative. The device itself doesn't contain AI—your INTERNAL PROCESS for developing regulatory content does. This is a different kind of risk entirely, and it's the category most manufacturers haven't figured out how to document, because it doesn't map cleanly onto either "device hazard" or "typical software validation."
This article is about Category 2, because Category 1 is well-covered by existing standards and existing Complizen content. Category 2 is the gap.
What ISO 14971 Actually Covers (And What It Doesn't)
The Scope, Precisely
ISO 14971:2019 specifies a process for manufacturers to identify hazards associated with a medical device, estimate and evaluate risks, control those risks, and monitor control effectiveness—covering the device across its entire lifecycle from concept through decommissioning [3]. The standard's hazard categories explicitly include biocompatibility, data and systems security, electrical safety, moving parts, radiation, and usability [3]—all framed around risks the DEVICE poses to patients, users, or third parties.
What this means concretely: A hazard in ISO 14971 is something about the device that could cause harm. An electrical short is a hazard. A misdiagnosis from a flawed algorithm embedded in the device is a hazard. A typo in an internal memo is not a hazard in the ISO 14971 sense—unless that typo is the kind of error that ends up inside a document determining whether your device's risks have been correctly identified and controlled.
Where AI/ML-in-the-Device Fits (Briefly—See Existing Complizen Content for Depth)
If your device contains an AI/ML component, that component's specific failure modes are product hazards under ISO 14971, and the relevant technical guidance is AAMI/BS 34971:2023, which provides guidance on applying ISO 14971 risk management specifically to machine learning in medical technology, without modifying the underlying ISO 14971 process itself [1]. The technical report includes worked examples of ML-specific hazards and their relationships to hazardous situations and harms, guidance on personnel qualifications for AI-specific risk assessment, and specific considerations for autonomous systems [1].
A newer, complementary document—ISO/TS 24971-2—is in development to provide additional targeted guidance on applying ISO 14971 to machine-learning-enabled medical devices specifically, covering data-related risks including quality, provenance, and representativeness [2].
Common AI/ML device hazard categories these documents address: - Dataset shift (training data no longer represents real-world use) - Model drift (performance degrading over time in deployment) - Algorithmic bias (differential performance across patient subgroups) - Adversarial inputs (inputs designed or incidentally structured to fool the model) - Explainability limitations (inability to characterize why the model produced a given output)
If this is your situation—AI/ML embedded in your device—this isn't the article for the deep dive. Complizen Learn's existing content on AI/ML SaMD risk categories, PCCP, and IMDRF frameworks covers this directly. This article is about the other, less-discussed category.
Category 2: When Internal AI Tool Use Actually Becomes a Risk Management Question
This is where most manufacturers currently have no clear answer, because the standard wasn't written with this scenario in mind, and no technical report currently addresses it directly.
The Core Question: Does Using AI to Draft Content Create a "Hazard"?
Strictly, under ISO 14971's own definition: not by itself. Your quality management system using a word processor, a spell-checker, or a generative AI tool to help draft a document is a process choice, not a device characteristic. ISO 14971's Risk Management File is not the place to document "we sometimes use ChatGPT to help write things."
But there's a real mechanism by which it CAN become relevant:
If AI-assisted drafting introduces an error into content that directly informs your risk analysis, clinical evaluation, or benefit-risk determination—and that error isn't caught before the determination is finalized—the RESULT is a gap in your actual risk management file's accuracy. At that point, the issue isn't "we used AI" as an abstract category; it's "our risk analysis contains an inaccurate hazard characterization," which is squarely a 14971 problem regardless of what tool helped produce the inaccurate text.
The practical distinction:
| Scenario | Where This Lives |
|---|---|
| Using AI to draft the STRUCTURE of a risk analysis document | QMS software validation procedure (see Complizen's ISO 13485 + AI use policy guidance) |
| Using AI to summarize literature for a clinical evaluation, with independent verification before inclusion | QMS software validation procedure + verification record |
| An AI-drafted hazard characterization that goes unverified and later proves inaccurate, discovered during audit or FDA review | Now a finding against your actual Risk Management File's accuracy—the AI tool is incidental, the RMF gap is the real issue |
| Your device contains an embedded AI/ML algorithm | Direct ISO 14971 product hazard—see AAMI/BS 34971 |
Why Manufacturers Should Still Track This, Even Though It's Not Strictly a 14971 Entry
Even though internal AI tool use isn't automatically a Risk Management File entry, there's a strong practical argument for documenting the RISK OF THE PROCESS somewhere in your quality system, because:
-
The failure mode transfers. An unverified AI-drafted hazard characterization becomes indistinguishable from a human-drafted one once it's in your file—but the probability of it being wrong is a known, non-zero rate (see Complizen's article on AI-drafted 510(k) content for the specific hallucination rate data).
-
Auditors increasingly ask about this. A notified body or FDA auditor examining your quality system may ask how AI-assisted content is controlled, particularly for higher-risk device classes. Having an answer—even if the answer is "documented in our software validation procedure, not the RMF, because it's a process control not a product hazard"—is a stronger position than having no answer at all.
-
It's cheap to document and expensive to skip. A short section in your software validation procedure or a cross-reference note in your risk management plan costs little and closes an obvious gap an auditor might otherwise probe.
How to Actually Document This: A Practical Structure
Rather than forcing internal AI tool risk into the Risk Management File where it doesn't strictly belong, use this structure.
1. Document the Process Risk in Your Software Validation Procedure
As covered in Complizen's guide to AI use policies under ISO 13485, your software validation procedure (tied to clause 4.1.6) is where AI tool use controls belong. This should specify:
- Risk tiers for AI-assisted content (low/medium/high, based on where the content ends up)
- Verification requirements scaled to risk tier
- Which categories of content (literature citations, predicate comparisons, hazard characterizations, clinical evaluation summaries) require mandatory independent verification before being incorporated into any document that feeds your Risk Management File
2. Add a Cross-Reference in Your Risk Management Plan
Your ISO 14971 risk management PLAN (distinct from the risk management FILE, which contains the actual analysis) is the document that describes your overall approach and methodology. This is an appropriate place for a brief statement establishing that:
- Content in the risk management file may be drafted with AI assistance as a documentation aid
- All AI-assisted content undergoes verification per the software validation procedure before inclusion
- This ensures the accuracy of the risk management file is maintained regardless of drafting method used
This single addition demonstrates to an auditor that you've thought about the question, without requiring you to treat every use of AI as if it were a device hazard.
3. If (and Only If) Your Device Contains AI/ML, Build the Actual Hazard Analysis
For devices where AI/ML IS part of the product, the hazard analysis entries belong directly in the Risk Management File, structured the same way as any other hazard:
Example hazard analysis entry structure (device-embedded AI/ML):
| Element | Example |
|---|---|
| Hazard | Model performance degradation due to data drift |
| Hazardous Situation | Algorithm trained on one patient population deployed on a demographically different population without retraining |
| Sequence of Events | Population shift occurs gradually post-deployment → model accuracy declines → decline goes undetected due to lack of post-market performance monitoring |
| Harm | Missed or delayed diagnosis due to reduced algorithm sensitivity in the shifted population |
| Severity/Probability | [Per your risk matrix] |
| Risk Control | Post-market performance monitoring plan with defined drift detection thresholds; PCCP defining retraining triggers |
This is the kind of entry AAMI/BS 34971 and the emerging ISO/TS 24971-2 guidance are specifically built to help populate—reference those documents directly for a comprehensive hazard checklist if this is your situation.
4. Example Structure for Internal AI Tool Use Risk (Process-Level, Documented Outside the RMF)
If you want to document the process risk itself (recommended, even though it's not a formal RMF entry), a simple structure works:
| Element | Example |
|---|---|
| Process Risk | AI-assisted drafting introduces inaccurate content into safety-relevant documentation |
| Where This Could Occur | Clinical evaluation literature review, risk analysis narrative drafting, benefit-risk summary drafting |
| Consequence If Unmitigated | Inaccurate hazard characterization or benefit-risk conclusion in the Risk Management File; potential FDA/notified body finding |
| Control | Mandatory independent verification for AI-assisted content before inclusion in safety-relevant documents (per software validation procedure); documented review sign-off |
| Where Documented | Software validation procedure; risk management plan cross-reference |
Real Scenario: How This Plays Out in Practice
Scenario: A manufacturer uses AI to help draft the clinical evaluation literature summary, and the summary is later found to have overstated the safety profile of a comparator device
What this is NOT: A device hazard requiring a new entry in the Risk Management File describing "AI tool malfunction."
What this actually IS: A gap in the clinical evaluation's accuracy—the same category of problem as if a human researcher had made the same overstatement. The corrective action isn't "stop using AI." It's:
- Correct the clinical evaluation content to accurately reflect the source literature
- Investigate whether the inaccurate content affected any risk or benefit-risk conclusions in the actual Risk Management File
- If it did, correct those conclusions and document the correction per your normal risk management file update process
- Update your software validation procedure's verification requirements if the root cause was a gap in your verification process (e.g., verification wasn't actually performed, or was performed but insufficiently rigorous)
The RMF entry, if any is warranted, describes the corrected risk/benefit conclusion—not "we used AI and it made a mistake." The AI tool is the drafting mechanism; the quality system gap (insufficient verification) is the actual root cause worth documenting and correcting.
Common Mistakes
Mistake 1: Treating "We Use AI" as Itself a Hazard Requiring an RMF Entry
Reality: This conflates a process choice with a device characteristic. Document AI tool use risk in your software validation procedure, not as a standalone device hazard, unless the device itself contains the AI.
Mistake 2: Assuming AAMI/BS 34971 Applies to Internal Tool Use
Reality: AAMI/BS 34971 and the emerging ISO/TS 24971-2 are specifically about AI/ML embedded in the device as a product feature [1, 2]. They don't address internal drafting tool use, and citing them for that purpose in an audit response would likely draw scrutiny for scope mismatch.
Mistake 3: Ignoring the Issue Entirely Because "It's Not Technically Required"
Reality: While internal AI tool use isn't a mandatory Risk Management File entry, having zero documentation of how you control AI-assisted content that feeds into safety-relevant documents is a real gap an auditor can reasonably probe. The fix is cheap (a procedure section, a plan cross-reference)—skipping it entirely isn't necessary caution, it's an unforced gap.
Mistake 4: Not Distinguishing Product AI Risk from Process AI Risk in Internal Communication
Reality: When your team discusses "AI risk," make sure everyone's talking about the same category. A conversation that starts as "should we worry about our diagnostic algorithm's bias" and drifts into "should we let people use ChatGPT for CAPA drafting" is conflating two different risk registers with two different owners and two different documentation homes.
Mistake 5: Waiting for a Formal Standard Before Documenting Anything
Reality: There's no dedicated technical report for internal AI drafting tool risk in medical device regulatory work (unlike AAMI/BS 34971 for device-embedded ML). Waiting for one before addressing the gap means operating with an unaddressed risk indefinitely. Use the existing software validation and risk-based thinking framework now; adopt formal guidance if and when it emerges.
The Fastest Path to Market
No more guesswork. Move from research to a defendable FDA strategy, faster. Backed by FDA sources. Teams report 12 hours saved weekly.
Frequently Asked Questions
Does using AI to draft parts of our clinical evaluation require a new entry in our Risk Management File?
Not automatically. The Risk Management File documents risks to patient/user safety from your device, not your internal drafting process. However, if AI-assisted content that goes unverified results in an inaccurate hazard characterization or benefit-risk conclusion in the file, correcting that inaccuracy—and documenting why—does become an RMF matter. The AI tool itself isn't the hazard; an uncorrected inaccuracy in your risk analysis is.
Is AAMI/BS 34971 relevant to us if we don't have AI/ML in our device?
No. AAMI/BS 34971 specifically addresses applying ISO 14971 to machine learning that is part of the medical device itself [1]. If your device doesn't contain an AI/ML component, this technical report isn't the relevant guidance for your internal AI tool use questions—that's a software validation and quality process question, not a device hazard question.
Where should we document the risk of AI-assisted drafting errors if not in the Risk Management File?
Your software validation procedure (tied to ISO 13485 clause 4.1.6) is the more appropriate home, since AI drafting tools are software used in your quality management system. A brief cross-reference in your risk management PLAN (not file) noting that RMF content may be AI-assisted and is verified per your software validation procedure closes the loop without misclassifying a process risk as a product hazard.
What's the difference between the risk management plan and the risk management file?
The risk management plan describes your methodology, scope, and approach to risk management for a device. The risk management file contains the actual hazard analysis, risk evaluation, and control records for that specific device. AI tool use documentation belongs primarily in procedures referenced by the plan; specific hazard analysis entries (for device-embedded AI/ML) belong in the file.
If our device has an AI/ML algorithm, do we need AAMI/BS 34971 in addition to ISO 14971?
ISO 14971 remains the governing risk management standard—AAMI/BS 34971 doesn't replace or modify it. It provides supplementary guidance specifically for identifying and characterizing ML-related hazards within the existing ISO 14971 process [1]. Most manufacturers with AI/ML-enabled devices use both together: ISO 14971 for the overall process, AAMI/BS 34971 (and increasingly ISO/TS 24971-2) for ML-specific hazard identification.
Should our AI use policy reference our Risk Management File, or is that unnecessary?
A brief cross-reference is good practice, but the primary control mechanism should sit in your software validation procedure. The Risk Management File itself shouldn't need substantial rewriting to accommodate internal AI tool use—if it does, that's a sign the AI risk discussion has drifted from process risk into being treated as if it were a product hazard.
Does this apply differently if we use a specialized regulatory AI platform versus a general-purpose AI tool?
The underlying principle (verify before it reaches safety-relevant content) applies either way. Platforms grounded in verified regulatory databases reduce the underlying error rate compared to general-purpose tools, which may lower the residual risk and the intensity of verification needed—but doesn't eliminate the need for a documented verification step for high-risk content categories.
Key Takeaways
1. Separate product AI risk from process AI risk—they don't belong in the same document. AI/ML embedded in your device is a product hazard under ISO 14971, addressed with AAMI/BS 34971 guidance. AI tools your team uses to draft documentation is a process risk, addressed through software validation procedures. Conflating them creates confusion about ownership and misapplies standards outside their intended scope.
2. Internal AI tool use isn't automatically a Risk Management File entry. The RMF documents device safety risk, not drafting methodology. Document AI tool use controls in your software validation procedure instead, with a brief cross-reference in your risk management plan.
3. The real risk mechanism is unverified content reaching safety-relevant documents. If AI-assisted drafting introduces an error that ends up in your clinical evaluation or risk analysis unverified, the resulting inaccuracy is a genuine RMF concern—not because AI was involved, but because your risk analysis is now wrong. Fix the accuracy, document the correction, and address the verification gap that let it through.
4. AAMI/BS 34971 and ISO/TS 24971-2 are for device-embedded AI/ML, not internal tools. Citing these standards for internal drafting tool questions is a scope mismatch that won't hold up under audit scrutiny. Know which category your AI question falls into before reaching for a standard.
5. Cheap documentation now beats an unaddressed gap later. A short procedure section and a plan cross-reference cost little. Given how directly this question is starting to come up in audit conversations, having a documented, defensible position—even a simple one—is worth the modest effort of writing it down.
References
-
AAMI/BS 34971:2023 - Application of ISO 14971 to Machine Learning in Artificial Intelligence: Guide
Referenced via BSI Group and Greenlight Guru technical guidance -
ISO/TS 24971-2 (in development) - Machine Learning Guidance for ISO 14971 Application
Referenced via CEN/ISO standards catalog -
ISO 14971:2019 - Medical devices — Application of risk management to medical devices
https://www.iso.org/standard/72704.html -
ISO 13485:2016 - Medical devices — Quality management systems — Requirements for regulatory purposes
https://www.iso.org/standard/59752.html -
FDA: Good Machine Learning Practice for Medical Device Development: Guiding Principles
https://www.fda.gov/medical-devices/software-medical-device-samd/good-machine-learning-practice-medical-device-development-guiding-principles -
FDA: Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft Guidance, January 2025)
https://www.federalregister.gov/documents/2025/01/07/2024-31543/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing -
FDA: Marketing Submission Recommendations for a Predetermined Change Control Plan for AI/ML-Enabled Device Software Functions (Final Guidance, December 2024)
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial -
21 CFR Part 820 - Quality System Regulation
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820 -
FDA: General Principles of Software Validation
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation