Scarlet US Inc. (Gabrielle Cesvet)

Scarlet, an FDA-recognized third-party review organization, submits the attached comments on the discussion paper Considerations for the Regulation of Generative AI-Enabled Medical Devices (Docket No. FDA-2026-N-7874). Please see the attached PDF for our full responses to the discussion questions.

October 19, 2026

Dockets Management Staff (HFA-305)​
Food and Drug Administration​
5630 Fishers Lane, Rm. 1061​
Rockville, MD 20852

Docket No. FDA-2026-N-7874, Considerations for the Regulation of Generative
AI-Enabled Medical Devices

Dear Sir or Madam,

Scarlet welcomes the opportunity to comment on FDA’s discussion paper, Considerations for
the Regulation of Generative AI-Enabled Medical Devices. We support FDA’s leadership in
developing a risk-proportionate framework that enables safe GenAI-enabled devices to
reach patients.

Scarlet is a certification body specializing in software and AI-enabled medical devices. We
are an FDA-recognized third-party review organization, a notified body under the European
Union’s Medical Device Regulation, and an approved body in the United Kingdom. Our
comments draw on our experience assessing these devices across all three jurisdictions.

In summary, we support the competency-based approach the paper describes. It offers a
sound basis for evaluating GenAI-enabled devices, and our responses suggest four ways to
strengthen it. Risk assessment should rest on intended purpose. Manufacturers should
demonstrate that their risk controls work in practice. Ongoing testing should reflect risk and
the manufacturer’s control over the deployed system. FDA should also draw on qualified
independent third parties for expertise and review capacity.

Our detailed responses to FDA’s questions follow. We would welcome the opportunity to
discuss them further.

Sincerely,

Gabrielle Cesvet​
Head of Public Affairs, Scarlet​
hello@scarlet.cc
Section IV: Considerations for the Assessment of Risk
for GenAI-Enabled Devices
Question 1

Does the two-axis risk framework, organized around device activity and the consequence of
relying on an incorrect output, appropriately capture the dimensions most relevant to the risk
of a GenAI-enabled software function? If there are additional dimensions—such as the
reversibility of a resulting action, the availability of downstream safeguards, the time
pressure of the deployment setting, or the traceability of the output (i.e., to primary source
materials)—that should be represented in a risk framework, please describe and provide
examples of how they should be represented.

We consider the two-axis framework appropriate for assessing the risk of GenAI-enabled
software functions. Risk assessment should reflect the objective nature of the device’s
intended purpose, and the two axes are broadly consistent with the IMDRF SaMD
framework’s “significance of information provided” and “healthcare situation or condition.”
This alignment supports international harmonization. We would expect the consequence axis
to account for the clinical context of use, including whether resulting actions are reversible
and how much time the setting allows to detect errors.

We caution against adding dimensions such as downstream safeguards to the risk
assessment itself. Doing so could allow manufacturers to argue for a lower risk category
based on the controls they choose to implement, rather than on what the device is intended
to do.

Factors such as reversibility, time pressure, traceability, and human oversight within the
clinical workflow remain relevant, but they are second-order considerations. They influence
the probability or severity of harm, and manufacturers should address them through risk
management within the device’s risk category rather than as separate dimensions of the
framework. The activity axis already distinguishes devices that act under clinician
supervision from those that act autonomously; beyond that distinction, human oversight
depends on how effectively clinicians can review outputs in practice.

When assessing these factors, we encourage FDA to focus on their effectiveness rather
than their presence. Two examples illustrate this:

●​ Traceability. Outputs that expose the patient information and source material they
rely on allow users to identify errors more easily. However, a cited source does not
guarantee that the output faithfully reflects it, and a plausible model-generated
explanation is not necessarily an accurate account of how the model produced an
output, nor evidence that the output is correct.
●​ Human oversight. A system that requires a qualified clinician to authorize an action
before execution differs materially from one that only advises users to check outputs.
Review is meaningful only if the reviewer has the information, time, competence, and
authority to intervene.

Manufacturers should demonstrate that these controls work in the intended clinical workflow.
Question 2

CDRH seeks input on how to account for the spectrum of GenAI-enabled informational
functions that vary in the degree to which they direct a user to a particular action (i.e.,
between “non-directive” and “action-directing”). What characteristics of an output—such as
its wording, specificity, personalization, or context—could be considered as modifiers of the
risk associated with an informational function, after accounting for the device’s overall
functionality and intended use? What additional information would provide manufacturers
with sufficient clarity and predictability around risk assessment for informational functions
while recognizing that directiveness may exist along a continuum rather than as a binary
distinction?

We recommend that CDRH assess directiveness at the level of the device’s intended
purpose rather than through characteristics of individual outputs. Treating wording,
specificity, or personalization as risk modifiers would introduce subjective distinctions that
are difficult to apply consistently. For example, it is not productive to debate whether “Your
dizziness is probably caused by your medicine” is meaningfully less directive than “Skipping
your next dose may help,” as both could lead a patient to change their treatment.

The distinction between information and direction also depends on how users engage with
the device. A patient who asks whether they can take a second dose of an over-the-counter
sleep aid will treat a restatement of the label, such as “do not exceed the dose,” as an
instruction. Manufacturers should therefore define, as part of the intended purpose, the
highest level of directiveness the device is designed to provide, taking into account the
questions intended users are likely to ask. This level should inform the device’s risk
assessment. Manufacturers should then demonstrate, through validation and postmarket
monitoring, that generated outputs remain within that level.

Disclaimers such as “For informational purposes only,” “I am not a healthcare professional,”
or generic advice to seek urgent care should not be sufficient to establish that a device is
non-directive if its outputs recommend specific actions.

To provide predictability, CDRH could publish a defined set of directiveness levels with
worked examples of the outputs consistent with each level.

Question 3

CDRH seeks input on whether and when a GenAI-enabled function that results in delivery of
clinical information to patients, as opposed to HCPs, could present different or higher risks,
while also recognizing the potential benefits associated with improved patient empowerment,
engagement, and access to clinical information. What device characteristics, output features,
or safeguards might mitigate risks that could arise when a user lacks the domain knowledge
to independently evaluate an output, without unnecessarily underestimating patient
capability?

We do not consider patient-facing information to present inherently higher risk. As in our
response to Question 4, what matters is whether the user can critically assess the output
and how far they rely on it. Safeguards should reflect the intended use of the generated
content. A GenAI-enabled device that explains laboratory results to patients presents very
different risks from one that supports a suicide prevention program, though neither should be
considered low risk on the basis of its description alone. Manufacturers should therefore
clearly define the intended use, the actions patients are expected to take, and the
consequences of incorrect or misunderstood outputs.

One useful output feature is a clear statement of the appropriate next step, if any, for the
intended use, such as booking a follow-up appointment with a clinician to discuss laboratory
results. Where a device recommends actions, manufacturers could limit these to a
predefined set of clinician-approved options and implement safeguards that prevent the
model from generating unsupported recommendations. However, restricting the available
options does not ensure the model selects the right one. Manufacturers should also evaluate
how the device selects options, when it presents them, and how it handles situations outside
the predefined set.

To empower patients, manufacturers should favor clear explanations, accessible language,
and access to supporting information over withholding useful clinical detail. Evaluation with
representative patients should establish whether they understand the output, its limitations,
and any suggested next steps. Where safe use depends on clinical support or escalation,
the device should clearly communicate that pathway, and support should be available within
the timeframe the associated risk requires.

Question 4

CDRH seeks input on whether and how the distinction between generalist and specialist
physicians might inform the assessment of risk for HCP-facing GenAI-enabled functions.
Under what circumstances, if any, might risk be affected when an HCP who lacks the
relevant clinical specialist knowledge receives information that falls within a specialist area of
practice? What device characteristics or safeguards might mitigate such risks?

