AI tool validation under the QMSR means proving, in proportion to risk, that an AI tool used in production or your quality system works for its intended use, as ISO 13485 requires. FDA's February 2026 software assurance guidance names AI tools directly, and Part 11 audit trails apply when the tool keeps records your quality system requires.
Key takeaways
- Since February 2, 2026, the QMSR requires manufacturers to validate software used in production or the quality system through ISO 13485 Subclauses 4.1.6, 7.5.6 and 7.6. That includes AI tools.
- FDA's Computer Software Assurance guidance, updated on February 3, 2026, lists artificial intelligence and machine learning tools as software its risk framework applies to.
- An AI feature is high process risk when its failure could cause a quality problem that compromises safety, for example drafting labeling with little human review. Lower-risk uses need less evidence.
- Part 11 generally applies to quality records kept in electronic form. FDA uses enforcement discretion on Part 11's audit trail clause, but you still need a documented, risk-based decision on audit trails.
- In the four fiscal years before the QMSR, FDA investigators cited software validation for automated processes 87 times on device 483s, and purchasing controls 685 times.
Does the QMSR require you to validate AI tools?
Yes, if the tool is used as part of production or your quality management system. The QMSR, which took effect on February 2, 2026, requires manufacturers to document a quality management system that complies with ISO 13485 [2]. Our QMSR guide covers the regulation itself. ISO 13485 requires validation of software used in the quality management system and in production, before first use and, as appropriate, after changes [7]. FDA's guidance points to Subclauses 4.1.6, 7.5.6 and 7.6 for this requirement [1].
FDA's Computer Software Assurance (CSA) guidance was updated on February 3, 2026. It says its risk framework applies to automation tools, data analytic tools, AI and machine learning tools, and cloud computing used in production or the quality system [1]. That includes software as a service, where you do not run the software yourself [1]. The CSA guidance supplements FDA's 2002 General Principles of Software Validation and replaces that guidance's section on automated process equipment and quality system software [1, 8].
The first question is the tool's intended use. FDA sorts software into three groups [1]:
| Group | Examples from FDA | Validation needed? |
|---|---|---|
| Used directly in production or the quality system | Automating production, inspection or testing; automating quality processes; maintaining a quality record | Yes |
| Used to support production or the quality system | Development tools that test software used in production; general record-keeping that is not part of the quality record | Yes, but often with less effort |
| Not part of production or the quality system | Email, accounting, networking, user login, backup and restore | No |
So an AI chatbot your team uses to draft emails is outside the requirement. The same model, set up to draft CAPA investigations, triage complaints or write labeling, is inside it. What matters is the use, not the product. This is the intended use of the software, which FDA notes is different from the intended use of your device [1]. Whether you also need a written AI use procedure is a separate question, covered in our guide to AI use policies under ISO 13485.
How risky is your AI tool?
FDA asks you to identify the reasonably foreseeable failures of each software feature, then decide whether a failure poses a high process risk [1]. FDA defines high process risk as a failure that may result in a quality problem that foreseeably compromises safety [1].
FDA lists features that are generally high process risk. Three of them matter most for AI tools [1]:
- Features that measure, inspect, analyze or decide the acceptability of product or process with limited or no additional human awareness or review.
- Features that produce instructions for use or other labeling that patients and users need for safe operation.
- Features that automate surveillance, trending or tracking of data the manufacturer identifies as essential to device safety and quality.
FDA also lists features that are generally not high process risk. These include CAPA routing, logging and tracking complaints, change control management, procedure management, and features that manage data or automate an existing calculation [1].
Here is how that applies to common AI uses. These are our worked examples, applying FDA's criteria:
| AI use | Likely risk under FDA's criteria | Why |
|---|---|---|
| Drafts IFU or labeling text that ships with little review | High process risk | It produces labeling needed for safe operation [1] |
| Decides whether a complaint is reportable, with no human check | High process risk | It analyzes and decides with limited human review [1] |
| Summarizes complaints so a person can decide reportability | Not high process risk | A qualified person makes the decision |
| Routes CAPAs or tracks change control | Not high process risk | FDA lists these as generally not high risk [1] |
| Helps an engineer write test scripts | Supporting software | It supports the quality system rather than running it [1] |
Human review is a control, and FDA lets you count it. Controls elsewhere in your quality system, such as later inspection or full verification of outputs, can reduce the assurance effort the tool itself needs [1]. But the review has to be real. In April 2026, FDA sent a warning letter to a drug manufacturer that used AI agents to write specifications, procedures and master records. FDA wrote: "If you use AI as an aid in document creation, you must review the AI generated documents to ensure they were accurate and actually compliant" [6]. That letter applied drug rules, but the principle carries across. Our analysis of that warning letter covers what happened.
Review is easier when the tool shows where each statement came from. Complizen's Drafting Studio links every claim in a draft to its source, so a reviewer can check the citation rather than trust the sentence.
What does validating an AI tool look like?
FDA does not prescribe one method. It asks for assurance activities in proportion to risk [1]. For high process risk features, FDA suggests more rigor, such as scripted testing or a mix of scripted and unscripted testing. For lower-risk features, it suggests unscripted methods such as scenario testing, error guessing and exploratory testing [1].
A practical sequence for an AI tool, built on FDA's framework:
- Write the intended use for each feature. For example: "Drafts a first-version complaint summary for review by a complaint handler." One tool can have several features with different risks [1].
- Assess the risk of each feature. Use FDA's high process risk criteria, and record the human review and other controls you rely on [1].
- Evaluate the vendor. FDA lets you start from the vendor's own development and validation work. It suggests reviewing certifications such as Service Organization Controls reports, the vendor's software development and cybersecurity practices, and data integrity controls such as audit trails and access controls. FDA accepts that an onsite audit of a software vendor may not be feasible [1].
- Build a test set from your own records. Use real inputs where you already know the right answer, such as past complaints already assessed by your team. Compare the tool's output against those answers.
- Add error guessing. AI tools fail in typical ways. Test for invented citations, wrong standard versions, missing information that the tool fills in instead of flagging, and inputs outside the tool's scope. Run important cases more than once, because many AI tools do not give the same answer twice.
- Record the result and approve it. The next section lists what the record should contain.
- Monitor in use. FDA counts data the software collects to detect issues after go-live as part of a comprehensive assurance approach [1].
Steps 4 and 5 are our recommendations for AI tools, not FDA wording. They apply FDA's request to identify reasonably foreseeable failures to the way AI tools actually fail [1].
What record should you keep?
FDA recommends a record with enough objective evidence to show the feature was assessed and performs as intended. In general, it should include [1]:
- The intended use of the feature, function or operation.
- The result of the risk-based analysis.
- A description of the testing done.
- Issues found, such as deviations, defects or failures.
- A conclusion that the software is acceptable for its intended use, with how any issues were resolved.
- Who did the testing and when.
- Review and approval, when appropriate.
FDA says the record need not include more evidence than necessary for the risk identified [1]. It also recommends digital records, such as system logs, audit trails and other data the software already keeps, instead of screenshots or paper copies [1]. For an AI tool, add the model name and version you tested. Without it, you cannot show later which model your evidence covers.
When does Part 11 apply, and do you need an audit trail?
Part 11 sets FDA's criteria for trusting electronic records and electronic signatures [3]. It applies to records in electronic form that are created, modified, maintained, archived, retrieved or transmitted under FDA's record requirements [3]. FDA's CSA guidance says that a document required under Part 820, kept in electronic form, would generally be an electronic record under Part 11 [1].
So the question for an AI tool is whether it creates or keeps a required quality record. FDA gives two contrasting examples. Documentation showing that a system correctly automates checks on materials before production would generally fall under Part 11. Routine activity logs that a commercial tool saves automatically, which are not needed as validation evidence, would not [1].
Part 11's audit trail requirement asks for secure, computer-generated, time-stamped audit trails. They record operator entries and actions that create, modify or delete electronic records, without hiding earlier entries [3]. Since 2003, FDA has said it intends to use enforcement discretion on this specific requirement. You must still meet the underlying record rules, including that changes to records do not hide earlier entries [4]. FDA recommends deciding whether to use audit trails based on a documented risk assessment. It notes that audit trails are particularly appropriate when users create, modify or delete regulated records during normal operation [4].
Two points are easy to miss:
- Validation is not covered by that discretion. FDA also uses enforcement discretion on Part 11's own validation clause. But the CSA guidance states that this discretion does not apply to validation required under ISO 13485 Subclauses 4.1.6, 7.5.6 and 7.6 [1].
- Submission drafts are a separate case. A record used to generate a submission, but not submitted itself, is not a Part 11 record. The exception is when a predicate rule otherwise requires you to keep it in electronic form [4]. Accuracy is still your responsibility, and our guide to using AI to draft a 510(k) covers how to check AI-drafted content.
If you use Complizen as part of your quality system, the same rules apply to it. Complizen's cloud workspace logs every action with a timestamp, user and change detail, and exports it as a Part 11-style log for your quality system. You still decide its intended use, assess its risk and validate it, like any other tool.
What happens when the AI model changes?
ISO 13485 requires revalidation after changes to the software or its application, as appropriate, in proportion to risk [1, 7]. AI tools change more often than most software. A vendor can replace the underlying model, and your own team may change prompts, instructions or configuration.
To stay in a validated state, which FDA makes your responsibility [1]:
- Know when the model changes. Ask the vendor how it announces model changes, and record that in your supplier controls.
- Keep your test set. When the model, prompts or configuration change, run the same test set again and compare results with your baseline.
- Scale the response to the risk. A change to a high process risk feature needs more evidence than a change to a complaint-routing feature [1].
- Watch for drift. Track the reviewer corrections the tool needs. A rise is a signal to reassess.
If your device has an approved PMA, check one more thing. FDA's guidance explains when a change to production or quality system software must be reported in a 30-day notice and when an annual report is enough [1].
What does FDA actually cite?
FDA publishes counts of the observations its investigators cite on Form 483 after inspections [5]. These counts come from 483s issued through FDA's electronic system, and they cover the old Quality System regulation, before the QMSR took effect:
| Fiscal year | Device 483s issued | Software validation for automated processes (820.70(i)) | Purchasing controls (820.50) |
|---|---|---|---|
| 2022 | 538 | 17 | 139 |
| 2023 | 720 | 21 | 196 |
| 2024 | 672 | 29 | 160 |
| 2025 | 791 | 20 | 190 |
| Total | 2,721 | 87 | 685 |
Software validation is not among the most cited problems, but it shows up every year. Purchasing controls are cited far more often, and most AI tools are bought from vendors. Under the QMSR, both requirements now come through ISO 13485 [2].
Frequently asked questions
What does AI tool validation under the QMSR require?
AI tool validation under the QMSR means showing that an AI tool used in production or your quality system works for its intended use. ISO 13485 requires this before first use and after changes, in proportion to risk. FDA's 2026 software assurance guidance explains how, and it names AI tools directly.
Do I need to validate ChatGPT or similar tools?
Only for uses that are part of production or your quality system. Drafting emails or general business writing is outside the requirement. Using the same tool to draft CAPA investigations, assess complaints or write labeling brings that use inside it. Validate each use in proportion to its risk.
What is FDA's Computer Software Assurance guidance?
It is FDA's guidance on validating software used in production and the quality system. FDA updated it on February 3, 2026, using QMSR terms. It sets out a risk-based approach, accepts unscripted testing for lower-risk features and supersedes Section 6 of FDA's 2002 software validation guidance.
Is an AI tool that writes labeling high risk?
Often, yes. FDA lists software that produces instructions for use or other labeling needed for safe operation as generally high process risk. Real human review, with clear acceptance criteria, is a control you can count. It does not remove the need to validate the tool.
Does human review of AI output count as validation?
Human review is a control, not a validation by itself. FDA lets you count controls elsewhere in your quality system to reduce the assurance effort for a tool. You still need a validation record showing the tool's intended use, risk analysis, testing and conclusion.
Does Part 11 apply to AI tools?
It applies when the tool creates or keeps a record required under Part 820 in electronic form. FDA's guidance says such a document would generally be an electronic record under Part 11. Routine logs that are not needed as evidence of a validated state generally fall outside Part 11.
Do I need an audit trail for my AI tool?
FDA uses enforcement discretion on Part 11's audit trail requirement. You still must make sure changes to records do not hide earlier entries. FDA recommends a documented, risk-based decision, and notes that audit trails are particularly appropriate when users create, modify or delete regulated records.
How do I validate a cloud or SaaS AI tool?
The same way as other software, starting with its intended use and risk. FDA's guidance covers software as a service. You can rely on the vendor's own validation work and certifications, such as Service Organization Controls reports, and add your own testing where the risk calls for it.
What happens when the AI vendor updates the model?
A model change is a software change, so ISO 13485 requires revalidation as appropriate. Ask the vendor how it announces changes, keep your test set, and run it again after each change. Scale the work to the risk of each feature. Record the model version you tested.
What should a validation record include?
FDA recommends recording the intended use, the risk-based analysis, a description of the testing, issues found and how they were resolved, a conclusion that the software is acceptable, who tested it and when, and approval where appropriate. Digital records and system logs can serve as evidence.
Can AI-drafted 510(k) content be a Part 11 record?
Usually not by itself. FDA's Part 11 guidance says a record used to generate a submission, but not itself submitted, is not a Part 11 record unless a predicate rule otherwise requires you to keep it electronically. You are still responsible for the accuracy of everything you submit.
How often does FDA cite software validation at inspections?
FDA's published 483 data shows 87 citations for software validation of automated processes on device 483s from fiscal years 2022 to 2025, out of 2,721 device 483s issued through its system. Purchasing controls were cited 685 times in the same period.
References
- FDA. Computer Software Assurance for Production and Quality Management System Software. Final guidance, February 3, 2026.
- FDA. Medical Devices; Quality System Regulation Amendments (21 CFR 820.10). Final rule, Federal Register, February 2, 2024, effective February 2, 2026.
- eCFR. 21 CFR Part 11, Electronic Records; Electronic Signatures (§§ 11.1, 11.3, 11.10). Current as of October 2026.
- FDA. Part 11, Electronic Records; Electronic Signatures: Scope and Application. Final guidance, August 2003, content current as of August 24, 2018.
- FDA. Inspection Observations, device data for fiscal years 2022 to 2025. Accessed October 13, 2026.
- FDA. Warning Letter to Purolea Cosmetics Lab, MARCS-CMS 722591. April 2, 2026.
- ISO. ISO 13485:2016, Medical devices: Quality management systems, Requirements for regulatory purposes, Subclauses 4.1.6, 7.5.6 and 7.6, as incorporated by reference in 21 CFR 820.7.
- FDA. General Principles of Software Validation. Final guidance, January 2002, content current as of May 15, 2019.