Microsoft Corporation

See attached file(s)

Microsoft Corporation
One Microsoft Way, Redmond, WA 98052

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

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

Dear Dr. Abramson and Dr. Tarver,
Microsoft appreciates the opportunity to comment on FDA's discussion paper. Consistent with
Executive Order 14434, "Inaugurating the Era of Super Intelligence," this response uses “Super
Intelligence” (SI) in place of “Artificial Intelligence” (AI) throughout, except where quoting or
referring to the title of FDA’s discussion paper, "Considerations for the Regulation of Generative
AI-Enabled Medical Devices." Microsoft agrees that generative super intelligence (GenSI)
enabled medical devices hold transformative promise for patient care and the broader health
ecosystem. This perspective is informed by Microsoft’s experience across clinical decision
support software, consumer health, foundation models, and the cloud platforms on which
healthcare solutions are built, recognizing that the applicable regulatory considerations depend
on a product’s intended use and whether it falls within FDA’s medical device authorities.

Microsoft also agrees with FDA that GenSI-enabled medical devices present unique regulatory
challenges that may not be addressed by the current medical device regulatory framework for
traditional software and SI-enabled medical devices. We share FDA's goal of a regulatory
framework that protects patients, supports responsible innovation, and remains proportionate
to risk. Our comments address the discussion questions in Sections IV through VI of the paper
and are guided by one principle: regulation would ideally attach to the device software function
as actually deployed, with the depth of evidence and oversight scaling to the consequence of an
output and the independence with which the function acts.

1. Risk assessment is best kept function-based, technology-neutral, and proportionate

FDA’s proposed framework, which considers both the nature of the device activity and the
potential consequences of relying on an incorrect output, is a sound starting point.
Directiveness and agency may be best considered separately because a system may strongly
recommend an action without taking it or autonomously perform a bounded task without
making a clinical recommendation. Deployment setting, clinical acuity, reversibility, time
pressure, and traceability could further inform risk. Human oversight is best credited as a risk
mitigation only where the workflow gives the reviewer adequate information, expertise, time,
and authority to identify and prevent a harmful action. For higher-consequence actions, FDA
may wish to consider whether review checkpoints are technically enforced and whether
escalation or handoff is completed, rather than merely initiated.

Risk assessment would ideally consider omitted, delayed, or incomplete outputs as well as
incorrect outputs. For conversational systems, assessment cases are most informative when
they reproduce the interaction conditions under which risks may emerge. Depending on the
system’s intended use, risk profile, and expected interaction patterns, this may include multiturn evaluation approaches, such as where safety-relevant behavior may develop over the
course of a conversation. Under-escalation and over-escalation are best measured separately
and weighted according to their clinical consequences.

Patient-facing status alone is not a sufficient basis to determine device classification.
Educational, comprehension, and navigation functions that remain outside diagnosis or
treatment could continue to receive proportionate treatment. At the same time, personalized
symptom interpretation, triage, treatment direction, or other directive functionality that
materially influences care may require a different regulatory pathway. FDA examples would
help distinguish safe escalation to professional care from diagnosis or treatment. Evaluation of
patient-facing functions would benefit from accounting for incomplete, ambiguous, or withheld
information and avoiding the assumption that a conversational interface can obtain every fact
necessary for a safe and clinically appropriate response.

2. Premarket evidence is most meaningful when it evaluates the final product while
permitting appropriate reuse of component evidence

Microsoft supports a competency-based approach that combines device benchmarking with
risk-appropriate clinical confirmation. The final configured product, including the model,
prompts, retrieval, safety controls, user experience, tools, and workflow, would appropriately
remain the unit of device evaluation. Evidence for stable and unchanged components may
nevertheless be reused where the sponsor demonstrates that the integration and deployment
remain within a validated performance envelope.

Evaluation is strongest when it combines methods suited to the claim and risk. These may
include (i) benchmarking against representative and diverse task and query datasets, which
combine clinically validated test cases, scoring rubrics, and appropriate held-out test sets, (ii)
human-factors evaluation, (iii) human red-teaming exercises, and (iv) prospective studies where
warranted. Automated scoring of configured product responses would ideally be demonstrably
reliable (i.e., robust to LLM scorer stochasticity) and calibrated against clinician judgment for
the construct being measured. Synthetic data may be useful in expanding the representation of
rare and safety-critical scenarios but is generally best used to supplement rather than replace
real-world evidence for higher-risk functions.
When evaluating product responses, acceptance criteria may appropriately consider clinical
substance; information grounding and uncertainty handling; safety behavior; directiveness and
appropriate deferrals to healthcare professionals; and usability. Comparators are most useful
when tailored to product intended use, clinically appropriate and pre-specified. Where AI
assists a clinician, human-AI team performance may be the most relevant measure.
Independent evaluation is most valuable for high-consequence claims and intended use
settings, sequestered benchmarks, and expert adjudication, rather than as a blanket
requirement for every iteration.
The same principles can apply across model architectures, with architecture-specific evidence.
Multimodal systems, for example, may require evaluation of cross-modal grounding, and
omitted findings.

