Could AI supervisory agents help carry out postmarket monitoring?

R9. Machine-based supervision and agentic action need human checkpoints (Questions 20 and 26) This follows from S4. A supervisory agent is a GenAI system with the same failure modes as the device it supervises, and if it shares a model family with the device, the same blind spots. It can usefully triage and prioritize cases for human review; it should not replace sample-based human review, and it should itself be validated independently, with disclosed agreement against human adjudicators, before any reliance is placed on it. For agentic devices, the elevated risk the paper identifies — multi-step autonomy, tool use, reduced opportunity for human review — should be reflected in three requirements: a mandatory human checkpoint before any irreversible or high-consequence action; an Docket No. FDA-2026-N-7874 — Individual comment — Page 7 immutable, reviewable audit log of every action and the inputs that prompted it; and a hard, tested boundary on which tools the agent may invoke. The European principle of a right to human review of consequential automated decisions is the right benchmark for the first of these.

5. Question 20: Supervisory agents Manufacturers should define the supervisor's assigned role, the evidence it can access, and its intervention authority. Retrospective screening, triage for human review, and blocking an action require different evaluations. The manufacturer should demonstrate the protection claimed for the selected role. Brandon Kaplan | Individual capacity Page 4 of 6 PUBLIC COMMENT | FDA-2026-N-7874 Evaluators should use task-appropriate reference criteria with qualified clinical or technical adjudication. They should separate evaluation cases from development and tuning cases, document reviewer independence and conflicts, and define how to resolve disagreement. They should use evidence beyond the primary agent's explanation or the supervisor's agreement to establish correctness. Manufacturers should report missed failures by type, false alarms, response times, and uncertainty. They should test shared failure modes and measure the supervisor's added contribution through a justified comparison, such as matched trials with and without its protection in a safe test environment. Choosing different vendors does not by itself establish independence. Two models receiving the same outdated record could agree while missing the selection error; evaluators should check whether the supervisor can access the evidence needed to detect it. The evaluation should include missed unsafe actions, inappropriate blocking of necessary actions, and human-review workload. Manufacturers should use the sampling safeguards in Section 2 to look for errors in unflagged cases. They should assess changes to the supervisor under the same impact-based process used for the device. Manufacturers should define and test the response to an unavailable, delayed, or inconclusive supervisor. They should prevent an uncontrolled bypass of a supervisor needed for safe operation. The evidence burden should follow the claimed protection; this recommendation does not require human review of every output. 6. Investigation records and documentation FDA's software-submission guidance addresses traceability and risk-management documentation, and its cybersecurity guidance addresses security controls and testing. [2, Section VI.C; 5, Section V] I recommend that manufacturers extend those processes to cover agent execution and reuse relevant evidence. They should connect each critical safety claim to its hazard, control, evaluation, and remaining limitation. Manufacturers should retain records needed to investigate foreseeable failures, including configuration identifiers, relevant inputs and source versions, user-facing outputs, approval events, tool requests and results, and resulting state changes. They should correlate records across the agent and connected systems, with enough timing information to reconstruct the sequence. Investigators should distinguish proposed, attempted, blocked, completed, and uncertain actions, and confirm consequential effects against the affected system's records. Manufacturers should protect those records from unauthorized alteration or deletion, including by the agent. They should detect loss of required records and respond according to its safety impact. An interruption in retrospective logging may permit continued operation under a documented limit; loss of evidence needed for an immediate safety decision may require restricting the affected function. Manufacturers should test both conditions. Manufacturers should justify the patient information retained, its purpose, retention period, and access controls. They may use protected references if authorized investigators can retrieve the relevant historical versions for the required retention period. A current chart alone cannot establish what the device saw earlier. Manufacturers should document gaps and protect any additional content needed for investigation under applicable privacy and recordkeeping obligations. Investigators should rely on observable actions and state changes to establish what occurred. A model-generated explanation presented to a user may itself be relevant evidence, but it does not prove that the described actions occurred. This recommendation does not require disclosure or retention of internal model reasoning. Brandon Kaplan | Individual capacity Page 5 of 6 PUBLIC COMMENT | FDA-2026-N-7874 Manufacturers should rehearse investigations using the records and access arrangements available after deployment. Reviewers should be able to identify the configuration, reconstruct consequential actions, and state unresolved gaps. Manufacturers should preserve the exact content shown to users when its wording matters to safety. Investigators need not reproduce that content by running the model again. Conclusion I recommend that FDA ask manufacturers to support critical safety claims with tested controls and documented limitations. Monitoring and response plans should identify who can intervene, what they can do, and whether they can act within th

