Amazon.com, Inc.

See attachment.

October 19, 2026

Dr. Michelle Tarver
Director, Center for Devices and Radiological Health
U.S. Food and Drug Administration
10903 New Hampshire Avenue
Silver Spring, MD 20993

Re: Docket No. FDA-2026-N-7874 – Considerations for the Regulation of Generative AIEnabled Medical Devices: Discussion Paper and Request for Feedback
Submitted via Regulations.gov

Dear Dr. Tarver,

Amazon.com, Inc. (“Amazon”) welcomes the opportunity to provide feedback on CDRH’s
Discussion Paper on Considerations for the Regulation of Generative AI-Enabled Medical
Devices. We share CDRH’s goal of enabling a regulatory approach that applies least burdensome
principles while allowing patients and providers timely access to safe and effective medical
devices.

Amazon brings significant experience building, deploying, and evaluating super intelligence in
healthcare settings. Amazon One Medical, a national primary care practice, uses generative AI to
handle routine administrative tasks and provides patients with personalized health information
through its Health AI assistant. Amazon One Medical is further exploring how to use generative
AI to increase access to and decrease the cost of care. Amazon Web Services (AWS) offers
purpose-built health services and general-purpose cloud infrastructure and tools to healthcare
providers, insurers, electronic health record vendors, life sciences companies, and medical
device and diagnostic manufacturers, among others, to support clinical workflows and help
build AI systems. Amazon Pharmacy uses AI to process prescriptions and predict medication
inventory needs. These products incorporate sophisticated AI, processing physiological inputs
into individualized recommendations, and may integrate with clinical services like Amazon One
Medical. This gives Amazon direct operational insight into the boundary between AI wellness
products and AI medical devices - a boundary CDRH’s framework must define clearly to avoid
either sweeping wellness AI into device-level regulation or leaving clinical AI under-regulated.

Several cross-cutting principles shape our responses and warrant emphasis at the outset. CDRH
should regulate AI-enabled solutions that meet the statutory definition of a medical device
under its existing statutory authority. The incorporation of AI should not alter whether a product
meets the definition of a device or necessitates novel regulatory categories. As the FDA
contemplates the long-term frameworks for AI-enabled devices, we encourage CDRH to take
timely steps to work with innovation-forward states testing novel AI technologies within their
regulatory jurisdictions. The pace of AI development is accelerating, and patients are waiting for
care that this technology can deliver today. CDRH has an opportunity to lead, and acting with
urgency on these partnerships will ensure that the benefits of clinical AI reach patients. Within
FDA’s device frameworks, oversight intensity and evaluation methods should track the actual
clinical risk a device presents based on factors like the system’s level of autonomy, the
downstream safeguards available, and the consequences of an incorrect output in context.
Because that risk profile can only be partially characterized before deployment, prospective
clinical studies may not be the gold standard for these devices. We believe real-world evidence
generated by the deployed system should be the primary basis for establishing and expanding
trust in clinical AI. Accordingly, postmarket monitoring should be a core mechanism of safety
assurance, with oversight mechanisms like continuous performance surveillance, clinician
feedback loops, and the ability to constrain or withdraw autonomy rapidly when warranted.
Sustaining that lifecycle of evidence requires clear accountability, and the framework should
allow postmarket monitoring to be performed by the entity best suited to do so, which may not
always be the device developer. For example, shared responsibility frameworks exist today
between cloud service providers, foundation model developers, and deployers to further share
responsibility with device developers.

Our recommendations are grounded in two convictions about what effective regulation of
clinical AI should accomplish over time.

First, healthcare should become dramatically more affordable and accessible. AI has the
potential to reduce the marginal cost of clinical care, which matters most for the patients who
today go without care because of cost, distance, or clinician shortages. A regulatory framework
that makes deployment economically impractical forfeits this outcome.

Second, healthcare should become safer and more effective. AI has the potential to reduce
diagnostic error, missed follow-up, and unwarranted variation in care. Regulation should be
structured so that safety improvements reach patients quickly, rather than locking systems at a
point in time while known failure modes persist.

These goals reinforce, rather than trade off against, each other when the regulatory framework
is built on lifecycle evidence, oversight and evaluation proportionate to risk and autonomy, and
graduated independence. The responses below address the discussion questions where our
operational experience provides a substantive basis for comment.

