Medical Device AI Is Hitting the FDA Regulatory Wall — And Systems Engineering Is the Unlock
The FDA’s evolving framework for AI/ML-based Software as a Medical Device (SaMD) — including the Predetermined Change Control Plan (PCCP) guidance — is creating new systems engineering obligations for medical device makers. Analyze what the PCCP requirement means in practice, how device makers are structuring requirements for AI components that are designed to change post-market, and what the FDA is actually looking for in traceability and change management documentation. Explore where current engineering practices fall short and what needs to change.
Current State: A Framework That’s Ahead of Most Engineering Organizations
The FDA finalized its PCCP guidance in December 2023. By any reasonable measure, the agency moved faster than most medical device engineering teams were prepared for.
Here’s the core problem the guidance is solving: traditional medical device regulation assumes software is static. You submit, you get clearance, you ship. Any change to the device — including software — triggers a new submission or a 510(k) change assessment. That model made sense when software was deterministic and version-controlled in the traditional sense. It does not work for AI/ML components that improve through retraining, adapt through feedback loops, or update their decision boundaries on a rolling basis.
The PCCP is the FDA’s solution. A device maker can describe, upfront, a set of anticipated modifications to an AI/ML component — along with the methodology used to implement them, the performance criteria used to validate them, and the impact assessment logic used to confirm they stay within approved boundaries. If the changes stay within that pre-approved envelope, the device maker can make them without a new submission.
This is genuinely useful. It creates a pathway for continuous improvement that the traditional regulatory model never had.
The catch: it requires device makers to specify their AI change architecture at submission time with a level of rigor that most organizations have never applied to software requirements. The FDA isn’t asking you to document what your AI does today. It’s asking you to document the boundary conditions within which it may change, the methodology by which changes will be validated, and the traceability logic that confirms any given change is still within scope.
Most engineering teams do not currently build their requirements architectures this way.
What the PCCP Actually Requires — In Engineering Terms
Strip away the regulatory language and the PCCP has three concrete technical obligations.
First: Modification Description. The device maker must identify the specific modifications anticipated during the post-market lifecycle. This is not a general statement like “the model may be retrained periodically.” It requires specifying the type of modification (e.g., changes to model architecture, changes to training data inputs, changes to preprocessing algorithms), the scope of the modification, and the rationale for why these modifications are clinically appropriate.
In engineering terms, this means you need a taxonomy of change types for your AI component, defined at submission, with each type mapped to a scope boundary. Teams that have only ever described their AI system at the functional level — “the algorithm classifies anomalies in retinal scans” — have to go much deeper. You need a requirements architecture that distinguishes between what the system does, how it does it, and within what performance envelope it is permitted to change any of those parameters.
Second: Methodology for Implementing Modifications. The PCCP must describe the process by which modifications will be developed and validated. This includes dataset management, model development practices, performance testing protocols, and the predetermined performance thresholds that constitute acceptable change.
This is essentially a systems engineering process requirement embedded in a regulatory document. The FDA is asking for evidence that your engineering organization has a repeatable, auditable process for change — not just that a specific change was tested adequately. Teams that rely on ad hoc validation practices for AI updates, even rigorous ones, will struggle here. The methodology has to be defined, documented, and referenced in the original submission.
Third: Impact Assessment. Before implementing any modification described in the PCCP, the device maker must conduct an impact assessment confirming the change remains within the approved envelope. This assessment must be documented and retained in the design history file (DHF).
This is where most current engineering practices break down completely. Impact assessment for a discrete software change in a traditional system is difficult enough — you trace the change to affected requirements, assess downstream risk, document the analysis. For an AI system where a change to training data may propagate to model behavior in non-obvious ways, and where that behavior may interact with clinical workflows in ways that weren’t modeled during original development, impact assessment becomes a genuine systems engineering problem.
Where Current Engineering Practices Fall Short
Talk to systems engineers at medical device companies attempting PCCP compliance and a consistent pattern emerges. The failure modes aren’t random — they cluster around specific structural weaknesses in how engineering organizations currently handle AI components.
The AI component is treated as a black box in the requirements architecture. In many SaMD programs, requirements are written at the system level (the device shall detect X with Y sensitivity) and at the integration level (the AI module shall accept inputs of format Z and return outputs of format Q). What’s missing is a requirements layer that describes the performance envelope of the AI component in terms that support impact assessment — statistical performance bounds, operational domain constraints, distributional assumptions about input data, known failure modes and their mitigations. Without this layer, there’s nothing to trace a post-market change against.
Traceability is one-directional and stops at the design artifact boundary. Traditional RTMs trace requirements to test cases and to design documents. For AI components, this is necessary but not sufficient. A PCCP impact assessment requires bidirectional traceability: not just “this requirement is verified by this test,” but “if this parameter changes, here are all the requirements whose satisfaction is now in question, and here is the reasoning chain that explains why.” That’s a graph problem, not a matrix problem. Document-based RTMs can’t represent it.
The Design History File doesn’t include the AI engineering record. DHF practices were developed for electromechanical systems and traditional software. They’re structured around design inputs, design outputs, verification, and validation — a linear flow. AI development doesn’t follow this flow. Training dataset curation decisions are design inputs. Model selection decisions are design decisions. Hyperparameter choices are implementation decisions. Evaluation on held-out data is verification. Clinical validation is validation. But the documentation linking these artifacts in a way that supports PCCP impact assessment typically doesn’t exist as a coherent record — it’s scattered across experiment tracking systems, data management tools, model registries, and engineering notebooks that weren’t built to talk to each other.
Change management processes aren’t defined at the level the FDA is looking for. Many device makers have change control processes for traditional software. Fewer have defined, documented methodologies for AI model updates that specify dataset versioning requirements, retraining triggers and thresholds, evaluation protocols, and the decision logic for whether a change requires new validation or falls within existing validation scope. The PCCP requires this methodology to be defined upfront. Teams that don’t have it defined internally can’t put it in a submission.
What the FDA Is Actually Looking For
The FDA’s expectations, as articulated in the guidance and in feedback from recent submissions, center on a concept the agency calls “transparency and traceability of modifications.” Unpacked, this means several specific things.
The agency wants evidence that the device maker has thought carefully about the failure modes of post-market AI modification — not just the success modes. A PCCP that only describes what will happen when a modification goes well is incomplete. The FDA wants to see that the modification methodology includes monitoring for distributional shift, performance degradation, and unexpected behavioral changes in the deployed system.
The agency wants the impact assessment logic to be embedded in the engineering record, not generated post-hoc. An impact assessment that says “we assessed this modification and determined it was within scope” is not adequate. The assessment needs to trace back to the original design rationale, demonstrate that the relevant requirements have been evaluated, and document the reasoning that supports the conclusion.
The agency wants the performance specifications for AI components to be quantitative and bounded — not qualitative. “The model shall maintain acceptable accuracy” is not a specification. “The model shall maintain sensitivity ≥ 0.92 and specificity ≥ 0.88 on the defined operational population, with confidence interval bounds verified against the validation dataset” is a specification. PCCP submissions with qualitative performance bounds get requests for additional information.
And the agency wants to see that change monitoring practices are built into the post-market surveillance system, not siloed in the AI development team. Post-market performance data needs to flow back to the engineering record in a way that triggers appropriate review when performance trends toward the modification boundary.
What Needs to Change in Engineering Practice
The engineering changes required aren’t small, and they don’t happen by adding a PCCP section to an existing DHF. They require structural changes to how AI components are specified, modeled, and traced.
Requirements architecture must include an AI performance layer. This layer sits between system-level requirements and implementation artifacts. It specifies the AI component’s operational domain, performance envelope, known limitations, and the conditions under which performance claims are valid. Every element of this layer needs bidirectional traceability to system-level safety requirements and to validation evidence.
Traceability infrastructure must support impact propagation, not just coverage verification. Teams need to be able to ask: “If this parameter changes, what is the transitive set of requirements, risk controls, and validation artifacts that are potentially affected?” This is a query that graph-based models support natively and that document-based RTMs cannot answer without manual reconstruction. Tools like Flow Engineering, which represent requirements as a connected graph rather than a flat document hierarchy, make this kind of impact query tractable. When a change is proposed, the affected subgraph can be identified and assessed systematically rather than through manual expert judgment.
The DHF needs to incorporate AI-specific artifacts as first-class records. Dataset lineage documentation, model development decisions, and evaluation results need to be structured as traceable engineering artifacts with defined relationships to requirements and risk controls — not attached as reference documents. This requires either extending existing PLM/requirements tools to accommodate AI-specific artifact types, or adopting tooling that was designed with AI engineering records in mind from the start.
Change methodology documentation must precede submission, not follow it. Teams need to develop their AI change control methodology as part of the systems engineering process, then reference that methodology in the PCCP submission. Organizations that try to reverse-engineer a methodology from their existing practices after a submission request will find the task difficult and the resulting documentation unpersuasive.
Flow Engineering’s model-based approach is worth examining in this context specifically because it represents requirements and their relationships as a queryable graph, with change propagation built into the data model rather than managed through manual traceability discipline. For teams building PCCP-compliant engineering records, the ability to define change boundaries as graph constraints — and to automatically surface affected nodes when a modification is proposed — maps directly to what the FDA’s impact assessment requirement demands.
Honest Assessment
The FDA got the direction right with the PCCP framework. Creating a regulatory pathway for adaptive AI is the correct move, and requiring device makers to define change boundaries at submission time is the right engineering discipline to impose. The alternative — treating every AI update as a traditional change assessment, or allowing unconstrained post-market modification — would be worse for patients and for the industry.
What the agency underestimated, or perhaps correctly identified as necessary pressure, is how far behind most medical device engineering organizations are in their ability to actually comply. The PCCP isn’t hard because of regulatory complexity. It’s hard because it requires a level of requirements architecture rigor, traceability infrastructure maturity, and process discipline for AI development that most organizations don’t currently have.
Teams that treat PCCP as a documentation task — something the regulatory affairs team handles — will produce submissions that generate requests for additional information, slow down clearance timelines, and create DHFs that don’t actually support post-market modification decisions. Teams that treat PCCP as a systems engineering discipline — something that requires restructuring how they specify, trace, and manage AI components throughout the development lifecycle — will build products that can improve in the field legally, safely, and with demonstrable engineering rigor.
The FDA regulatory wall isn’t an obstacle to AI in medical devices. It’s a forcing function for engineering practice that should have matured alongside AI capability. The wall is there because the engineering discipline wasn’t. Build the discipline, and the wall becomes a pathway.