The relevant distinction is not whether an HCP is a generalist or a specialist, but whether
they have the expertise to critically assess a particular output. A specialist working outside
their own field could face the same risks as a generalist. These risks increase when a
GenAI-enabled function presents outputs with high confidence or apparent authority, which
may lead an HCP without the relevant expertise to accept an output without recognizing its
limitations or the need to consult a specialist.

Sponsors can mitigate these risks through the model harness, meaning the controls
surrounding the model that govern what actions it can take, what tools it has access to, and
how it operates. Safety mechanisms, such as a harness, should constrain outputs to the
device’s intended use and reflect the knowledge expected of its intended users. Where a
request requires specialist interpretation beyond that scope, the device could withhold an
actionable recommendation, explain why, and direct the HCP to appropriate specialist
review. Sponsors should test these boundaries across realistic interactions, including
attempts to elicit recommendations outside the intended scope.

These safeguards should not prevent a device from making specialist information accessible
to generalists where that is its intended purpose. However, manufacturers should not rely on
HCPs to detect errors that require expertise they are not expected to have. Where
safeguards depend on human review, manufacturers should evaluate them with
representative intended users to show that those users can recognize when they need
specialist input and act on it.

Question 5

For multi-turn conversational GenAI-enabled devices that may migrate from providing
“non-directive” information to “action-directing” information over the course of an exchange,
how should risk be assessed across realistic conversational trajectories? How could the
intended use of such a device be characterized when its behavior is emergent across a
conversation?

Manufacturers should implement safety mechanisms that prevent GenAI models from
moving beyond the device’s intended use, including migrating from non-directive information
to action-directing recommendations outside its scope. These controls should operate
across the whole conversation, since a sequence of individually acceptable responses could
collectively steer a user toward an inappropriate action.

Risk assessment should therefore consider realistic conversational trajectories, including
repeated requests for advice, the gradual introduction of patient-specific information, and
situations where the model reinforces an earlier error. For example, a conversation may
begin with a general explanation of a medicine and progressively move toward advising a
patient to change their dose. Manufacturers should test whether the device recognizes and
appropriately manages that transition, rather than assessing each response in isolation.

Where a device cannot reliably constrain such behavior, the risk assessment should account
for credible worst-case scenarios and the most severe reasonably foreseeable harms, even
if the interaction begins as informational. This does not mean assuming that the most severe
harm will inevitably occur, but manufacturers should not dismiss it because its probability is
uncertain.

The intended use should define the permitted conversational functions, intended users,
clinical context, and the decisions or actions the device supports, along with the boundaries
that require refusal or escalation. Manufacturers should assess emergent behavior against
these predefined boundaries, and such behavior should not implicitly expand the intended
use during a conversation. Consistent with our response to Question 2, the highest level of
directiveness defined in the intended use should apply across the entire conversation, not
only to individual responses.

Question 6

For GenAI-enabled care escalation functions, CDRH is considering how the evaluation may
account for both under-escalation and over-escalation. How could manufacturers
characterize and weigh these two directions of error, given that they may not be
commensurable and that acceptable trade-offs may vary by clinical context?

Balancing under-escalation and over-escalation mirrors the familiar trade-off between false
negatives and false positives in existing diagnostic devices. No single balance suits every
device, as it always depends on the clinical workflow, context, and indications.
Manufacturers should therefore treat under-escalation and over-escalation as distinct
sequences of events within their risk management process. For each, they should identify
the hazardous situations and potential harms, estimate the severity and probability of harm,
and establish appropriate risk controls, taking into account the urgency of intervention, the
reversibility of harm, and the availability of alternative care pathways.

For example, a GenAI-enabled device supporting care escalation for patients receiving
chemotherapy could under-escalate symptoms of a serious infection, delaying urgent
treatment. Conversely, it could over-escalate low-risk symptoms, leading to unnecessary
investigations and additional demand on emergency services. The manufacturer should
assess these pathways separately, justify how its controls address each, and consider
whether reducing one risk increases the other. Controls need not be fixed decision rules
within the model. They could also operate at the device, user interaction, or clinical workflow
level, provided the manufacturer demonstrates their effectiveness.

Manufacturers should justify the trade-off through the acceptability of the residual risks and
the overall benefit-risk assessment, rather than assuming that one direction of error is
universally preferable. Where the harms are not directly comparable, manufacturers should
characterize them separately rather than combine them into a single measure, and use
postmarket evidence to revisit the assumptions underlying the assessment.

Section V: A Competency-Based Approach for
Premarket Evaluation of GenAI-Enabled Devices
Question 7

Is the competency-based approach described above, i.e., device benchmarking followed by
clinical confirmation, a useful and appropriate framework for evaluating GenAI-enabled
devices?

Yes. We consider the competency-based approach a useful and appropriate framework for
evaluating GenAI-enabled devices. We welcome CDRH’s intention to use the premarket
assessment as a baseline for re-benchmarking and to pair it with stronger postmarket
monitoring.

The approach suits agentic devices particularly well, as these devices perform a range of
tasks within their intended use. Assessing competence across realistic clinical tasks and
workflows, rather than relying solely on a small number of large retrospective or prospective
studies, can generate evidence more quickly, across multiple workflows, and in a way that
better reflects real clinical use.

We offer three recommendations to further strengthen the framework.

1.​ Trigger re-benchmarking for changes outside the manufacturer’s control.
Re-benchmarking should not depend solely on manufacturer modifications. When a
device relies on an externally hosted third-party model, the provider can introduce
changes that affect device performance even when the manufacturer has changed
nothing. A manufacturer could specify which version of a model it wants to use
 through the API, but the third-party provider could still decide to stop providing that
version with little to no explanation. A fully fixed model may also perform differently
as patient populations, inputs, or clinical workflows shift.
2.​ Scale testing to risk and control, not model ownership. We recommend that FDA
base the frequency and scope of ongoing testing on the device’s risk, the
manufacturer’s control over the deployed system, and evidence of changes in its
operating context. Where the manufacturer can fix the model weights, software
dependencies, and execution environment, less frequent routine testing may suffice,
with more thorough re-evaluation at each new release. Where the manufacturer
cannot reliably pin the model version or obtain advance notice of updates, we would
expect more frequent testing.
3.​ Account for deployment scale. The clinician analogy has an important limit. The
same per-decision competence does not imply the same system-level risk. A
clinician’s caseload bounds the impact of their decisions, whereas a manufacturer
can deploy a software device across a hospital system or national program with little
marginal effort. Competency assessment is therefore necessary but not always
sufficient. We encourage FDA to consider staged rollout, expanding from individual
clinicians to sites, regions, and national programs, with predefined expansion criteria,
close monitoring at each stage, and the ability to pause or roll back deployment if
real-world performance differs from expectations. FDA could anchor these conditions
in existing mechanisms, such as conditions of approval or postmarket surveillance
requirements.

Question 8

How might the two-axis risk framework described in Section IV be considered within the
competency-based approach described above to help determine the level of evidence
needed for a premarket submission?

The two-axis framework should set the baseline level of evidence. Consistent with our
response to Question 1, a function’s position on the two axes should determine the scope of
benchmarking and the rigor of clinical confirmation.

Risk controls should then shape what the evaluation tests, without reducing how much
evidence the manufacturer must provide. Where a manufacturer relies on a control to
mitigate risk, the competency-based evaluation should demonstrate that the control works in
the intended clinical workflow. The presence of a control should not, by itself, justify a lower
level of evidence. For example:

●​ Human oversight. Where a device relies on clinicians to review its outputs, the
evaluation should demonstrate that clinicians have sufficient information to identify
clinically significant errors, sufficient time to review outputs, and an effective means
of intervening before the device takes an action.
●​ Traceability. Where a device relies on explanations or links to source material as risk
controls, the evaluation should assess their reliability and usefulness. A plausible
model-generated explanation does not prove that it faithfully represents how the
model produced the output.
Benchmarking and clinical confirmation should therefore reflect both the function’s position
on the two axes and the risk controls identified through the manufacturer’s risk management
process.