For clarity, this response uses the following terms: “Device developer” refers to the entity that
builds, validates, deploys, and maintains the GenAI-enabled medical device and bears primary,
non-delegable responsibility for the safety of the deployed system. This is the party FDA would
recognize as the device’s sponsor or manufacturer. As used here, device developer denotes the
entity accountable for the device’s safety, not merely a downstream user of it. Where the device
is utilized by a different entity than its developer, any framework should permit obligations to
be delegated to the party best positioned to prevent or reduce harm. “Foundation model
developer” refers to the upstream provider of an AI model trained using large datasets that can
serve as a foundation upon which further models can be built and adapted for specific uses
through further training (i.e., fine-tuning). “Clinician” (or “provider”) refers to the licensed
healthcare professional who may review, approve, or act on the device’s output, and “user”
means the device’s intended user, whether a clinician or a patient, as specified by the intended
use.

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 that should be
represented in a risk framework, please describe and provide examples of how they should be
represented.

Amazon supports CDRH’s stated intent to apply a risk-based approach to the regulation of
GenAI-enabled devices, calibrated to the device’s intended use and technological
characteristics. CDRH’s two-axis risk framework is a sound foundation that should operate
within the shared responsibility model that allocates responsibility, or permits delegation, to the
party best positioned to prevent or reduce harm. Organizing risk around what the device does
and what happens when its output is wrong captures the dimensions most likely to affect
patient safety. We encourage CDRH to also consider the reversibility of the resulting clinical
action, the availability of downstream safeguards such as escalation pathways or clinician
review, and the system’s containment capabilities, including the ability to withdraw autonomy
rapidly. These dimensions can meaningfully alter the risk profile of devices that otherwise share
similar intended uses. We also caution FDA against directly equating autonomous systems with
inherently higher risk than other GenAI-enabled devices.

Moreover, we urge CDRH to ensure this framework applies only to products that meet the
statutory definition of a medical device and does not inadvertently extend device-level oversight
or evaluation obligations to software functions that fall outside that definition or that CDRH has
historically deemed non-device functions including non-device clinical decision support tools.
More clarity on the boundary between device and non-device GenAI-enabled software functions
would help device developers across the ecosystem understand their obligations and promote
innovation.

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. What
characteristics of an output could be considered as modifiers of the risk associated with an
informational function?

We believe FDA should constrain this framework to products that already meet the statutory
definition of a medical device based on intended use. The incorporation of AI should not itself
determine whether a product is a device. For products that do meet that definition, risk
modifiers along the informational spectrum could include items like: for clinician-facing
products, whether a clinician reviews the output before clinical action is taken, whether the
system operates within explicit clinical boundaries or adapts openly, and the severity and
reversibility of the action that may follow, or, for patient- or caregiver-facing products, whether
the output provides general information from trusted reference sources that an end user may
independently validate.

Amazon operates services across this spectrum, from non-device non-directive health
information to proposed treatment plans reviewed by clinicians to proposed autonomous care
delivery. Operating across this continuum confirms the value of distinguishing risk levels within
the spectrum rather than treating all AI-generated clinical outputs as equivalent.

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.
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?
We encourage CDRH to avoid a blanket requirement that patient-facing clinical AI outputs
undergo clinician review. The appropriate role of clinician oversight should be determined by
data, context, and risk, not by a categorical distinction between patient-facing and
clinician-facing delivery. AI could drive the marginal cost of routine clinical care toward zero,
which matters for patients who go without care because of cost, distance, or provider
shortages. A mandatory clinician intermediation requirement would take that benefit away.

Other safeguards that may mitigate risk for patient-facing clinical AI could include validated
performance thresholds, reliable emergency detection and escalation, continuous postmarket
monitoring, and the ability to withdraw autonomy immediately when warranted. Further we
encourage CDRH’s framework to accommodate a risk-based spectrum for “action-directing”
within an output. The framework and safeguards should be proportionate to the risk of the
device and the context of use. For example, an output that encourages patients to “talk to their
doctor” about a medical concern is likely lower risk than one that encourages the patient to take
action without consulting a clinician. CDRH should also recognize that restricting patient access
to AI-generated clinical guidance or care can itself be a source of harm when the alternative is
no guidance or care at all.

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?

