Amadeus Brandes

Comment of Amadeus Brandes (independent researcher, Germany) on Docket FDA-2026-N-7874, Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback. The full comment (7 pages) is attached.

Questions addressed: 18, 24 and 26 (with Appendix A, element A.1); a related note on Question 1.

Where FDA accepts greater premarket uncertainty through greater reliance on postmarket monitoring (Question 18), one condition is that postmarket evidence remains attributable. Outputs should be linkable to the configuration that produced them and to the evaluation evidence then applicable. Where a checkpoint is relied on as a safeguard, they should also be linkable to the oversight record. For action-taking functions, each consequential action attempt should be linkable to its execution record. Attributability is necessary but not sufficient: monitoring also needs adequate detection, timely review and an effective response.

The comment proposes four linked records: (1) a configuration identifier, including the identifier returned by a foundation model interface (Question 24); (2) the oversight state, including "not presented" and "status not established"; (3) for action-taking functions, the action attempt and its execution status; and (4) the applicable evaluation evidence, with its coverage status preserved as it stood when each output was produced. It also proposes that manufacturers demonstrate that the linkage works, with missing links kept visible; for agentic functions this could form part of the acceptance criteria (Question 26). The elements build on existing records and recommendations, and existing configuration-management, quality-system and audit records can satisfy them where they provide reliable, preserved linkage. A synthetic worked example is included.

Comment on FDA-2026-N-7874: Attributable Postmarket Evidence for
GenAI-Enabled Devices
To: Dockets Management Staff (HFA-305), U.S. Food and Drug Administration
Docket: FDA-2026-N-7874, Considerations for the Regulation of Generative AI-Enabled Medical Devices:
Discussion Paper and Request for Feedback (August 2026)
From: Amadeus Brandes, Independent Researcher, Germany · brandesamadeus@gmail.com · ORCID 00090009-9902-2587
Date: October 2026
Questions addressed: 18, 24 and 26 (with Appendix A, element A.1); a related note on Question 1

Summary
The discussion paper contemplates accepting greater premarket uncertainty in exchange for greater reliance
on postmarket monitoring (Question 18). One condition of that exchange is that postmarket evidence
remains attributable. Outputs should be linkable to the configuration that produced them and to the
evaluation evidence then applicable. Where a checkpoint is relied on as a safeguard, they should also be
linkable to the oversight record. For action-taking functions, each consequential action attempt should be
linkable to its execution record.
Attributability is necessary but not sufficient. Monitoring also needs adequate detection, timely review and
an effective response, soon enough for the risk at hand.
The paper notes that GenAI-enabled devices can change through the underlying model, prompts, retrieval
strategies, guardrails, orchestration logic and user interface (Section II), and that some changes may originate
with a third-party foundation model developer (Section VI.C). Where outputs cannot be linked to their
configuration, monitoring pools results across configurations, and reassessment after a change becomes
broader and less defensible.
This comment recommends four linked records: a configuration identifier; the oversight state, wherever a
checkpoint is relied on; for action-taking functions, each consequential action attempt and its execution; and
the applicable evaluation evidence, with its coverage status preserved as it stood when the output was
produced. It also recommends that manufacturers demonstrate that the linkage works, with missing links
kept visible. Annex A gives a synthetic example.
Comments FDA-2026-N-7874-0049, -0093, -0105, -0127 and -0131 propose related records for configuration
attribution, version custody and agent actions. This comment is offered as a compact, complementary
specification.

