Glacis Technologies (Joseph T. Braidwood)

Glacis Technologies appreciates the opportunity to provide feedback on FDA’s discussion paper on generative AI-enabled medical devices.
Our feedback discusses how clinical risk should inform premarket evidence requirements and postmarket monitoring, and the role of observable, independently verifiable evidence that required safety controls operated during individual AI inferences, so that clinicians, manufacturers, and regulators can better understand what happened when an AI system contributed to a clinical decision, investigate potential safety failures, and determine whether the expected safeguards were in place and functioning for gen AI systems.

We have attached our responses to Questions 16, 18–24, and 26, along with a case study use case showing how runtime evidence can generate evidence to support premarket evaluation, PCCP, and postmarket monitoring.

Runtime evidence for GenAI medical devices
This proposed use case examines how independently verifiable runtime evidence from an AI system
could support a medical device manufacturer during premarket evaluation, assessment of device
changes, and postmarket monitoring. It describes an evidence design for discussion, not a completed
device integration, clinical study, or FDA-endorsed approach.

The Role of Runtime Evidence
For every AI inference within the monitored clinical workflow, evidence would be recorded, e.g. the
model and configuration used, the clinical information made available to the AI and its response (or
secure references to those records), and the safety checks expected to apply. They would document
whether each check was evaluated, its recorded result, and whether the device proceeded, abstained,
or requested clinician review. Examples include checking for necessary clinical information, keeping
recommendations within the device’s intended use, and withholding a recommendation when
information is insufficient. Where connected clinical systems are also monitored, relevant subsequent
actions could be recorded.
The manufacturer would assess whether expected AI interactions and safety checks were captured and
identify missing records, monitoring interruptions, or possible bypasses. Where available, records
would be compared with relevant application or clinical-system logs to identify gaps. Changes in clinical
performance would need separate evaluation; knowing which configuration was used does not
demonstrate clinical accuracy.
Patient information could remain in the manufacturer’s or healthcare organization’s secure
environment. Independently verifiable records could instead contain limited information and protected
references to the original clinical data, with access for authorized investigation and appropriate privacy
protections. Even limited metadata can be sensitive and must be protected.

Use across the device lifecycle

Use Evidence Captured

Link the model and safety checks used in testing to their recorded results.
Premarket Test whether required checks, abstention, escalation, and evidence capture
operate as intended before deployment.

Record what changed in the model or system, which clinical safeguards
Changes under an
may be affected, and the relevant testing results required by the authorized
authorized PCCP, where
plan. These records help evaluate compliance with the plan; they do not
applicable
authorize the change.

Capture evidence for AI inferences and safety checks in actual use.
Postmarket Support review of safety concerns, changes in behavior, missing records,
and whether the required response occurred when a safety check failed.

Glacis Technologies | Illustrative evidence design | 1
The proposed design
A first demonstration could focus on a specific clinical safeguard. Consider a hypothetical GenAIenabled device that recommends medication treatment or dosing. If the device does not have the renalfunction laboratory results necessary to support a safe recommendation, it should abstain from offering
a specific recommendation, identify the missing information, and request additional testing or clinician
review, according to its defined clinical requirements.
The demonstration should show which relevant clinical information was available to the AI, which safety
controls should have applied, whether they were evaluated, and their recorded results. It should also
show whether the device provided a recommendation, abstained, or escalated, and what response was
presented to the clinician when that information is observable. Test cases should include missing
information, failed checks, interruptions in monitoring, and attempts to bypass required safeguards.
Report the controls tested, the completeness of records, any discrepancies, and whether the expected
response occurred.

The role of runtime evidence
Runtime evidence can help manufacturers and regulators reconstruct an individual AI-mediated clinical
interaction: which model and configuration were used, what information was available, which
safeguards were expected, whether they were evaluated, and the results recorded. For example,
following a medication-related event, reviewers could examine whether the system checked for the
required renal-function laboratory results and whether it withheld a dosing recommendation when that
information was missing.
When appropriately implemented and tested, these records can support investigation of adverse
events, evaluation of changes, and postmarket oversight. They cannot, by themselves, establish that
every relevant event was captured, that each recorded action happened as described, that a safety
check correctly assessed the clinical situation, or that a treatment recommendation was clinically
appropriate. Those judgments require assessment of the monitoring system, source records, and
relevant clinical context. Runtime evidence complements rather than replaces software verification and
validation, clinical performance evaluation, and postmarket clinical assessment.

