Anthropic PBC

Please see the attached comment letter of Anthropic PBC in response to Docket No. FDA-2026-N-7874, Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback

​ 548 Market St., PMB 90375
​ San Francisco, CA 94104-5401

​ 412-837-9797
​ anthropic.com

October 19, 2026

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

Submitted electronically via regulations.gov

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

Anthropic appreciates the opportunity to comment on the discussion paper on generative
AI-enabled (GenAI-enabled) medical devices that the Food and Drug Administration (FDA)
issued through its Center for Devices and Radiological Health (CDRH).1 Anthropic is an artificial
intelligence (AI) safety and research company. We develop Claude, a family of general-purpose
AI models, build products on those models, and publish safety and capability evaluations for
each model release.
Broadly speaking, Anthropic supports the approach that CDRH is considering, with a two-axis
view of risk, a competency-based evaluation before authorization, and postmarket monitoring. In
our responses, we place patient safety as a core principle and theme. A GenAI-enabled device
should reach patients on evidence measured with the people who will use it, and it should stay
in use as long as monitoring shows that it continues to perform. Downstream safeguards,
whether human or software based, should count toward a lower level of risk when their effects
are measured.
Manufacturers build devices on general-purpose models, and Anthropic writes largely from the
perspective of an AI model developer. We describe first-hand how these models behave, how
they are evaluated, and how they change. Where FDA's paper leaves a gap, we point to tools
FDA already uses.
Our responses follow Sections IV to VII of FDA's paper and keep its question numbers. We do
not answer Questions 6, 15, and 17. We answer Question 4 with Question 14, Question 13 with
Question 12, Question 16 with Question 10, Question 24 with Question 23, and Question 26
with Question 5.
FDA, Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request
for Feedback (August 2026, posted August 18, 2026), www.fda.gov/media/194242/download.
Summary of recommendations
We recommend that FDA:
-​ Competency (Questions 7 and 8): Clarify what a competency is. The definition we offer
is one device function, stated as a bounded clinical task, and assigned one activity level
and one consequence level on FDA's two axes of risk.
-​ Human or software review of device outputs (Questions 1, 3, 4, 14): Count review of
a device's outputs by a human or by separate software toward a lower level of risk only
where the manufacturer has measured how often that review catches the device's
errors. Do not rank a device as riskier simply because a patient uses it, or as safer
simply because a clinician does.
-​ Conversations and AI agents (Questions 5, 9, 12, 26): Ask manufacturers of
conversational and agentic devices for benchmarking results on whole conversations
and whole tasks. Each test case would be run several times, because outputs vary
between runs. Add four behaviors to FDA's benchmarking elements: recognizing a test,
staying faithful to the information supplied, keeping a correct answer under pressure
from the user, and reporting completion accurately.
-​ Independent benchmarks (Questions 10, 16, 22, 24): Keep the benchmarks pivotal to
an authorization, or a manufacturer's move to a new model version, independent of the
manufacturer and of the model developer. Keep the test cases for those benchmarks
apart from the regression set that the manufacturer re-runs after each change. Set a
common standard for how a benchmark is built, and review a manufacturer's own
benchmark against that standard.
-​ Evidence from intended users (Questions 3, 8, 11, 18): Favor study of the device with
its intended users, under conditions close to real use, during development and before
authorization, especially when risk warrants it. Apply the principles and factors in FDA's
existing guidance to the choice of study, in place of a fixed rule for a type of device, such
as a rule that every autonomous or patient-facing device needs a prospective clinical
study.
-​ Postmarket monitoring (Question 18): Treat monitoring of a device in use as a
supplement to the evidence gathered before authorization, and not as a substitute for
that evidence. Where FDA does accept more uncertainty before authorization because
monitoring will follow, write the terms into the authorization, including the measures, the
thresholds, and the action taken if a threshold is crossed.
-​ Model changes and roles (Questions 21 to 24): Treat a change to a hosted model as
one of three events, and expect the manufacturer to manage each event separately. The
first event is a new model version. A device's move to a new version is the
manufacturer's own change, which a predetermined change control plan could cover.
The second event is the retirement of a version, which sets the last date for the
manufacturer's move. The third event is a change to the serving systems, meaning the
systems around a model version that handle each request. The manufacturer looks for
the third event by re-running its regression set through its device. Keep the manufacturer
accountable for the device, as FDA's paper does in Question 21.
 -​ Information about the underlying model (Question 25): Treat a voluntary master file
for foundation models as a supplement to what the model developer publishes. Publish,
without a new requirement, the questions about underlying models that FDA staff most
often cannot get answered.