Question 9

Would a benchmarking structure such as the one described above be likely to provide
adequate evidence of clinical knowledge, analytic capabilities, safety behavior,
communication, and generalizability to support a reasonable assurance of safety and
effectiveness? Are there elements that are missing, redundant, or inappropriately
categorized? Are there externally developed standards that could be leveraged?

We think the proposed benchmarking structure is useful, but we would draw more explicitly
on the layered approach used in software testing. Sponsors should first evaluate each
relevant competency individually against predefined, clinically justified acceptance criteria,
analogous to unit testing. This would help identify specific weaknesses and prevent strong
performance in one area from obscuring a safety-critical failure in another.

Sponsors should then complement these assessments with “integration tests,” where
several competencies must work together within a complete clinical scenario. For example, a
device might correctly identify a concerning symptom, communicate uncertainty
appropriately, and select an appropriate escalation pathway when each capability is tested
separately, yet fail to combine them safely during a multi-turn conversation. This integrated
assessment would be closer to evaluating how a clinician manages a complete case,
drawing on knowledge, reasoning, communication, and recognition of their own limitations.

The analogy does not require treating the model’s competencies as separable software
components. Rather, we would apply focused tests and integrated scenarios to the final
configured device, including its safeguards and connected tools. Sponsors should assess
the robustness and subgroup performance across both levels. For that reason, we would
treat generalizability as a dimension that applies across every competency, rather than as a
separate competency in its own right. This layered approach would strengthen the
benchmarking evidence while retaining clinical confirmation to establish whether the findings
translate into the intended clinical setting.

Established standards could inform this approach. IEC 62304 already distinguishes between
software unit verification, integration testing, and system testing (clauses 5.5 to 5.7), which
maps closely onto the layered benchmarking we propose. IEC 82304-1 complements this by
requiring validation of the complete health software product against its use requirements in
the intended operational environment (clause 6), which corresponds more closely to clinical
confirmation. Together, they mirror the distinction between verification and validation that
already underpins the assessment of medical device software, and would give the
competency-based approach a familiar basis. As noted in our response to Question 16,
qualified third parties could also help develop consensus standards specific to
GenAI-enabled devices.

Question 10
CDRH recognizes that publicly available benchmarking assets may be subject to data
contamination, saturation, and limited real-world representativeness. How should a sponsor
establish that performance on a given benchmark predicts safe and effective real-world
behavior for the device’s intended use? What evidence should support the construct validity
of a benchmark used to gate device evaluation, and what role should sponsor-developed
benchmarks play given potential concerns around independence and optimization to the
test?

We would be cautious about relying on public benchmarks as the principal evidence of
clinical competence or as a gate for device evaluation. Models may have been trained on the
benchmark data or optimized to perform well on those particular tasks, without
demonstrating that the same performance generalizes to clinical practice. Even where
sponsors can exclude direct contamination, repeated optimization against a public
benchmark can reduce its value as an independent test.

We think sponsors should instead establish the link between benchmark performance and
safe and effective real-world behavior during clinical confirmation, using data representative
of the device’s intended use that the sponsor has not used at any stage of the model training
or device optimization. This should cover the intended patient populations, clinical settings,
inputs, and workflows. The evaluation should demonstrate that the competencies and
acceptance criteria measured by the benchmark correspond to clinically meaningful
performance of the final configured device.

Sponsor-developed benchmarks could therefore be more appropriate when tailored to the
intended use, provided sponsors protect them from the same optimization problem. We
would expect prespecified evaluation methods and acceptance criteria, independent clinical
review, and a sequestered test dataset that remains separate from the development set.
Qualified independent third parties could support this by reviewing the clinical relevance of
the benchmarks and maintaining or administering sequestered test datasets, as discussed
further in our response to Question 16. An independent body could also build a benchmark,
validate it once against real clinical data, and keep its test set protected. Sponsors could
then rely on that validation rather than repeating it, and use the benchmark as a gate before
clinical confirmation. Where the sponsor cannot verify the training history of a third-party
model, it should acknowledge and address that uncertainty, for example through newly
collected, non-public clinical data obtained after the provider fixed the evaluated model
version. Public benchmarks could still provide supplementary context, but we would not
consider strong performance on them sufficient evidence of generalizability.

Question 11

CDRH is considering that clinical confirmation for a GenAI-enabled device might not require
a prospective clinical study in every case, and has described above a range of approaches
of increasing rigor and patient exposure. How might a sponsor select and justify a
confirmation approach tailored to a device’s intended use and proportionate to the device’s
risk profile? Are there device types or risk profiles for which one or more of these
approaches would be insufficient or inappropriate? How might the anticipated distribution of
real-world inputs be taken into consideration? Are there other methods of clinical
confirmation that might help inform the evaluation of GenAI-enabled devices?
The manufacturer should select the clinical confirmation approach based on the device’s
intended use, its position on the two-axis risk framework, and any remaining uncertainties
after benchmarking. The manufacturer should explain which questions each method can
answer and why the combined evidence is sufficient to address the identified risks. A
prospective clinical study should not be necessary in every case, but the manufacturer
should justify its omission with the evidence available.

For example, retrospective evaluation with independent clinical review could provide useful
evidence for a device that summarizes patient records. However, if its safe use depends on
clinicians detecting and correcting omissions, reviewing the summaries alone would not
establish that this safeguard works. The manufacturer would also need to evaluate the
device with representative users. Similarly, shadow deployment could assess performance
on live inputs, but would not establish how users respond to outputs they cannot see. For
devices that autonomously direct care, or where safety depends on how a conversation
changes patient behavior, retrospective testing alone would generally be insufficient.

We would also consider in silico methods and computational modeling as part of the
evidence strategy. Virtual patients, simulated conversations, and models of clinical workflows
could help explore rare but serious scenarios, variations in patient characteristics, and the
consequences of different device actions without exposing patients to those risks. However,
the manufacturer should establish the credibility of these methods for the specific question
they aim to answer, including their assumptions, validation against independent real-world
observations, and uncertainty. FDA’s guidance on assessing the credibility of computational
modeling and simulation, which builds on the ASME V&V 40 standard, addresses
physics-based models and would not apply directly to generative simulations, such as
model-generated patient conversations. We propose adapting its principles to these
simulations, in particular by requiring stronger evidence of credibility the more heavily a
decision relies on the simulation’s results and the greater the consequences of an error. A
simulation does not count as clinical confirmation merely because it generates
realistic-looking cases. In particular, model-generated patients or responses could reproduce
the same blind spots as the device under evaluation. The extent to which simulation could
replace other evidence should depend on its demonstrated ability to represent the relevant
clinical behavior and consequences.

The evaluation should reflect the anticipated distribution of real-world inputs, including
incomplete or conflicting information and changes over the course of a conversation. Real
clinical data used for confirmation should remain separate from model training and device
optimization. Synthetic or simulated cases could supplement this evidence, particularly for
challenging scenarios, but manufacturers should report their results separately from
estimates of performance in the intended population.

Where a device learns from interactions or feedback after deployment, whether through
model updates, changes to the information it retrieves, or feedback from users, we would
also consider the possibility of malicious manipulation of that learning process. Deliberately
misleading feedback could reinforce unsafe recommendations and affect subsequent users.
In silico testing could help explore how such contamination propagates through successive
updates and whether controls detect or contain it. However, clinical confirmation of a fixed
device configuration would not, by itself, establish the safety of a continually changing
system. The evidence strategy should also address control of learning data, validation
before updates affect patients, detection of deterioration, and the ability to suspend learning
or revert to a validated version.

A staged combination of retrospective evaluation, credible in silico studies,
representative-user simulations, shadow deployment, and appropriately controlled
prospective evaluation could therefore be useful. The manufacturer should justify the
combination by the risks and remaining uncertainties, with predefined criteria for progression
and for renewed evaluation following changes, consistent with the staged rollout we propose
in our response to Question 7.