User expertise is one contextual factor within a broader risk assessment, not a categorical
determinant of risk. The two-axis framework already captures most situations in which it
matters: a function that directs diagnosis or treatment of a serious condition may warrant
additional safeguards where the intended user has limited ability to evaluate the output
independently, while educational, summarizing, or readily verifiable functions do not become
higher risk merely because the content is specialized. Many such low-risk functions are not
devices at all, and CDRH should not inadvertently subject non-device software to device-like
standards.

The risk that a generalist physician may over-rely on an AI-generated output they lack the
specialist knowledge to independently verify is best addressed through device-level validation
and safeguards rather than a risk classification tied to the user’s specialty. For example, device
developers should be able to gather and present real-world evidence that the device is used
safely by the intended user population, including generalist physicians. Moreover, risk
associated with the lack of user expertise can be mitigated through transparency about
intended users and use environments, sources and evidence, communication of uncertainty and
scope, escalation prompts when specialist input is warranted, and validation across
representative populations. CDRH should preserve flexibility to tailor these controls to specific
functions rather than presume that delivering specialized information to a generalist is
inherently higher risk.
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?

Risk should be assessed at the conversation level, not the turn level. The clinical significance of
any single output in a multi-turn conversation depends on what preceded it and what follows. A
question that appears non-directive in isolation may be clinically meaningful in the context of
the information already gathered and the action the system will propose. Evaluating individual
outputs without accounting for the conversational arc would fail to capture the risks and
benefits that emerge across a full interaction.

We recommend that CDRH encourage evaluation methodologies that account for realistic
conversational patterns and the cumulative effect of information exchange, rather than
requiring device developers to classify the risk of each turn independently. Our testing of
conversational clinical AI evaluates full multi-turn trajectories against clinical criteria that span
the complete interaction.

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?

Under-escalation and over-escalation present asymmetric risks and should be treated
accordingly. Under-escalation is a patient safety concern: a patient who should have been
referred to higher-acuity care was not. Over-escalation is an access, cost, and quality concern: a
patient who could have been safely treated was unnecessarily delayed or denied care or sent to
a more expensive service offering. Both matter, but the severity and immediacy of harm differ,
and evaluation frameworks should reflect that asymmetry.

Emergency detection should be evaluated as a separate, high-priority criterion. For
non-emergency escalation, device developers should monitor escalation rates as a continuous
safety signal and, where available or provided, track whether escalated cases confirm that
escalation was warranted. Over-escalation should be measured and managed, but should not be
weighted equivalently with failures that could result in direct patient harm.

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?

We strongly support a competency-based approach. We recommend that CDRH distinguish
between clinical competencies (what the system must be able to do for the patient) and
operational assurance requirements (how the device developer demonstrates and maintains
safe performance over the product lifecycle). The clinical competencies should be observable
and testable without requiring judgments about the system’s internal reasoning.
For example, we provide the following competencies for consideration related to a broad
purpose GenAI-enabled device: understand the patient’s situation by gathering and interpreting
relevant information; develop a clinical assessment including dangerous possibilities that must
not be missed; identify medically reasonable options and rule out those that are unsafe or
contraindicated; choose an appropriate plan using the patient’s goals and preferences without
allowing preferences to override safety; deliver and explain the care correctly; follow through
and adjust the plan as new information emerges; and recognize when the system should not
continue autonomously. These competencies apply whether the system executes bounded
protocols or adapts openly to patient input.

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

The risk framework should translate directly into graduated evidence requirements. A device
that operates with mandatory clinician review may require a different evidentiary standard than
one that delivers treatment autonomously, even if both demonstrate the same clinical
competencies. The presence or absence of downstream safeguards should be a principal factor
in determining the level of evidence required.

We recommend a graduated independence model in which evidence requirements scale with
the system’s level of independent clinical action. Our experience confirms that a multi-stage
validation approach, where each stage addresses safety questions the others cannot answer
alone, provides an effective structure for calibrating evidence to risk.
Evidence requirements and monitoring intensity should be proportionate to risk and should
reflect the context of use. A one-size-fits-all approach could fail to reach intended safety
outcomes while delaying patient access to beneficial technologies. Our experience with clinical
AI systems across different autonomy levels confirms that these additional dimensions produce
materially different risk profiles in practice.

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? Are there elements that are missing, redundant, or
inappropriately categorized? Are there externally developed standards that could be used?