Request for FDA feedback
We welcome FDA feedback on what information about AI configuration, safety-check execution,
completeness of evidence, and responses to identified failures would be useful during premarket
review, evaluation of changes under an authorized PCCP, and postmarket oversight. The use case
could accompany formal comments as a proposed design; claims about demonstrated performance
would require supporting methods and results.

Regulatory context
FDA’s GenAI discussion paper seeks input on these questions and is not draft or final guidance. The
uses proposed here are for discussion; they are not a statement that FDA has accepted this evidence
design.
FDA: GenAI-enabled medical devices discussion paper (2026)
FDA: Predetermined Change Control Plan guidance (2025)

Glacis Technologies | Illustrative evidence design | 2

Glacis Comments on Generative AI Enabled Medical Devices
Docket No.: FDA-2026-N-7874
Document: Considerations for the Regulation of Generative AI-Enabled Medical Devices:
Discussion Paper and Request for Feedback
To: Dockets Management Staff (HFA-305), Food and Drug Administration
Date: October 19, 2026
Questions addressed: 16, 18, 19, 20, 21, 22 to 24, and 26

About Glacis and disclosure of interest
Glacis Technologies, Inc. ("Glacis") builds runtime evidence infrastructure for AI systems. Its
software evaluates controls defined by the manufacturer or deploying organization at instrumented
points between an application and its AI model. It records the outcomes as signed, tamper-evident
records that others can verify within a stated scope.
Glacis created OVERT (Observable Verification Evidence for Runtime Trust), an open specification
for these records, published under a royalty-free patent covenant. In September 2026, Glacis, the
Coalition for Health AI (CHAI), and the AIGovOps Foundation signed a stewardship agreement for
OVERT. The public charter records that commencement is pending. Once the agreement takes
effect, CHAI and the AIGovOps Foundation will hold voting stewardship and Glacis will become a
non-voting editor. [3]
Glacis sells runtime evidence software and related services to organizations that develop or deploy
AI systems. The Utah Office of Artificial Intelligence Policy lists Glacis among the approved thirdparty evaluators for its AI regulatory sandbox, in the runtime attestation category. The listing is under
a non-exclusive memorandum of understanding signed August 10, 2026. Several recommendations
below concern the kind of evidence Glacis produces. We have written them so that any qualified
provider could meet them. Glacis does not author clinical standards, make clinical decisions, or
certify devices. [2]

Summary of recommendations
1. Question 16. Qualify independent assessors through an open, non-exclusive process based on
published criteria. Keep the production of a device's runtime records separate from the
independent evaluation of its clinical performance.
2. Question 18. Accept greater premarket uncertainty only where errors can be detected and
addressed before serious harm, with a monitoring program implemented and tested before
deployment.
3. Question 19. Combine clinical sampling with automated checks of defined safety controls across
instrumented interactions, with verifiable records and explicit capture coverage.
4. Question 19. Trigger reassessment on defined events as well as on a schedule, because a
GenAI-enabled device can change without a release from its manufacturer.
5. Question 20. Validate machine-based supervisors against independent reference judgments,
measure clinically consequential errors, and track their versions and changes.
6. Question 21. Have labeling state which safeguards the manufacturer provides and which the
deploying organization must configure.

Glacis Technologies | FDA-2026-N-7874 | 1
7. Questions 22 to 24. Assess third-party foundation model changes under the applicable devicechange framework. Combine provider notices, version controls, and behavioral testing, and
document uncertainty about undetected updates.
8. Question 26. For agentic devices, enforce checkpoints before high-consequence actions with
controls outside the model, and record whether each checkpoint operated.

Question 16 Independent third parties in the competency-based approach
Independent third parties are most useful where the sponsor would otherwise control both the
evidence and its interpretation. We support a role for them, scaled to the risk of the device.

