Does Your Medical Device Company Need an AI Use Policy? What ISO 13485 Actually Requires
Quick answer: ISO 13485 does not use the term "artificial intelligence" and does not mandate a standalone AI policy document. But it already regulates AI use through three existing clauses: 4.1.6 requires validation of any software used in your quality management system before initial use, 7.4 requires evaluation of suppliers (including AI vendors) who affect product conformity, and your risk management file under ISO 14971 must account for hazards introduced by AI/ML tools. If employees use ChatGPT, Claude, or similar generative AI to draft technical documentation, analyze data, or support quality processes, that use falls under existing QMS software validation requirements whether or not you've written it down. Most manufacturers need a short procedure addendum, not a new standalone policy. Even FDA itself uses generative AI internally (Elsa, built on Anthropic's Claude) to support staff reviews—the regulatory question isn't whether to use AI, it's whether your use is validated, documented, and risk-assessed.
Why This Question Is Suddenly Urgent
Two years ago, "do we need an AI policy" wasn't a question regulatory teams asked. Now it comes up in nearly every audit prep conversation, every new-hire onboarding, every conversation about who's touching your Design History File.
What changed:
Generative AI tools became genuinely useful for regulatory work. Engineers use them to draft test protocols. Regulatory affairs staff use them to summarize guidance documents. Quality teams use them to draft CAPA narratives. None of this happened because companies rolled out formal AI programs—it happened because employees started using tools they already had access to on their personal accounts.
The gap this creates:
Your QMS almost certainly has procedures for validating production software, monitoring equipment, and quality system software. It almost certainly does NOT have anything addressing an employee who opens ChatGPT to draft a section of a risk analysis or summarize a literature review for a 510(k). That's not a hole in the standard—it's a hole in how most companies have implemented the standard.
The regulatory reality:
ISO 13485 doesn't need updating to cover this. Its existing clauses were written broadly enough to already apply. The problem is that most Quality Management Systems don't yet map "AI tool" onto those existing clauses, so employees are using unvalidated software without anyone realizing a validation requirement was triggered.
What ISO 13485 Actually Says About Software (and Why It Applies to AI)
ISO 13485 doesn't mention AI, machine learning, or generative tools anywhere in its text. This leads some companies to conclude AI use falls outside the standard's scope. That conclusion is wrong, and here's why.
Clause 4.1.6: Validation of Computer Software Used in the QMS
The actual text:
Clause 4.1.6 requires organizations to document procedures for validation of the application of computer software used in the quality management system. Such software applications must be validated prior to initial use and, as appropriate, after changes to the software or its application. The specific approach and activities associated with validation must be proportionate to the risk associated with the use of the software.
Why this covers AI tools:
"Computer software used in the quality management system" is a functional definition, not a technology-specific one. It doesn't matter whether the software is a legacy desktop application, a cloud-based eQMS, or a generative AI model. If the software's output affects a QMS process, decision, or record, it's in scope.
What triggers 4.1.6 for AI specifically:
- Drafting sections of Design History File documentation
- Generating risk analysis narrative language
- Summarizing literature searches for clinical evaluation
- Drafting CAPA investigation summaries
- Assisting with complaint file categorization
- Generating training materials for QMS procedures
What likely does NOT trigger 4.1.6:
- General brainstorming with no QMS record produced
- Drafting internal meeting notes not incorporated into controlled documents
- Personal productivity use unconnected to any regulated process
The determining question: Does the software's output become part of, or directly inform, a QMS record, decision, or regulated submission? If yes, validation applies.
Clause 7.5.6 and 7.6: Production and Measurement Software
Less commonly triggered for AI but still relevant:
Clause 7.5.6 requires validation of software used in production or service processes. Clause 7.6 requires validation of software used to monitor and measure product conformity.
Where this matters for AI:
If you use an AI tool to analyze manufacturing data, flag out-of-spec conditions, or support inspection decisions, these clauses apply in addition to 4.1.6. This is less common for generative AI (used mostly for documentation) but increasingly relevant as manufacturers pilot AI-assisted visual inspection or defect detection.
Clause 7.4: Purchasing and Supplier Evaluation
The actual requirement:
Organizations must evaluate and select suppliers based on their ability to supply product/services that meet requirements, with evaluation criteria proportionate to risk.
Why this applies to AI vendors:
If you're using a third-party AI tool or platform (OpenAI, Anthropic, a specialized regulatory AI platform, or an embedded AI feature in your eQMS), that vendor is a supplier under 7.4. Your supplier evaluation should address:
- Data handling and security practices
- Model update/versioning practices (does the underlying model change without notice?)
- Documented limitations and known failure modes
- Whether the vendor provides validation support documentation
Practical distinction:
A generic consumer AI chatbot (ChatGPT web interface, personal accounts) is much harder to evaluate as a "supplier" in the traditional sense—there's no enterprise agreement, no SLA, no defined data handling commitment specific to your use. This is precisely why generic consumer AI use for QMS-relevant work creates more audit risk than use of a vetted enterprise tool with a defined data processing agreement.
How ISO 14971 Risk Management Ties In
Your Risk Management File must account for new hazard categories introduced by AI use.
If AI tools are used in ways that could introduce errors into regulated documentation, decisions, or product-related processes, your risk management process should identify and evaluate hazards such as:
- Hallucination risk: AI generating plausible-sounding but factually incorrect regulatory citations, test data summaries, or technical claims
- Data bias/drift: For AI used in ongoing analysis (e.g., production data monitoring), model behavior changing over time without detection
- Inappropriate reliance: Staff accepting AI output without adequate independent review, especially for staff without deep subject matter expertise to catch errors
- Data leakage: Confidential design data, unpublished clinical data, or trade secrets entered into consumer AI tools that may retain or train on submitted data
This isn't a separate risk management file—it's an extension of your existing ISO 14971 process to cover a new category of process/tool risk, similar to how you'd evaluate a new piece of measurement equipment or a new software vendor.
The Three-Clause Framework: How to Actually Structure Your AI Controls
Rather than writing a freestanding "AI Policy" document (which auditors may not know how to assess against a specific clause), map your controls to existing procedures.
1. Software Validation Procedure (Ties to 4.1.6)
Add to your existing software validation SOP:
- Define "AI-assisted output" as a category requiring validation commensurate with risk
- Establish a simple risk tiering:
- Low risk: Internal brainstorming, non-QMS drafting → no formal validation required
- Medium risk: Drafting sections of internal procedures, training materials → documented review by qualified reviewer required
-
High risk: Content incorporated into DHF, risk management file, regulatory submissions, or CAPA records → full review, source verification, and sign-off by subject matter expert required
-
Require a documented intended use statement for any AI tool used routinely (similar to how you'd document intended use for any QMS software)
Practical validation activities (proportionate to risk, per 4.1.6's own language):
- For high-risk use: Independent verification of factual claims, citations, and technical statements generated by AI before incorporation into any controlled document
- Documented record of who reviewed AI-assisted content and what was checked
- Periodic sampling review of AI-assisted outputs to confirm ongoing accuracy
2. Supplier/Vendor Evaluation (Ties to 7.4)
For any third-party AI platform used in QMS-relevant work:
- Document evaluation of the vendor's data handling practices
- Confirm whether the vendor trains models on your submitted data (critical distinction between enterprise agreements and consumer-tier tools)
- Document known limitations disclosed by the vendor
- Establish re-evaluation triggers (major model version changes, vendor terms of service updates)
Practical guidance for manufacturers:
Enterprise agreements with AI vendors (that include data processing agreements, no-training clauses, and defined SLAs) are significantly easier to document as validated suppliers than ad hoc personal use of consumer AI accounts. If your team is currently using personal ChatGPT accounts for regulatory work, the fastest risk-reduction step is migrating to an enterprise agreement with appropriate data controls—not necessarily banning AI use outright.
3. Risk Management File Addendum (Ties to ISO 14971)
Add AI-specific hazards to your existing risk analysis:
- Identify processes where AI-assisted content could introduce errors (see hazard categories above)
- Assess probability and severity using your existing risk matrix
- Document risk controls (independent review requirements, restricted use cases, training requirements)
- Include AI-related risks in your periodic risk management file review cycle
Real Scenario: Where This Actually Goes Wrong
Scenario: Regulatory affairs associate drafts a literature review section for a Clinical Evaluation Report using a generative AI tool
What happens without controls:
- Associate asks AI tool to summarize recent literature on a predicate device's clinical performance
- AI tool generates a fluent, well-organized summary citing several studies
- Associate incorporates summary into CER draft with light editing
- Reviewer, trusting the polished language, doesn't independently verify each citation
- Notified body reviewer or FDA reviewer checks citations during audit/review
- One or more citations are fabricated or misattributed (a known failure mode of generative AI models, sometimes called "hallucination")
- Finding issued: data integrity concern, potential need to redo literature review, credibility damage to broader submission
What should happen with controls in place:
- Associate uses AI tool as permitted under documented procedure (medium/high-risk use case, requiring independent verification)
- Associate or independent reviewer verifies every citation against primary source before incorporation
- Documented record shows verification was performed (who checked, what was confirmed, date)
- If AI-assisted, this can be noted in internal work records (not necessarily disclosed in the CER itself, but auditable internally)
- Finding avoided because the actual control that matters—independent verification of factual claims—was performed regardless of drafting tool used
The lesson: The risk was never really "someone used AI." The risk was "someone incorporated unverified content into a regulated document." That risk existed before generative AI (an unqualified junior staff member copying from an unreliable source has the same failure mode) but generative AI increases the volume and fluency of unverified content being produced, which increases the odds that verification gets skipped because the output "looks right."
What FDA's Own Position Tells You
FDA has been unusually transparent about its own generative AI use, and this signals how the agency is likely to view manufacturer use of similar tools.
FDA deployed its own generative AI tool internally in 2025—Elsa, built on Anthropic's Claude—to help staff read, write, and summarize internal documents, with the stated goal of streamlining scientific reviews. FDA leadership has highlighted the tool's potential to reduce review time.
At the same time, FDA has acknowledged open questions about oversight: how AI-assisted conclusions would hold up if challenged, and what independent verification looks like when AI contributes to decision-making.
FDA's broader AI guidance (January 2025 draft, covering AI-enabled device software functions) emphasizes:
- Transparency about where and how AI is used
- Documentation of model limitations
- Human oversight built into workflows, not treated as optional
- Total Product Lifecycle monitoring, not just premarket validation
What this signals for manufacturers:
FDA is not taking the position that generative AI shouldn't be used in regulatory work. FDA is using it internally. The regulatory expectation forming across FDA's guidance is governed use with documented oversight, not prohibition. Manufacturers who ban AI outright may be over-correcting; manufacturers who use it with no controls are under-correcting. The middle path—validated, documented, risk-tiered use—is where both FDA's own practice and ISO 13485's existing clause structure point.
Common Mistakes Companies Make
Mistake 1: Treating "No AI Policy" as Automatic Non-Compliance
Reality: ISO 13485 doesn't require a document titled "AI Policy." It requires your existing software validation, supplier evaluation, and risk management procedures to actually be applied to AI tools your staff are using. Auditors are more likely to ask "how do you control AI-assisted content in your DHF" than "show me your AI policy document."
Mistake 2: Banning AI Use Entirely Without Addressing Shadow Usage
Reality: Blanket bans rarely eliminate use—they push it underground. Staff continue using personal AI accounts without any company visibility, which is worse than governed use because there's no data control, no vendor evaluation, and no documented review requirement. A workable policy that permits controlled use is more effective than an unenforceable ban.
Mistake 3: Confusing "AI Wrote It" with "AI Made It Non-Compliant"
Reality: The compliance question isn't the drafting tool—it's whether the content was verified before being relied upon. A human-drafted risk analysis with fabricated data would fail an audit just as badly as an AI-assisted one. Focus controls on verification, not on the tool itself.
Mistake 4: Not Distinguishing Consumer AI Tools from Enterprise/Validated Regulatory Platforms
Reality: There's a meaningful difference between an employee's personal ChatGPT account (no data agreement, no domain-specific grounding, higher hallucination risk for specialized regulatory content) and a purpose-built regulatory platform that grounds outputs in verified FDA/ISO source data with audit trails. Your policy should reflect this distinction rather than treating all "AI use" as equivalent risk.
Mistake 5: Forgetting to Update the Risk Management File
Reality: Companies often update software validation SOPs but forget that ISO 14971 risk management is where the actual hazard analysis lives. An AI use policy without a corresponding risk management file update addresses procedure but not the underlying risk documentation auditors will look for.
Building Your AI Use Procedure: Practical Outline
Rather than a lengthy standalone policy, most manufacturers can address this with a focused addendum to existing procedures. Suggested structure:
1. Scope and Definitions
- Define "AI-assisted content" and "generative AI tools" in terms relevant to your operations
- Clarify what's in scope (QMS-relevant work) vs out of scope (general non-regulated tasks)
2. Risk Tiering
- Low/medium/high risk use case categories (as outlined above)
- Corresponding review/validation requirements for each tier
3. Approved Tools and Vendor Requirements
- List approved enterprise AI tools (if any) with documented data handling agreements
- Prohibit or restrict use of consumer-tier tools for high-risk use cases
- Reference your supplier evaluation records for approved AI vendors
4. Verification Requirements
- Mandatory independent verification for any AI-assisted content incorporated into controlled documents
- Documentation requirements (who verified, what was checked, when)
5. Training Requirements
- Staff training on appropriate use, known failure modes (hallucination, bias), and verification obligations
6. Risk Management Cross-Reference
- Reference to relevant sections of your ISO 14971 risk management file addressing AI-related hazards
7. Periodic Review
- Schedule for reviewing this procedure as AI tools, vendor terms, and regulatory guidance evolve
Frequently Asked Questions
Does ISO 13485 specifically require an AI policy?
No. ISO 13485 does not mention artificial intelligence and does not require a standalone AI policy document. However, existing clauses (4.1.6 software validation, 7.4 supplier evaluation, and ISO 14971 risk management) already apply to AI tools when they're used in QMS-relevant work. Most manufacturers should update existing procedures rather than create a new freestanding policy.
Do we need to validate ChatGPT or Claude before employees can use them?
Validation is required proportionate to risk, per clause 4.1.6's own language. Low-risk use (general brainstorming not incorporated into QMS records) typically doesn't require formal validation. Higher-risk use (drafting content that becomes part of DHF, risk files, or regulatory submissions) requires documented review and verification proportionate to that risk.
Can auditors cite us for using AI tools without a written policy?
An auditor is more likely to ask how you control AI-assisted content within your existing software validation and risk management processes. If you can demonstrate that AI use is appropriately risk-tiered, verified, and documented within your existing QMS framework, the absence of a document specifically titled "AI Policy" is unlikely to be a finding on its own. The absence of ANY control over unvalidated software use in your QMS could be a finding.
Should we ban employees from using consumer AI tools like ChatGPT entirely?
Outright bans often push usage underground rather than eliminating it, removing your ability to control data handling and verification. A more effective approach is permitting controlled, risk-tiered use with clear verification requirements, while restricting high-risk use cases to approved enterprise tools with appropriate data agreements.
What's the difference between generic AI tools and specialized regulatory AI platforms for compliance purposes?
Generic consumer AI tools generate content based on general training data and can produce fluent but factually incorrect output (a known failure mode called hallucination), with no built-in verification against regulatory source data. Specialized regulatory platforms that ground outputs in verified FDA/ISO databases reduce (but don't eliminate) this risk, and typically come with clearer data handling agreements suitable for supplier evaluation under clause 7.4. Both still require appropriate verification for high-risk use cases—grounding reduces error rates, it doesn't eliminate the need for independent review.
Does using AI to draft a 510(k) submission require FDA disclosure?
FDA's current draft guidance on AI-enabled devices addresses AI as a device feature (e.g., an AI-powered diagnostic algorithm), not necessarily AI used as an internal drafting tool for the submission itself. As of this writing, there's no specific FDA requirement to disclose that AI assisted in drafting a submission document, though the accuracy and integrity of all submitted content remains the manufacturer's full responsibility regardless of drafting method.
How does this apply to companies using AI-embedded features within their eQMS platform?
If your electronic quality management system includes built-in AI features (e.g., auto-drafting CAPA summaries, auto-categorizing complaints), your vendor evaluation under clause 7.4 should specifically address these AI features—not just the eQMS platform generally. Ask your eQMS vendor for documentation on how their AI features are validated and what limitations apply.
What documentation should we keep to show AI use is controlled?
At minimum: your updated software validation procedure addressing AI-assisted content, records of verification performed on high-risk AI-assisted content before incorporation into controlled documents, supplier evaluation records for any third-party AI tools used, and the corresponding risk management file section addressing AI-related hazards.
Does this apply differently to a 50-person manufacturer versus a 500-person manufacturer?
The clause requirements are the same regardless of company size, but the proportionality principle in 4.1.6 ("commensurate with risk") allows smaller companies to implement simpler, less resource-intensive controls. A small company might address this with a one-page procedure addendum and a shared list of approved tools; a larger company might need more formal training programs and dedicated AI governance committee review.
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.
Key Takeaways
1. ISO 13485 already regulates AI use—you just may not have mapped it yet. Clauses 4.1.6 (software validation), 7.4 (supplier evaluation), and ISO 14971 (risk management) apply to AI tools whether or not you've written a specific AI policy. The gap most companies have isn't a standard gap—it's an implementation gap.
2. Risk-tiering, not banning, is the practical path. Blanket AI bans typically push usage underground, eliminating your visibility and control. A risk-tiered approach—low-risk uses proceeding freely, high-risk uses requiring documented verification—is both more enforceable and more defensible in an audit.
3. The real risk is unverified content, not the drafting tool. Whether content was AI-generated or human-drafted, the compliance failure is the same: unverified claims entering a controlled document. Build your controls around independent verification requirements for high-risk content, regardless of source.
4. Even FDA uses generative AI internally. FDA's own deployment of Elsa (built on Claude) signals that the regulatory expectation is governed use with appropriate oversight, not prohibition. This should inform how manufacturers calibrate their own AI use policies—neither reckless adoption nor blanket bans reflect where the regulatory conversation is heading.
5. Update your Risk Management File, not just your SOPs. Companies often remember to update software validation procedures but forget that ISO 14971's risk management file is where auditors expect to see the actual hazard analysis for new categories of risk, including AI-related hazards like hallucination, data leakage, and inappropriate reliance.
References
-
ISO 13485:2016 - Medical devices — Quality management systems — Requirements for regulatory purposes
https://www.iso.org/standard/59752.html -
ISO 14971:2019 - Medical devices — Application of risk management to medical devices
https://www.iso.org/standard/72704.html -
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: Artificial Intelligence in Software as a Medical Device
https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-software-medical-device -
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 -
Bipartisan Policy Center: FDA Oversight - Understanding the Regulation of Health AI Tools
https://bipartisanpolicy.org/issue-brief/fda-oversight-understanding-the-regulation-of-health-ai-tools/ -
FDA Digital Health Advisory Committee: Generative AI-Enabled Digital Mental Health Medical Devices (November 6, 2025)
FDA Website - Advisory Committee Meetings -
ISO 13485 Clause 4.1.6 - Software Validation Requirements
Referenced via multiple industry sources including OpenRegulatory and SimplerQMS guidance -
21 CFR Part 11 - Electronic Records; Electronic Signatures
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 -
FDA: Computer Software Assurance for Production and Quality System Software (Draft Guidance)
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software