3. Postmarket monitoring works best as a supplement to, not a replacement for, a riskappropriate premarket safety floor

GenSI devices require lifecycle assurance because models, prompts, retrieval, orchestration,
user behavior, and deployment environments may change. Postmarket plans are most effective
when risk-based and may combine periodic re-evaluation, drift detection (in both product and
user behavior), user and clinician reporting, representative sampling, and automated
monitoring of defined safety signals. A monitoring plan could usefully describe the proportion
and types of interactions it can observe, material gaps in coverage, and at least one method of
detecting degradation that does not depend solely on the device's own assessment of its
outputs.

Automated supervisory systems can help identify and prioritize potential issues at scale, but
they are not infallible; their necessity is best judged based on the device’s intended use and risk
category. Their sensitivity, specificity, reproducibility, subgroup performance, and limitations
would ideally be understood for their intended monitoring purpose and periodically re-assessed
to mitigate against drift in product and user behavior. Human review can be most efficiently
targeted to flagged risk cases.
Monitoring duties would appropriately reflect practical access and control. Responsibility for
safety may be distributed across the healthcare SI ecosystem, with device manufacturers,
clinicians, healthcare institutions, platforms, model providers, and standards organizations each
playing different roles and contributing different safety signals depending on the intended use
and deployment context. Their participation would not diffuse the manufacturer's
accountability for the marketed device function. At the same time, obligations assigned to
another participant are most workable when they reflect that participant's lawful access to
relevant information, technical control, and ability to intervene. An infrastructure or model
provider would not reasonably be presumed to have access to customer-controlled clinical
content or authority to modify a downstream product. FDA could encourage clear contractual
and technical mechanisms for exchanging relevant signals while preserving privacy, security,
and role-based accountability.

4. Change control works best when impact-based, bounded, and aligned to each party's
control
The extent of re-evaluation would ideally scale with the expected effect of a change on the
validated device function. Low-impact changes may be managed within the quality system;
sufficiently specified modifications may be addressed through a PCCP; and changes that
materially alter intended use, risk, or performance would warrant appropriate FDA review.
Change assessment would benefit from addressing clinically relevant changes in behavior,
including those caused by models, prompts, retrieval sources, safety policies, routing,
orchestration, or inference infrastructure, even where the downstream application code is
unchanged.
Competency baselines can provide useful acceptance criteria within a sufficiently described
modification envelope but would not substitute for identifying the types of planned
modifications and their validation methods. Not every change would automatically require the
same re-benchmarking; the scope of evaluation is best based on the reasonably expected effect
of the change on the validated clinical function. Sponsors could use documented impact
assessment to determine the appropriate evidence.
For devices using third-party models, reasonable controls may include version identification,
change notification, support and deprecation information, regression testing, and version
pinning where technically and operationally feasible. These mechanisms cannot eliminate every
upstream change or guarantee indefinite access to prior configurations. Responsibility is
therefore best allocated to the parties able to provide notice, evaluate downstream impact,
and alter the deployed function.

5. Foundation-model information can support review, while agentic functions require end-toend evaluation
A voluntary, confidential foundation-model information mechanism could support device
review if it is version-specific, sufficiently current, and clear about the uses for which the
information was generated. It may reduce duplication by making safety-relevant information
available to device sponsors and FDA. Useful content could include model identity and version,
intended technical characteristics, known limitations, relevant evaluation results, changemanagement practices, and information needed to assess benchmark contamination. Such
information would support, but not authorize, the downstream device or transfer the sponsor's
responsibility for the final product.
Agentic functions warrant additional scrutiny because orchestration, tool use, and multi-step
action can reduce opportunities for human review and create less reversible outcomes.
Evaluation would be most robust if it tested the complete configured system in a representative
environment, including context selection, routing, authorization, tool calls, retrieved
information, checkpoints, resulting system state, and recovery from failure. Acceptance criteria
may appropriately be more stringent where the system can write to records, place orders,
communicate clinical direction, or initiate care pathways.
For GenSI-enabled medical devices, FDA’s approach to auditability could focus on whether
device sponsors maintain reliable operational records sufficient to reconstruct relevant events.
Depending on the device’s intended use and risk, these records could include model and
configuration identifiers; relevant prompts or instructions; retrieval, guardrail, and
orchestration configurations; source information; tool calls; policy decisions; authorizations;
outputs; and resulting system-state changes. These records are meant to allow an event to be
reconstructed without presuming that hidden model reasoning is a faithful or necessary
regulatory artifact.

Conclusion
Microsoft supports a rigorous and adaptable framework for GenSI-enabled medical devices.
FDA can protect patients and support responsible innovation by regulating the deployed
medical function, scaling evidence and oversight to risk, enabling appropriate reuse of
component evidence, and assigning lifecycle responsibilities to the parties with the information
and control necessary to fulfill them.
Microsoft welcomes continued engagement with FDA as this framework develops.
Sincerely,
Microsoft Corporation