Where third parties can contribute
Independent testing. A third party can maintain sequestered benchmark sets and run them against
the deployed configuration. This can reduce exposure to data contamination and optimization to the
test. The voluntary Medical Device Development Tools (MDDT) program may offer a route to qualify
suitable benchmark methods for a defined context of use, subject to FDA's qualification criteria. [4]
Clinical adjudication. Independent, specialty-matched clinicians can assess outputs where clinical
judgment is required. Blinded review and reported inter-rater agreement strengthen the results. We
support the paper's principle that adjudicators be structurally independent of the sponsor and of the
foundation model developer, including when the adjudicator is itself an LLM.
Verification of postmarket evidence. A qualified third party can review recorded monitoring and
control outcomes, assess the recording system, and evaluate completeness within the stated
capture boundary. This supplies evidence beyond retrospective summaries prepared by the
sponsor. A valid signature alone does not establish that the instrumentation was accurate, that every
relevant event was captured, or that a downstream action occurred.
Utah's AI regulatory sandbox offers a recent example. Its Office of Artificial Intelligence Policy
recognizes evaluators for clinical and technical evaluation separately from runtime attestation. Its
framework emphasizes post-deployment evidence while retaining pre-deployment evaluation. [2]

Qualifications and independence criteria
FDA could consider the following criteria for organizations performing these roles.
• Structural independence from the sponsor and from the developer of any incorporated
foundation model, with conflicts disclosed
• Fees that do not depend on the outcome of the assessment
• Demonstrated competence, such as reproducible results on reference tasks, with documented
methods, scope, and limitations
• A duty to report patient safety concerns to the manufacturer and FDA whether or not the device
passes
• Openness to audit by FDA, with loss of recognition when a reported result does not match the
assessor's actual findings
Utah's published evaluator safeguards include similar requirements for independence certification,
safety reporting, and audit.

Where third-party involvement would be inadvisable
Third-party determinations should be inputs to CDRH's review, with CDRH keeping the decision.
Utah's office retains final decision-making control over its sandbox in the same way.

Glacis Technologies | FDA-2026-N-7874 | 2
The organization that produces a device's runtime records should not also serve as the independent
evaluator of that device's clinical performance. Combining the roles would let one party shape both
the record and its interpretation.
Mandatory third-party assessment for lower-risk functions would add cost without a clear safety
benefit. For those functions, sponsor testing reviewed by FDA should remain available.
Development-stage testing should also stay with sponsors, who need to iterate quickly. Independent
involvement adds the most value at defined gates, such as the benchmark supporting a marketing
submission and periodic postmarket audits.

Safeguards for competition and innovation
FDA should qualify assessors through an open, non-exclusive process based on published
requirements. Sponsors should be free to choose among qualified providers. The Accreditation
Scheme for Conformity Assessment (ASCA) offers a procedural analogy for criteria-based
accreditation, although its current scope does not establish a GenAI assessment program. [5] Utah's
sandbox similarly gives no evaluator an exclusive role and permits companies to choose among
recognized evaluators. [2]
Benchmark methods, scoring rules, and evidence formats should be openly documented, while
protecting sequestered test items where disclosure would undermine validity. Authorized reviewers
should be able to verify records without buying the originating provider's service. Verification
materials should include the applicable schema, software, and trusted key information. Removing
dependence on a vendor dashboard does not remove the need to assess the recording system and
its capture limits.

Question 18 Accepting greater premarket uncertainty
The degree of premarket evidence required should be proportionate to the device's intended use,
clinical risk, degree of autonomy, and potential consequences of an incorrect output or action.
Greater reliance on postmarket monitoring may be appropriate where errors are detectable, effective
safeguards can prevent or mitigate harm, and the consequences of failure are limited or reversible.
For higher-risk applications, particularly where an incorrect recommendation or autonomous action
could result in serious harm before intervention is possible, postmarket monitoring should not
substitute for adequate premarket clinical evidence. Human review is a meaningful safeguard only
when the reviewer has adequate information, time, expertise, and authority to intervene before harm
occurs. [1]
Where FDA determines that greater premarket uncertainty is acceptable, manufacturers should
demonstrate before deployment that the monitoring and response mechanisms needed to manage
the remaining risks are operational and have been tested. Postmarket collection and review should
begin at deployment. The plan should identify the remaining uncertainty, how and when it will be
resolved, and the conditions for restricting or ending use. These should include:
1. Risk-based monitoring and response requirements. Define the clinically significant failure
modes for the intended use, how they will be detected, acceptable performance thresholds,
and the actions required when those thresholds are exceeded. Clinical and patient-safety
expertise should inform these requirements.
2. Evidence captured for every required model invocation. Define the capture boundary
and the events that must be recorded, including model invocations, retries, applicable control
checks, and consequential tool actions within the instrumented workflow. Record every
required event within that boundary, including the observed model identifiers and