1. Question 18: attributability as one condition of postmarket reliance
Recommendation. Where FDA accepts greater premarket uncertainty through greater reliance on a
monitoring program, that program should be able to attribute the outputs it reviews to the device
configuration that produced them. Where human review or another checkpoint is relied on as a safeguard, it
should also link outputs to the oversight record. For action-taking functions, it should link each consequential
action attempt to its execution record, whether or not a checkpoint applies.

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 1 of 7
Necessary, not sufficient. Where an incorrect output can cause irreversible harm, the boundary is whether
detection and intervention can occur soon enough for that risk. Identifying the responsible configuration
afterwards does not prevent the harm.
Rationale. Each monitoring approach in Section VI.A compares outputs against prespecified benchmark
thresholds, clinician judgment or a performance trend. Each comparison is more reliable when the outputs
can be linked to a known configuration. Without that link:
• performance degradation monitoring has difficulty separating drift in the input population from a
change in the device;
• sample-based clinician review has difficulty telling whether an error arose under the authorized
baseline or after a modification;
• it is harder to justify the scope of re-benchmarking after a modification (Question 22) and to identify
which outputs require look-back review or correction.
Attributability also bears on Question 21: shared monitoring roles diffuse accountability less when each
reviewed output resolves to a configuration on the manufacturer’s record. Some of these records are held by
others, such as execution confirmation in a health system’s order-entry system or a version identifier
returned by the model provider. The monitoring program should specify how the manufacturer obtains
them.
Capture scope. Later review or investigation may select outputs that no sampling plan identified in advance.
Each output of a GenAI-enabled device software function should therefore resolve to its contemporaneous
configuration, not only the outputs in a predefined sample. The recording unit is a device output or a
consequential action event, not a token or intermediate step. The full configuration can be stored once and
referenced by its identifier. For action-taking functions, every consequential action attempt would be
recorded, including attempts that are blocked or fail.
Demonstrating the linkage. A manufacturer relying on monitoring could show, through risk-proportionate
testing, that outputs resolve to the correct configuration and applicable evidence, including across a
configuration change. Outputs whose links are missing or unresolved should remain visible and be counted. A
review confined to successfully linked records would exclude unresolved events that may themselves warrant
investigation.
Possible framework language. “A monitoring program relied on to offset premarket uncertainty should be
able to attribute each output it reviews to the device configuration that produced it and to the evaluation
evidence then applicable. Where a checkpoint is relied on as a safeguard, the output should also be linked to
the oversight record. For action-taking functions, each consequential action attempt should be linked to its
execution record. Outputs whose links are missing should remain visible to the program. Attributability
supports, but does not replace, detection and response that are timely for the risk.”

2. Question 24: detecting and responding to third-party model changes
Recommendation. Manufacturers should record, with each output, the identifier returned by the foundation
model interface where one is available, alongside the device’s own configuration identifier. An automated
check should compare it against the accepted configuration, and an unexpected value should trigger a
predefined, risk-proportionate response.
What an identifier can show. A returned identifier reveals an upstream change only if the provider changes it
whenever the relevant implementation changes. Some identifiers denote an alias or a service configuration
rather than every safety-relevant component; one provider, for example, has described its returned
fingerprint as representing “the backend configuration that the model runs with” [1]. Manufacturers should

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 2 of 7
therefore document what the identifier identifies and which changes alter it. The device’s UDI does not, by
itself, establish the configuration of a hosted model at a given time: for stand-alone software not distributed
in packaged form, the production identifier conveys the version number [2], which should not be assumed to
capture every upstream change.
An unchanged identifier is informative only to the extent that its documented meaning covers the relevant
changes. Separately, substantial behavioral differences have been documented between the March and June
2023 versions of GPT-3.5 and GPT-4 [3]. Contractual change notification and behavioral monitoring therefore
remain necessary for changes an identifier may miss.
Recording is not detection. A changed identifier in a log triggers nothing unless something checks it. For
action-taking functions, the check can run before execution, so that an unexpected configuration leads to the
predefined response rather than to an action.
Evaluation and response. Question 24 also asks how manufacturers evaluate and respond. Evaluation is
recorded under element 4: the change assessment, with coverage shown as not yet established until the
assessment is complete. The response to an unexpected configuration could be set in advance and scaled to
the function’s risk: review, restriction of the affected function, or a validated fallback. Where an interface
exposes no version identifier, that gap should be documented and addressed by other means, for example
version pinning or advance notice of changes.
Link to Question 25. Footnote 24 lists update notification commitments and audit log availability as possible
content of a Foundation Model MAF. A MAF could also describe the identifier scheme the interface returns
and which changes alter it, so that device-level records can be interpreted without disclosing confidential
model details.

3. Question 26: linked action records for agentic functions
Recommendation. For agentic GenAI-enabled devices, each consequential action attempt should leave
linked, time-ordered records that keep three things apart: the oversight state under which it was attempted,
the action attempted, and the execution evidenced afterwards. They need not form one fully populated
record at generation time, because the downstream outcome may not yet exist. The records would include:
• a stable action identifier linking the attempt, checkpoint events and downstream evidence;
• the attempted action, or a protected reference to it;
• the oversight state: not required; required but not presented; presented and approved; presented
and rejected; presented without a response; or status not established. A missing record reads as
“status not established”, never as “not required”. The reviewer is identified by role and as human or
automated (compare Question 20);
• the observed execution status: completed, blocked, failed, pending or unknown;
• a reference to downstream confirmation, added when available and taken from the relevant control
or downstream system wherever possible;
• each observable source class among the inputs available to the action (user input, retrieved content,
tool output, system instruction), with its trust classification, and “unknown” where a source cannot
be observed.
What the records support. Appendix A, element A.1 names compliance with human-oversight checkpoints
before irreversible or high-consequence actions, and resistance to prompt injection through user inputs,
retrieved content and tool outputs. After deployment, these records support investigation of suspected
checkpoint failures and suspected injection. Agent identifiers, real-time monitoring and activity logging have

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 3 of 7
been proposed as general measures for visibility into AI agents [4]; these records apply that approach to
consequential device actions.
They do not by themselves establish why an action occurred. In a multi-turn interaction the triggering input
may not be identifiable, and a model’s own account of its reasons should not be treated as authoritative.
Why the separation matters. An action can be attempted and blocked, attempted and failed, or completed
with an outcome that differs from the attempt. A record of the outcome alone cannot distinguish a working
safeguard from a failure that happened to cause no harm.
Acceptance criteria and oversight (second part of Question 26). Acceptance criteria for an agentic function
could include a demonstration that each consequential action attempt resolves to the correct configuration,
oversight events and execution evidence. Test cases would cover a changed configuration, a blocked attempt
and a downstream confirmation that does not arrive. Oversight expectations could then be stated in terms of
these records: for each consequential action, whether a required checkpoint was presented, its result, and
the reviewer’s role.