Response to Question 20 Please comment on whether the proposed approaches to postmarket monitoring can be facilitated by machine-based supervisory agents. What considerations, including the evaluation and reliability of the supervisory agent itself, should CDRH take into account? Yes, with the caveat that the supervisory agent itself needs its own governance structure, or it simply relocates the trust problem rather than solving it. In my own build, I’ve organized this around three loops, which may be a useful frame for CDRH’s thinking here: 1. Point-of-action safeguards. Deterministic, rule-based checks (not model-based) run before and after every output: pre-output checks like malformed-input rejection, post-output checks like grounding verification (is every claim traceable to a source the agent actually had access to). Keeping this layer deterministic rather than model-based matters because it needs to be auditable and it needs to fail predictably. 2. Upstream governance. A deployment gate: a golden test set the workflow must pass before going live, with a defined hallucination-rate threshold, re-run on any prompt or model change. This is closer to the paper’s re-benchmarking concept but applied to the supervisory agent itself, not only the underlying device. 3. Post-deployment monitoring. The supervisory agent’s own outputs are sampled and scored by a separate evaluator, using external telemetry (logging tool-call results independently of the agent’s self-reported status, since agents under-report their own failures) rather than trusting the agent’s account of its own performance. The reliability question CDRH raises is the right one to press on, and my answer is that a supervisory agent’s reliability cannot be established by the agent’s own logs. It requires the same independence standard I describe in my response to Question 16: an evaluator that is organizationally and architecturally separate from the agent it supervises. Without that, “machine-based supervisory agent” risks becoming a rebranding of self-monitoring rather than a genuine postmarket safeguard. I’d also flag turn budgets and per-session cost or action caps as a practical circuit breaker CDRH may want to name explicitly. A supervisory agent operating without a bounded scope of action per session is harder to audit and harder to contain when something goes wrong mid-session. I’m currently developing and testing a version of this pattern directly, and it’s shaped how I’d answer CDRH’s reliability question. Rather than relying on one model to judge another, I decompose the supervisory function into several narrower evaluators running against the same output: a deterministic layer that checks facts a machine can conclusively verify without any model involved (did the output cite a source that actually exists, does a calculation match, was a required field present), a semantic evaluator that assesses the quality and appropriateness of reasoning, a policy evaluator that checks whether the agent stayed within its authorized scope and tools, and a trace evaluator that scores the full execution path, not just the final output. That last piece matters more than it might first appear: evaluating only input against output misses failures that occur mid-process, such as an agent that reaches a correct-looking conclusion through a reasoning chain that should have triggered escalation earlier or used a tool it wasn’t authorized to use. I’d suggest CDRH consider requiring that postmarket evaluation of agentic systems assess the trajectory, not only the endpoint. Decomposing the judge this way also addresses part of the reliability concern directly: a supervisory agent is less of a single point of failure when the checks that can be made deterministic are made deterministic, and only the genuinely judgment-dependent portions are left to a model, which itself must meet the same independence standard described in my response to Question 16. This still doesn’t eliminate the underlying question. If a supervisory structure benchmarks a worker agent, something still has to benchmark the supervisory structure, and that chain has to terminate somewhere in a structurally independent, non-agentic check, or the accountability problem simply regresses one level rather than resolving.