Glacis Technologies | FDA-2026-N-7874 | 3
 configuration, relevant inputs and outputs or secure references to them, the safety controls
expected to operate, whether those controls executed and their recorded results, and any
attempted or observed downstream actions. These records should be tamper-evident and
independently verifiable, with explicit documentation of capture coverage and gaps.
Assessed alongside validated instrumentation and relevant source evidence, they support
reconstruction of the recorded interaction rather than relying solely on aggregate
performance reports or manufacturer assertions.
3. Risk-based clinical performance monitoring. Conduct ongoing clinical assessment of
sampled AI outputs and associated decisions, with sampling designed around the frequency
and severity of potential failures. Higher-risk uses may require more intensive review and
independent clinical adjudication. Automated checks can continuously evaluate defined
operational safeguards, but do not replace assessment of clinical correctness.
4. Defined triggers for reassessment. Reassess performance and safety when there are
material changes to the model, configuration, clinical workflow, patient population, or
observed behavior, including changes detected through monitoring.
5. Demonstrated ability to intervene. Establish and test mechanisms to restrict, suspend, or
modify device functionality when clinically significant safety thresholds are exceeded or
required safeguards fail. The response should be proportionate to the risk and the potential
consequences of continued operation.
6. Monitoring completeness and failures. Manufacturers should demonstrate that required AI
interactions are captured within the defined monitoring boundary, identify gaps or bypasses,
and specify what happens when monitoring or evidence capture becomes unavailable. For
higher-risk uses, failure of required safety monitoring should trigger an appropriate restriction
or fallback rather than allowing the device to continue operating without the intended
safeguards.

Where the approach would not be appropriate
Monitoring detects failures after they occur. It cannot substitute for premarket evidence where a
single error could cause severe or irreversible harm before anyone can intervene. Examples include
action-taking functions without an effective human checkpoint. They also include measurement or
signal processing functions whose outputs users cannot check, which the paper identifies as
potentially higher risk. Monitoring is also a weak substitute where the failures of concern are rare,
because sampling detects rare failures slowly.
An authentic record of a safeguard outcome does not establish that an output was clinically
appropriate. Utah's framework similarly distinguishes runtime attestation from evidence that an AI
system is safe. [2] A monitoring program used to offset premarket uncertainty needs appropriate
clinical evaluation as well as operational evidence.

Question 19 Postmarket performance evaluation
A GenAI-enabled device may produce a different output on each interaction. It may also change
through modifications to the model, prompts, retrieval sources, tools, guardrails, or surrounding
workflow. Postmarket evaluation should account for both.
It helps to distinguish four related functions.
• Validation asks whether a system can perform as intended under defined conditions.
• Monitoring asks whether its performance or operating environment is changing.

Glacis Technologies | FDA-2026-N-7874 | 4
• Runtime controls govern what the system is permitted or required to do while it operates.
• Runtime evidence supports reconstruction of the control outcomes recorded for a particular
interaction. Its reliability depends on validated instrumentation, capture coverage, and
trustworthy signing and time information.
Clinical quality and appropriateness generally require expert review and risk-based sampling. Some
defined safety and operational requirements can be checked automatically across instrumented
interactions, with coverage measured and gaps reported. We recommend a hybrid postmarket
framework that uses each method where it fits, with results recorded as independently verifiable
evidence. Runtime evidence requirements can scale with clinical risk and intended use.

