Google

See attached file(s)

October 19, 2026

To: U.S. Food and Drug Administration (FDA), Center for Devices and Radiological Health
(CDRH)

Re: Google Response to Docket No. FDA-2026-N-7874
“Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion
Paper and Request for Feedback”

Google appreciates the FDA’s proactive engagement through its discussion paper,
Considerations for the Regulation of Generative AI-Enabled Medical Devices. CDRH’s
exploration of novel evaluation paradigms is directionally accurate and a constructive starting
point.

We commend the Agency for engaging stakeholders early on these foundational questions
and applaud CDRH’s commitment to balancing a nimble, risk-proportionate framework
consistent with least-burdensome principles against the need to ensure timely access to safe,
effective, and innovative technologies.

We are particularly encouraged by CDRH’s recognition that traditional evaluation methods built
for bounded-input, deterministic software do not directly translate to Generative AI (GenAI), as
well as the Agency's openness to adapting Total Product Life Cycle (TPLC) oversight to match
the realities of modern AI development.

Clear, practical, and consistent regulatory expectations are essential to fostering responsible
healthcare innovation while safeguarding patient safety, and we welcome the opportunity to
collaborate with the Agency to help shape this framework.

We encourage the FDA to continue to look beyond legacy assumptions designed for
single-manufacturer, deterministic devices, and explore the following principles as the
foundation for a durable governance framework for GenAI in healthcare:

1.​ Regulating Clinical Intended Use: Focus oversight on clinical outputs at the
application layer—where a developer defines a medical intended use—rather than
general-purpose models.

2.​ Transitioning from Static Benchmarks to Dynamic Competency-Based Analysis:
Progress from static tests and premarket evaluation to a rhythmic review in tempo with
the rate at which the device may materially change.
 3.​ Building a Collaborative Postmarket Ecosystem: In addition to existing infrastructure,
FDA would be well advised to incorporate clinical outcomes into any postmarket
monitoring infrastructure in order to ensure approved devices do not stray outside of
intended use.

I. Introduction & TPLC Ecosystem
While CDRH considers a TPLC approach, GenAI’s TPLC differs fundamentally from “traditional”
device manufacturing. Legacy regulation assumes a linear supply chain where a single
manufacturer holds end-to-end control over a deterministic product. GenAI operates within a
"system of systems," where multiple actors contribute across the stack, control is distributed,
and the specific device manufacturer builds far less from scratch.

The International Medical Device Regulators Forum (IMDRF) guidelines on Software as a
Medical Device (SaMD) already recognize that software operates in complex, interconnected
environments. Consistent with IMDRF precedent, regulatory responsibility sits best with the
entity defining the clinical intended use (the downstream application developer), not the
upstream provider of, for example, raw compute or base model weights.

II. Definitions & Scope
Clarifying Definitions and Foundation Model Typologies
The discussion paper’s definitions of "Generative AI" and "Foundation Models" are overly broad
for effective regulatory implementation. CDRH would benefit from starting or aligning with
frameworks already crafted and used by established industry voices.

"Foundation models" are not a monolith; there are material architectural and deployment
differences that impede effective blanket regulatory feasibility. Consider the following
typologies:

●​ General-Purpose Models: Broadly pre-trained reasoning and linguistic engines that
exhibit emergent capabilities intended for general purposes. Consistent with the
Stanford Center for Research on Foundation Models (On the Opportunities and Risks of
Foundation Models, Bommasani et al., 2021), these models are horizontal infrastructure,
not task-specific devices.

●​ Domain-Adapted Solutions or Models: Base models further pre-trained or fine-tuned
on biomedical corpora (e.g., Med-PaLM). As shown in Large language models encode
clinical knowledge (Singhal et al., Nature, 2023), while these models encode clinical
knowledge, they lack a specific clinical "intended use" until constrained and embedded
in a user-facing application.
 ●​ Proprietary APIs vs. Open-Weight Models: Proprietary models are accessed via APIs,