A benchmarking structure can establish a floor for evaluating these capabilities, but existing
public AI benchmarks often fail to predict how clinical AI systems perform in practice. Their
content is public and static, which means results can reflect familiarity with the test as much as
clinical capability, and they evaluate bare models rather than the deployed systems patients
encounter.

We would support benchmark performance as a factor in determining the level of autonomy a
system may exercise. Benchmarks should be hazard-weighted and focused on clinically
meaningful failure modes, not on representative case distributions. A shared benchmark can
serve as a floor; but the device developer’s own system-level evaluation remains essential.

10. 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?

A benchmark predicts real-world safety only if it was designed with clinicians who understand
the failure modes that matter. Without that expertise, benchmarks risk testing what is
convenient rather than what is dangerous. The distribution that matters for safety is not the
distribution of production traffic; safety-critical failures concentrate in rare edge cases.
Benchmarks therefore have validity when designed by clinicians who understand how and why a
system can fail, with test cases constructed to manifest specific, named hazards.

This expertise can be developed internally by the device developer or externally through
well-designed standardized benchmarks, provided those benchmarks are hazard-weighted,
sequestered to prevent overfitting, and assessed by qualified clinical adjudicators. Device
developers’ own benchmarks play a valuable role because the device developing organization
has the deepest understanding of its system’s failure modes. CDRH should require device
developers to demonstrate that the utilized benchmarks cover the clinically meaningful failure
modes for the intended use, rather than mandating reliance on a particular external
benchmark.

11. CDRH is considering that clinical confirmation for a GenAI-enabled device might not
require a prospective clinical study in every case. How might a sponsor select and justify a
confirmation approach tailored to a device’s intended use and proportionate to its risk
profile?

Amazon agrees that the regulation of GenAI-enabled devices should be tailored to the device’s
risk profile, and that a prospective clinical study may not be needed nor feasible in every case.
Rigorous alternatives exist, including shadow-mode evaluation in which the system is run
against real patient encounters handled by licensed clinicians. For lower-autonomy devices
where a clinician reviews every case, the deployment itself can function as continuous clinical
confirmation, producing a systematic stream of evidence about system performance.

For example, a shadow-mode evaluation at scale can provide high-quality evidence of real-world
performance while surfacing failure modes that synthetic or simulated testing may miss. CDRH
should permit device developers to select and justify confirmation approaches proportionate to
risk, with more intensive approaches required for devices operating with greater independence.
The framework should specify the safety expectations rather than prescribing a particular study
design, number of cases, or provider review rate, since the appropriate approach depends on
the device's intended use and the consequence of an incorrect decision.

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?

Synthetic and real-world data serve complementary roles. Synthetic patient generation provides
scalable coverage with low overfitting risk and is particularly useful for measuring performance
disparities across patient subgroups, because demographic attributes can be explicitly sampled
rather than incidentally observed. Real-world data provides ground truth about how the system
performs in production and surfaces the novel presentations that synthetic generation may not
anticipate.

For open-ended devices where the input distribution is effectively unbounded, real-world cases
are especially important. Device developers should report performance by data type (synthetic
or real-world) rather than combining them into a blended metric, and should use synthetic data
to stress-test specific failure hypotheses while relying on real-world data to estimate
population-level performance.

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 is a valuable supplement to real-world evidence to stress test specific failure
hypothesis where real data is limited, difficult to obtain, privacy-constrained, or insufficient to
answer a specific performance question. It is particularly well-suited to expanding coverage of
rare conditions, edge cases, and underrepresented populations. Its adequacy depends on the
context of use, and CDRH should adopt a flexible, risk-based approach that lets device
developers demonstrate a synthetic dataset is sufficiently representative, reliable, and
fit-for-purpose for its intended role.