Periodic re-benchmarking
Re-benchmarking against the premarket baseline is important for detecting regression, especially
after changes to the model or other components. Consistent with Section V.A, it should test the
production configuration and not the foundation model alone. That configuration includes the model
version, system prompt, retrieval corpus, tools, guardrails, and orchestration logic. We support the
paper's inclusion of triggering events alongside a defined cadence, and we suggest specific triggers
at the end of this section. [1]

Sample-based clinician review
Clinician review is essential for properties that require judgment. Sampling may detect rare failures
slowly. At a constant failure probability of one in 1,000, about 3,000 independent, randomly selected
interactions give a 95 percent chance of encountering at least one failure, assuming reviewers
reliably identify it. This illustrates detection of an event, not precise estimation of its rate. Correlated
observations or missed errors reduce what the sample establishes.
Risk-based stratification can make review more informative. Reviews can oversample high-acuity
encounters, interactions where an automated control failed, complaints, and populations that were
underrepresented premarket. The selection method and denominators should be reported;
population estimates require adjustment for unequal sampling probabilities. Where more than one
reviewer is used, blinding reviewers to device version and reporting inter-rater agreement strengthen
the evidence.

Performance degradation monitoring
Two kinds of change should be monitored separately. Changes to observable, manufacturercontrolled configuration can be detected against a documented baseline. Behavioral testing may
reveal changes in a hosted model, but cannot guarantee detection of every upstream update or
establish its exact time. Behavioral drift should be measured statistically against a reference period,
with the sensitivity and limits of the monitoring method stated.
For open-ended clinical outputs, performance degradation can be difficult to measure because
reliable reference judgments are often unavailable when the output is produced. Performance often
has to be assessed retrospectively, through sampled expert review, delayed outcome labels, or
validated proxies. Monitoring should therefore combine input distribution shift, output characteristics,
and task-specific quality measures. Useful output characteristics include length, refusal and
escalation rates, and departures from intended scope. For functions that generate clinical text, taskspecific measures include omission of clinically important information and clinician edit burden
between draft and final record. Where input is spoken, they also include parity of speech recognition
error rates across demographic groups. These examples come from ambient clinical documentation,

Glacis Technologies | FDA-2026-N-7874 | 5
which may fall outside device oversight. Comparable measures can be defined for device functions
that generate or summarize clinical content.

Additional approaches
Automated checks of defined safety controls. Some requirements can be checked automatically
as the device is used. Examples include whether required structured fields and timestamps meet
specified rules, whether a user has permission to act, and whether a proposed action falls within a
defined scope. Assessing whether clinical information is sufficient or an escalation is clinically
appropriate may require model-based evaluation or human judgment. Each recorded result should
identify the check performed and its limitations.
Tamper-evident interaction records. For higher-risk devices, the postmarket record should
support investigation of relevant events. It should identify the observed configuration, applicable
controls, recorded outcomes, and resulting decisions. Permission to act should be distinguished
from evidence that a downstream action completed. Signatures and integrity checks help
authenticate captured records and make subsequent alteration detectable under stated verification
assumptions. Claims about event timing also depend on trustworthy time information; a signature
alone does not establish when an event occurred.
Tamper evidence does not reveal events that were never captured, such as actions through an
uninstrumented path. Evidence should state which workflow points it covers, and be reconciled on a
defined schedule against appropriate source-system logs, such as an EHR audit log. Report
denominators, unmatched events, outages, bypasses, and unresolved differences. Reconciliation
remains limited by the coverage and reliability of the comparison source.
Records can use limited metadata and hashes while clinical content remains in the deploying
organization's environment. Hashes, metadata, and linkable aggregates should not be assumed
anonymous. Access, retention, linkage, and disclosure controls should reflect the information's
sensitivity. Where investigation or adjudication requires clinical content, the evidence plan should
preserve lawful access to retained source records; a hash cannot reconstruct that content.
Site, population, and subgroup analysis. Performance can vary with workflow, specialty, site, and
patient population. Where clinically relevant and statistically feasible, postmarket reporting should
allow analysis by site and across demographic, linguistic, and clinical subgroups, particularly where
premarket data were limited. Where a device is deployed at many sites, each site can compute the
same measures locally and share aggregate results. This can support comparison without pooling
raw clinical records, provided measures are comparable and aggregates have appropriate
disclosure controls.
Clinician correction and override signals. Edits, rejections, overrides, escalations, and reopening
of an AI-generated output are useful signals. They should be read in context and not treated as
direct measures of error. Meaningful changes from baseline may warrant investigation.
GenAI-specific adverse event categories. FDA should consider whether existing device problem
codes and the IMDRF adverse event terminology adequately capture failure modes common to
GenAI-enabled devices. These include fabricated content, material omission, departure from
intended scope, failure to escalate, and unsafe tool use. Consistent categories would make patterns
easier to identify across devices.