where application developers rely on third parties for compute, baseline guardrails, and
version control. Conversely, open-weight models provide raw weights that developers
download, host, modify, and freeze in-house. The method by which developers access
and control these models influences the ways in which they change their devices over
time.

Focus on the Application Layer

As CDRH rightly notes, the FDA does not regulate software, hardware, or AI as such; rather, it
regulates products that meet the statutory definition of a medical device based on their
specific clinical intended use. In any digital health product, the vast majority of underlying
hardware and software serves as horizontal computing infrastructure. Just as the FDA does
not regulate a laptop or microprocessor simply because Software as a Medical Device (SaMD)
runs on it, upstream models lack a standalone medical intended use and therefore fall outside
the definition of a device.

A regulated medical device only emerges at the application layer: the downstream, user-facing
software environment where a developer integrates and constrains an underlying model, such
as through a combination of clinical system prompts, Retrieval-Augmented Generation (RAG)
grounded in specific medical sources, orchestration logic, safety guardrails, and a defined user
interface (UI), to perform a specific clinical function. Because it is exclusively at this application
layer that a developer defines the clinical intended use, bounds the system's inputs and
outputs, and directly influences patient risk, the application layer alone constitutes the "device
software function" subject to FDA oversight.

Protecting General Wellness Exclusions and Multi-Function Segmentation

We urge the FDA to confirm that the adoption of GenAI does not automatically elevate an
application's regulatory risk tier or invalidate existing regulatory carve-outs. The FDA’s
longstanding policies, including the General Wellness guidance, remain essential baselines for
safe and effective digital health innovation. Modern consumer devices and wearables
frequently combine general wellness coaching with distinct, cleared medical applications.
Using GenAI to summarize lifestyle metrics, support user engagement, or facilitate
administrative communication must not pull an otherwise exempt wellness function under FDA
oversight, nor should it subject low-risk functions to heightened premarket evidentiary
burdens. Oversight should continue to align with the specific clinical intended use of each
distinct function, thus ensuring that generative capabilities are evaluated by their real-world
risk rather than their technological novelty.

III. Jurisdictional Boundaries in Clinical Workflows
Statutory Boundaries Under the 21st Century Cures Act
In keeping with a clear and effective framework, we recommend the FDA also plainly state that
Section 3060 of the 21st Century Cures Act, which excludes Clinical Decision Support (CDS)
software from the "device" definition when it satisfies four criteria, may equally apply to CDS
tools that utilize GenAI. A GenAI tool may clearly be text- and record-based, not process raw
images or physiological signals, and present clinical options to practitioners (Criteria 1-3). Some
critics have pointed to Criterion 4, “Independent Review,” as justification to exclude all GenAI
tools from the CDS exclusion. However, Criterion 4 is satisfied if the CDS is intended to enable
the HCP to independently review the basis for recommendations without relying primarily on
them for individual patient decisions. A modern GenAI system may be capable of satisfying
Criterion 4 through current and future capabilities, such as RAG and direct source-linking to
primary medical literature and patient chart records, allowing clinicians to immediately verify
underlying evidence. It should not be subject to greater scrutiny purely because it uses GenAI.

IV. Risk Assessment Framework
●​ Redefining the X-Axis (Autonomy vs. Jurisdiction): CDRH’s proposed X-axis—scaling
from non-directive information to autonomous "action-taking"—risks conflating
autonomy with jurisdiction. Autonomy can include device-to-device automations, such
as an artificial pancreas, which is currently regulated by the FDA, but autonomous
functions can also reference actions like labs and prescription ordering. A robust and
sustainable FDA regulatory framework will need to recognize the nuance in these
“autonomous” actions, and have a clear endpoint if utilizing this “x-axis”.