4. A related note on Question 1
Question 1 mentions traceability of the output to primary source materials. A related but distinct property is
attributability of the output to the configuration and oversight state that produced it. Traceability enables
assessment of whether content is grounded, though a source link does not establish correctness;
attributability tells a reviewer which version of the device produced an output, under what supervision.
The two can fail independently. This comment does not propose attributability as an additional riskclassification dimension. It affects how much confidence monitoring and corrective action can draw from
postmarket evidence.

The record
The elements build on existing records and recommendations. FDA’s draft guidance on AI-enabled device
software functions recommends model version history, including differences between the tested and
released versions of a model, and performance monitoring that addresses data drift [5]. Premarket
submissions for cyber devices must include a software bill of materials, including off-the-shelf components
[6]. These provide foundations for configuration documentation; element 1 adds preserved linkage to each
output.
Four linked elements. Information is recorded as the relevant events occur; later confirmations and
assessments are linked without rewriting earlier entries. A comparable preservation principle appears in 21
CFR 11.10(e), for electronic records within Part 11’s scope: “Record changes shall not obscure previously
recorded information” [7].

Element and scope Content What it supports

1. Configuration identifier. Resolves to a preserved configuration record: device and Linking outputs to the
Every output of a GenAI- component versions, including the foundation model identifier authorized baseline or a
enabled device software as returned by its interface, with documentation of what it later change; automated
function identifies; prompt, retrieval-corpus, guardrail, orchestration, comparison against the
tool and interface versions where they affect behavior. Stored accepted configuration
once and referenced; the historical mapping is protected (Questions 18, 22, 24)
against silent revision.

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 4 of 7
 Element and scope Content What it supports

2. Oversight state. Whether a checkpoint was required; if so, whether it was not Showing whether relied-on
Wherever human review or presented, approved, rejected or presented without a review occurred;
another checkpoint is relied response, or its status is not established; reviewer role, human investigating suspected
on as a safeguard, including or automated. A missing record reads as “status not checkpoint failures
action-directing functions established” (Questions 18, 26)

3. Action attempt and Stable action identifier; attempted action or a protected Distinguishing blocked,
execution. Consequential reference; execution status (completed, blocked, failed, failed and completed
actions of action-taking pending, unknown); downstream confirmation reference, attempts; investigating
functions, agentic or not added when available; observable input source classes and suspected injection
trust classification (Question 26, element A.1)

4. Applicable evidence and Reference to the evaluation evidence and change assessment Showing which evidence
change assessment. Every that apply to the configuration, including relevant PCCP supported reliance at the
configuration in use provisions and implementation results; coverage status as it time, and what was
stood when the output was produced, which may be “not yet established later (Questions
established” 22, 23, 24)

Element 4 preserves timing. A later evaluation or change assessment is linked from its own date; it does not
make earlier outputs appear covered when they were produced.
A PCCP describes planned modifications and the methods for implementing them [8]; a pointer to it does not
show that a particular change followed those methods. Element 4 therefore refers to the change assessment
and its results.
The records hold metadata and protected references, not duplicated clinical content; protected references
may still require access controls. Reviewers can be identified by role where privacy requires. This is not a
general logging requirement: the records hold the fields on which evidentiary claims about an output
depend, which may be unrecoverable later unless equivalent records were kept at the time. Cost lies mainly
in reliable linkage, instrumentation, validation and retention.