Case example
Consider a hypothetical GenAI-enabled clinical decision support device that reviews a patient's
electronic health record and generates medication treatment recommendations. The device has

Glacis Technologies | FDA-2026-N-7874 | 6
defined safety controls requiring it to verify that relevant clinical information is available, including
current renal function, medication history, allergies, and contraindications. It should also identify
when the available information does not meet prespecified, clinically justified requirements for
recency and sufficiency, and abstain or request clinician review instead of issuing an actionable
medication or dosing recommendation.
For example, a patient with chronic kidney disease may have a recent change in renal function that
is not reflected in the available medical record. If the device does not have the necessary renalfunction laboratory results to safely recommend a medication or determine an appropriate dose, an
expected safeguard would be to abstain from making a specific treatment recommendation, identify
the missing information, and request additional testing or escalate for clinician review.
If an adverse event occurs, traditional validation and postmarket performance reports may establish
that the device was tested for these safeguards, but not whether they operated during the specific
clinical encounter. Investigators would need to determine what clinical information was available to
the device, whether the required checks were performed, whether the device identified uncertainty
or missing information, and whether it appropriately abstained, requested clarification, or generated
a recommendation despite those limitations.
With runtime evidence captured for every required model invocation and control event within the
defined boundary, investigators could examine which safety controls were expected to apply,
whether they were evaluated, their recorded results, and whether the device generated a
recommendation, abstained, or escalated for clinician review. The evidence could also identify the
observed model and configuration, relevant inputs and outputs or secure references to them, and
any gaps in capture. Tamper-evident records would allow independent verification of what the
system recorded rather than relying solely on retrospective manufacturer reports.
Assessed with validated instrumentation and retained source evidence, these records would support
investigation of which safeguards were invoked, what they reported, and what actions followed.
They would not, by themselves, determine whether the available clinical information was adequate,
whether the treatment recommendation was clinically appropriate, or whether the clinician’s
subsequent decisions were reasonable. Those questions would require review of the clinical record
and clinical adjudication. The example illustrates a proposed evidence design; it does not report
measured clinical performance or establish clinical safety on its own.

Cadence and triggering events
For GenAI-enabled devices, defined triggering events may matter as much as scheduled review.
Potential triggers include the following.
• A change to the foundation model version or provider
• A change to the system prompt, retrieval sources, tools, guardrails, or other production
configuration
• Behavioral drift beyond prespecified thresholds
• A runtime safety control failure rate above a prespecified threshold
• Deployment into a materially different site, specialty, population, workflow, or language
• A meaningful increase in complaints, adverse events, overrides, or corrections
• A publicly disclosed vulnerability or safety issue affecting the model or another component
• A change in the applicable clinical standard or intended use
Recording or monitoring outages should also trigger a defined response, including a tested fallback
appropriate to the clinical risk. The frequency and depth of reassessment should be proportionate to

Glacis Technologies | FDA-2026-N-7874 | 7
risk, degree of autonomy, and the severity and detectability of potential failures. A single fixed
cadence would not fit all devices.