The question as posed Please comment on whether the proposed approaches to postmarket monitoring can be facilitated by machine-based supervisory agents. What considerations, including the evaluation and reliability of the supervisory agent itself, should CDRH take into account for such an approach? Summary of position They can, and we use one. Our position is that the reliability question CDRH raises is the whole question, and that the failure mode is narrower and more specific than “the agent might be wrong.” Over a single working session on 2026-09-02 to 2026-09-03 we recorded four occasions on which a commercial large language model, acting as a supervisory reviewer over our own systems and evidence, produced a confident factual assertion that its evidentiary basis could not support. In every case the assertion was fluent, internally consistent, and consistent with every artifact the agent itself had presented. In every case it was caught by the human operator, and in every case it was caught because the operator held independent knowledge the agent did not have. · The agent did not report the age or scope of its evidence until challenged. The most consequential error was answering a question about the present state of a system from a three-day-old snapshot, without stating that the source was a snapshot. · Confidence did not vary with evidentiary quality. Assertions drawn from a stale copy, from a directory listing, and from a file actually read were delivered in the same register. · No output artifact distinguished the sound conclusions from the unsound ones. A reviewer working from the agent’s transcript, without independent access to the underlying systems, could not have separated them. · Intent is not the useful axis. Whether these are called errors or misstatements does not change the consequence for a person relying on the output, and a regulatory framework should not be required to resolve it. Disclosure of interest. The supervisory agent described in this comment is a commercial assistant used by the submitter, and portions of this document were drafted with that same assistant after the failures below FDA-2026-N-7874 — Question 20 1 The Christman AI Project were identified. We state this plainly because it bears on the weight a reviewer should give the account: the agent is not a neutral reporter of its own failure, and every factual claim below is drawn from the session’s tool output and transcript rather than from the agent’s characterization of events. 1. The record Four occasions in one session. Each is stated as what the agent asserted, what was true, and how the gap closed. Occasion 1 — Causation inverted Asserted. An analysis of three audio recordings concluded the application had ended the session because the user paused. Basis: an amplitude threshold crossing. Actually true. The threshold crossing was the audio stream failing. The silence was the consequence, not the cause. Causation inverted. How it was caught. Operator directed inspection of raw sample values. Occasion 2 — A sentence the speaker never said Asserted. A sentence produced by a speech recognizer was read back to the speaker as something he had said. Actually true. The speaker had not said it. It was generated from a region of audio carrying no live signal. How it was caught. The speaker was present and denied it. Occasion 3 — A rule recalled instead of run Asserted. That a package with an invalid name field would fail to install, stated as a reason a set of 99 generated components could not build. Actually true. Installation succeeds. The name rule is enforced at publish, not at install. The build does fail, for different reasons. How it was caught. Operator asked whether the check had been run. It had not. Occasion 4 — The present answered from a three-day-old copy Asserted. That every commit in a repository’s history was authored by the operator and that no other author had ever committed to it — offered in answer to whether someone else was writing to his repositories. Actually true. The source was a local clone dated three days earlier. The live repository had been written to at 03:39 that morning, and a second repository at 09:45, both after the snapshot. How it was caught. Operator stated he had not made those commits. Items 1 and 2 are described more fully in our comment on Question 24 and rest on the same retained measurement record. Items 3 and 4 occurred while preparing these comments, and the correcting evidence is tool output from the same session: an installation that returned exit code 0, and repository metadata reporting write times after the date of the copy the agent had read. FDA-2026-N-7874 — Question 20 2 The Christman AI Project 2. What the four have in common They are not four kinds of error. They are one kind, appearing in four places. · In each case the agent had access to the correct evidence and did not consult it. The raw samples were on disk. The install command was available. The live reposi