Question 12

How should sponsors achieve statistically meaningful performance measurement for
GenAI-enabled devices? Where synthetically generated inputs supplement real patient data,
how should sponsors account for differences between the synthetic and real-world
distributions when estimating performance, and under what conditions, if any, is it
appropriate to combine benchmarking evidence and clinical confirmation evidence to support
a single performance estimate?

Sponsors should first define the performance they need to measure for the device’s intended
use, including the relevant patients, users, clinical settings, and the final configured version
of the device. They should identify clinically important outcomes and failure modes, set
acceptance criteria before testing, and justify a sample size that can estimate performance
with useful precision. Sponsors should report results by relevant subgroup and safety-critical
tasks, so that an overall score does not obscure poor performance in either.

Because GenAI-enabled devices can produce different outputs from the same input, a single
run per test case may miss failures that occur only some of the time. Unless the sponsor
controls the model sufficiently to make its outputs reproducible, sponsors should run each
case several times and report both how often the device responds correctly and how much
its outputs vary.

The analysis should also reflect how the device is used. Sponsors should not count several
outputs from the same patient or conversation as independent cases. When serious errors
are rare, testing may not be able to precisely estimate their real-world frequency. Sponsors
should be clear about that uncertainty and use focused challenging cases to test whether
safeguards work, without presenting the frequency of those cases in a test set as their
expected frequency in practice.

Measurement is only as reliable as the grading. Where open-ended outputs require clinical
judgment, sponsors should use multiple independent reviewers and report their level of
agreement. Where sponsors use AI models to grade outputs, they should demonstrate that
the grading model does not share the blind spots of the device under evaluation.

Synthetic inputs could be particularly useful for exploring cases that are difficult to collect in
sufficient numbers, such as unusual presentations, combinations of symptoms, or missing
information. For example, a care-escalation device could be tested on synthetic cases
involving uncommon but serious complications. However, those cases may be deliberately
more challenging than the patients the device usually encounters. We would therefore
expect sponsors to compare synthetic inputs with independent real patient data across
characteristics that matter to performance, explain how they generated the cases, and report
the results separately. Adding synthetic cases to a real patient dataset should not, by itself,
make an estimate of real-world performance more statistically meaningful. Where sponsors
do include synthetic cases in such an estimate, they should reweight the results to reflect the
intended-use population and justify that adjustment.

We would also be cautious about combining benchmarking and clinical confirmation into a
single performance estimate. Benchmarking may show how the device performs on defined
tasks under controlled conditions, while clinical confirmation examines whether that
performance translates to representative patients, users, and workflows. Combining the
results might be justified for a specific measure if both evaluations assess the same device
version, outcome, and intended population, and if the analysis accounts for differences in
case selection and assessment methods. Sponsors should specify the method in advance
and still report the separate results, so that a weakness in either setting remains visible.

Question 13

For which clinical domains, device functions, or subpopulations is synthetic data particularly
well-suited, or particularly inadequate, as a supplement to real-world evidence? What
safeguards would mitigate the risk that synthetic data generated by models of the same
class as the device under evaluation reproduces the very performance gaps the evaluation
is intended to detect, particularly for underrepresented subgroups?

Synthetic data can help test rare or high-risk scenarios that real data seldom captures,
provided sponsors define each scenario and its expected response independently. It is less
reliable where sponsors rely on a generative model to represent a population that real data
covers poorly, because the model learns from the same limited data. We think the suitability
of synthetic data should depend on the specific question under evaluation and whether
sponsors can represent and independently check the relevant clinical characteristics.

For example, synthetic patient records could be useful for testing whether a summarization
device preserves important information, identifies contradictions, or handles missing data.
Sponsors could construct the cases to contain known findings and deliberately challenging
combinations, with independent clinical reviewers establishing the expected response. This
would provide useful evidence about particular competencies, although sponsors would still
need to compare the frequency and complexity of those cases with real patient records.

We would be more cautious where performance depends on patient behavior, the evolution
of a condition, or aspects of communication that are difficult to reproduce faithfully. For
example, simulated conversations could help test whether a mental-health support device
recognizes predefined warning signs, but would provide more limited evidence about how
distressed patients actually communicate or respond to its advice. The same caution applies
to rare conditions and underrepresented subgroups, where the lack of real data may also
limit the generator’s ability to represent them accurately. Generating more examples of a
subgroup does not establish that those examples capture its clinically relevant
characteristics.
To address shared performance gaps, we would expect reviewers independent of both the
device and the model generating the synthetic data to check the evaluation cases and
expected responses. This could include clinical experts with relevant experience, cases
based on documented real-world failures, and protected real patient datasets that neither
system has used during development or optimization. Different generation methods could
help broaden the range of scenarios tested, but using a different model or provider does not,
by itself, provide sufficient evidence of independence, as models may share training data,
assumptions, or weaknesses. As in our responses to Questions 11 and 12, the same model
should not be the sole source of both the test cases and the judgment that the device
handled them correctly.

For underrepresented subgroups, sponsors should validate whether the synthetic cases
preserve the characteristics that could affect device performance, including variations in
presentation, comorbidities, language, and the information available in clinical records.
People from the relevant communities, or organizations representing them, could help
identify unrealistic cases, particularly on language and communication. Changing a
demographic label in an otherwise identical case would not establish that the case
adequately represents the subgroup. Where sufficient real data are unavailable to check
these characteristics, sponsors should state the uncertainty explicitly, and the evidence
strategy should identify what additional data or clinical evaluation they would need.

Question 14

For open-ended device outputs, how should performance comparators and acceptance
criteria be selected? When a panel of qualified clinicians serves as the comparator, how
should the applicable standard (for example, the standard of care versus the performance of
a median clinician in practice) be defined and justified? Should generalist or specialist
physicians be used as a performance standard? When should human-AI team performance,
rather than the device operating alone, serve as the basis for evaluation?

We believe that the choice of comparator should follow from the device’s intended clinical
task and the claim under evaluation. With open-ended outputs, several responses may be
clinically acceptable, so the evaluation needs criteria that distinguish meaningful differences
in accuracy, completeness, and safety from differences in wording. This also means
distinguishing the reference used to judge an output’s clinical acceptability from the
comparator used to assess performance in practice. An expert panel may establish what
constitutes an acceptable response, while representative clinicians provide a comparison
with routine care. We therefore think the standard of care should define what counts as an
acceptable response, with the performance of a median clinician providing context.

Where a panel establishes that reference, its expertise should align with the clinical content
under assessment, and reviewers should initially assess the outputs independently using
predefined criteria. As in our response to Question 12, sponsors should report the reviewers’
level of agreement and explain how they resolved disagreements to demonstrate the
reference’s reliability, particularly where the evidence permits more than one reasonable
approach. Clinical guidelines, patient outcomes, or other independently established evidence
should support these judgments where appropriate. The performance of a median clinician
could then provide useful context, but it should not automatically become the acceptance
threshold. Consistent with our responses to Questions 1 and 8, that threshold should reflect
the consequences of errors. Sponsors should justify any permitted difference from clinician
performance and assess it with appropriate confidence intervals. Similar average
performance would offer limited reassurance if the device made more serious errors or
performed poorly with an important subgroup.

This distinction also helps clarify the roles of generalists and specialists. Specialist
knowledge may be necessary to judge whether an output is clinically sound, even when
generalists are the intended users. For example, a system providing specialist
recommendations in primary care could require specialist review to establish the quality of
those recommendations, alongside evaluation with generalists to determine whether they
can interpret and use them safely. The relevant question is therefore what expertise each
part of the evaluation requires, rather than which professional group should serve as the
standard in every case.