Premises and terms
Under the approach that CDRH is considering, "the final user-facing device, as configured and
intended to be deployed for real-world use," would be evaluated. We agree, and we take the
device as configured to mean the model together with the following — whether the manufacturer
or the model developer supplies each: the standing instructions that accompany every request;
reference material; connections to records and tools; model safeguards, defined below; limits on
outputs; and the interface. The model alone is too narrow a unit of evaluation. Whoever
assembles and offers that device is the device's manufacturer, and a model developer that does
so is a manufacturer too.2 The same is true of Anthropic as of any other model developer. FDA's
paper says that FDA "does not regulate GenAI as such; it regulates medical devices, including
GenAI-enabled devices." FDA's paper sets aside the question of whether the approaches it
discusses fall within FDA's existing legal authorities, and this letter sets that question aside too.
We use FDA's terms and add several. FDA's paper says both sponsor and manufacturer, and
we say manufacturer. A general-purpose model is what FDA's paper calls a foundation model,
and a model developer is the company that trains a general-purpose model and makes the
model available to others. A model version is one release of a model, with its own identifier. A
hosted model runs on servers operated by the model developer or by a cloud platform, and the
manufacturer reaches the hosted model over a network. A model safeguard is software, such as
a classifier, placed around a model to screen requests and outputs.
In this letter, a reviewer is a human or separate software that checks an output before the output
takes effect, meaning before a person acts on the output or the device completes an action. The
user of the device can be the reviewer. To catch an error means to detect the error and to stop
the error from taking effect. Question 1 of FDA's paper speaks of downstream safeguards and
does not define the term. We take a reviewer to be a downstream safeguard. A test case is one
input, conversation, or task with its reference answer, and a benchmark is a set of test cases
with a method for scoring a device's outputs. An independent evaluator is a body, outside both
the manufacturer and the model developer, that writes a benchmark, keeps the test cases, and
scores the results. Sequestered test cases are test cases that an independent evaluator keeps,
for benchmarks pivotal to an authorization or a manufacturer's move to a new model version. A
regression set is the standing set of test cases that a manufacturer keeps and re-runs after each
change to its device.
FDA's paper says the examples in its Section IV "are illustrative only" and "are not intended to
mean that the software discussed is necessarily a device or is a software function that is the
focus of FDA's regulatory oversight" (page 6, footnote 12). We use FDA's examples on the
same terms.
See Anthropic's comment of June 29, 2026, page 3, regulations.gov/comment/FDA-2026-N-4390-0223.
FDA's Section IV. Considerations for the Assessment of Risk for
GenAI-Enabled Devices (Questions 1 to 6)
In Section IV, FDA's paper offers two axes as a possible way of thinking about the risk of a
GenAI-enabled function. The activity axis describes how independently the function acts, in four
levels: providing non-directive information, providing information that directs an action, taking an
action under a clinician's supervision, and taking an action autonomously. The consequences
axis describes the severity of harm that could result from relying on an incorrect output.

Question 1. Keep the two axes, and let only measured safeguards lower risk
Question 1 asks whether the two axes capture the dimensions most relevant to risk, or whether
other dimensions should be added.
Recommendation. The two axes are sufficient, and we recommend that FDA define both axes
so that the definitions also apply when no clinician reviews a function's output. The four
additional dimensions in Question 1 fit within the axes, with reversibility and time pressure on
the consequences axis and downstream safeguards and traceability on the activity axis.
FDA could base a function's consequence level on the most serious harm that an incorrect
output could credibly cause if the output took effect without review. Four factors would determine
the consequence level: severity, reversibility, time to harm (which reflects time pressure), and
time to discovery, meaning how soon the patient's course or routine follow-up would reveal the
error. We add time to discovery because a systematic error in a model version can recur
wherever that version is in use, until the error is found. A risk score for a future cardiovascular
event is one of FDA's examples, and an understated score might go unnoticed for years.
We suggest that the activity level reflect what the function may do without review, and what
review takes place before the function's output takes effect. Review lowers the likelihood that an
incorrect output takes effect. We recommend that a downstream safeguard count toward a
lower activity level only when the manufacturer has measured how often the downstream
safeguard catches errors (Question 14). FDA's paper considers moving a function higher on the
consequences axis when the user cannot independently evaluate the output, and that
placement can work too, provided FDA counts the user's ability only as far as the manufacturer
has measured that ability, and on only one axis.
Traceability lets a reviewer check an output against the sources of that output and, for an AI
agent, which performs multi-step tasks, against the log of the sources the AI agent read and the
tools the AI agent used. A model's own account of its reasoning is not a reliable record of what
produced the output, and interpretability — the study of a model's internal workings — cannot
yet reliably explain an individual output. We recommend that device oversight not depend on
either kind of explanation.3
Anthropic, "Reasoning models don't always say what they think" (April 3, 2025),
anthropic.com/research/reasoning-models-dont-say-think; Anthropic, "Tracing the thoughts of a large language
model" (March 27, 2025), anthropic.com/research/tracing-thoughts-language-model; Claude Opus 5.5 system card
(September 22, 2026), section 6.1.1, page 93, anthropic.com/claude-opus-5-5-system-card.
Question 2. Assess directiveness by its effect on users, across many outputs
FDA's paper describes a continuum of directiveness for functions that provide information, from
general information, to information tied to the user's circumstances, to an endorsed action, to a
specific instruction. CDRH is considering treating more directive functions as higher risk.
Question 2 asks which characteristics of an output could modify that risk, and what would give
manufacturers clarity and predictability.
Recommendation. FDA could assess directiveness by a function's effect on users, across
many outputs from the same device. Wording, specificity, and personalization could each modify
risk, because each characteristic changes how likely a patient or clinician is to act on the output.
A manufacturer could therefore measure how often intended users act on an incorrect output
(Question 14).
We suggest one consideration that Question 2 does not raise, although FDA's paper raises that
consideration under benchmarking (Section V and Appendix A, element R.1). A GenAI-enabled
device can phrase its output differently each time the device receives the same request, so one
output does not show how directive the device is.
For clarity and predictability, we suggest that the manufacturer's statement of intended use
name the most directive level on FDA's continuum that the device may reach in any turn of a
conversation, and that FDA assess the function at that level (Question 5). Benchmarking,
whether by the manufacturer or by an independent evaluator (Question 10), would try to elicit
outputs beyond that level.