Depending on the circumstances, approaches that may support confidence in the use of
synthetic data could include validating synthetic data against relevant real-world evidence,
assessing performance across clinically relevant subgroups, being transparent about the role
synthetic data played, and using complementary methods to confirm it can identify meaningful
performance limitations. The controlling question is whether the overall evaluation provides
confidence that the device performs safely and effectively for its intended use and population.
CDRH should preserve flexibility for alternative methodologies that achieve the same objective.

14. For open-ended device outputs, how should performance comparators and acceptance
criteria be selected? When should human-AI team performance, rather than the device
operating alone, serve as the basis for evaluation?

The appropriate comparator should reflect the actual deployment model. For autonomous
systems where no clinician reviews the output before clinical action, the device should be
evaluated as a solo performer against a qualified clinical standard. For systems where a clinician
reviews every case, human-AI team performance is the natural evaluation unit; success means
the clinician needs to do progressively less work to safely and effectively resolve each case.

For open-ended clinical outputs, acceptance criteria focused on clinical appropriateness,
completeness, and actionability are more meaningful than criteria requiring an exact match to a
single predetermined answer. CDRH should permit device developers to select comparators that
reflect their deployment model.

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?

Yes, and for many patients, this is the most relevant comparator. CDRH should permit device
developers to identify and justify the comparator most relevant to their intended population.
Where evidence supports that a meaningful proportion of the target population would receive
delayed care, no care, or care inconsistent with evidence-based guidelines, the benefit-risk
calculus should account for that reality. This does not mean that a lower standard of care is
acceptable; it means the benefit side of the analysis should reflect the actual alternative the
patient faces.

16. Should independent third parties be involved in some or all aspects of a
competency-based approach, including device benchmarking and clinical confirmation?

Independent clinical judgment has value in benchmarking and periodic audit, and qualified third
parties can play a constructive role in those activities. However, we caution against mandating
third-party involvement in ongoing validation activities, which often depends on continuity of
clinical judgment within the device developing or deploying organization. One factor to consider
may be whether the validating team is a direct clinical provider integrated with device
developer, as opposed to truly external reviewers. In the first case, the team that identifies
hazards, designs test cases, and evaluates results carries institutional knowledge that makes
each successive stage of validation more rigorous. Distributing that work across external parties
can slow the iteration that drives safety improvements.

If CDRH establishes a third-party role, we recommend structuring it as periodic audit rather than
ongoing gatekeeping. Safeguards should prevent third-party programs from limiting
competition, creating bottlenecks, or favoring organizations with the resources to engage
external reviewers over those with strong internal clinical governance.

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?

We support a competency-based approach that is architecture-neutral. Any evaluation
framework should remain technology-neutral rather than tied to particular model architectures,
which makes it more durable as GenAI systems evolve. The framework described in the
Discussion Paper can accommodate multimodal and other architectures provided the evaluation
stays focused on the safety, effectiveness, and real-world performance of the device as used.
Intended use and resulting device function are usually more informative than the underlying
architecture in determining which competencies are relevant and how they should be
evaluated.

Certain architectures raise distinct considerations: multimodal systems require attention to how
different input types are integrated and evaluated together, and predictive world models may
raise considerations related to reasoning, simulation, or temporal prediction. Rather than
establishing architecture-specific requirements, CDRH should provide examples illustrating how
the competency-based framework applies to different architectures under a consistent
risk-based approach, focusing on the device’s capabilities, clinical context, and the
consequences of incorrect outputs rather than the specific technical architecture.

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?
We strongly support this approach. For devices that produce variable, open-ended outputs and
may improve continuously after deployment, premarket testing cannot fully characterize
performance across all possible interactions. Requiring systems to be frozen at a point in time
forfeits the potential for continuous improvement and can make them less safe, because
yesterday’s validated version still contains the failure modes that have since been identified and
corrected.

This principle has relevance for AI-enabled products that occupy the boundary between
wellness and clinical use. As these products accumulate real-world performance data, that
evidence may support either a confirmation that the product appropriately remains in the
wellness space or a determination that its real-world use has drifted toward clinical applications
warranting device-level oversight. CDRH should recognize that postmarket evidence can also
serve a boundary-maintenance function, not only a safety-assurance function, and should
provide a pathway for wellness-oriented AI products to demonstrate through real-world data
that their use remains consistent with their intended wellness purpose.