Where the intended use depends on a clinician reviewing and acting on the output,
human–AI team performance should be central to the evaluation. A study comparing
representative clinicians with and without the device could establish whether assistance
improves decisions or introduces new errors, using randomized study conditions where
feasible and accounting for variation between clinicians and cases. This would also test
whether users actually recognize and correct the errors that human review aims to address.
In particular, it could reveal automation bias, where clinicians defer to the device’s output
and miss errors they would otherwise catch. Device-alone testing would remain useful for
characterizing those failure modes, while evaluation of autonomous functions would need to
reflect their intended workflow without assuming human intervention that will not occur.

Question 15

Are there ways in which performance might be assessed relative to the care, technology, or
course of action likely to occur in the absence of the device, rather than to the comparators
described in this section? What approaches might be used to identify and justify a
comparator such as unaided clinical judgment, delayed specialist review, or no intervention?

We believe that comparing the device with the care patients would actually receive in its
absence could provide useful evidence of its clinical value, particularly where access to
specialist advice is limited. However, demonstrating improvement over a poorly functioning
care pathway would not, by itself, establish that the device’s performance is acceptable.
Sponsors should still meet clinically justified acceptance criteria for serious errors and
residual risks. As in our response to Question 14, we would distinguish the reference used to
judge whether an output is clinically acceptable from the care pathway used to assess the
device’s benefit. For example, sponsors could evaluate a device providing specialist
recommendations in primary care against initial generalist management followed by the
usual referral pathway, while specialist adjudication establishes whether its
recommendations are appropriate.

Sponsors should support the comparator with evidence from the intended deployment
setting, rather than an assumption that patients would otherwise receive delayed care or no
intervention. Prospective observation of clinical workflows, audits of representative patient
records, and referral and waiting-time data could help establish what usually happens. This
should include the information and existing technologies available to clinicians, the care
provided while patients await specialist review, and variation between sites and patient
groups. “Unaided clinical judgment” should mean judgment without the device under
evaluation, while retaining the resources ordinarily available in practice. Similarly, sponsors
should not automatically interpret the absence of recorded intervention as evidence that no
care occurred.

Because the care pathway varies between settings and changes over time, any benefit claim
based on such a comparator should apply only to settings where that comparator holds. A
device that adds value where specialist review is hard to access may add little where it is
readily available.

Where the claim concerns improved clinical decisions or outcomes, we would favor a
pragmatic, randomized comparison of care with and without the device, where appropriate
and feasible. Randomization could occur at patient level, or at clinician or site level where
using the device could influence how clinicians manage control patients. The study should
prespecify the population, comparison, follow-up period, and clinically meaningful endpoints.
For the primary-care example, these could include time to an appropriate management
decision, missed urgent referrals, unnecessary investigations, and relevant patient
outcomes. Faster recommendations alone would not establish benefit if they introduced
clinically significant errors. Sponsors should report effect estimates with confidence intervals,
accounting for clustering and examining clinically relevant subgroup differences.

Where randomization is impractical, a comparative observational study could use
contemporaneous patients receiving the usual care pathway. Statistical methods such as
matching or propensity-score weighting can adjust for measured differences between
groups, such as disease severity or access to care, but cannot rule out unmeasured ones,
so sponsors should include sensitivity analyses. Shadow deployment could help
characterize differences between device recommendations and actual care, but could not
establish the outcomes that following those recommendations would have produced.

Delayed specialist review or no intervention may be relevant comparators where they reflect
the actual pathway, but that does not justify deliberately withholding effective care or
introducing harmful delays for evaluation. The study design should preserve necessary
treatment and rescue pathways.

Question 16

Should independent third parties be involved in some or all aspects of a competency-based
approach, including device benchmarking and clinical confirmation? If so, in what ways
might qualified, independent third-party participation contribute to this approach, and what
qualifications and independence criteria should apply? Are there aspects of the assessment
for which third-party involvement would be impractical or inadvisable? What safeguards or
program design features would be critical to prevent third-party participation from limiting
competition or preventing innovation?

As an FDA-recognized third-party review organization, a notified body in the EU, and an
approved body in the UK, already performing this function for AI-enabled and software
medical devices, we believe qualified independent third parties have a clear and practical
role to play in a competency-based approach, both as independent experts and as a source
of the review capacity needed to bring safe devices to patients without delay.

Where third-party involvement adds the most value

The core value a qualified third party brings is highly specialized, scarce expertise combined
with independence from the sponsor. Neither is sufficient alone. That combination suits tasks
such as maintaining sequestered benchmarking datasets developed independently from the
manufacturer, serving as independent expert adjudicators for clinical confirmation, and
issuing a determination FDA could rely on in its own review, as described in Section V.D.2.

Above all, as the number of GenAI-enabled devices grows, and as more of them require
periodic re-benchmarking rather than a single point-in-time review, a qualified pool of third
parties helps prevent review capacity itself from becoming a bottleneck. For that reason,
third-party involvement should extend across the device types the competency-based
approach covers, not only those currently eligible for third-party review.

●​ Making evaluation expectations transparent. Standards for GenAI-enabled
devices lag the technology, and most emerging AI standards are horizontal rather
than specific to medical devices. Manufacturers therefore spend time working out
what good evidence looks like, submit documentation that misses the mark, and lose
months in review queries. Third parties that routinely assess these devices already
hold tested positions on what good evidence looks like. Publishing those positions, or
feeding them into consensus processes such as fast-track specifications and
standards committees, would let manufacturers build against them from the outset,
reducing query cycles and review burden for third parties and FDA alike. Over time,
this work could mature into consensus standards that FDA could recognize.
●​ Developing and maintaining shared benchmarks. As noted in our response to
Question 10, an independent body could build a benchmark, validate it once against
real clinical data, keep its test set protected, and refresh it with new cases over time,
as our response to Question 19 recommends. That addresses contamination and
independence concerns together, and gives FDA a consistent basis for comparing
devices, which manufacturer-specific benchmarks cannot provide. FDA’s Medical
Device Development Tools Program could offer a route to qualify such benchmarks.
●​ Supporting postmarket and change oversight. Independent review of
re-benchmarking results, monitoring evidence, and changes made under
criteria-based PCCPs would balance the greater discretion those approaches give
manufacturers, as noted in our responses to Questions 21 and 23. In the EU, we
already review manufacturers’ postmarket surveillance and have issued certificates
with explicit conditions that set deadlines for outstanding evidence.
●​ Testing foundation models. Where developers do not file Foundation Model MAFs,
independent testing of the underlying model offers an alternative source of evidence,
as noted in our response to Question 25.

Qualifications and independence criteria

Third parties should demonstrate competence across three areas, namely software and AI
engineering, clinical expertise relevant to the devices they assess, and evaluation and
statistical methodology. Where they act as adjudicators, including on the expert panels
described in our response to Question 14 and in checking synthetic test cases as described
in our response to Question 13, third parties should meet the standards we set out for
clinical reviewers, including independent initial assessment and reporting of reviewer
agreement.

Independence criteria should prevent a third party from assessing a device it helped design
or develop, or for whose manufacturer it provided consultancy services. EU notified bodies
already operate under this prohibition. Fees should never depend on the outcome of an
assessment, and staff should declare conflicts of interest. A third party that develops a
benchmark should not also sell services that prepare manufacturers to pass it, since that
would recreate the optimization-to-the-test problem described in our response to Question
10. Publishing evaluation expectations openly differs from consultancy, since it gives every
manufacturer the same information at the same time. Where a third party publishes
evaluation expectations, develops benchmarks, or contributes to standards that it also
assesses against, it should still actively manage the resulting impartiality risk. Published
expectations should state clearly that they create no binding requirements, and
manufacturers should remain free to propose alternative, technically justified evidence. FDA
should monitor third-party performance and retain the ability to suspend or withdraw
recognition.

Where third-party involvement would be impractical or inadvisable