Question 20 Machine-based supervisory agents
Machine-based supervisors can make parts of postmarket monitoring practical at scale. Two kinds
should be distinguished.
Deterministic checks apply fixed rules, such as confirming that required inputs are present or that an
action falls within the device's permitted scope. Their correctness can be tested directly, and their
results can be recorded for each interaction.
Model-based supervisors, including LLMs that score output quality, need their own evaluation. We
suggest the following.
• Validate the supervisor against independent human adjudication using representative cases and
sufficient examples of consequential failures. Report sensitivity for high-severity failure modes,
false-alarm rates, predictive value where estimable, detection delay, and uncertainty. Overall
agreement alone is insufficient when failures are rare.
• Apply the paper's adjudicator independence principle. A supervisor built on the same foundation
model may share its blind spots. Different models can also share training data or failure modes,
so different model provenance alone does not establish independent judgment.
• Assess changes to the supervisor's model, prompts, or thresholds as changes to the monitoring
program, with revalidation proportionate to their expected effects.
• Record the supervisor's determinations, version, and configuration with the same integrity as the
device's own records.
• Have human reviewers audit a sample of the supervisor's decisions on an ongoing basis,
including cases it passed, to estimate how often it misses problems.
Evaluate the consequences of both missed errors and unnecessary interruption, including delayed
care and alert fatigue. Test the response to supervisor failure, unavailability, and bypass. Highseverity failure modes should have safeguards appropriate to the clinical setting, including effective
human review where needed; a model-based supervisor should not be treated as sufficient
protection merely because it agrees with the primary system.

Question 21 Stakeholder roles without diffusing manufacturer accountability
The manufacturer should remain accountable for the device, including the behavior of any third-party
model components it incorporates. Deploying organizations often control part of the configuration
and the clinical workflow around the device. Accountability stays clear when labeling states which
safeguards the manufacturer provides and which the deploying organization must configure, and
when the deploying organization records its configuration choices and approvals.
A common operational record can reduce inconsistent reporting and help the manufacturer,
deploying organization, independent assessors, and FDA act within their roles. It does not settle
every factual dispute or transfer accountability. Professional societies can define specialty-specific
rubrics and supply qualified adjudicators. Standards development organizations can develop test
methods and open evidence formats for consideration by FDA, supporting consistency without
privileging particular vendors.

Glacis Technologies | FDA-2026-N-7874 | 8
Questions 22 to 24 Modifications and third-party foundation model changes
Scaling re-evaluation to the change (Question 22). The benchmarking elements in Section V.B
offer a structure for mapping a change to the capabilities it could affect. [1] The scope of reevaluation should follow a documented impact analysis covering clinical performance, latency,
reliability, cybersecurity, and workflow effects. A bounded change may justify focused regression
testing; broad re-benchmarking is warranted where its effects cannot be bounded. Model, prompt,
retrieval, tool, guardrail, and orchestration changes should not be treated as documentation-only
changes by default. Infrastructure changes also require assessment, even when nominal model
inputs and outputs are unchanged. The manufacturer should determine the applicable regulatory
steps under the device-change framework and any authorized PCCP.
PCCPs when future changes cannot be fully prespecified (Question 23). FDA's current PCCP
guidance organizes plans around a Description of Modifications, a Modification Protocol, and an
Impact Assessment. [6] For GenAI-enabled devices, FDA could consider bounded classes of future
modifications, with defined affected components, intended use, performance limits, and excluded
changes. An example might be a version update within a specified foundation-model family, where
its effects can be evaluated under the authorized plan. The protocol would define the evidence
required, acceptance criteria, rollout and monitoring procedures, and the response if a change fails
evaluation. Prespecifying a method alone should not authorize an undefined range of modifications.
Changes outside the authorized scope require assessment under the applicable device-change
framework.
Third-party foundation model changes (Question 24). Manufacturers may not control, or receive
timely notice of, changes to an underlying foundation model. Such changes should be evaluated for
their effects on the device. Where a change falls outside an authorized PCCP, it should be assessed
under FDA's existing framework for device changes, as a manufacturer-initiated change would be.
The contractual, technical, and PCCP mechanisms the paper names can be combined.
• Contractual. Version pinning where the provider supports it, advance notice of changes and
deprecations, and access to change logs. These overlap with the update notification
commitments the paper lists as possible Foundation Model MAF content.
• Technical. Record the provider-reported model identifier on each captured interaction, with
capture coverage disclosed. Run the production configuration against a fixed reference set of
inputs on a schedule and after any notice of change. A provider can change the model behind an
unchanged name or alias, so identifiers alone are not sufficient. Keep safety controls that do not
depend on the model in place, so they continue to operate if a change goes undetected.
• PCCP. Prespecify the response to a detected change, such as holding or restricting the affected
function, re-benchmarking the production configuration, and resuming only if acceptance criteria
are met.
For example, a provider may update a hosted model without changing the name the device calls.
Scheduled reference testing may reveal a material behavioral change, but a passing test does not
establish that no update occurred. Records should distinguish the last known baseline, the time a
change was detected, and uncertainty about when it began. The authorized PCCP or other
applicable change-control process should define the response, including restrictions or additional
evaluation where the uncertainty is clinically significant.