Question 3. Keep risk agnostic to the type of user
Question 3 asks, in part, whether and when functions that deliver clinical information to patients
could present different or higher risks than functions for clinicians.
Recommendation. FDA should not consider a GenAI-enabled device as riskier simply because
a patient uses it, or as safer simply because a clinician does. Risk should be determined by the
context of use.
FDA should ask the same questions about devices for patients and devices for clinicians: how
severe a harm an incorrect output would cause, how soon that harm would occur and be visible,
whether a reviewer checks the output before the output takes effect, and whether that reviewer
can catch an error and intervene before the error causes harm. A patient using a device at
home, with no clinician present, often cannot catch an error in the output. As such, it is likely
that most devices for patients will need more evidence, and that evidence should come from
patients.
A physician who signs a batch of orders may also fail to catch an error (Question 14). FDA
should ask the manufacturer to measure how often each reviewer, human or software, catches
an error.

Questions 5 and 26. Evaluate whole conversations and whole tasks several times
Question 5 asks how to assess risk and describe intended use when a conversational device
drifts from providing information toward directing an action. Question 26 asks, in part, what
additional considerations apply to agentic GenAI-enabled devices, which perform multi-step
tasks.
Recommendation. FDA could assess conversational trajectories, as CDRH is considering, and
still apply its risk-based approach function by function (Question 7). A conversation or a
sequence of actions would be a condition under which patients and clinicians use the function.
The manufacturer or an independent evaluator would evaluate the function on whole
conversations and whole tasks, each run several times.
A conversational device's intended use could state the highest of FDA's four activity levels that
the device may reach in any turn and, for a device that only provides information, the most
directive level on FDA's continuum (Question 2). Benchmarking (Section V) would include
conversations built to elicit outputs beyond that level, as FDA's element S.2 anticipates.
For the same clinical task, more unreviewed steps raise the likelihood that an error takes effect.
On the activity axis, we suggest that FDA place an agentic GenAI-enabled device according to
the most consequential action that the device can complete without review. A device whose
every consequential action waits for review would not be placed higher for being agentic.
Benchmarking would include tasks built to draw the device into using a tool beyond the scope
that its competency statement gives (Question 7).
Anthropic publishes results of multi-turn and multi-step evaluations of its own models, and we
offer four reporting practices that FDA could ask of a manufacturer.4
First, because errors compound across steps, the manufacturer could report the share of whole
conversations or whole tasks that the device handled acceptably.
Second, because outputs vary between runs, the manufacturer could run each test case several
times and report the share of test cases on which the device succeeds in every run.
Third, where a device takes actions, the manufacturer could report two results separately. One
result is the end state of the task, meaning what the electronic health record or other system of
record shows, rather than what the device reports. The other result is whether the device
completed the few steps that the intended use requires, such as a human's approval before an
order is placed, which FDA's element A.1 calls a human-oversight checkpoint. A correct end
state can conceal a skipped step. The manufacturer could set the number of runs and the
acceptance criteria in advance for the end state, for each required step, and for the share of
tasks completed in every run.
Fourth, where a model simulated the patient or the clinician, the manufacturer could report how
the simulator's behavior compares with real users' behavior.
Anthropic publishes system cards that report evaluation results and known limitations (anthropic.com/system-cards).
For example, Claude Opus 5.5 system card, sections 4.1.3 and 8.14.5. See also Anthropic, "Demystifying evals for AI
agents" (January 9, 2026), anthropic.com/engineering/demystifying-evals-for-ai-agents.
FDA's Section V. A Competency-Based Approach for Premarket
Evaluation of GenAI-Enabled Devices (Questions 7 to 17)
In Section V, FDA's paper says that CDRH is considering a two-stage, competency-based
approach to premarket evaluation. In device benchmarking, the device as configured is
evaluated outside clinical care on elements grouped under safety (elements S.1 to S.3), clinical
proficiency (E.1 to E.4), generalizability (R.1 and R.2), and agentic AI capabilities (A.1). In
clinical confirmation, the manufacturer shows how the device performs in real or clinically
representative use, by methods ranging from retrospective evaluation to a prospective clinical
study.

Question 7. Define a competency, and note where a model differs from a physician
Question 7 asks whether the competency-based approach, inspired by how clinicians are
evaluated and credentialed, is useful and appropriate.
Recommendation. We ask FDA to define a competency. The approach is sensible, because a
GenAI-enabled device's tasks can be functionally analogous to a clinician's tasks. We add two
points that Question 7 does not raise.
First, FDA's paper does not define a competency. We ask FDA to say whether a competency is
what a device is authorized to do or an ability that is evaluated. We offer a candidate definition:
a competency is one device function, stated as a bounded clinical task. The statement gives
nine items: the task, the patients, the setting, the inputs, the form of the output, the intended
user or receiving system, the check required before the output takes effect, the requests the
device declines, and the tools the function may use, with what each tool can reach and do.
Under this candidate definition, a device's intended use would be stated as the set of
competencies that the manufacturer claims for the device.
Second, a model differs from a physician in five ways that impact adapting this approach.
Acquiring knowledge. A physician acquires knowledge in medical school and residency, usually
seven years or more. A model acquires knowledge when its developer trains the model on text
and then does further post-training work on the model.
Evaluation and supervision. Independent examiners evaluate a physician before practice, and
attending physicians supervise the first years. A model is evaluated before release mostly by its
own developer, which is one reason the evidence for a device has to come from evaluations of
the device as configured, run by the manufacturer or an independent evaluator (Question 10).
Learning from patients. A physician learns from yesterday's patients across a career. A released
model version does not, because its weights (or parameters) are fixed. When a device saves
notes from earlier visits and returns the notes to the model, the device does the recall.
Gaining experience. A physician gains experience year by year and remains the same person.
A model improves only when its developer trains and releases a new version, which can be
better at some tasks and worse at others, so the manufacturer would re-evaluate the device
when moving to that version (Question 24).
Number of patients. A physician sees about 20 patients a day,5 so a physician's systematic error
reaches that physician's patients, while a systematic error in a model version can recur
wherever that version is in use, which could be significantly more patients (Question 14).