Greater reliance on postmarket monitoring is appropriate when the device developer
demonstrates operational infrastructure for continuous monitoring, phased clinical oversight
with defined step-down criteria, rapid response capabilities including the ability to suspend or
roll back the affected clinical action or patient population without disrupting the rest of the
system, and longitudinal outcomes tracking that is proportionate to the risk of the device and
the context of use. Our experience operating phased monitoring programs confirms that this
infrastructure can detect and respond to problems faster than a static premarket evaluation.

When the device developer is not the party best positioned to perform a given postmarket
obligation (for example, where one entity develops a device that another entity operates and
deploys it in a care setting), FDA should permit the device developer to discharge those specific
obligations through an enforceable agreement that flows the relevant duty to the betterpositioned party. This should be conditioned on the device developer certifying that any
delegates will be capable of performing the function and retaining the operational ability to act
if the delegate does not. Ultimate accountability for the obligation should remain with the
device developer.

19. Please comment on the potential approaches to postmarket performance evaluation,
including periodic re-benchmarking, sample-based clinician review, and performance
degradation monitoring.

We support all three proposed approaches and recommend that CDRH’s framework retains
flexibility to accept other postmarket performance approaches. For example, a device developer
may wish to leverage continuous learning from clinician review as a postmarket performance
monitoring method. When a clinician reviews an AI-generated output and modifies it, that
modification itself may be a signal about system quality. Systematically capturing when
clinicians change, add, or reject outputs could provide a continuous, real-world measure of
device performance that complements structured benchmarking. Where the party best
positioned to capture these signals is the organization operating the system (device deployer)
rather than the device developer, the device developer should be able to flow the
corresponding data-collection and reporting duties to that party by agreement, while remaining
accountable for acting on what the monitoring reveals.

We also recommend that newly identified failures discovered through any monitoring channel
be permanently added to the system’s regression test suite and run on every subsequent
system change, creating a safety record that grows over time. Cadence should be continuous for
high-autonomy systems, with re-assessment triggered by system changes, foundation model
updates, or statistical detection of performance drift.

20. Please comment on whether the proposed approaches to postmarket monitoring can be
facilitated by machine-based supervisory agents. What considerations should CDRH take into
account for such an approach?

Machine-based supervisory agents can and should facilitate postmarket monitoring. They
enable review of every encounter rather than relying on sampling alone. CDRH should require
that supervisory agents be validated as detection instruments with measured sensitivity and
specificity against expert-labeled cases, not simply deployed and assumed to be reliable.

Machine-based monitoring should complement clinician review, not replace it. Over-sensitivity
in supervisory agents can itself become a failure mode by creating alert fatigue or slowing access
to care; monitoring precision and escalation yield alongside sensitivity is essential.

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?

Multiple stakeholders have meaningful roles. Clinicians contribute expert review and
adjudication. Healthcare institutions provide deployment context and outcomes data.
Professional societies develop clinical standards for performance measurement.
Standards-setting bodies establish technical and process standards for monitoring
methodology.

The critical design principle is that the device developer must retain clear, non-delegable
accountability for system safety and the authority to act quickly when safety signals emerge.
Shared responsibility works when stakeholders contribute data, expertise, and standards while
the device developer retains operational control, including the ability to constrain or suspend
the system without requiring consensus from other stakeholders. Our experience is that this
structure is achievable and effective.

Where a party other than the device developer is best positioned to perform a specific
postmarket function, for example, a healthcare organization that operates the system and
observes real-world outcomes directly, FDA should permit the device developer to discharge
that function through an enforceable agreement that flows the duty to that party. This allocates
the work to whoever can best detect and reduce harm without diffusing accountability. The
device developer should certify that any delegate will have the required capabilities to conduct
the postmarket function, and retains the operational ability to act if the delegate does not, and
remains FDA’s accountable point of contact.
22. How might the extent of re-benchmarking or other evidence be scaled to the nature and
expected impact of a given modification?

We recommend a tiered approach. Localized changes such as prompt updates or protocol
clarifications should pass the system’s full regression suite before reaching production; this gate
should be automated and apply to every change. Major changes such as a new foundation
model or architecture update should additionally require proportionate synthetic, adversarial,
and clinical evaluation. Expansions of clinical capability should carry the highest evidentiary bar.

