I host a podcast conversation almost every week with someone building software as a medical device (SaMD), and the same problems keep showing up. Teams understand the technology, they can explain what their model does, how it was trained, and why it works... What trips them up is the compliance architecture around it: the plan for change, the proof of data quality, the system that watches the algorithm after it ships. That's where FDA deficiency letters come from, so I want to talk about the specific mistakes instead of talking about AI regulation in the abstract.
I covered the regulatory framework itself in a previous piece on what the FDA actually says about AI in medical devices: what SaMD means, the difference between a locked algorithm and an adaptive one, and what the guidance actually asks for. This piece is the other half. These are the mistakes I keep seeing SaMD teams make once they start to apply that framework to a real device.
A predetermined change control plan (PCCP) tells the FDA what changes you expect to make to your algorithm after clearance, how you'll validate them, and how you'll determine performance. Too many teams write it the week before submission, as a description of what they hope their process looks like. A reviewer can tell the difference between a PCCP that describes a real development process and one reverse engineered from the regulation. If your change control procedure, your validation protocol, and your PCCP are not the same document wearing different hats, you have written fiction for a regulator whose job is to catch it. Our breakdown of the FDA requirements that catch SaMD teams off guard goes deeper on where this specifically breaks down.
The FDA wants to know where your training, validation, and testing data came from, and whether it represents the population you intend to treat. This is not a one-time checkbox exercise. An algorithm that performs well in aggregate can still fail badly on a specific subpopulation, and that failure can be a safety issue. Teams that only look at overall accuracy find this out from a reviewer, or worse, from a complaint. Our breakdown of the Purolea warning letter shows what this looks like once it becomes a regulatory action instead of an internal finding.
BONUS RESOURCE: Click here to download the 3-in-1 SaMD Gap Assessment Tool.
Most quality management systems were built to control physical parts and documents that do not change once approved. An adaptive algorithm breaks that assumption by design. If your QMS has no mechanism for algorithm-specific risk categories under ISO 14971 and its companion guide, AAMI TIR34971, you're trying to govern software change with a system built for bill-of-materials revisions. The fix is not a new binder. It is design controls and risk management built around the fact that the thing you are controlling keeps moving.
FDA clearance for an AI-enabled device is a checkpoint, not an ending. Teams that plan their quality system around getting to clearance, and stop there, are building for the wrong milestone. The total product lifecycle model assumes multiple checkpoints as the algorithm evolves, and a quality system that cannot show ongoing monitoring is a quality system designed for a static product.
Traditional post-market surveillance is reactive: something goes wrong, a customer reports it, the company investigates. That model does not hold up for an adaptive algorithm, because by the time a pattern of complaints appears, the algorithm may have already drifted well outside the bounds you validated. Proactive monitoring that tracks real-world performance against the validated baseline and catches drift before it becomes a safety event is the standard the FDA is moving toward. Companies that have not built that habit yet are the ones most likely to get a deficiency letter that starts with "please describe your process for monitoring." Our guide on how to validate the AI and ML in your medical device before it ships covers the validation side of this same problem.
These mistakes are the predictable result of applying a hardware mindset to a product that is designed to change. Teams that get this right build their quality infrastructure around change from day one: version-controlled design history that tracks algorithm iterations the way a software team tracks releases, risk files that treat a false negative in one subpopulation as its own failure mode, and surveillance that pulls real-world performance data automatically instead of waiting for a complaint to land in an inbox. Our piece on what competent AI use actually looks like inside a medical device team walks through what that looks like day to day.
Spark Biomedical went through this shift while scaling a novel neurostimulation device and cut its overall product development timeline by 50% once its quality system stopped fighting the engineering process and started matching it. That is the difference between a QMS that treats every change as an exception and one built to expect it.
BONUS RESOURCE: Click here to download the 3-in-1 SaMD Gap Assessment Tool.
If you are building your quality system around an AI-enabled device, these related pieces go deeper on the specific pieces:
If your team is building an AI-enabled device and your QMS still assumes nothing changes after clearance, that gap is worth closing before a reviewer finds it for you. Greenlight Guru is built for design control and risk management work at software speed, without asking you to trade the audit trail for it. Get a demo and see what that looks like for your device.