Any Biosignal, Inc. (Stephen R. Saine)

AnyBio builds infrastructure that sits between a model and a patient. This comment answers questions 24, 25, 18, 20 and 7 from operating experience on synthetic programs. In short: a manufacturer can detect, evaluate and respond to foundation-model changes only if every patient-facing output records the policy version, the model version and the decision; a PCCP should name the model pin, the re-benchmark trigger and the constraint that the generative component converses but does not alter fixed clinical logic; a Foundation Model MAF is useful if it carries version retention commitments, change notices and the vendor’s usage terms; postmarket reliance is justified only on per-output records, with an observe phase as the bridge; supervisory agents must be pinned and benchmarked like the device and never be the only check; and benchmarks belong in the deployed configuration. Full comment attached.

ANY BIOSIGNAL, INC.
2261 Market Street STE 86985
San Francisco, CA 94114

Comment in Response to Discussion Paper and Request for
Feedback
Considerations for the Regulation of Generative AI-Enabled Medical Devices
Docket No. FDA-2026-N-7874 Submitted by Any Biosignal, Inc.
Date: October 19, 2026

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

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

Dear Dockets Management Staff and CDRH colleagues:
AnyBio builds infrastructure that sits between a model and a patient: home and clinical devices connect to
one record, a clinic's protocol runs as configuration rather than code, and every message an AI system
produces for a patient passes a policy check before it is delivered. We are not a device manufacturer and we
author no clinical model. We run these controls today on synthetic programs and in sandboxes. This
comment answers questions 24, 25, 18, 20 and 7 from that operating experience and leaves the others to
those better placed to answer them.

1. Summary of Positions
• A manufacturer can detect, evaluate and respond to a foundation-model change only if every patientfacing output records the policy version that evaluated it, the model version that produced it, and the
decision with its reasons (Question 24).
• A predetermined change control plan for a generative component should name the model pin, the rebenchmark trigger, and the constraint that the generative component converses but does not alter fixed
clinical logic (Question 24).
• A voluntary Foundation Model Master File is useful if it carries version retention commitments, update
notices with lead time, and the vendor’s usage terms as they bear on medical use; a sponsor-side
disclosure requirement would give vendors a reason to file (Question 25).
• Greater reliance on postmarket monitoring is justified only on per-output records, never on aggregate
telemetry alone; an observe phase is the practical bridge between benchmarking and clinical
confirmation (Question 18).
• Machine-based supervisory agents belong as a second tier, pinned and benchmarked like the device, and
never as the sole gate for a safety-critical screen (Question 20).
• Benchmarks belong in the deployed configuration, including the deterministic layer and the human
review step (Question 7).

Any Biosignal, Inc. — Comment to Docket No. FDA-2026-N-7874 Page 1 of 4
2. Responses to Specific Discussion Questions
2.1 Question 24. How can a manufacturer detect, evaluate and respond to changes a third-party
foundation model developer initiates, and what contractual, technical or PCCP mechanisms give
reasonable assurance?
Detection, evaluation and response all rest on one technical mechanism: a record written at the moment each
patient-facing output is produced, holding the version of the device's policy that evaluated it, the model and
model version that produced it, and the decision with its reasons. With that record a vendor change is
detectable by re-running a fixed input suite against the version named in the record and comparing.
Evaluation is the comparison, scored against the same capabilities the device was benchmarked on.
Response is a setting the manufacturer already controls: the governance layer can hold outputs for human
review, or fall back to observe mode, while the re-benchmark runs.
Three mechanisms follow, one of each kind the question names.
Technical. A deterministic layer, authored by the clinical owner, should run before any model sees an input
and after any model produces an output: red-flag phrases, prohibited claims and scope fences are matters of
the owner's words, and a model's judgment about them should never be the only check. That layer does not
change when the vendor changes the model, which is why it is the right place for the safety-critical screen. A
change the vendor makes without changing the version identifier, which does happen, is caught by the fixed
suite rather than by notice.
PCCP. The plan should name the model pin explicitly: vendor, model, and the version or snapshot identifier
the device was benchmarked against. A change to the pin, whoever initiates it, is the trigger for rebenchmarking under the plan. The plan should also state the boundedness of the generative component as a
design constraint it preserves: the component may converse with the patient but may not alter the fixed
clinical logic, which is validated separately and is what the device's claims rest on. The first cleared patientfacing large language model device used this structure, and in our experience it is what makes the vendorchange question tractable. When the logic that matters is fixed and separately tested, a change to the
conversational component is a bounded question about tone, scope and safety behaviors rather than an open
question about clinical performance.
Contractual. Two commitments from the vendor make the technical mechanism work: that a pinned version
remains callable for a stated period after a newer one ships, and that behavior-relevant changes arrive with
notice and lead time. We address both under question 25.