Third parties should not take over activities for which manufacturers remain accountable,
such as device design, risk management, and continuous monitoring, including the
automated checks described in our response to Question 24. Doing so would diffuse the
accountability that FDA’s Question 21 seeks to protect. Nor should third parties turn
published expectations into de facto mandatory requirements.

Protecting competition and innovation

Third-party participation should support innovation by expanding review capacity and
reducing the time it takes safe devices to reach patients, rather than adding a further layer of
review. Several design features would prevent it from becoming a barrier. FDA should
recognize multiple qualified third parties against transparent criteria that new entrants can
meet, so that sponsors can choose between providers and no single organization controls
access to the market. Third parties should make benchmarks available on fair and
non-discriminatory terms, and publish their evaluation methods even where test data remain
protected. Benchmarks and published evaluation expectations should measure performance
rather than favor particular technical architectures, so they do not lock in today’s
approaches, and should allow manufacturers to demonstrate conformity through alternative
routes. Transparent, published fee structures would help all manufacturers, including smaller
ones, plan for third-party assessment.

Question 17

CDRH is exploring whether a competency-based approach could be applied to devices that
incorporate a variety of underlying model architectures, such as multimodal vision-language
models and generative or predictive world models. Are there aspects of the described
approach that might be ineffective or inapplicable to these devices? What additional or
distinct considerations might need to be addressed?

FDA could apply a competency-based approach across different model architectures,
provided the competencies, tests, and acceptance criteria reflect what the device is intended
to do. The manufacturer should evaluate the final configured device, including how its
components work together. Text-based questions and assessment of generated
explanations would be insufficient for a device whose clinical function depends on
interpreting images, predicting future states, or deciding on actions. Similarly, conversational
competencies would not necessarily apply to a device that does not interact with users
through conversation.

For multimodal vision-language models, testing should establish whether the device
correctly interprets each relevant input and combines information safely, consistent with the
layered approach in our response to Question 9, which tests individual competencies before
integrated scenarios. For example, testing for a device interpreting an image alongside a
patient’s medical history should check whether the image supports the findings, rather than
whether the device produces a plausible report from the history alone. Evaluation should
include missing or poor-quality inputs, contradictions between modalities, and clinically
relevant differences in acquisition equipment and settings. Acceptance criteria should
distinguish clinically significant omissions, invented findings, and incorrect measurements
from differences in wording that do not affect clinical interpretation.

For generative or predictive world models, evaluation should address the accuracy of
predicted states and their evolution over the time period relevant to the clinical decision. A
model could predict the next step accurately but accumulate clinically significant errors over
a longer sequence. Testing should therefore compare predictions with independent
longitudinal observations, assess uncertainty at relevant time horizons, and examine how
errors affect subsequent predictions or actions. Because a world model is itself a form of
simulation, the credibility principles in FDA’s guidance on computational modeling, adapted
as proposed in our response to Question 11, offer a relevant framework. Where the device
compares possible treatments, accurately predicting outcomes under observed care would
not, by itself, establish that it can predict what would happen under a different treatment.
Those claims would need additional evidence supporting the predicted effects of the
interventions. Realistic-looking simulated images or patient trajectories should not be
sufficient without evidence that they represent the clinically important features and
consequences accurately, as discussed in our response to Question 13. Where a world
model informs actions the device takes, the considerations for agentic devices in our
response to Question 26 also apply.

Section VI: Postmarket Monitoring for GenAI-Enabled
Devices
Question 18

CDRH is considering whether it may be appropriate to accept greater premarket uncertainty
regarding a GenAI-enabled device’s benefit-risk profile through greater reliance on
postmarket monitoring. Under what conditions might such an approach be appropriate, and
what characteristics of a monitoring program would need to be in place to justify reduced
premarket evidence? Are there device types or risk profiles for which this approach would
not be appropriate?

We think greater premarket uncertainty could be acceptable where the available evidence
already supports a favorable benefit-risk assessment and postmarket data can resolve the
remaining uncertainty within a justified timeframe. The manufacturer should specify what
remains uncertain, which evidence it would defer, and why it is reasonable to expose
patients to that uncertainty while it collects the evidence. An unmet clinical need or limited
alternatives could strengthen the justification, but would not compensate for insufficient
evidence of safety-critical performance.

To justify reduced premarket evidence, the monitoring program should have predefined,
clinically meaningful endpoints, acceptance criteria, and sufficient observations and
follow-up to resolve the identified uncertainty. Its design should support statistically
meaningful estimates, including for relevant subgroups, and account for incomplete outcome
data. The manufacturer should demonstrate access to reliable data, qualified clinical review
where needed, and the capacity to respond to adverse findings. The manufacturer should
base monitoring intensity and review intervals on the device’s risks, deployment volume, and
expected time to detect a problem, rather than on arbitrary fixed schedules. There should
also be explicit milestones for obtaining the deferred evidence and predefined thresholds for
restricting or suspending use. Failure to meet those milestones should itself trigger
restrictions, so that deferred evidence does not remain outstanding indefinitely. As an EU
notified body and a UK approved body, we have issued certificates with explicit conditions
that set deadlines for outstanding evidence and allow us to restrict or suspend certification if
the manufacturer misses them.

We would not support this approach where the unresolved uncertainty concerns failures that
could cause serious, irreversible harm before monitoring could prompt an effective response.
Consistent with our responses to Questions 1 and 8, these would typically be functions at
the higher end of the consequence axis. For example, a GenAI triage chatbot could falsely
reassure a patient with chest pain that urgent assessment is unnecessary, creating a risk of
delayed treatment. Nor would the approach suit cases where the relevant failures would not
reliably surface in monitoring data. In the chest pain example, if the patient later suffers
harm, nothing may link that harm back to the device, so monitoring would not detect the
failure. It would also be inappropriate where safety depends on users detecting clinically
significant errors, but testing with representative users has not shown that they can
recognize those errors and avoid acting on them. The same applies where the manufacturer
cannot collect reliable evidence within an acceptable period. In particular, infrequent events
or small subgroup populations may make postmarket estimates too imprecise to justify
deferring the relevant premarket evidence.

Question 19

Please comment on the potential approaches to postmarket performance evaluation,
including periodic re-benchmarking, sample-based clinician review, and performance
degradation monitoring. What additional approaches should CDRH consider, and how
should the cadence and triggering events for reassessment be determined?

We think the three approaches should work together to establish whether the device
continues to perform safely in practice. Re-benchmarking can check whether the device still
meets predefined criteria on clinical test cases, including, where outputs are not
reproducible, whether repeated runs produce consistent clinical responses. Consistent with
our response to Question 10, sponsors should periodically refresh benchmark test sets with
new, unseen cases, since repeated use of the same cases weakens their value as an
independent test. Clinician review should assess real interactions, including complete
conversations where earlier exchanges affect later advice. Reviewers should have relevant
clinical expertise and the information needed to identify errors. A random sample of
interactions would provide estimates of typical performance, while a targeted sample would
focus review on high-risk interactions. As in our response to Question 12, sponsors should
not present results from a targeted sample as typical performance. Tracking the frequency
and severity of these errors over time, including across patient groups, would help detect
deteriorating performance.

Sponsors should complement these checks by reviewing incidents and near misses and
following up relevant clinical outcomes. This would help identify whether patients
misunderstood generated advice or whether it contributed to delayed or inappropriate care.
As noted in our response to Question 18, monitoring detects only failures that surface in
available data, so outcome follow-up matters most where harm may occur outside the
setting in which the device operates. Automated screening of device outputs could also
support clinician review, subject to the considerations in our response to Question 20.