Scope and limits
This comment does not propose:
• new legal authority, a question the discussion paper expressly leaves open;
• a specific data format or schema;
• a parallel record system: existing configuration-management, quality-system and audit records can
satisfy these elements where they provide reliable, preserved linkage;
• duplication of patient data or clinical content in the metadata record;
• the same record depth for every function.
Comparable requirements and standards exist elsewhere. Article 12 of the EU AI Act establishes
requirements for automatic logging in high-risk AI systems, including events relevant to substantial
modifications and post-market monitoring, subject to the Act’s scope and application dates [9]. ISO/IEC
24970, now at final-draft stage, describes an information model for AI system logging [10]. Alignment could
support reuse of records across frameworks, subject to their respective requirements.
Where FDA accepts greater premarket uncertainty through greater reliance on monitoring (Question 18), the
applicable elements would be a condition of that reliance. Outside that case, elements 1 and 4 are offered as

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 5 of 7
recommended practice, because upstream model changes (Question 24) can occur whatever premarket
evidence was accepted.
Element 2 follows the safety case rather than the activity level. Section IV recognizes that a nominally
informational function can direct an action. A function that directs a consequential treatment step but leaves
execution to the clinician still relies on that clinician’s review, so whether the review occurred remains
relevant evidence. Element 3 applies only where the device itself acts. Retention periods could scale with the
consequences axis.

References
1. S. Anadkat, “How to make your completions outputs consistent with the new seed parameter,”
OpenAI Cookbook (6 November 2023; archived), describing the system_fingerprint field.
2. 21 CFR 801.50(a), labeling requirements for stand-alone software not distributed in packaged form.
3. L. Chen, M. Zaharia, J. Zou, “How Is ChatGPT’s Behavior Changing over Time?,” Harvard Data Science
Review (2024); arXiv:2307.09009.
4. A. Chan et al., “Visibility into AI Agents,” ACM FAccT 2024; arXiv:2401.13138.
5. FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing
Submission Recommendations, draft guidance (January 2025), Docket FDA-2024-D-4488.
6. FD&C Act § 524B(b)(3), 21 U.S.C. 360n-2(b)(3); FDA, Cybersecurity in Medical Devices: Quality
Management System Considerations and Content of Premarket Submissions, guidance (February
2026).
7. 21 CFR 11.10(e).
8. FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial
Intelligence-Enabled Device Software Functions, guidance (August 2025).
9. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Art. 12.
10. ISO/IEC FDIS 24970, Artificial intelligence — AI system logging, final draft (ballot opened August
2026).

Annex A: Synthetic worked example
The example is synthetic. It builds on the paper’s illustration of the autonomous initiation of a thrombolytic
therapy order set in a stroke workflow (Section IV). It assumes that a required HCP checkpoint precedes
execution, that the foundation model interface returns a version-specific identifier, and that the device
compares it automatically against the accepted configuration.
1. Day 0. The device is authorized. Its accepted configuration is C1, built on foundation model version
M1.
2. Day 40. The foundation model developer updates the model to M2 without notice. The
manufacturer-controlled components are unchanged.
3. Day 55. Sample-based clinician review finds an order-set initiation that appears to have skipped the
HCP checkpoint.
Without the identifier check or linked records, and with no other mechanism detecting the change, it
surfaces only on day 55, through the clinical event. The reviewer cannot readily tell whether the output came
from M1 or M2, whether the checkpoint was presented, or which inputs were available to the action. Rebenchmarking remains possible, but its scope is harder to defend.

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 6 of 7
With the identifier check in place, M2 is flagged on day 40 and the predefined response is triggered.
Depending on the function’s risk, that response may be review or restriction; restriction could prevent the
day-55 event altogether. The linked records show which outputs and action attempts ran under M2 before
the response took effect. If the event still occurs, the review starts from recorded events: whether the
checkpoint was presented and, if so, its result and the reviewer’s role, and whether retrieved content was
among the inputs.
These records distinguish recorded events; they do not establish cause. Whether interface design, misleading
information or inadequate safeguards contributed to a skipped checkpoint or an approval still requires
investigation. Element 4 shows coverage for M2 as not yet established, so reassessment begins from that fact
rather than from an assumed baseline. If testing later accepts M2, that assessment is linked from its own
date; outputs produced before it still show that coverage was not established at the time.

Annex B: Related public work by the commenter
• Minimum Action Records for Consequential AI Agents, consultation response prepared for ISED
Canada’s 2026 consultation on advancing AI transparency (September 2026). Zenodo, DOI
10.5281/zenodo.22817224. It proposes an action-record profile that distinguishes delegated
authority, attempted execution and evidenced outcome.
• Evidence Records for Public-Record Changes: Definitional Class Membership as the Certifiable Citation
Unit, arXiv:2609.11978, implemented as TrialDiff for ClinicalTrials.gov protocol amendments.
About the commenter. Amadeus Brandes is an independent researcher in Germany working on audit trails
and chain of custody for digital records. He previously commented on FDA dockets FDA-2026-N-4390 and
FDA-2019-D-4964.

FDA-2026-N-7874 · Comment of Amadeus Brandes · Page 7 of 7