Question 8. The axes show the kind of study and how much evidence is premarket
Question 8 asks how Section IV's two axes could help determine the evidence that a premarket
submission needs.
Recommendation. We suggest that each competency have one activity level and one
consequence level. The activity level indicates the kind of study (Question 11). The
consequence level impacts how much of the evidence has to come before authorization. FDA's
2019 guidance on uncertainty lists the factors for that judgment. The guidance does not address
510(k) clearance, and FDA could say whether the same factors apply there.6

Question 9. Add four behaviors to FDA's benchmarking elements
Question 9 asks, in part, whether benchmarking gives adequate evidence and whether any
benchmarking element is missing.
Recommendation. FDA could add four behaviors to its benchmarking elements (FDA's Figure
2). When the test cases are fixed in advance and kept from the people who build the device,
benchmarking can do two jobs: screen a device for poor performance, and show whether a new
version of the device performs worse than the version before. Benchmarking does not show that
patients' outcomes have improved. FDA's elements omit or only partly name the four behaviors
below.
Recognizing a test. A model can recognize a test as a test, and a model that does so can
behave differently (Question 18). The manufacturer or an independent evaluator could therefore
write realistic test cases and count the transcripts in which the model says that it suspects a
test, which gives a lower bound on recognition.
Staying faithful to the information supplied. Benchmarking could score two errors separately
from clinical correctness: an omission of something material, and a statement that the supplied
information does not support.
Keeping a correct answer under pressure from the user. Element S.1 covers users who resist
care escalation, meaning advice to seek care. A user can also insist on an incorrect diagnosis,
and paired test cases with and without that insistence could show whether the device obliges.
Reporting completion accurately. An AI agent can falsely report a task as complete or verified,
so the manufacturer or an independent evaluator could check the AI agent's report against the
system of record (Question 5).
The Physicians Foundation, 2018 Survey of America's Physicians: Practice Patterns and Perspectives (September
2018), pages 15 and 41, physiciansfoundation.org/wp-content/uploads/physicians-survey-results-final-2018.pdf. The
figure is a self-reported average of 20.2, from 8,774 responses to a survey emailed to more than 700,000 physicians.
FDA, Consideration of Uncertainty in Making Benefit-Risk Determinations in Medical Device Premarket Approvals,
De Novo Classifications, and Humanitarian Device Exemptions (August 2019), page 4, note 1, and section IV,
www.fda.gov/media/115672/download.
Anthropic's system cards, the documents that Anthropic publishes with model releases, report
on each of the four behaviors in Anthropic's models.7 The system cards make no claim about
any device.

Questions 10 and 16. Keep benchmarks independent of manufacturer and model
developer
Question 10 asks, in part, what role a manufacturer's own benchmark should play. Question 16
asks, in part, what role independent third parties should play.
Recommendation. FDA could keep the benchmarks pivotal to an authorization, or a move to a
new model version, independent of the manufacturer and of the model developer, either through
protections on a manufacturer's own benchmark or through an independent evaluator's
benchmark. Under one principle that CDRH is considering, expert adjudication, where
warranted, would include adjudicators who are "structurally independent from the device
sponsor and, where the device incorporates a third-party model, from the developer of that
model." We agree with that principle.
Independence matters for two reasons. First, the same test cases would be used many times,
and a manufacturer that sees benchmark results can adjust the device until the score rises.
Second, test cases that were ever public may be in the model's training data, so the model may
have memorized the answers (contamination).
A manufacturer can check for memorization without seeing the training data. The manufacturer
could write test cases after the model's published training data cutoff, compare scores on
original and rewritten test cases, and score the benchmark again after removing the test cases
that the model may have memorized. Anthropic reported all three checks on one of its models in
an April 2026 system card and called detecting memorization after the fact "inherently
approximate."8
A manufacturer's own benchmark could borrow protections used in clinical trials and in FDA's
2022 guidance below, such as a plan fixed and sent to FDA before the benchmark is first
scored, a report of every time the benchmark is scored, and a firewall between the people who
build the device and the test cases. An independent evaluator can do three tasks that a
manufacturer cannot: prove to others that the test cases were sequestered from the people who
build the device, keep a record that others trust of how many times the benchmark has been
used, and produce a result that is comparable with another manufacturer's result. An
independent evaluator would add the most where a claim depends mainly on benchmarking,
where one benchmark will decide repeated moves to new model versions, where devices that
claim the same competency need to be compared, and where the manufacturer also develops
the model.
A device built on a hosted model is usually evaluated where the model runs. Each test case
goes to the servers of the model developer or the cloud platform when the benchmark is run. A
For example, Claude Opus 5.5 system card, sections 6.4.3, 6.4.6, and 6.5.4.2. Three of the four are measures in
Anthropic's automated behavioral audit, which the cards define. The measure for keeping a correct answer under
pressure is a public benchmark of whether a model contradicts its own stated belief when pushed.
Claude Mythos Preview system card (April 7, 2026), sections 6.2.1, 6.2.2, and 6.8,
anthropic.com/claude-mythos-preview-system-card.
test case that has been sent has left the independent evaluator's keeping, so the independent
evaluator could record that test case as used. The independent evaluator could also follow three
practices that FDA's 2022 guidance on radiology detection software recommends: draw test
cases from a bank that keeps growing, limit the number of assessments in which each test case
is used, and report results separately for test cases used before and test cases never used.9
FDA could set a common standard, in guidance or by recognizing a consensus standard, for
how test cases are written, how reference answers are set, and how outputs are scored. FDA
staff could review a manufacturer's own benchmark against that standard, and accredited
independent evaluators could apply the same standard, as under the Accreditation Scheme for
Conformity Assessment that FDA's paper names.