Review frequency should reflect the consequences of error, the number of patients exposed,
and the amount of data needed to detect meaningful deterioration, rather than arbitrary fixed
schedules. Manufacturers should also define reassessment triggers, including changes to
the model, prompts, retrieved sources, or safeguards, and material changes in the patient
population or clinical workflow. Changes in clinical guidelines or medical knowledge should
also trigger reassessment, as a device can become outdated without itself changing. As
noted in our response to Question 7, scheduled reassessment cannot capture updates that a
third-party model provider makes without notice. Sponsors relying on such models should
run continuous automated checks, such as a fixed set of test cases at frequent intervals, to
detect sudden shifts in performance. An unexpected error with potentially serious
consequences should prompt reassessment without waiting for the next scheduled review.

Question 20

Please comment on whether the proposed approaches to postmarket monitoring can be
facilitated by machine-based supervisory agents. What considerations, including the
evaluation and reliability of the supervisory agent itself, should CDRH take into account for
such an approach?

We think machine-based supervisory agents could support postmarket monitoring by
running benchmark tests, tracking performance, and identifying interactions requiring clinical
review. Where the supervisor also intervenes, enforcement points in the software could help
apply safeguards. These could serve as predefined points in the workflow where the system
holds an output pending a required check or authorization, for example, preventing a flagged
response from reaching the user until a qualified clinician has reviewed it.

The distinction between monitoring and intervening matters. A supervisor that only monitors
and flags interactions supports the sponsor’s quality processes. A supervisor that blocks or
alters outputs forms part of the device’s safety controls, and FDA should evaluate it as part
of the device, subject to the same evidence and change control expectations.

Sponsors should evaluate the supervisor against assessments made by clinicians with
relevant expertise, using cases excluded from its development. Testing should measure
missed clinically significant errors, unnecessary alerts, response time, and consistency
across repeated assessments. If the device and supervisor use the same or related models,
testing should examine whether both overlook the same mistakes. Agreement between them
would not, by itself, establish clinical correctness.

Evaluation should also verify that the enforcement points actually enforce the required
checks and cannot silently bypass them when the supervisor fails or is unavailable. The
system should fail safe, defaulting to holding outputs or suspending the function rather than
releasing outputs unchecked. The workflow should define how the sponsor reports and
handles such failures. Holding outputs carries its own risks, however. In time-critical settings,
delay may itself cause harm, consistent with the time pressure considerations in our
response to Question 1. Frequent unnecessary alerts may also lead clinicians to disregard
flags, undermining the effectiveness of oversight discussed in our responses to Questions 1
and 14.

During deployment, clinical audits should include interactions the supervisor has not flagged,
so that clinicians can identify missed errors. Changes affecting any of the device, supervisor,
or enforcement mechanism should prompt reassessment of their combined reliability. Where
the supervisor relies on a third-party model, its provider may update that model without
notice, so the continuous checks described in our responses to Questions 7 and 19 should
apply to the supervisor as well.

Question 21

What roles might clinicians, healthcare institutions, professional societies, standards-setting
bodies, and other stakeholders appropriately play in postmarket monitoring, and how can
these roles be structured without diffusing manufacturer accountability?

The manufacturer should remain accountable for postmarket monitoring, with other
stakeholders contributing evidence to its processes rather than sharing responsibility for
them. Postmarket monitoring should connect stakeholder observations to the manufacturer’s
risk management through traceable evidence. Clinicians could review generated advice and
report errors and their clinical consequences, while patients could report misunderstandings
or difficulties following it. Healthcare institutions could supply the relevant clinical records
and workflow context. Professional societies could help define clinically meaningful errors,
and standards-setting bodies could establish consistent methods for collecting and
assessing monitoring evidence. Stakeholder reports should supplement, not replace, the
active monitoring described in our response to Question 19, since clinicians can underreport
adverse events and, as noted in our response to Question 18, many failures may go
unnoticed. Building simple reporting mechanisms into the device itself would make reporting
easier.

The manufacturer should link each concern to the relevant inputs, generated outputs, device
and model versions, and clinical circumstances. That record should then connect to the
manufacturer’s investigation, risk assessment, and any action taken. Arrangements for
sharing this information should address patient privacy and data protection. Consistent with
our response to Question 24, the manufacturer should secure commitments from model
providers, such as advance notice of changes or access to fixed model versions. FDA’s
proposed Foundation Model Device Master Files could also allow providers to share
confidential model information with FDA directly. Independent reviewers could assess the
quality of the evidence and investigation. As an EU notified body, we already review
manufacturers’ postmarket surveillance under the MDR, which shows how independent
review can strengthen monitoring without displacing manufacturer responsibility.

Written arrangements should specify each contributor’s role, how findings reach the
manufacturer, and the timeframes for reporting. In particular, the manufacturer remains
accountable for the adequacy of monitoring, assessing whether findings change the
benefit-risk profile, implementing necessary corrective actions, and checking that those
actions work. The manufacturer should document these decisions and their supporting
evidence, so that responsibility remains identifiable throughout the process.

Question 22

CDRH envisions that a manufacturer’s premarket competency-based assessment might
serve as a baseline against which post-deployment modifications could be re-evaluated.
How might the extent of re-benchmarking or other evidence be scaled to the nature and
expected impact of a given modification? For example, are there categories of change that
might not significantly affect safety or effectiveness of a GenAI-enabled device, or might be
appropriately managed within a sponsor’s quality management system versus requiring FDA
premarket review and authorization before implementation? Are there categories of changes
that might be appropriate for inclusion in a PCCP?

FDA’s existing PCCP guidance already provides the core mechanism, namely a description
of planned modifications, a protocol for developing, validating, and implementing each, and
an impact assessment. The open question is which categories of change belong inside that
mechanism, which fall outside it and require a new marketing submission, and which need
no submission-based involvement at all.

The extent of re-benchmarking should scale with the expected impact of a change. Building
on the layered approach in our response to Question 9, a limited change could require
re-running the tests for the competencies it affects, together with a core set of integrated
clinical scenarios to detect unexpected effects elsewhere. A major change, such as a
change to the foundation model, should require full re-benchmarking against the premarket
baseline.

We would suggest anchoring the distinction between these categories the same way we
anchor them in change management more broadly, as an EU notified body assessing
reportable changes under the MDR, not by the type of change, but by whether it affects the
device’s intended purpose or materially changes its safety or performance profile. Types of
change can serve as typical examples, but the effect of each change should determine its
category. This matters particularly for GenAI-enabled devices, where seemingly small
changes can have large and unpredictable effects on outputs.

A change to the underlying foundation model or its provider is a useful test case. Even
where the manufacturer has made no code-level change, swapping model versions or their
providers is a change to a critical supplier with implications for device behavior as a whole. It
should therefore sit outside a PCCP’s pre-authorized scope rather than inside it, unless the
manufacturer specifically drafted the PCCP to anticipate that kind of substitution and assess
its impact. Not every model change is the manufacturer’s choice. As noted in our response
to Question 7, providers may update models without notice, which is why the continuous
checks described in our response to Question 19 matter.

Day-to-day changes, such as user interface refinements or bug fixes, are best handled
without any submission-based involvement, through the manufacturer’s own quality system,
provided testing confirms they do not affect clinical outputs. Changes that fall between the
two, most notably retraining and deploying a GenAI model within previously validated limits,
are those a PCCP is best suited to cover, provided the modification protocol and impact
assessment were specific enough at authorization to anticipate them. Performance tuning
belongs in this category too, since it changes the device’s performance profile. So do other
changes typical of GenAI-enabled devices, such as changes to prompts, retrieved sources,
or safeguards, which we identify as reassessment triggers in our response to Question 19,
where the PCCP anticipates them.

Question 23

How might PCCP concepts or other change-control approaches be adapted for
GenAI-enabled devices when the nature or scope of future modifications cannot be fully
prespecified?

Where manufacturers cannot fully describe future modifications in advance, PCCPs could
place greater emphasis on prespecified risk-assessment and validation criteria. These would
define what the manufacturer must demonstrate for a modification to remain within the
authorized plan, whether it affects the model, prompts, retrieval, or safeguards. The intended
use, patient population, and required safety-critical performance should remain clearly
bounded. Third-party model updates, which providers may make without notice as noted in
our responses to Questions 7 and 19, are the clearest example of changes that no
manufacturer can fully prespecify. Consistent with our response to Question 22, however, a
PCCP should cover a change to the foundation model only where it specifically addresses
that kind of change and requires full re-benchmarking against the premarket baseline.

