Stuyvenberg Advisory Group (Jessica Stuyvenberg)

Docket: FDA-2026-N-7874 Re: Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback Submitted by: Jessica Stuyvenberg, Stuyvenberg Advisory Group, jessica@stuyvenbergadvisorygroup.com

Thank you for seeking input at this stage. I responded to Questions 1, 19, 20, 23, and 24.

I advise eClinical and clinical AI companies and am the author of ARCH (Adaptive Regulatory Compliance and Human Oversight), a field-level implementation specification for anchoring AI compliance evidence inside CDISC’s Unified Study Definitions Model (https://doi.org/10.5281/zenodo.20262730). ARCH was developed for AI in clinical trial data pipelines. Several of the problems the discussion paper raises have direct analogues there, and each response below describes how ARCH handles them.

Question 1: Additional risk dimensions (traceability)

ARCH treats traceability as a property of each individual output, not of the session or device. Every proof certificate is bound to the unique identifier of the specific object being governed, never to a parent container. The certificate records which data elements were checked, by identifier and version; the exact input data submitted for evaluation; and the specific rule applied, cited by name and version. A problem can be traced to the exact output, and review limited to the outputs it affects.

Question 19: Postmarket performance evaluation, triggers for reassessment

ARCH defines in advance the events that invalidate an existing verification record and require re-verification. There are eight: edits to a draft; formal amendments after approval; model weight changes outside a formal change control plan; updates to the jurisdiction-specific ruleset; drift threshold breaches; continuous learning updates; changes to the sponsor’s risk configuration; and changes to training or test datasets or quality-system documentation.

The response is scaled to risk tier. For HIGH and MODERATE risk outputs, the prior record is superseded immediately and re-verification is mandatory. For LOW and MINOR risk outputs, re-verification may run asynchronously in the background, which avoids alert fatigue.

Question 20: Machine-based supervisory agents

ARCH uses no generative model at the verification step. Its first gate evaluates outputs deterministically against versioned, machine-readable regulatory rulesets. Its second uses a formal theorem prover to produce proofs of structural properties, not probabilistic assessments. Risk classification is assigned deterministically by the orchestration engine, based on the identity of the object and the sponsor’s risk plan.

The second gate proves structure only and explicitly makes no claim about clinical appropriateness. Human attestation is a separate third gate. For HIGH and MODERATE risk outputs, the schema prevents automated substitution for human review. Automated substitution is permitted only for LOW and MINOR risk outputs with a valid sponsor delegation record. When automated remediation cannot resolve a failure, or a human reviewer does not respond within a defined window, ARCH escalates and pauses the affected workflow. Failures are never silently ignored.

Question 23: Change control for model updates

ARCH’s first gate evaluates whether a proposed continuous-learning update stays within the boundaries of an authorized change control plan. If the update exceeds those bounds, a flag is set and deployment is hard-blocked pending a new regulatory submission. The evaluation is recorded together with a hash of the model and the identifier and hash of the modification protocol it was evaluated against, so the record shows which model ran under which authorized rules. The modification protocol is ingested at evaluation time rather than hardcoded, so the same mechanism applies across different sponsors’ protocols.

ARCH identifies a standardized, machine-readable schema for encoding modification protocols as a critical target for future standards development.

Question 24: Third-party foundation model changes

Each ARCH verification record carries a cryptographic hash of the model that generated the output. A change to the model’s weights is one of the eight events that supersedes the existing record and triggers re-verification of the outputs that relied on the prior model. For LOW and MINOR risk outputs, re-verification may run in the background. Superseded records are never deleted. They stay permanently linked to the new record, so it is always possible to determine which outputs were generated under which model version.

This mechanism depends on being able to fingerprint the model version. The paper does not address models operated by a third party.

I would be glad to provide further detail on any of the above.

Jessica Stuyvenberg Stuyvenberg Advisory Group