2.2 Question 25. Would voluntary Foundation Model MAFs be practical and useful, what should
they contain, and are there alternatives?
Three contents, in order of importance, one of which the paper's footnote already lists. A version retention
commitment: how long a pinned version remains callable after a newer one ships. Re-runnable evidence is
only re-runnable if the version is still there; without this commitment a master file is a brochure. Update
notification commitments with lead time, describing behavior-relevant changes such as training cut-off,
safety tuning and system-level filters, so a manufacturer can schedule re-benchmarking rather than discover
drift. And the vendor's usage terms as they bear on medical use. Those terms now carry duties of their own.
One major vendor's policy, effective 12 November 2026, requires that a qualified person review any
medical recommendation the model produces before it is delivered to an individual, and that the individual
be told AI was used. A reviewer of a device submission should be able to see that the device's design
satisfies the conditions the model vendor itself imposes, and the master file is the natural place for those
conditions to be stated once.

Any Biosignal, Inc. — Comment to Docket No. FDA-2026-N-7874 Page 2 of 4
On incentive and practicality: vendors already publish model cards, system cards and usage policies; a
master file that references those documents by version costs little to keep current. The alternative
mechanism is sponsor-side. A submission for a device built on a third-party model should state the model
pin, the retention and notice terms the sponsor holds by contract, and the re-benchmark trigger. If sponsors
must state it, vendors will have a reason to file it.

2.3 Question 18. Under what conditions might greater reliance on postmarket monitoring justify
reduced premarket evidence, and what must the monitoring program have?
We support the shift, on one condition: postmarket evidence must be a record of individual outputs, not
aggregate telemetry. The minimum record for a patient-facing output is what was proposed, what the
deterministic and model stages decided and why, whether it was held, who released it and in what role, what
the patient actually received, and whether the AI-identity disclosure had been delivered to that patient.
Every useful aggregate derives from that record: messages held, held messages released unchanged, false
holds, misses, overrides. Aggregates reported without the record beneath them cannot be audited and should
not count as evidence.
We also suggest the agency recognize an observe phase as a bridge between device benchmarking and
clinical confirmation. A governance layer can run on real traffic in observe mode, recording what it would
have held without changing anything the patient sees, for a defined period before enforcement begins. The
result is a pre-deployment estimate of the device's behavior in its real population, produced with no change
to care. We run this on synthetic programs today and believe it is the most practical form of early postmarket
evidence available for conversational devices.
Where the approach is not appropriate: outputs that act without a human path at high consequence. The
record and the observe phase presume that a held output reaches a person who can decide. Where no such
path exists, premarket evidence should not be reduced.

2.4 Question 20. Can postmarket monitoring be facilitated by machine-based supervisory agents,
and what about the supervisory agent itself?
Yes, as a second tier and never the only one. A supervisory model that screens outputs is itself a model: it
should be pinned, benchmarked on the same fixed suite, and recorded on every decision by version, exactly
as the device's generative component is. Its disagreements with the deterministic layer are the most useful
signal it produces, and they belong in the record. A supervisory agent that can be the sole gate for a safetycritical screen is a second device without a submission; a supervisory agent that ranks items for human
review adds evidence without adding an unreviewed decision.

2.5 Question 7. Is the competency-based approach appropriate?
Yes, with one caution the paper already anticipates. Competency of the model is not competency of the
device. Benchmarks should be run in the deployed configuration, including the deterministic layer and the
human review step, because those are what the patient encounters. We also agree with the paper's position
that a "talk to your doctor" disclaimer does not move action-directing output back to non-directive. In our
experience a disclaimer changes nothing about the lane an output is in; a hold for a person does.
We would be glad to share the record schema and the synthetic program artifacts described above with
Center staff.

Any Biosignal, Inc. — Comment to Docket No. FDA-2026-N-7874 Page 3 of 4
3. About Any Biosignal, Inc.
Any Biosignal, Inc. ("AnyBio") is a San Francisco company that builds governed data and AI infrastructure
for care between visits: home and clinical devices connect to one record with provenance on every value, a
clinic’s protocol runs as versioned configuration, and every message an AI system produces for a patient is
checked against the organization’s policy before it is delivered, held for a qualified person when the policy
requires it, disclosed as AI, and kept on a record a reviewer can read. AnyBio is not a device manufacturer
and authors no clinical model. The company is SOC 2 Type II attested and operates under HIPAA business
associate agreements with its model providers under zero-data-retention terms.

Respectfully submitted,

Stephen R. Saine
Founder and Chief Executive Officer
Any Biosignal, Inc.
stephen@anybiosignal.com

Submitted electronically to https://www.regulations.gov under Docket No. FDA-2026-N-7874.

Any Biosignal, Inc. — Comment to Docket No. FDA-2026-N-7874 Page 4 of 4