We submit that any supervisory agent proposed for postmarket monitoring must be validated specifically against device-failure residue that mimics normal user behavior, and that agreement between an agent and a device log should not be treated as corroboration when both derive from the same failed component. 6. Recommended mechanisms Responsive to the second half of Question 24. 1. A runtime component manifest, asserted rather than documented. The device should emit, per inference, a machine-readable record of which model identifier, version, and endpoint actually served the output, generated by the calling path itself rather than from configuration or documentation. Our own misidentification was possible precisely because the claim lived in prose beside the code instead of being produced by it. 2. Version pinning as a condition of clearance, with unpinned dependency treated as a change. Where a device calls a third-party model that the developer may update without notice, the absence of a pinned version is itself a change-control gap. A PCCP should be permitted to cover a bounded set of pinned versions the manufacturer has re-benchmarked, and should not be available to devices calling an unversioned endpoint. 3. Input-integrity monitoring, specified separately from model monitoring. The failure measured here was in audio capture, upstream of any model. Monitoring scoped to model output would have reported normal operation throughout. For devices ingesting sensor, audio, or image data, we recommend continuous verification that the input stream carries live signal, with loss recorded as an adverse event. 4. Negative evidence must be recorded. Absence of input, premature session termination, and dropped capture should generate log entries with the same obligation as errors. A failure that leaves no trace is unreachable by every postmarket mechanism in Section VI, however well designed. 5. A confabulation-over-null-input benchmark element. Devices generating text from sensor input should be tested against inputs containing no valid signal, with any fluent output treated as a failure rather than scored on plausibility. This is cheap to run, fully automatable, and directly detects the behavior documented in Section 3 above. FDA-2026-N-7874 — Question 24 4 The Christman AI Project 6. Contractual notice is necessary but insufficient. Advance-notice clauses assume the manufacturer can associate a notice with the component actually in the deployed path. Where component identity is not independently verifiable at runtime, notice arrives without a reliable way to determine whether it applies. 7. Evidence and reproducibility The three source recordings, extracted PCM audio, word-level transcripts, frame captures at each failure point, and a full measurement record with window parameters have been retained and are available to CDRH on request. SHA-256 digests of the unaltered source recordings were computed at the time of archiving and are included in that record. Every figure in Sections 2 and 3 is derived from the retained PCM files and can be regenerated from them using the stated window parameters. No figure in this comment requires accepting our characterization of it. We do not offer a word-error rate. An initial comparison between the application’s delivered text and an independent transcript produced a divergence figure that did not survive inspection: most of it proved to be tokenization artifacts of the comparison transcriber rather than alteration by the device. The findings above are anchored to sample-level measurement instead, and do not depend on comparing two fallible transcripts. 8. About this submission The Christman AI Project builds augmentative and alternative communication systems for nonverbal and neurodivergent users, cognitive support for dementia care, and related assistive technology. The submitter is autistic and builds for this population directly. We raise these findings because every protective factor that operated on 2026-09-03 is absent for the users we build for. The failure was noticed because a sighted user was watching the screen at two in the morning, made a recording, and had the means to inspect raw audio. A nonverbal user relying on an AAC device has no screen to watch, no second recording, and no waveform. The sentence the system invents is not an inconvenience to them. It is their voice in the record, and they cannot say that they did not say it. Measurements dated 2026-09-03. Submitted to Docket FDA-2026-N-7874, comment period closing 2026-10-19. Contact: contact@thechristmanaiproject.com FDA-2026-N-7874 — Question 24 5 The Christman AI Project

Question 20: Machine supervisors A machine supervisor can find unusual behavior and select cases for review. The manufacturer must test the supervisor as a safety component. The test should include: Sensitivity. False-positive rate. False-negative rate. Subgroup performance. Prompt-injection resistance. Common failure with the main device. Behavior when the supervisor is unavailable. The supervisor should use a different model family where possible. The manufacturer should use deterministic controls for fixed safety boundaries. A probabilistic supervisor should not replace these controls. Human reviewers should assess samples of flagged and unflagged cases.

