An AI Model You can Defend in an Audit
What MLOps discipline in QMS means for building AI-enabled devices
Every AI-enabled imaging product I have taken through FDA had a moment, usually after clearance, when someone asked which model version was running at a given site and what data it had been trained on. The teams that could answer in minutes had built the plumbing early. The ones that could not spent weeks reconstructing it. FDA’s QMSR, in force since 2 February 2026, and the arrival of AI models inside the quality system itself make that plumbing a compliance matter, not just good engineering.
Abhineet Johri, Regulatory Affairs Manager and Senior Key Expert for AI at Siemens Healthineers, a contributor to MITA and IEC SC 62B standards work on AI, and a former colleague of mine, takes that question on in the November 2026 issue of the Journal of Medical Device Regulation (“An MLOps framework for AI-integrated quality management systems”). His premise fits in one sentence: code does not drift, models do. A defect-detection model trained on last quarter’s data can start missing issues when the process shifts, and nobody notices until something escapes downstream. His answer is a practical MLOps framework in five parts, and he shows how each one lines up with 21 CFR Parts 11 and 820, ISO 13485 and ISO 9001:
- Automated data pipelines, with validation gates ahead of training, consistent labelling with a record of who labelled what and when, and a documented line from raw image to training set.
- Continuous monitoring with three alert tiers, each tied to an action and a clock. A warning gets reviewed within a day. An alert (accuracy or drift past threshold) puts retraining on the table within hours. A critical alert triggers automatic fallback and a notification within 15 minutes.
- Retraining on conditions, not a calendar: a drift or accuracy threshold crossed, enough newly labelled data, a known upcoming process change, or a maximum interval as a backstop.
- A model registry treated as a QMS record: training data, hyperparameters, performance metrics, approvals and deployment details, with data lineage behind it.
- Controlled deployment: run the new model in shadow mode first, where it sees live data but makes no decisions; then hand it a small share of the work (5%, then 25%, 50%, 100%) while the old model keeps running; and have a tested rollback plan written before anything ships.
The real test comes when the auditor arrives. Auditors, he notes, tend to ask the same five things: how the model was developed and validated, how it is deployed and monitored, how changes are managed, how data are handled, and whether the documentation exists and has been retained. The answers should already be there. That is compliance by design: validation evidence, approvals and change records are generated and maintained as part of the MLOps workflow, not assembled retrospectively for an audit. In a regulated quality environment, that makes MLOps the difference between a model that can be defended in an audit and one that cannot.
From the production line to the reading room. Abhineet’s article is about AI inside the QMS. Anyone who has shipped AI as the device will recognize all five parts, and will also notice the one thing his factory model has that a cleared device model never did: permission to change. When one of his retraining conditions is met, the factory model is retrained, validated and released under the company’s own change control. I lived the other version. The CAD products I was responsible for at Siemens, LungCAD and ColonCAD among them, never drifted by surprise. Every new scanner generation, reconstruction kernel, dose protocol and patient population was expected to move performance, so every new system was in the conversation with the scanner product managers long before release. A technical comparison could sometimes justify a letter to file; as product manager I still asked for performance data on the new system and kept adding to the training pool. A larger change meant a new 510(k). Either way, the retrained version usually existed well before its clearance did. Models marketing wanted to sell waited in a queue behind clearance, and research might have to pause because the pipeline was full.
There was a subtler problem too. A retrained model is not a patched one. It finds some new true positives and loses a few old ones, even when aggregate performance holds or improves, because it now covers scanners and protocols the old one did not. FDA understood that. Customers who re-ran the new version on old cases and watched findings appear and disappear did not, and explaining it was a recurring conversation.
The PCCP addressed the first problem and gives you a place to handle the second. It is not new: statutory since FDORA in 2022, with final guidance for AI-enabled device software in December 2024. The retraining conditions, acceptance criteria and staged rollout Abhineet describes are exactly what a modification protocol asks for. Written down and authorized with the submission, they turn a model update from a submission event into a controlled change. And the acceptance criteria are where you decide, in advance, how much case-level variation between versions you will accept and how you will explain it to the people reading the output, so the next version does not surprise them. Whether a model inspects a part or reads a CT scan, the reviewer and the auditor ask the same five questions.
If you are building an AI-enabled device, treat the model registry, data lineage and performance monitoring as part of the design history file from day one, and write the retraining triggers, acceptance criteria and rollout plan into the PCCP before you submit. They are what make a PCCP credible to a reviewer, what make a field performance question answerable, and what keep a model update from becoming a new submission. Retrofitting them after the first audit finding is the expensive way to learn this. And regulatory affairs is not a passenger you pick up at the last stop; it is the partner you plan the journey with.
The article appears in JMDR November 2026, Volume 23, Issue 4, alongside a timely companion piece on simultaneous compliance with the US QMSR, EU MDR and MDSAP, and was announced by Global Regulatory Press on LinkedIn. Subscription and single-issue options are at globalregulatorypress.com.
Abhineet and I were colleagues at Siemens Healthineers. The opinions here are my own.