Question 26 Agentic GenAI-enabled devices
Agentic devices can increase the consequences of error by acting across several steps and, in
some workflows, with fewer points of human review. We suggest four additional considerations.

Glacis Technologies | FDA-2026-N-7874 | 9
1. Evaluate action sequences. Acceptance criteria should apply to sequences of actions as well
as to single outputs, consistent with the paper's approach to multi-turn conversations.
2. Enforce checkpoints outside the model. Benchmark element A.1 includes compliance with
human-oversight checkpoints before irreversible or high-consequence actions. A control outside
the model should enforce those checkpoints, so that a required checkpoint does not depend
solely on the model correctly judging its own scope. The enforcement mechanism should itself
be tested for bypass and failure.
3. Record each consequential action. The postmarket record should show the authority under
which the agent acted, the result of the scope check, whether human approval was required and
obtained, the tool called and its observed result, and the model and configuration identifiers.
Distinguish attempted actions, permissions, and observed completion.
4. Treat tool outputs and retrieved content as untrusted inputs. Records should identify the
tool outputs or retrieved sources made available to the agent, with access to relevant content
under appropriate privacy controls, so that prompt injection and erroneous tool outputs can be
investigated.
These records should support post-incident investigation of the authority granted, recorded checks,
required approvals, and observed actions. Their interpretation depends on validated instrumentation
and stated capture limits. The oversight plan should also address cumulative effects across a
sequence and the consequences of interrupting or failing to complete an action.

Conclusion
GenAI-enabled devices increase the importance of postmarket methods that address variable
outputs, changes in clinical context, and updates to components outside the manufacturer's direct
control. Periodic validation and aggregate summaries cannot, on their own, reconstruct how a device
behaved in a specific case.
For higher-risk uses, the postmarket record should support investigation of the system configuration,
applicable safeguards, recorded outcomes, and response to failures. Explicit capture limits and
appropriate clinical review make that evidence more useful. We encourage CDRH to include these
capabilities in any approach that accepts greater premarket uncertainty in exchange for postmarket
monitoring.
We would be glad to provide more detail on any of these points.
Respectfully submitted,
Joseph T. Braidwood
Co-Founder and Chief Executive Officer
Glacis Technologies, Inc.
Jennifer C. Shannon, MD
Co-Founder and Chief Medical Officer
Glacis Technologies, Inc.

Glacis Technologies | FDA-2026-N-7874 | 10
References
[1] U.S. Food and Drug Administration. Considerations for the Regulation of Generative AI-Enabled Medical
Devices: Discussion Paper and Request for Feedback. August 2026.
https://www.fda.gov/media/194242/download
[2] Utah Department of Commerce, Office of Artificial Intelligence Policy. Third-Party Evaluators. Reviewed October
18, 2026. https://commerce.utah.gov/ai/third-party-evaluators/

[3] OVERT. Governance and Stewardship. Public charter, reviewed October 18, 2026.
https://overt.is/governance
[4] U.S. Food and Drug Administration. Qualification of Medical Device Development Tools. Final guidance, July
2023. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/qualificationmedical-device-development-tools
[5] U.S. Food and Drug Administration. Accreditation Scheme for Conformity Assessment (ASCA). Program scope
and participation information, reviewed October 18, 2026. https://www.fda.gov/medical-devices/divisionstandards-and-conformity-assessment/accreditation-scheme-conformity-assessment-asca
[6] U.S. Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change
Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final guidance issued August 18, 2025.
https://www.fda.gov/media/166704/download

Glacis Technologies | FDA-2026-N-7874 | 11