●​ Alignment with CPOE/EHR and IVD Precedents: From a policy precedent
perspective, we note that treating "action-directing" or "action-taking" functions (e.g.,
order sets, prescriptions) as inherently higher risk would depart from established health
IT practice. Electronic Health Record (EHR) and Computerized Provider Order Entry
(CPOE) systems routinely facilitate one-click ordering and medication reconciliation
under Office of the National Coordinator for Health IT (ONC) certification criteria
without FDA device oversight, as real-world workflows include systemic clinical
mitigations—such as clinicians who authorize orders and pharmacists who
independently verify prescriptions. Similarly, even where regulated devices, signal
processing tools, and IVDs produce outputs where users cannot independently verify
raw calculations, they remain calibrated proportionately by indication and clinical
context rather than defaulting to a higher risk tier.

●​ Patient-Facing Tools: While exploring the risk of a patient-facing GenAI tool, we
strongly encourage the Agency to also consider and not discount the potential public
health benefits. As the OpenNotes movement proved, giving patients direct access to
clinical notes and analysis improves medication adherence, catches errors, and boosts
 health literacy—enabling patients to translate medical jargon, ask better questions, and
seek second opinions.

●​ Generalist vs. Specialist Risk Approach: We note that modulating a device’s risk
classification based on whether an HCP is a generalist or a specialist may create
unnecessary workflow friction, potentially judge medical training, and inadvertently
restrict specialty decision support in rural and underserved areas. In practice,
automatically shifting a function into a higher risk tier when a generalist accesses
specialist-level insights may not fully account for the real-world clinical baseline: we
observe that in resource-constrained settings, the alternative to AI decision support is
often unaided clinical judgment or prolonged delays in care rather than immediate
specialist consultation. Rather than differentiating risk by physician credentialing, we
suggest the Agency consider evaluating the combined performance of the human-AI
team relative to unaided care. Similarly, it may be more useful to address cross-domain
clinical risk through application-layer safeguards which may enable any licensed
clinician to independently review the underlying evidence and determine when specialty
referral is appropriate.

V. Premarket Evaluation & Competency-Based Approach (Addressing FDA Section V)
We support further exploring the competency-based approach described in the paper. We
caution against relying only on static premarket benchmarks, which incentivize overfitting to
the test and can saturate within 18 months or less. For premarket evaluation, the nature of the
technology is better investigated by using dynamic, independently maintained held-out
evaluation environments, such as by interactive synthetic patient actor personas.

Third-Party Based Governance & Public-Private Partnership (PPP) Model
We recognize that the operational and financial burden of maintaining dynamic benchmarks
would be significant for the FDA or any other single agency alone to bear. The FDA could look
to other industry-funded PPP or self-regulatory organizations under federal oversight for
potential governance structures, such as the Financial Industry Regulatory Authority (FINRA)
and FCC testing labs, bringing together technical experts, clinical leaders, and open-source
representatives to administer dynamic benchmarks. However, we caution that the FDA should
explicitly specify which benchmark rubrics it relies upon for authorization rather than implying
an all-or-nothing battery, as elements like pre-visit information gathering fall outside FDA
jurisdiction. We ask that the FDA also take lessons learned from previous attempts, particularly
regarding measure proliferation, cost effectiveness, and overall regulatory burden, into
consideration.

The Clinical Residency Model
We also support further exploring whether premarket evaluation could mirror the residency
model, where Premarket Authorization equals the GenAI model equivalent of demonstrated
Clinical Competency (Clinical Knowledge + Supervised Assessment). HHS and the FDA should
begin investigating the feasibility of adapting such a structure by partnering with medical
colleges and specialty societies as third-party adjudicators to map AI “residency” guidelines
utilizing existing, analogous standards.

The FDA's remit is, in part, to ensure that devices are safe and effective. Like existing software,
user behavior with real, deployed GenAI systems (particularly in complex healthcare delivery
settings) can be different than what developers predict, and users may change behavior as
they learn and interact with the capabilities of these GenAI systems.