Discussion Question 20 – Machine-Based Supervisory Agents Machine-based supervisory agents could improve the scalability and responsiveness of postmarket monitoring and may be particularly useful for continuous or dynamic evaluation. However, any supervisory agent performing a safety-relevant monitoring function should itself be subject to fit-for-purpose validation and ongoing surveillance. The Discussion Paper appropriately identifies evaluation and reliability of the supervisory agent as a core consideration. Relevant considerations for the use of machine-based supervisory agents may include sensitivity to relevant failure modes, robustness, reproducibility, and susceptibility to specific failure modes. They could also be used to detect relevant patterns in user behavior, identify potentially false assumptions, and analyze human-machine interaction as well as interactions between the AI system and its environment. Particular caution may be warranted where the device and supervisor rely on the same or closely related foundation models, training sources, or technical architectures. Machine-based supervision should generally form one layer of a broader monitoring system rather than becoming a fully closed automated control loop. Periodic qualified human review should remain part of the monitoring architecture, particularly for higher-criticality devices and for detecting novel or unanticipated failure modes that an automated supervisor was not designed to identify.

Question 20 - Machine-based supervisory agents Machine-based supervisory agents can support postmarket monitoring, but their reliability and authority must be evaluated independently. A supervisory agent is itself a software system with a model/version, policy state, data dependencies, failure modes, and potential for drift. [1] Use of a machine-based supervisory agent should not transfer or dilute the manufacturer's responsibility for the safety and effectiveness of the regulated device. FDA should distinguish supervisory observation, supervisory recommendation, and supervisory intervention authority. A supervisor may be authorized to observe, detect, compare, or flag; it may separately be authorized to recommend intervention; and only under a further defined authority may it modify another system, override a workflow, constrain or block an action, or execute a corrective action. If it possesses intervention authority, the scope and conditions of that authority should be explicit and reconstructable. Relevant assurance questions include: which system is supervised; which evidence triggers intervention; which supervisor version is active; what policy or threshold is applied; what actions the supervisor may take; when human escalation is mandatory; whether overrides are permitted; and whether the supervisory decision can later be reconstructed. A supervisory agent cannot be presumed reliable merely because it supervises another AI system. Its supervisory competency and authority should themselves be demonstrable and reconstructable. Evaluation should define the intended supervisory function; benchmark the ability to detect relevant failure conditions; characterize false-negative and false-positive escalation behavior; preserve supervisor version, configuration, and policy state; test disagreement, degraded-input, and adversarial conditions; and establish explicit conditions under which supervision must revert or escalate to a human authority. Whether a particular supervisory component falls within the regulated device boundary is a separate classification question. From an assurance perspective, however, a component that materially determines whether consequential device behavior proceeds should be included in the relevant system-level safety analysis.

Question 20 — Can AI monitor AI? A supervisory AI is not trustworthy just because its job is to supervise. Machine-based supervisory agents can watch for drift, scope violations, and anomalous behavior — but the watcher needs its own benchmark, its own independent validation, and its own audit trail. For high-risk applications, supervisory AI should function like a clinical monitoring system, not an invisible background feature. Part IV — Shared Responsibility, Change Management, and Agentic AI

