“We used to regulate the machine; now we regulate its leash. When software learns on its own, compliance stops being about what you shipped and starts being about proving the boundaries where it’s allowed to roam.”
The Assumption We Did Not Question Until it Stopped Being True
IEC 62304’s entire verification and validation model rests on one premise: the software you tested is the software that ships, and it behaves the same way in month twelve as it did on day one. Fixed inputs, fixed logic, fixed outputs. You verify it once, you validate it once, and short of a formal change control process, that behavior is locked.
An AI model that learns, adapts, or gets retrained on new data doesn’t hold up its end of that bargain. The thing you verified in your V&V report is not, strictly speaking, the thing running in production six months later. That’s not a compliance gap you patch with better documentation. It’s a structural mismatch between how the standard thinks about software and how modern AI actually behaves.
This is exactly why regulators didn’t just tweak a definition here and there. In the US, the FDA’s own guiding principles document acknowledges that predetermined change control plans exist specifically because deployed AI models need to be monitored and managed for continuous learning, something classic software change control was never designed to anticipate. (FDA)
The Real fix least likely V&V binder, it Probably is Leash
The FDA finalized its guidance on Predetermined Change Control Plans for AI-enabled device software functions in December 2024, and it’s worth reading closely if you haven’t. (FDA) A PCCP has to describe the planned modifications, the methodology to develop, validate, and implement them, and an assessment of their impact, submitted and authorized before the changes happen, not after. Once authorized, the manufacturer can only implement the modifications the plan actually describes, deployed exactly the way the plan specifies. Step outside that, and you’re back to a new submission. (FDA)
That’s a genuinely different discipline than classic 62304 change control. You’re not asking “did we change the software,” you’re asking “did the software change itself within limits we already proved were safe.” Most QMS documentation I’ve seen still isn’t structured to answer that second question at all.
Europe is converging on the same idea from a different angle. The joint MDCG/AI Board guidance on how the AI Act interacts with MDR and IVDR explicitly flags “significant change” as the open problem for AI systems that keep evolving after they’re placed on the market, and points to PCCP style mechanisms as the likely mitigation, with the International Medical Device Regulators Forum currently developing the framework that EU guidance will probably build on. (European Commission)
The Classification Arbitrage We are missing to Pricing In
Here’s the part that should be a bigger conversation at the strategy level than it currently is. Under the EU AI Act, an AI system embedded in or constituting a medical device under MDR is captured directly by Article 6 and Annex I, which means it’s treated as high risk by definition, not by a case by case risk assessment. (European Commission) Most such devices land at Class IIa under MDR or higher, which means a Notified Body is involved regardless of how modest the actual clinical claim feels.
Compare that to the US side, where the FDA’s PCCP pathway is explicitly designed to let manufacturers avoid a new marketing submission every time they want to meaningfully update a model, provided the update was pre-authorized. (FDA) One system is built to keep pulling you back into full conformity assessment as your AI evolves. The other is explicitly engineered to let you keep iterating without going back to the regulator each time, as long as you did the upfront work.
Put those two facts next to each other and you get a real strategic decision, not a compliance checkbox: the same evolving AI product can face a fundamentally different long term regulatory rhythm depending on which market it launches into first. I don’t see enough companies sequencing their market entry around that difference on purpose. Most default to “wherever our investors expect us to launch first,” when the regulatory mechanics might argue for a different order entirely.
Where this leaves Veterans and the Beginners
If you’ve been doing this for a decade, the mistake isn’t misunderstanding the classification rules anymore. It’s applying a static mental model, verify once, document once, submit once, to a category of software that was never built to sit still. The organizations that are going to have a bad year are the ones treating PCCP, or its coming EU equivalent, as a checkbox in the submission rather than as the core architecture decision it actually is.
The ones who get ahead of this are the ones asking a harder question earlier: not “what class is this,” but “what happens the day this model behaves differently than the version we submitted, and did we already prove that was allowed.”
That’s the conversation worth having. Curious whether others are seeing the same gap between how QMS documentation is structured today and what PCCP actually demands, or whether I’m overstating it.