Question 11. Match the study to the claim and to who acts on the device's output
Question 11 asks, in part, how a manufacturer might select and justify a method of clinical
confirmation, and when a method would be insufficient.
Recommendation. CDRH is considering that clinical confirmation "might not require a
prospective clinical study in every case," and we agree. FDA could apply the principles and
factors in its existing guidance (Question 8) in place of a fixed rule for a type of device, such as
a rule for every autonomous or patient-facing device. Where a clinician or patient has to read
the output and act on it, the benefit depends on what that clinician or patient does, and the
evidence should include that clinician or patient using the device. A method that leaves out the
clinician or patient would be insufficient in that case.
FDA's 2013 guidance on pivotal clinical investigations distinguishes two kinds of study.10 A
diagnostic clinical performance study measures accuracy against a clinical reference standard,
and a clinical outcome study follows patients' outcomes. A manufacturer of a GenAI-enabled
device could choose between the two kinds of study according to what the manufacturer claims
for the device and who acts on the output.
Where the study follows authorization, the manufacturer could build a randomized comparison
into deployment. The 2013 guidance describes cluster randomization, in which clinical sites are
randomized, and encourages sponsors to consult FDA first. One form, which the guidance does
not name, is the stepped-wedge cluster randomized trial, in which sites begin live use one after
another, in random order. A stepped-wedge trial suits a device that every site will receive, and is
at greater risk of bias from secular trends than a parallel cluster randomized trial, so the
manufacturer would justify the choice. FDA could name cluster randomization among its
methods of clinical confirmation, which now include a randomized controlled trial.

