A team finishes validating an imaging-AI model. The test set is curated, the metrics are stable, the verification report is signed. Then someone asks whether the system is cleared for clinical use — and the room goes quiet, because that is a different question entirely. This is the gap most engineering teams discover too late. Engineering validation proves that a system does what its specification says it does. FDA medical device regulation asks whether the system is safe and effective for a defined clinical use in the hands of intended users. Those two questions overlap, but they are not the same question, and the work that satisfies one does not automatically satisfy the other. What FDA Medical Device Regulation Actually Governs When imaging-AI software performs a medical function — flagging a suspicious region, measuring an anatomical structure, triaging a worklist — it is frequently regulated as Software as a Medical Device (SaMD). That status is not determined by how the software is built. It is determined by its intended use and the clinical claim it makes. A model that outputs a diagnostic suggestion is in scope; the same architecture trained to sort logistics images is not. The regulatory framework cares about a chain of evidence that engineering validation rarely produces on its own. The FDA’s central question is whether the device’s intended use is supported by clinical evidence under the conditions it will actually be deployed. A verification report showing 94% sensitivity on a held-out set is an input to that argument — it is not the argument itself. There are three distinct things the regulation governs that an engineering validation plan typically does not: Intended use and indications for use. The precise clinical claim, patient population, body region, modality, and operator. Narrowing or broadening this statement changes the entire evidence burden. Clinical validity and the risk it carries. Not just “does the model perform” but “what is the harm if it performs wrong, and how likely is that harm in real use.” The change-control commitment over the device’s lifetime. How the model may be updated after clearance, and what re-evaluation each class of change triggers. The FDA’s proposed framework for a Predetermined Change Control Plan (PCCP) exists precisely because adaptive imaging-AI models do not hold still. A model that is retrained, re-thresholded, or re-deployed on a new scanner is, from a regulatory standpoint, potentially a different device. We treat that as a first-class design constraint, not a post-clearance afterthought. Why “We Validated It” Is the Wrong Frame The most common misconception we encounter is that thorough engineering validation is the regulatory work, minus some paperwork. It isn’t, and the reason matters. Engineering validation answers a closed question: given this specification, this dataset, and these acceptance criteria, does the system pass? It is reproducible, bounded, and largely under the team’s control. Regulatory clearance answers an open question: in the messy clinical environment this device will enter, with the scanners, protocols, demographics, and operators it will actually meet, is it safe and effective? That question is not fully under the team’s control, and it cannot be closed by a single test campaign. The divergence shows up most sharply around dataset representativeness. A model can pass every engineering acceptance criterion on a test set that quietly fails to represent the deployment population — under-sampled demographics, a single scanner vendor, one imaging protocol. The verification report is honest; the clinical claim built on it is not portable. This is the same boundary problem we describe in how computer-aided diagnosis software works and where validation decides whether it holds: the model can be technically correct and clinically unsupported at the same time. This is why the boundary between validation and clearance is best treated as a handoff with a contract, not a wall. The distinction between where validation ends and clearance begins is the spine of any credible regulatory strategy for imaging AI, and getting the artifacts to line up across that handoff is where most of the avoidable rework lives. Engineering Validation vs Regulatory Clearance: Where the Line Sits The cleanest way to keep teams out of trouble is to be explicit about which question each activity answers. The table below is the decision rubric we use when scoping an imaging-AI program — it is extractable on its own, and it is the artifact most teams wish they had drawn at the start rather than the end. Activity Answers Owns the question Output Unit / integration testing Does the code match its spec? Engineering Verification report Model performance validation Does the model hit its metrics on a defined set? Engineering Validation report (benchmark-class) Dataset representativeness analysis Does the test set reflect the deployment population? Shared (eng + clinical/regulatory) Population-coverage evidence Intended-use / indications definition What clinical claim are we making? Regulatory + clinical Intended-use statement Clinical evidence generation Is the claim supported in real use? Clinical / regulatory Clinical evaluation Risk classification (SaMD) What harm if it fails, how likely? Regulatory + quality Risk file Change-control plan (PCCP) How may the model change post-clearance? Regulatory + engineering Predetermined change control plan Read top to bottom, the table is a maturity gradient. Teams that are strong on the first two rows and silent on the rest are not “almost cleared” — they have completed the part of the work that was always under their control and have not yet started the part that determines whether the device reaches patients. In our experience this asymmetry is the single most reliable predictor of a stalled submission (observed across life-sciences engagements; not a published benchmark). What Triggers a New Regulatory Question After Clearance? This is the question that separates teams who built imaging AI from teams who built a regulated imaging AI program. Clearance is a snapshot of a device at a moment. The model rarely stays at that moment. A few changes are routine and well-contained. Most are not. Retraining on new data, adjusting an operating threshold, adding a new scanner model to the supported list, or extending the indication to a new body region — each can constitute a modification that requires re-evaluation, and in some cases a new submission. The PCCP framework lets a manufacturer pre-specify which changes are anticipated and how each will be validated, so that anticipated modifications do not each force a fresh clearance cycle. What it does not do is grant a blanket license to evolve the model freely; market-direction signals from the FDA point toward more structured lifecycle oversight of adaptive AI, not less. The practical consequence is that change control has to be an architectural decision, not a documentation chore added at the end. A system designed so that retraining is traceable, threshold changes are logged, and the deployment population is monitored for drift can map cleanly onto a PCCP. A system that treats the model as an opaque, frequently-replaced artifact cannot — and that mismatch surfaces during, not before, the submission. The same discipline underpins what we describe in what a clinical-grade medical imaging AI validation engagement actually looks like: the validation work has to be designed to be re-runnable, because the regulator will assume the model will change. There is also a workflow boundary that is easy to conflate with the device boundary. Whether a deployment is HIPAA- or GxP-ready is a separate question from whether the device is cleared; a cleared model running inside a non-compliant data workflow is still a compliance failure. We pull those threads apart in what makes an AI or video workflow HIPAA- or GxP-ready. A Worked Boundary: One Model, Two Questions Consider a chest-radiograph triage model, built in PyTorch, exported to ONNX, and served behind a Triton inference endpoint. Suppose it measures 92% sensitivity for the target finding on a held-out internal set drawn from two hospital sites and one scanner vendor. The engineering question is answered: the model meets its specification, the inference path is deterministic, the verification report is signed. The regulatory question is wide open. Two sites and one vendor do not establish that the 92% figure (benchmark-class, single-source) holds across the demographics, protocols, and equipment of the intended-use population. The intended-use statement has not been written. The harm of a missed finding has not been formally classified. The plan for what happens when the model is retrained next quarter does not exist. None of those gaps are engineering defects. They are the regulatory half of the program, and the worked example exists to make one point unmissable: a perfectly valid model and an unclearable device can be the same artifact at the same time. FAQ Is engineering validation enough to get an imaging-AI device cleared by the FDA? No. Engineering validation proves a system meets its own specification on a defined dataset, which is a necessary input but not the whole regulatory argument. FDA clearance additionally requires a defined intended use, clinical evidence supporting that claim in real deployment conditions, a risk classification, and a change-control commitment. The validation report feeds the submission; it does not replace it. When is imaging-AI software regulated as a medical device? It depends on intended use, not architecture. When the software performs a medical function — flagging a finding, measuring anatomy, triaging cases — and makes a clinical claim, it is typically in scope as Software as a Medical Device. The same model architecture used for a non-clinical task is not regulated as a device. What changes to a cleared imaging-AI model require re-evaluation? Retraining on new data, changing an operating threshold, adding a new supported scanner, or extending the indication can each constitute a modification requiring re-evaluation, and sometimes a new submission. The FDA’s Predetermined Change Control Plan framework lets manufacturers pre-specify anticipated changes and their validation method, so those changes do not each force a fresh clearance cycle. It does not authorize unbounded model evolution. Why can a model pass every engineering test and still fail regulatory review? Because the two ask different questions. A model can hit every acceptance criterion on a test set that fails to represent the deployment population — under-sampled demographics, a single scanner vendor, one protocol. The verification report is honest, but the clinical claim built on it is not portable, and regulatory review evaluates the claim under real-use conditions. Drawing that boundary cleanly is the spine of the imaging-AI validation work we take on in life sciences. The honest version of this work starts by drawing the boundary before any code is written: which questions engineering will close, which questions clearance will close, and how the artifacts cross between them. If your imaging-AI program can answer “what triggers a new regulatory question” before it ships, the representativeness-and-change-control failure class that stalls most submissions is no longer waiting to be discovered.