Therefore, the strength of inference about safety and efficacy from an isolated randomized
controlled trial may significantly diverge from real-world use, and may do so to a greater
degree than in biological studies of drugs. An approach that may give regulators better
confidence about safety and efficacy is a residency- based model that resolves comparator
questions by evaluating operational competency in practice rather than static recall.

VI. Postmarket Monitoring
●​ A Non-Punitive, Shared Ecosystem: We applaud FDA’s recent efforts to roll out the
modern AEMS system. HHS and the FDA could benefit from transitioning from strictly
mandatory manufacturer reporting to a shared, non-punitive ecosystem engaging
providers, institutions, patients, researchers, and developers. FDA could look to
innovations attempted across the federal regulatory ecosystem (such as the FAA’s
Aviation Safety Reporting System (ASRS) (encouraging proactive reporting of
near-misses and workflow hazards) and the Health Information Sharing and Analysis
Center (Health-ISAC)), establishing a "Clinical AI Safety & Assurance Exchange" to
rapidly share anomalies, prompt-edge cases, and systemic errors while preserving
manufacturer accountability.

●​ Incentivizing Positive Signals: Monitoring currently over-indexes on negative signals
like model drift. The FDA should incentivize public reporting of positive postmarket
signals—such as clinical successes and improved outcomes—to build clinical trust and
reflect true real-world benefit-risk.

●​ The Limits of PCCPs for GenAI: Predetermined Change Control Plans (PCCPs) were
designed for deterministic software and task-specific AI/ML models undergoing
discrete, pre-specified updates. In contrast, we suggest the Agency consider
continuous dynamic benchmarking, which is well suited for the continuous,
non-deterministic nature of GenAI.

VII. Master Files
While Google strongly supports frontier model transparency via model cards, system cards,
and our Frontier Safety Framework, voluntary Foundation Model Device Master Files (MAFs) are
difficult to implement for clinical regulation:

●​ Upstream Model Safety Does Not Guarantee Downstream Clinical Safety:
Upstream transparency artifacts do not necessarily proxy for clinical safety, which
depends on downstream application-layer engineering (RAG, system prompts,
guardrails, and UI). Adapting component MAFs to base models risks a false sense of
assurance; instead, it may be useful for application developers to validate their specific
integrated intended use.

●​ Instant Staleness and Burden: Base models update frequently, API endpoints have
frequent versioning and can deprecate, and cloud infrastructure continuously updates,
meaning MAFs would become instantly stale and create an overwhelming maintenance
burden for developers and FDA reviewers.

●​ Reaffirming the General Purpose Paradigm: Base models are like general purpose
platforms. Medical applications need to be architected and validated at the application
layer to operate safely independent of upstream model changes.

VIII. Considerations for Agentic AI Systems

Current evaluation rubrics assume monolithic base models, failing to capture agentic GenAI
systems capable of multi-step reasoning, planning, and external tool use. HHS and the FDA
would benefit from evaluating agentic architectures in concert with established design
patterns—including Tool Use, Reflection, Planning, and Multi-Agent Orchestration.

Conclusion

Generative AI offers an unprecedented opportunity to expand patient access and elevate
clinical quality. Unlocking these benefits requires a predictable, risk-proportionate regulatory
framework anchored in clinical intended use at the application layer, dynamic
competency-based evaluation, and a collaborative approach to postmarket performance
monitoring.

Google commends the FDA for proactively engaging stakeholders to help shape this
framework early in its development. As the discussion paper rightly observes, the unique,
iterative nature of generative technologies calls for a thoughtful evolution of traditional
oversight models. Establishing a scalable, non-punitive ecosystem for continuous postmarket
evaluation stands out as one of the most impactful near-term priorities.
We encourage the Agency to continue partnering closely with patients, healthcare providers,
developers, medical specialty societies, standards bodies, interagency counterparts across
HHS, and other stakeholders. A coordinated, multi-stakeholder approach reinforces clinical
trust and patient safety while preserving the flexibility needed to mitigate emerging risks and
deliver transformative health technologies in a timely manner.