Questions 12 and 13. Report uncertainty, and keep each kind of evidence separate
Question 12 asks, in part, how to make performance measurement statistically meaningful and
when evidence from benchmarking and evidence from clinical confirmation might be combined.
FDA, Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data: Premarket
Notification [510(k)] Submissions (September 2022), section V.B, www.fda.gov/media/77635/download.
FDA, Design Considerations for Pivotal Clinical Investigations for Medical Devices (November 2013), sections 6.1,
7.2, and 7.7, www.fda.gov/media/87363/download.
Question 13 asks where synthetic data is well suited or inadequate, and how to mitigate the risk
when the data comes from "models of the same class as the device under evaluation."
Recommendation. We suggest that FDA consider five statistical recommendations, published
by Anthropic in 2024 for evaluations of AI models, that a manufacturer or an independent
evaluator could apply to a device.11
First, report with every score a standard error or a confidence interval. Second, where several
test cases are related, for example because they share one patient, cluster the standard errors
by patient. Anthropic's summary of the recommendations reports that "clustered standard errors
on popular evals can be over three times as large as naive standard errors." Third, run each test
case several times and analyze the average score for each test case. Fourth, compare two
versions test case by test case, a method called paired differences. Fifth, use a power analysis
to calculate the number of test cases needed for a stated aim.
A manufacturer would not combine benchmarking results and clinical confirmation results into
one estimate. The manufacturer would report the two estimates separately, with the gap
between them. A small gap is the evidence for relying on benchmarking after a later change
(Question 22).
The 2024 recommendations do not cover rare serious errors, which need a separate
calculation. For example, a device that makes no serious error in 300 independent test cases
could still have a true rate of up to about 1 percent (one-sided 95 percent confidence bound).
The average over runs estimates performance, and success in every run (Question 5) shows
reliability. The manufacturer would report both.
On Question 13, synthetic test cases suit benchmarking in which the designer of each test case
fixes the correct output in advance, such as an emergency that cannot be staged, an
out-of-scope request, or a calculation with a known answer. Synthetic test cases do not show
how a device performs with real users.
For a small subgroup, synthetic test cases can show whether a device handles a value that the
designer sets, such as renal function. Synthetic test cases are weaker where the subgroup
differs in how patients speak or present, because the generating model has to imitate those
patients, and is likely to do so less well where its own training data is thin.12 The manufacturer
could name the model that generated the test cases, say how that model is related to the
device's model, and report synthetic and real results separately. Clinicians could write or review
each synthetic test case that supports a claim. Their review can catch a test case whose clinical
content is wrong, but it cannot necessarily demonstrate external validity in representative
patients.
Anthropic, "A statistical approach to model evaluations" (November 19, 2024),
anthropic.com/research/statistical-approach-to-model-evals, which has the quotation; E. Miller, Adding Error Bars to
Evals: A Statistical Approach to Language Model Evaluations (November 2024), arxiv.org/abs/2411.00640.
E. Perez et al., Discovering Language Model Behaviors with Model-Written Evaluations (December 2022), section
8, arxiv.org/abs/2212.09251. The authors, most of them at Anthropic, caution that model-written evaluations may "be
lower quality for languages under-represented in the LM training data." They did not test the point. The step from
languages to patient groups is Anthropic's own inference.
Questions 14 and 4. Weigh the patients reached, and measure what reviewers catch
Question 14 asks, in part, what to compare a device's performance against, such as a median
clinician, and when to evaluate the human and the device together. Question 4 asks, in part,
whether risk differs between generalist and specialist clinicians.
Recommendation. A reference standard fixes the right answer for a case, and a comparator
shows how clinicians do on the same cases. A panel's agreed judgment could serve as the
reference standard, and a sample of the intended users as the comparator. FDA could also take
the number of patients a device reaches into account when acceptance criteria are set, a
consideration that Question 14 does not raise. Serious errors would have a separate
acceptance criterion. A clinician who performs at the median treats only that clinician's own
patients. A device that performs at the median delivers that performance to every patient the
device reaches, and the number of patients can be orders of magnitude larger. This is germane
for two reasons. First, a systematic error can reach more patients (Question 1). Second, where
acceptance criteria call for performance above the median clinician, a device could raise
performance across the whole distribution, which would move the median itself.
On evaluating the human and the device together, we recommend that a reviewer — human or
separate software — count toward a lower activity level only where the manufacturer has
measured how often the reviewer catches errors in simulated or real use. The manufacturer
would report the reviewer's sensitivity and specificity: how often the reviewer catches an
incorrect output, and how often the reviewer passes a correct output without flagging it. For a
human reviewer, a manufacturer could measure both in a reader study on device outputs
enriched with incorrect ones, a design that FDA's 2022 guidance on clinical studies of radiology
detection software describes for cases enriched with abnormal findings.13 Measuring a human
reviewer in simulated or real use means evaluating the human and the device together. The
possible framework in FDA's paper places a function lower on the activity axis when a clinician
supervises the function, and a lower activity level could mean less premarket evidence.
FDA's paper names automation bias, "in which a user accepts an output without appropriate
scrutiny because of the device's fluency or perceived authority," among the risks that device
benchmarking would consider. Two studies show clinicians misled by incorrect model output or
leaving it uncorrected. In a randomized vignette study, predictions from a systematically biased
model lowered clinicians' diagnostic accuracy by 11.3 percentage points from their own
baseline.14 In a simulation study, 20 primary care physicians reviewed AI-drafted replies to
patient messages. For each of the four drafts that contained an error, 65 to 75 percent of the
physicians left the error uncorrected.15
FDA, Clinical Performance Assessment: Considerations for Computer-Assisted Detection Devices Applied to
Radiology Images and Radiology Device Data in Premarket Notification (510(k)) Submissions (September 2022),
section IV, www.fda.gov/media/77642/download. The guidance cautions that enrichment "will likely alter reader
performance in the trial compared with clinical practice."
Jabbour et al., JAMA 2023;330(23):2275-2284, doi.org/10.1001/jama.2023.22295. 457 hospital clinicians took a
web survey. The investigators built the bias into a model that scored the likelihood of each of three diagnoses, which
is not a generative model. An unbiased version raised accuracy by 2.9 percentage points.
Biro et al., npj Digital Medicine 2025;8:222, doi.org/10.1038/s41746-025-01586-2. The physicians were not given
full patient records, and the study did not compare the physicians' replies with replies written without an AI draft. One
of the four errors was a drug name misspelling copied from the patient.
Requiring a second human check does not ensure an independent one. In a direct
observational study of 5,140 pediatric medication administrations, policy required an
independent double check for 3,563. Of those, 1 percent received an independent check, and
double checking was not significantly associated with fewer errors than single checking. Where
nurses chose an optional double check, errors were less likely.16 Human review integrated into
the care team's work has been associated with fewer harmful errors. In a before-and-after study
with a control unit, a pharmacist's participation on physician rounds in one intensive care unit
was associated with a 66 percent lower rate of preventable adverse drug events due to
prescribing errors.17
Before a device takes an action that cannot be undone, a human should approve the action,
unless the manufacturer has shown, and FDA has accepted, that the device can take that action
safely without human approval.
On Question 4, we suggest that FDA treat a difference in risk between a generalist and a
specialist as a difference to be measured, by the same approach as for any other reviewer.

FDA's Section VI. Postmarket Monitoring for GenAI-Enabled Devices
(Questions 18 to 24)
In Section VI, FDA's paper describes three possible monitoring approaches: periodic device
benchmarking, periodic sample-based clinician review, and performance degradation
monitoring.

Question 18. Monitoring supplements premarket evidence, on terms set in advance
Question 18 asks, in part, when FDA could accept more uncertainty before authorization in
return for monitoring after authorization.
Recommendation. We favor study of a device with its intended users, under conditions close to
real use, during development and before authorization (Question 11). Monitoring supplements
the evidence gathered before authorization and does not replace that evidence. Accepting more
uncertainty could be reasonable where the authorization states five terms in advance: what the
manufacturer measures; the threshold for each measure; the action taken if a threshold is
crossed; the reports the manufacturer sends to FDA, with results given as rates with
denominators; and how long each commitment lasts and what ends it.
Before accepting more uncertainty, FDA could ask, function by function, whether monitoring
would detect a failure before it harms many patients. The answer depends on whether anyone
can observe the outcome, how fast a signal would appear, and how severe and reversible the
harm is.
A model that recognizes a test as a test can behave differently in the test than in real use.
Anthropic has seen signs of this behavior in its own models and has reported the signs in its
Westbrook et al., BMJ Quality & Safety 2021;30(4):320-330, doi.org/10.1136/bmjqs-2020-011473. Odds ratios 0.89
(95 percent confidence interval 0.65 to 1.21) where checks were required and 0.71 (0.54 to 0.95) where they were
optional. So few checks were independent that the authors could not assess whether independent checking works.
Leape et al., JAMA 1999;282(3):267-270, doi.org/10.1001/jama.282.3.267, with erratum, JAMA 2000;283(10):1293.
11 events before and 3 after (10.4 and 3.5 per 1,000 patient-days), in 75 sampled charts each.
system cards. None of the evaluations in which Anthropic saw those signs was clinical, but a
device could also behave differently in an evaluation than in use, so the manufacturer's
monitoring has to compare the device's behavior in use with its behavior in the evaluations run
before authorization.18 A human reviewer's performance can change with continued use of a
device, which supports postmarket monitoring in real-world settings.