For each modification, the manufacturer should identify the affected clinical functions,
assess new or increased risks, and demonstrate that the necessary risk controls remain
effective. Validation should assess the complete modified device, including unintended
effects and the combined effects of successive changes. To prevent gradual drift, the
manufacturer should validate each modification against the original premarket baseline, not
only against the previous version. A traceable record should connect the changed
components and versions to the affected functions, identified risks, controls, validation
evidence, and release decision.

A modification that exceeds the agreed boundaries, or whose risks the agreed methods
cannot adequately assess, should undergo further regulatory review before implementation.
The manufacturer could then revise the plan through regulatory review as new modifications
and their risks become sufficiently understood. Because a criteria-based plan gives
manufacturers greater discretion, periodic reports to FDA summarizing modifications made
under the plan, or independent review of how the manufacturer applies its criteria, would
help maintain oversight.

Question 24

For devices built on third-party foundation models, changes to the underlying model may be
initiated by the third-party model developer rather than the device manufacturer. How can a
manufacturer detect, evaluate, and respond to such changes in a timely manner? What
mechanisms—for example, contractual, technical, or through a PCCP—could provide
reasonable assurance that third-party developer-initiated changes do not compromise the
safety or effectiveness of the device?

Manufacturers should manage third-party model changes through supplier controls, risk
management, and traceable device evaluation. Supplier agreements should seek advance
notice of updates or withdrawals, time to validate replacements, and access to relevant
technical information. In practice, many manufacturers, particularly smaller ones, have
limited leverage over major model providers, so their technical measures and planned
fallbacks should not depend on securing such terms. As noted in our response to Question
21, FDA’s proposed Foundation Model Device Master Files could allow providers to share
technical information with FDA that they may not share with individual manufacturers. Where
possible, manufacturers should select fixed model versions and prevent automatic
substitution. Regular automated tests of clinically important functions should also check that
the deployed device continues to meet performance criteria, including when the provider has
notified no change. Monitoring broader characteristics of live outputs, such as response
length or the frequency of declined responses, could help detect changes that these tests do
not cover.

Manufacturers should evaluate notified updates before adoption where feasible. Unexpected
changes in behavior should trigger prompt investigation and targeted testing of the complete
device, assessing affected clinical functions, new or increased risks, and whether
safeguards remain effective. Consistent with our response to Question 22, where the
investigation confirms a change to the underlying model, full re-benchmarking against the
premarket baseline should precede any decision to keep the changed model in use. Records
should connect the available model and version information, identified risks, and evaluation
results to the decision on continued use.

An authorized PCCP could cover anticipated provider updates through defined evaluation
methods and acceptance criteria. The manufacturer should subject changes outside its
scope to separate change assessment, including whether further regulatory review is
needed. Manufacturers should plan responses in advance, such as retaining a validated
version where available, using a validated fallback, or restricting or suspending affected
functions while they assess the change. Because providers retire older model versions,
manufacturers should also plan for retirement, for example by validating an alternative model
before a version’s withdrawal date. Testing frequency and response times should reflect the
clinical consequences of failure and the manufacturer’s control over the deployed service.

Section VII: Other Topics
Question 25

Would voluntary Foundation Model MAFs be practical for foundation model developers to
provide and to keep current, and what content might they include? Given that participation
would be voluntary and that model developers may have limited incentive to disclose
safety-relevant information, what would make such a program sufficiently useful for
premarket review? Are there alternative mechanisms CDRH should consider for obtaining
information about underlying foundation models?

Voluntary Foundation Model MAFs could be practical if they use a standardized structure,
identify the model version and service configuration, and developers update them when
relevant capabilities or safeguards change. Content should include training-data provenance
and limitations, healthcare-relevant evaluation methods and results, subgroup performance,
known failure modes, safety-related behaviors, and arrangements for version control and
notifying manufacturers of changes. As noted in our response to Question 24, MAFs could
also carry commitments that individual manufacturers struggle to secure, such as advance
notice of changes and minimum support periods for model versions.

For premarket review, claims should be traceable to supporting evidence for the version
used in the device, with dated evaluations and explicit information gaps. Clear minimum
content expectations and a process for answering reviewers’ questions would help make the
files useful. Allowing several manufacturers to reference one confidential file could
incentivize participation by reducing repeated information requests while protecting
proprietary information. Market demand could provide a stronger incentive. If referencing a
MAF simplifies premarket review, manufacturers will favor models that have one, giving
participating developers an advantage in the healthcare market. FDA could reinforce this by
setting out how a MAF would streamline review for manufacturers that reference it.

Where developers do not participate, alternatives could include structured supplier
documentation submitted by manufacturers, confidential information provided directly to FDA
for a particular application, and independent testing of the underlying model. FDA could also
draw on documentation that developers already prepare elsewhere. Under the EU AI Act,
providers of general-purpose AI models must prepare technical documentation and make
information available to companies that integrate their models. Aligning MAF content with
that documentation would reduce the burden on developers and, consistent with our
response to Question 1, support international harmonization. These routes provide different
kinds of evidence. External testing can characterize behavior but cannot establish
undisclosed training-data provenance. Remaining gaps should therefore be explicit in the
manufacturer’s risk assessment, and model-level evidence should support evaluation of the
complete configured device.

Question 26

Are there additional considerations that inform the premarket and postmarket evaluation of
agentic GenAI-enabled devices, beyond those applicable to non-agentic GenAI-enabled
devices? How should the elevated risk associated with autonomous multi-step action, tool
use, and reduced opportunity for human review be reflected in acceptance criteria and
oversight?

Sponsors should evaluate agentic devices on the safety of complete action sequences, as
well as the final clinical result. Consistent with our responses to Questions 1 and 8, agentic
functions sit in the action-taking categories of the two-axis risk framework, so their position
on the framework should already reflect much of their elevated risk. Premarket testing
should use realistic multi-step workflows and include incorrect tool results, interrupted tasks,
and malicious instructions embedded in retrieved content, known as prompt injection. It
should establish whether the device detects and contains an early error or propagates it into
subsequent actions. Building on the layered approach in our response to Question 9, testing
should cover both individual steps and complete sequences. Because tool access widens
the device’s attack surface, FDA’s existing premarket cybersecurity expectations should
apply in full.

Acceptance criteria should cover correct tool selection and inputs, adherence to permitted
actions, safe stopping and recovery, and obtaining required human approval before
consequential actions. Manufacturers should define permitted actions narrowly, granting the
device only the access and actions its intended use requires, to limit the harm any error or
attack can cause. Sponsors should assess unsafe or unauthorized actions separately from
overall task success. More stringent safety criteria and stronger evidence of preventive
controls should apply where actions could cause irreversible harm and clinicians cannot
intervene in time. Enforcement points, as described in our response to Question 20, could
apply permissions and approval checkpoints, with testing for bypass attempts and control
failures, and should fail safe if a control becomes unavailable. Approval requirements should
also avoid approval fatigue. If the device requests approval too often, clinicians may approve
without meaningful review, consistent with the concerns about automation bias and alert
fatigue in our responses to Questions 14 and 20.

Postmarket oversight should preserve traceable records of tool calls, results, approvals, and
executed actions, linked to the relevant model and tool versions and, where available,
clinical outcomes. Reviewing these sequences would help identify where errors occurred,
whether safeguards worked, and what corrective action is needed. Changes to models,
tools, or workflows should trigger reassessment of affected action sequences, and the
manufacturer should incorporate the findings into its risk management. Where third parties
provide the tools, their updates raise the same issues as model changes, as discussed in
our response to Question 24.