For systems that improve iteratively, many refinements should be manageable within the device
developer’s quality management system (QMS), provided continuous monitoring confirms that
safety and effectiveness are maintained. Consistent with CDRH’s competency-based proposal,
CDRH should define clear categories of change appropriate for QMS management versus those
requiring FDA review, giving device developers predictability on which pathway applies.

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?

We strongly support CDRH’s acknowledgement that PCCPs need to evolve beyond their current
state, but we believe the PCCP is still a valuable mechanism for GenAI-enabled devices.
Requiring systems to be frozen at a point in time forfeits the potential for continuous
improvement and safe expanded functionality and may stifle innovation. For open-ended
systems where scope is defined by capability rather than enumerated tasks or conditions, the
PCCP should specify performance thresholds and monitoring requirements rather than
prespecifying the exact nature of future changes. The value of an adaptive system is that
improvements emerge from observed real-world performance. CDRH should permit PCCPs that
define the evidentiary standard a change must meet, while allowing the specific changes
themselves to be identified through operational experience.

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?

Foundation model changes should be governed through the same regulatory framework that
applies to changes in any other commercial off-the-shelf software used in a medical device. The
device developer, not the foundation model developer, bears responsibility for detecting,
evaluating, and responding to upstream changes. This is consistent with how FDA has treated
COTS (Commercial Off-The-Shelf) software in medical devices and preserves a clear
accountability structure.

Existing change-control mechanisms, including automated regression testing and tiered
evaluation for major changes, provide reasonable assurance that upstream modifications do not
compromise device safety. We appreciate FDA’s recognition that device developers may
incorporate third-party foundation models developed and maintained by external providers. In
developing its approach, FDA should avoid establishing expectations that would require
developers to monitor or manage aspects of third-party foundation models that are outside of
their visibility or control. Such requirements may be difficult or impossible to satisfy in practice
and could discourage developers from incorporating advanced third-party AI technologies into
their medical devices (or third parties from making their technologies available for healthcare
uses), potentially slowing innovation and patient access to beneficial products.
25. Would voluntary Foundation Model MAFs be practical for foundation model developers to
provide and to keep current, and what content might they include?

Voluntary MAFs could provide useful context for premarket review. Amazon has experience
with a similar concept through our AI Service Cards, which provide documentation on intended
use cases, limitations, responsible AI design choices, and deployment best practices. We support
a voluntary program focused on broad capability and known limitation disclosures that do not
include proprietary data, such as training data.

CDRH should recognize two limitations. First, disclosures about a foundation model’s general
capabilities may not predict the model’s behavior in specific clinical applications, because
performance depends on how the model is integrated, prompted, constrained, and monitored
within the device. Second, the device developer’s own testing and validation should remain the
primary evidence of safety and effectiveness regardless of MAF content, because the device
developer is best positioned to evaluate performance in the specific context of use.

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?

The relevant regulatory distinction for agentic devices should be the nature and immediacy of
real-world clinical actions and whether meaningful human review occurs before those actions
affect a patient. An agentic system that analyzes medical images and proposes a treatment plan
for clinician review presents a different risk profile than one that executes treatment without
human intervention, even though both are agentic. CDRH should evaluate agentic devices
through the same risk-based, competency-based framework described in this paper. CDRH
should also assess the risk of an agentic device across the complete episode of care rather than
at the moment of a single decision. A system that can detect non-resolution or deterioration,
follow up with the patient, adjust the plan, and involve a provider when needed can responsibly
support greater autonomy than one that issues a recommendation but cannot take
responsibility for what happens next.

Additional attention should be given to containment mechanisms: defined scope boundaries,
mandatory escalation criteria, the ability to withdraw autonomy rapidly, and monitoring of
whether the system operates within its authorized scope. Our experience operating agentic
clinical AI systems confirms that bounded autonomy with mandatory escalation and rapid
containment provides an effective safety architecture for this class of device.

Thank you again for the opportunity to provide feedback on this important issue and for the
administration’s thoughtful approach to advancing innovative health technologies. Please
continue to think of Amazon as a resource and partner in this and other ventures.