Question 19. Schedule by patients reached and severity, and name the triggers
Question 19 asks, in part, about the schedule and triggers for reassessing a device.
Recommendation. We suggest that FDA ask the manufacturer for a schedule for re-running
the regression set, and for a list of triggers. A scheduled re-run could go through the live device
as deployed, and not only through a test environment. A manufacturer could set the schedule by
how many patients the device reaches between re-runs, how severe an undetected error would
be, and how often a human or software reviewer has been measured to catch the device's
errors (Question 14). Patient volume matters because an undetected systematic error can recur
among the patients the device reaches until the next re-run, so a device that reaches more
patients could warrant more frequent re-runs.
The manufacturer could also name the events that trigger a reassessment outside the schedule:
the manufacturer's own change (Question 22), including a move to a new model version; a
model developer's announcement of a change; a model developer's published account of a
defect; a change in clinical guidelines or in the patients served; and any crossing of a threshold
set at authorization.

Question 20. Supervisory AI agents first need validation against clinicians
Question 20 asks whether "machine-based supervisory agents" could facilitate monitoring, and
what CDRH should take into account, including how a supervisory agent should be evaluated.
FDA's paper does not define the term, and we use supervisory AI agent to mean software that
scores a device's outputs.
Software can read every output a device produces, and clinicians can read only a sample, so a
validated supervisory AI agent could facilitate monitoring. Anthropic is a member of a
university-led team that a federal research program funds to build a supervisory AI agent.19
Recommendation. The manufacturer and FDA could rely on a supervisory AI agent's scores
only to the extent that the scores have been shown to agree with clinicians' judgments of the
same outputs. A second AI system that checks the supervisory AI agent has to be validated too,
so the sequence of checks would have to end at clinicians' agreed judgment or at what
happened to patients.
Claude Haiku 5.5 system card (October 7, 2026), section 6.4.1, anthropic.com/claude-haiku-5-5-system-card. The
Claude Opus 5.5 system card (September 22, 2026), sections 6.1.2 and 6.6.1, reports an automated review of
transcripts with interpretability tools. The review scored the model as internally treating the situation as a test, and as
letting that view shape a choice, in as many as 36 percent of about 5,000 safety audit transcripts, more than for
earlier models, and in 0.4 percent of about 500 transcripts from real use inside Anthropic, which the card calls a
check on the measure. Anthropic uses such tools to audit its models. Interpretability tools cannot yet explain an
individual output reliably (Question 1).
Advanced Research Projects Agency for Health, Award Directory, "Constitutional Oversight: A Disease-Agnostic
Supervisory Agent for Clinical AI Safety," arpa-h.gov/explore-funding/awards/4737.
A hosted model on which a supervisory AI agent is built is changed and retired in the same way
as the device's model (Questions 23 and 24). The manufacturer could therefore repeat the
validation whenever the supervisory AI agent or the device moves to a new model version. The
manufacturer could also name the supervisory AI agent's model, say how that model is related
to the device's model, and measure how often the two models make the same error.

Question 21. The manufacturer answers for the device, and other parties can help
Question 21 asks what roles clinicians, healthcare institutions, and others might play in
postmarket monitoring without diffusing manufacturer accountability.
Recommendation. We agree that the manufacturer answers for the device.
For the other parties, a role could belong to the party that can both observe a problem and act
on it. A healthcare institution, for example, sees outcomes in patient records and can suspend
local use. Where the device's output waits for a clinician, the clinician sees the patient and the
output and can decline to follow the output.
The manufacturer would obtain from the model developer the documentation the manufacturer
cannot produce for itself: what changed between versions, evaluation results and the
configuration evaluated, known limitations, and retirement dates. The manufacturer decides
what to ask for.
In FDA's second monitoring approach, sample-based clinician review, "[q]ualified, independent
clinician adjudicators" review samples "against prospectively defined criteria." Professional
societies and standards-setting bodies could write those criteria and the sampling method as a
consensus standard FDA could recognize (Question 10).

Question 22. Scale re-benchmarking to the competencies that a change can affect
Question 22 asks, in part, how re-benchmarking could be scaled to the nature and expected
impact of a modification.
Recommendation. We suggest that FDA scale re-benchmarking to the competencies that a
change can affect. For a change that leaves the model version in place, a manufacturer could
state in advance which competencies the change can affect, fully re-benchmark those
competencies, and check the rest by re-running the regression set. A move to a new model
version can affect every competency (Question 24).
The manufacturer could run the authorized and the changed configurations on the same test
cases and test the paired differences against a non-inferiority margin set in advance (Question
12). A confidence bound outside the margin would lead to full re-benchmarking.
The manufacturer's regression set would stay apart from an independent evaluator's
sequestered test cases. A regression set that a manufacturer uses after every change shows
whether performance has been lost. The regression set does not support a new claim and does
not decide a move to a new model version (Questions 10 and 24).