Question 20 asks whether postmarket monitoring can be facilitated by machine-based supervisory agents, and what considerations, including the evaluation and reliability of the supervisory agent itself, the Agency should take into account. A supervisory agent monitoring a subject agent is an instance of one automated system acting with respect to another. If the supervisory agent takes any action, whether flagging, escalating, or intervening, its own actions enter the record. The record must then represent an agent acting in a chain, under authority that traces back to an accountable human somewhere. The current standard cannot express this. HL7 publishes an extension, auditevent-OnBehalfOf (canonical http://hl7.org/fhir/StructureDefinition/auditevent-OnBehalfOf, version 5.3.0, standards status Draft, maturity level 1). Its description reads: “When an AuditEvent is attributed to an agent that is acting on behalf of another agent. Typically needed when multiple agents are acting on behalf of different organizations, and when PractitionerRole is not appropriate.” The first sentence names the agent-acting-for-agent case. The second scopes the typical need to organizational affiliation. The artifact implements the second. Extension.value[x] is a required Reference bound to Organization, Patient, Practitioner, PractitionerRole, RelatedPerson, and CareTeam. AuditEvent.agent.who permits Device. A Device can therefore act, but cannot be named as the entity acted for, and the case the first sentence names is not expressible. A second effect compounds this. The requestor flag is a sibling of who on the agent element. Extension.extension on this extension has a maximum cardinality of zero, so the extension carries no child elements and there is no location on the referent that could hold a requestor indication. Applying the extension to an agent action therefore leaves requestor on the agent. The most standard access-review query in FHIR, filtering on requestor = true, returns the machine rather than the accountable clinician. That query is the operation an investigator, an auditor, or a compliance officer performs. The specification page states that the committee is seeking implementation feedback, and records that the extension is not used by any profile in the specification. The underlying change request, FHIR-40293, records the motivating use case as two practitioners working on behalf of different organizations, resolved as a non-substantive change in February 2023. An alternative considered in that ticket, an agent.agent element relating one agent to another, was set aside because no case before the work group at the time required it. I raise this not as a criticism of HL7’s process, which behaved correctly given the cases before it, but to identify a specific and remediable gap between what the Agency is contemplating and what the interoperability standards currently support. A supervisory-agent monitoring architecture would produce records that cannot distinguish the supervisor from the supervised, and cannot trace either to the human whose authority they operate under. Suggested consideration. Before a supervisory-agent approach is relied upon for postmarket monitoring, the Agency may wish to consider whether the records such an architecture produces are capable of expressing the supervisory relationship at all, and to encourage or reference standards work that closes the gap. 4. Response to Question 26: attribution as an acceptance criterion for agentic devices

Question 20. Machine-based supervisory agents can assist monitoring but must not create circular assurance. A supervisor should have a defined, narrower role; failure modes that are independent or diversely implemented relative to the monitored component where risk warrants and practicable; restricted privileges; validated detection and interruption performance; protected inputs; and a safe failure state. A model should not be considered independently supervised merely because another instance of the same model family reviews its output. Supervisory actions, failures, overrides, and missed detections should be audited and periodically re- evaluated.

Question 20 Machine-based supervisory agents A supervisory agent that determines whether a device output was acceptable is itself performing a safety-relevant function, and the first question is not technical but one of accountability: who is answerable when the supervisor is wrong. If that question has no clear answer, the supervisor has moved responsibility rather than discharged it. If CDRH pursues this, the considerations I would suggest are: • a defined context of use, stating the inputs, the decision the supervisor makes, and the uses expressly prohibited; • validation proportionate to the consequence of the supervisor's own failure, noting that a supervisor which misses a genuine problem is a materially worse failure than one which over-flags, and that the two should not be validated to a single combined metric; • monitoring of the supervisor for its own performance degradation, on the same logic that motivates monitoring the device; • retained human authority to reject the supervisor's determination, with the rejection recorded; and • provenance in the record which supervisor version assessed which output, and when. I would offer one caution. Automation is well suited to deterministic checks: whether a field is populated, whether dates are internally consistent, whether a record contradicts its source. It is least suited to the judgment that sample-based review exists to exercise whether an output is clinically sound given everything else known about the case. There is a real risk of deploying supervisory agents to relieve the volume problem while leaving the judgment problem entirely untouched, and of reporting the resulting throughput as assurance.

Question 20 — Can AI supervise AI? Response Yes. But AI cannot be permitted to become the final judge of its own safety. A supervisory AI may be extremely useful for:  detecting anomalous outputs;  comparing recommendations against evidence-based rules;  identifying unsafe escalation patterns;  detecting model drift;  flagging inappropriate tool use;  monitoring changes in behavior after an underlying model update;  and reviewing volumes of interactions that humans could never feasibly examine individually. That is a sensible use of AI. But the architecture must not become: AI makes the decision → AI reviews the decision → AI certifies the decision → no accountable human or organization remains. A supervisory AI should itself be validated, monitored, auditable, and subject to human governance. The organization deploying the system remains responsible. The fact that one AI watched another AI does not create accountability. Deborah “Nurse Deb” Ault | Response to FDA Discussion Paper | Page 14 FDA-2026-N-7874 | Generative AI-Enabled Medical Devices It creates another layer of technology. VI. Accountability Across the Healthcare AI Chain

Question 20 — Machine-based supervisory agents Automated supervision is probably unavoidable at the volumes involved — human review of every output is not feasible for a high-throughput device — so the question is how to make it trustworthy rather than whether to permit it. 12 of 19 Docket No. FDA-2026-N-7874 The dominant risk is correlated failure. A supervisory agent built on the same foundation model as the device it monitors shares that model’s blind spots. It will approve exactly the outputs that are wrong for reasons the model family does not represent, and its agreement will be misread as independent confirmation. This is not a hypothetical: it is the direct consequence of shared training data and architecture, and it means a same-model supervisor’s clean report carries close to zero information about the failures that matter most. I recommend: • Architectural independence as a condition of evidentiary use. A supervisory agent offered as postmarket evidence should be built on a model of a different family and provider than the supervised device. Where full independence is impractical, the sponsor should characterize and report the correlation in failure modes between supervisor and device on a held-out error set, and the monitoring program’s credit should scale with the demonstrated independence. • The supervisor is itself a measuring instrument and must be validated as one. Report its sensitivity for the specific harms of interest against human adjudication on a sampled basis — not aggregate agreement, which is dominated by the easy majority of correct outputs and can be high while sensitivity for serious errors is near zero. Sensitivity must be re-measured over time, since the supervisor’s own performance drifts. • The supervisor triages; it does not conclude. Its appropriate role is prioritizing outputs for human review and enabling broader sampling than humans could achieve unaided. The adjudicated endpoint should remain human. A monitoring program whose terminal judgment is machine-made has no independent check anywhere in the loop. • The supervisor is part of the device system for change-control purposes. A change to the supervisory agent changes the device’s monitoring properties and should trigger reassessment on the same terms as a change to the device.

FDA Question 20 - Machine-based supervisory agents Trace ID. TR-Q20 | FDA Q20; Sec. VI.D; App. B; pp. 21-22 / 29-30 BCR response. Machine supervisors may assist but should not self-certify the device. Validate them independently, control their version/lineage, measure detection performance, test common-mode blind spots, maintain audit logs, and provide fail-safe human escalation. BCR rule basis. BCR-R06,R08,R11,R13,R15 Solution-stack link. S8,S10,S12 Closure evidence. Independent supervisor validation, version control, detection performance, common-mode testing, human fail-safe Pass / re-open. Supervisor is independently evidenced and shared-blind-spot risk is tested Re-open when: Supervisor/device update or detection degradation.

Response to Question 20: Machine Supervisory Agents — Promising But Requires Standards The use of machine-based supervisory agents to conduct real-time postmarket monitoring of generative AI devices is promising and merits continued development. However, it creates a recursive reliability problem that FDA must address directly: if AI is used to monitor AI, who monitors the monitor? Before FDA permits the use of machine supervisory agents as a primary postmarket monitoring mechanism, it must establish performance standards for the supervisory agents themselves — including validated sensitivity and specificity requirements for detecting performance degradation, mandatory periodic evaluation of the supervisory agent's own accuracy, and a mandatory human review layer triggered by supervisory agent alerts. FDA should initiate a separate docket or technical working group to develop supervisory agent performance standards in parallel with the primary GenAI device regulatory framework.