Right now, somewhere in your building, an engineer is drafting a protocol with Copilot. Someone in regulatory affairs is summarizing a complaint file with ChatGPT. A vendor switched on an AI feature inside your eQMS last month and didn’t mention it in the release notes. And none of it — not a single use — is in a procedure.
This is not a hypothetical. This is Tuesday.
The instinct from quality is usually one of two things: block it all, or pretend it isn’t happening. Neither works. If you block it, people use it anyway — they just stop telling you. If you ignore it, you have AI-generated content in quality records with no documented qualification, no risk assessment, and no answer when the investigator asks how it got there.
There is a third option, and it starts with understanding what the regulations actually require.
The Regulatory Landscape: It’s Already Covered
Here’s the part that surprises people: there is no new regulation you need to worry about. The existing framework already covers AI tools in your quality system. You just have to read it with fresh eyes.
ISO 13485:2016, Clause 4.1.6 requires that “computer software used in the quality management system shall be validated.” That’s it. The clause doesn’t care whether the software is an ERP, a spreadsheet, or a large language model. If it’s computer software and you’re using it in your QMS, you validate it. The QMSR — which has been in force since February 2026 — incorporates ISO 13485 by reference, so this requirement now has the force of FDA regulation behind it.
FDA’s Computer Software Assurance guidance, finalized on 3 February 2026 under the title Computer Software Assurance for Production and Quality Management System Software, goes further. It expressly names AI and ML tools as in scope. That one sentence is the most important thing in the document for quality departments, because it closes any argument about whether AI tools need assurance activities at all. They do.
The good news: the same guidance replaces the old Computer System Validation (CSV) approach with a risk-based model. You don’t need to validate every button and dropdown. You need to establish confidence that software is fit for its intended use — and the assurance activities scale with the risk. The guidance explicitly says “sufficient evidence of confidence, but no more than necessary.”
And then there’s ISO/IEC 42001:2023, the AI management system standard. You don’t need to certify against it tomorrow. But its responsible-use controls — impact assessments, AI-specific risk management — are what auditors reference when they ask how you govern AI. Worth knowing it exists.
Why the Old Approach Doesn’t Work
Traditional software validation assumes the system you qualified yesterday is the system you’re using today. That was a reasonable assumption for an on-premise ERP that updated once a year with a change control form and a service technician.
AI tools are not that.
ChatGPT’s underlying model has changed multiple times since it launched. Copilot gets capability updates that aren’t announced in your vendor’s release notes. Cloud-based AI features can change behavior between the morning you qualified them and the afternoon you used them. A qualification with no revalidation trigger and no way to detect change describes a state that ended when the vendor pushed an update.
This is the gap that catches quality teams. They either apply the full CSV apparatus to everything — spending weeks validating a tool someone uses to brainstorm CAPA root causes — or they skip it entirely because the effort feels disproportionate. Both approaches end the same way: with documentation that doesn’t match reality.
What a Practical Approach Looks Like
The answer is risk-tiered qualification. Most AI use in a quality system is low-risk — drafting, brainstorming, summarizing content that a qualified person reviews before it enters any record. These uses need a documented decision, not a validation protocol. You assess the risk, record the rationale, define the controls (usually “independent review before use in a regulated document”), and move on. An afternoon, not a quarter.
The small number of high-risk uses — an AI tool writing directly into a complaint database, or generating content that feeds a regulatory submission — those deserve rigorous validation. Scripted testing. Challenge sets. Defined acceptance criteria. And critically, revalidation triggers tied to model updates, because the thing you’re qualifying will change.
The framework needs to tell quality teams three things: what tier is this use case, what assurance activities does that tier require, and when do I need to re-qualify?
A Toolkit for Exactly This
This is the problem we built the AI Use Qualification Toolkit to solve. It’s a complete, adoptable system for qualifying AI tools in a medical device quality environment — built on FDA’s CSA logic, ISO 13485 clause 4.1.6, and ISO/IEC 42001’s responsible-use controls.
The core of it is an interactive triage tool: describe your use case, and it returns a risk tier, the reasoning, the specific assurance activities required, and the records to produce. It runs in your browser, offline — nothing you type leaves the file. Around it: a governing SOP, qualification and validation forms scaled by tier, a live AI use register with a monitoring log, a regulatory crosswalk, and an employee quick guide in plain language.
The part I think matters most: it tells you which uses are low-risk and lets you approve them quickly, so the effort lands on the small number of cases that genuinely need weeks. Because the fastest way to lose control of AI in your quality system is to make the approval process so painful that people stop asking.
Your people are already using AI. The question isn’t whether to allow it — that ship has sailed. The question is whether quality has a documented, defensible, risk-based answer when someone asks how you qualified it. And right now, for most companies, the honest answer is: we haven’t.
That’s fixable. And sooner is better than after the investigator asks.