Questions 23 and 24. Treat a change to a hosted model as one of three events
Question 23 asks, in part, how a predetermined change control plan, which FDA authorizes in
advance, could cover changes that cannot be fully specified. Question 24 asks, in part, how a
manufacturer can detect, evaluate, and respond to changes that the model developer makes to
an underlying model.
Recommendation. We suggest that FDA treat a change to a hosted model as one of three
events, each with its own control, meaning its own way for the manufacturer to manage the
change. FDA could say that a predetermined change control plan may set the evaluation and
the acceptance criteria in advance, in place of a description of the new version.
The first event is the release of a new model version. A manufacturer pins its device to a
version, which means that the device directs every request to that version's identifier. The
device stays on the pinned version when a newer version appears, so the move to a new
version is the manufacturer's own change.
The second event is the retirement of a version, which sets the last date for that move. For each
active version, Anthropic publishes a date before which it will not retire the version. Anthropic
notifies customers with active deployments at least 60 days before Anthropic retires a publicly
released model, and a request to a retired version then fails.20 A requirement to stay on one
version would preserve limitations that later versions correct.
A predetermined change control plan could cover the first and second events. The manufacturer
would repeat, on the device with the new version, the benchmarking that supported the
authorization, and an independent evaluator would re-run any sequestered test cases, within
the limit on reuse (Question 10). The benchmarking would use the same hosted service and
settings as the device, with the model safeguards switched on, including the model developer's.
The manufacturer would not deploy a version that fails. The plan would also say what the
manufacturer does if no available version passes before the retirement date. Access to a hosted
version can also stop without notice, for reasons such as an outage or a government order. A
manufacturer could say in advance what the device does when the model does not answer.
The third event is a change to the serving systems, meaning the systems around a pinned
version that handle each request. Anthropic's documentation says "the serving infrastructure
around the model can change over time," names "the request router, safety classifiers, and
sampling logic," and says updates "[o]ccasionally" produce "minor differences in observable
behavior."21 A model developer changes a model safeguard, or a feature of its programming
interface, on purpose and can announce the change. Other changes are not meant to alter
outputs, and when one of those changes does alter outputs, there is nothing to announce
beforehand. In August and September 2025, three infrastructure defects degraded responses
from Anthropic's models. Anthropic's published account says that Anthropic's evaluations
"simply didn't capture the degradation users were reporting," and that each defect "produced
different symptoms on different platforms at different rates."22
Advance notice therefore could not be the main control for the third event. A manufacturer could
re-run its regression set (Question 22) through its own device on a schedule (Question 19) and
Anthropic, "Model deprecations," platform.claude.com/docs/en/about-claude/model-deprecations. The dates on that
page apply on the platforms Anthropic operates. Amazon Bedrock and Google Cloud set their own dates.
Anthropic, "Model IDs and versioning," platform.claude.com/docs/en/about-claude/models/model-ids-and-versions.
Anthropic, "A postmortem of three recent issues" (September 17, 2025),
anthropic.com/engineering/a-postmortem-of-three-recent-issues.
after any announced change, and could treat user complaints as a further signal of an
unannounced change. A manufacturer could also build into the device a way for a patient or
clinician to report a problem. The thresholds and actions set at authorization would apply
whatever the cause of a decline in performance (Question 18).
A model developer can help a manufacturer in five ways: give every release its own identifier, so
that the model behind an identifier is never replaced silently; publish retirement dates; say what
can change in the serving systems; announce a deliberate change to a model safeguard that is
likely to alter outputs; and publish an account when a defect alters outputs. The manufacturer
would act on each one. Anthropic does the first three as standing practice and has done each of
the last two at least once.23

FDA's Section VII. Other Topics (Questions 25 and 26)
In Section VII, FDA's paper raises two further topics: a voluntary device master file for
foundation models, and agentic AI systems, which we address with Question 5.

Question 25. A voluntary master file can add to what model developers publish
Question 25 asks, in part, whether voluntary master files would be practical and useful, what a
file might contain, and what alternatives exist.
Recommendation. FDA's paper says submission of a file "would not constitute authorization of
the underlying model for any device intended use," and that sponsors "would remain
responsible for independently demonstrating the safety and effectiveness of their own device."
We support a voluntary program on those terms. We suggest that FDA treat a file as a
supplement to what model developers publish, because a confidential file reaches FDA alone.24
Manufacturers, FDA staff, clinicians, and researchers can read and test what is published. A
manufacturer can also compare what model developers publish. Published information supports
the manufacturer's own evaluation of the configured device and does not replace that
evaluation.
As much useful information as a model developer is able to publish belongs in model cards and
system cards. An item is worth publishing if the item would change how a manufacturer designs,
evaluates, or monitors a device, or what FDA staff decide.
A file would then contain the useful information that remains unpublished. An item could belong
in a file only if the item meets four conditions: FDA staff can act on it; the manufacturer cannot
cite it, obtain it from the model developer, or learn it by evaluating the device; the manufacturer,
which cannot see the file, does not need to act on it; and the model developer can keep it
current and give it to FDA in confidence. FDA's paper lists candidate contents (page 22,
footnote 24), and the four conditions could sort that list.
For the first three, see notes 20 and 21. Anthropic announced a change to one model's biology safeguards on
August 7, 2026 (anthropic.com/news/improving-fable-5-s-biology-safeguards) and published the account of
September 17, 2025, cited above.
FDA, "Device Master Files,"
www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/device-master-files
.
FDA could start with one alternative, without a new requirement, by publishing the questions
about underlying models that FDA staff most often cannot get answered. If FDA published such
a list, Anthropic would endeavor to answer in public wherever Anthropic is able to.

Conclusion
Anthropic broadly supports the approach that CDRH is considering and shares FDA's aim of
safe and effective GenAI-enabled devices. As CDRH develops policy in this area, we would be
glad to provide, through CDRH's public processes, further technical information about how our
models are evaluated, released, hosted, and changed.