in2being LLC (Aaron Kehrer)

See attached file(s)

Comment on Docket
FDA‑2026‑N‑7874: Considerations for
the Regulation of Generative AIEnabled Medical Devices
Submitted by: in2being, LLC
Contact: Aaron Kehrer - Director of Product Development, contact@in2being.com

1. Introduction

in2being provided design and regulatory services to early-stage medical device and life-science
companies for more than 15 years. We see generative AI (GenAI) moving quickly from a tool our clients
use to develop products, to a component within the products themselves, and in some cases to GenAI
being the product. Our clients need a regulatory path that is predictable, risk-proportionate and least
burdensome, and that tells them what to design for, not only what to test.

We support CDRH's goal of a nimble, risk-based approach across the total product life cycle. Rather
than addressing each question one-by-one we propose a unified framework for viewing GenAI device
functions as medical devices. We believe that this approach keeps these technologies within the device
definition and regulations and ties the FDA's proposed activities together.

2. The issue with clinical evaluation

The discussion paper recognizes that bench testing developed for bounded inputs and fixed outputs is
not sufficient for GenAI. To fill that gap it borrows from how clinicians are evaluated: knowledge
assessment, supervised practice and ongoing review. We agree that bench testing of bounded inputs is
insufficient and an additional method of testing is needed. The paper also cites literature that proposes a
licensure-style framework for AI. But it is unclear which parts of clinician evaluation and licensure should
carry over and which should not.

While drawing inspiration from clinical credentialing is a natural starting point for open-ended AI
capabilities, we believe a licensure model for devices is ultimately inappropriate for four reasons:

1. Scope: A license grants a broad scope of practice. A device is authorized for a specific intended
use. A credential-style authorization could invite a scope expansion that intended-use boundaries
exist to contain.
2. Accountability: Licensure works partly because licensed professionals face personal professional,
legal and reputational consequences, and those consequences shape how they practise. A GenAI
device does not respond to consequences in the same way, and they fall on the manufacturer, who
can only act through device design, monitoring and updates. The discussion paper acknowledges
this concern, citing Freyer et al.
3. Independence of errors: Errors across a population of clinicians are largely independent. A single
model would make the same error for every patient who presents similarly, so failures would be
correlated across patients. Given that multiple devices may be built on the same foundation model, a
single weakness could appear across products from different manufacturers at the same time.

in2being — Comment on FDA-2026-N-7874 Page 1 of 12
 4. Change: A clinician's capability changes slowly. A GenAI device's behavior could change all at once
with an update, or within a single session as context accumulates.

We suggest a different basis for the evaluation of GenAI functions. Clinicians, patients, devices and
GenAI functions can all be viewed as controllers within a care system: each receives information,
maintains some picture of a patient's state, and takes or directs actions for their care. There is a long
body of research treating both devices and people as controllers within systems and with this view a
GenAI function is a medical device when it meets the device definition, and can be treated as a
controller. What changes from current device evaluations is what is evaluated: the actions the device is
delegated to take or direct, and whether it, and the people and systems around it, are adequate to
control those actions safely.

3. Our approach

Risk analysis and device safety are central to our design work and as the complexity of medical devices
has increased, we have taken a systems engineering approach to our work. While reviewing the paper
we found that the research and methods developed by Prof. Nancy Leveson and her colleagues at MIT
provided a good guide for our thinking. Specifically we found the System-Theoretic Process Analysis
(STPA) method useful.1 Unlike traditional reliability engineering which assumes accidents are caused by
component failures, STPA views safety as a control problem, focusing on unsafe interactions between
system components.

STPA describes how a control action can be unsafe in four ways. Several considerations the FDA paper
raises separately fit into these four types:

From the discussion paper STPA type of unsafe control action

Under-escalation (Q6) A needed action is not provided

Over-escalation (Q6) An action is provided when it is unsafe

Delayed escalation; time pressure (Q1) An action is provided too early, too late, or out of order

Multi-turn drift (Q5); agentic action sequences (Q26) Out of order; stopped too soon or applied too long

Informational vs. action-directing vs. action-taking (Q2) How much control has been delegated to the function

Two points shape our recommendations:

• The four types are a checklist, not a severity scale. They make sure hazard identification
considers omissions, timing and duration, not only incorrect outputs. Severity still comes from the
harm that results, as defined by a risk management process.
• Confabulation is a flaw in the device's picture of the patient. A GenAI function builds an internal
representation of the patient, the user's intent and the record from its context, retrieved data and
memory. Under STPA this "process model" contains the controller's internal beliefs that it uses to
make decisions. When that representation is wrong, otherwise "correct" behavior produces unsafe
actions. This explains why confabulation is dangerous, not just that it occurs.

1. N. G. Leveson and J. P. Thomas, STPA Handbook (MIT Partnership for Systems Approaches to Safety and Security, 2018), https://
psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf. See also N. G. Leveson, Engineering a Safer World: Systems Thinking
Applied to Safety (MIT Press, 2011; open access), https://doi.org/10.7551/mitpress/8179.001.0001.

in2being — Comment on FDA-2026-N-7874 Page 2 of 12
We recommend that FDA involve Prof. Leveson's group at MIT (Partnership for Systems
Approaches to Safety and Security)2 in further development of this framework. Their experience
applying these methods in aviation, automotive and other safety-critical industries would be a benefit to
CDRH.

4. Recommendations

The recommendations below are expressed in terms already used in device regulation: ISO 14971, IEC
62304, IEC 62366-1 and FDA guidances.

4.1 Refine the activity axis into four delegation levels
We suggest the activity axis discussed in section IV describe how much control is delegated to the
function:

Level Meaning

Inform Output feeds a person's decision

Direct Output tells a person what to do

Act-supervised The function acts, and a person can intervene before harm

Act-autonomous The function acts with no human step

This closely follows the paper's own axis. Maintaining the separation between supervised and
autonomous action exposes the critical determination: can the supervising person or system detect a
problem and stop it before harm can occur?

• Functions that take actions should be classified as Act-autonomous by default. We recommend that
FDA guidance describe how a sponsor may justify classifying a function as Act-supervised. We
suggest demonstrating:
◦ that supervisors detect seeded errors at the function's realistic error rate, over a realistic time on
task;
◦ that the time to intervene is shorter than the time to harm, and that this is enforced by design;
◦ that skipped or unavailable checkpoints are visible and fail safe;
◦ that indicators of supervision (for example, override and acceptance rates) are monitored after
deployment.
• Supervision should not count as a risk reduction when the action cannot be undone; the supervisor
can only watch it happen.

For example: A function that recommends an insulin dose from a photo of a meal would be Direct. The
same function sending the dose to a pump without confirmation is Act-autonomous so its classification
and required evidence should be regulated accordingly.

2. MIT Partnership for Systems Approaches to Safety and Security (PSASS), https://psas.scripts.mit.edu/home/.

in2being — Comment on FDA-2026-N-7874 Page 3 of 12
4.2 Credit human review only when it is shown to work
The people around a device (clinicians, patients, caregivers) should be considered part of the system
being analyzed and should not be assumed to be effective risk controls. We suggest a person's review
of the AI actions be credited as a risk control only when it is shown, for the intended user population,
that the person:

• knows what to look for and understands what an incorrect output would look like;
• can judge the action and has the knowledge and experience to recognize the error;
• has independent information and can see the patient's actual state, not only the device's output;
• can act in time, sees the output before it takes effect and can override it, with the device's workflow
enforcing this.

These can be demonstrated using existing human factors methods (e.g. through an IEC 62366-1
summative validation), when extended to include tasks in which the user must detect seeded, realistic
errors. The intended population sets a ceiling on how effective any human safeguard can be: age,
cognitive ability, health literacy and acute stress are all factors.

This addresses the patient-facing question (Q3) and the generalist/specialist question (Q4) without fixed
assumptions about either group. An experienced patient may meet these conditions for a decision that is
familiar to them; a generalist clinician may not for a specialist output.

4.3 Credit engineered controls through segregation
Engineered controls can remove a GenAI function's contribution to a serious harm. Examples are
workflow enforcement, least-privilege access, hard limits on doses or actions, and contraindication
checks. We suggest using the approach IEC 62304 already takes to segregating software items. A
control should be credited only if it is:

• independent of the generative component and itself non-generative, so that it does not share the
component's failure modes and cannot be bypassed by it;
• classified and verified using IEC 62304 methods at the class of the harm it prevents;
• bounded where the sponsor justifies that no output of the generative component can reach the
patient, clinician, device or medical record except through the control.

Guardrails implemented through prompts, LLM-based judges and AI supervisory agents do not meet this
test because they share the failure modes of what they monitor. They may still be used to support
postmarket monitoring.

This approach has a practical benefit for sponsors. Parts of a device that can be bounded are evaluated
with established device methods. Only the authority left uncontained needs new GenAI-specific
evaluation and sponsors who contain more need less novel evidence.

in2being — Comment on FDA-2026-N-7874 Page 4 of 12
4.4 Let severity set the amount of evidence, and delegation set the kind
The paper asks how the risk framework should determine the level of evidence (Q8). We suggest the
framework produce two outputs rather than one combined risk position.

• Residual severity sets the rigor.
◦ Severity is assessed after credited controls, using ISO 14971 risk management harm and
severity defined by the sponsor.
◦ It is assessed on severity alone, as IEC 62304 software safety classes and FDA's basic and
enhanced documentation levels already do. The probability that a GenAI output is wrong cannot
be credibly estimated in advance.
◦ FDA can set boundaries above which evidence expectations increase, such as the potential for
serious injury or death.
• Delegation sets the type of evidence.
◦ Inform and Direct: output correctness and calibration, communication, and the user's ability to
detect errors.
◦ Act-supervised: adds evidence of supervisor capacity.
◦ Act-autonomous: adds testing of timing, sequence and duration, of action chains, and of
containment.

Where an autonomous function's remaining harms are not serious, premarket rigor can stay
proportionate to the severity. The submission could then include a postmarket surveillance plan with
population-level indicators. This restores the observation point that autonomy removes, and helps detect
errors that repeat across many patients.

in2being — Comment on FDA-2026-N-7874 Page 5 of 12
4.5 Treat GenAI competency and supervisor capacity as the same question
The request for feedback contains a proposal for evaluating a GenAI function's competency. Section 4.2
above discusses a person's capacity to act as a safeguard. The competency of the AI function to meet
its goal and a person's capacity to interact with that function can be seen as a closed loop where the
same question can be asked of the two different controllers: is this controller adequate to control the
actions it has been given? This is the idea we would most like CDRH to consider.

A person relied on as a safeguard
(capacity) The GenAI function (competency)

Knows the goal Knows what a wrong output looks like and Holds to its intended use and scope under
what safety means in context pressure: user distress, insistence, claimed
authority

Accurate picture Has the information and expertise to judge Its picture of the situation matches reality; it
the output recognizes missing, stale or absent inputs

Independent Can see the patient's state for themselves Receives the inputs it needs and knows
information when one is missing

Can act correctly Sees the output before it takes effect and Issues only authorized actions, with correct
can override it timing, sequence and duration

Framing competency this way provides a basis for the paper's clinician analogy, explains what can carry
over from clinician evaluation, and it does not require treating the device as a practitioner. It also
suggests how benchmarking could be organized:

• Derive test scenarios from the hazard analysis. Use the specific situations in which an action would
be unsafe, and the ways the function's picture of the patient could be wrong.
• Use the benchmarking elements in the FDA paper's Appendix A as a coverage check. They confirm
the test scenarios address safety, clinical proficiency, generalizability and agentic behavior, rather
than standing as separate exams.
• Set pass/fail limits per test scenario for scenarios whose harms are above the severity boundary, so
that good overall performance cannot offset a critical failure.

The comparison also shows where the GenAI function should be held to a higher standard than a
person:

• its errors repeat across every patient with similar inputs;
• its adherence to its goal must be tested rather than assumed;
• its behavior can change all at once with a model update;
• its competence affects the vigilance of the people supervising it.

4.6 Ask sponsors to state the assumptions their safety depends on, in a form
deployers can monitor
Every device's safety case relies on assumptions about the setting it is used in. For example: that a
qualified person reviews the output, that certain inputs are available, or that no other automated system
acts on the same information at the same time. For GenAI functions used alongside clinicians, devices,
drugs and AI systems, how the overall system behaves cannot be fully predicted before market release.

in2being — Comment on FDA-2026-N-7874 Page 6 of 12
We recommend that sponsors provide, as part of labeling, a system card containing a description of the
deployed system, including the model, with a section on operating assumptions. Each assumption
would state:

• what is assumed (output review, required inputs, etc.), and which hazard it guards against;
• an observable indicator that the assumption is met;
• who can observe it (manufacturer or deploying organization);
• the acceptable range of outcomes;
• the response when it is out of range.

This builds on existing work: the example model card in FDA's draft guidance on AI-enabled device
software functions, the Coalition for Health AI's Applied Model Card,3 and ONC's HTI-1 source-attribute
requirements for decision support.4

Assumption violations should also count as reassessment triggers, alongside performance drift. One
example is a falling review time or a rising rate of outputs accepted without change by human
supervisors, which shows supervision drifting toward autonomy without any software change.

Since FDA cannot place requirements on health systems we encourage CDRH to coordinate with
organizations and institutions that oversee these areas.

5. Paper questions addressed

Recommendation Discussion questions

4.1 Four delegation levels Q1, Q2, Q26

4.2 Credit human review only when shown to work Q3, Q4, Q14

4.3 Credit engineered controls through segregation Q1, Q9, Q20

4.4 Severity sets rigor; delegation sets evidence type Q8, Q18

4.5 Competency and capacity as one question Q7, Q9, Q10

4.6 System card with operating assumptions Q19, Q21, Q22

We have not commented on predetermined change control plans, which we believe can be used for
GenAI devices as they are, or on Foundation Model Master Files.

3. Coalition for Health AI (CHAI), Applied Model Card, https://www.chai.org/workgroup/applied-model.
4. Office of the National Coordinator for Health IT, Health Data, Technology, and Interoperability (HTI-1) Final Rule, decision support
interventions criterion (45 CFR 170.315(b)(11)), https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-andinteroperability-certification-program.

in2being — Comment on FDA-2026-N-7874 Page 7 of 12
6. Closing

We appreciate CDRH's early engagement with stakeholders on this topic. With a clear basis for
evaluation, GenAI functions can be managed as safely as existing medical devices. We would welcome
the opportunity to discuss these recommendations with CDRH further.

Aaron Kehrer - Director of Product Development
in2being, LLC
contact@in2being.com

Disclosure on the use of generative AI
In preparing this comment, in2being used generative AI systems to help analyze the discussion paper and public docket,
and to assist with drafting. All content was critically reviewed, revised and approved by in2being. The opinions,
recommendations and statements in this comment are those of in2being, and in2being is solely responsible for its content.

in2being — Comment on FDA-2026-N-7874 Page 8 of 12
Appendix: Worked examples

These examples apply the approach in Section 4 to three functions described in the discussion paper.
The severity assignments and controls are examples, not determinations, and a sponsor's analysis
would be more detailed.

Example A: Advising a patient whether to seek emergency care for chest pain
Function: A patient-facing conversational function that advises whether to seek emergency department
care for chest pain.

Who it affects: The patient, who decides whether and where to seek care. No clinician is involved before
the patient acts. The function's picture of the patient comes from what the patient types over the
conversation.

Delegation level: Direct.

Hazard type Example in context Potential harm

Not provided Does not advise emergency care when symptoms Delayed treatment; death or
indicate acute coronary syndrome serious injury

Provided when unsafe Advises home care and follow-up for a presentation Delayed treatment; death or
needing emergency care serious injury

Provided when unsafe Advises emergency care when not warranted Unnecessary visit, cost and
anxiety, reduced trust (nonserious per patient)

Wrong timing Advises emergency care only after an extended Delay; serious
exchange

Stopped too soon Withdraws its emergency advice after the patient Delayed treatment; serious
minimizes symptoms or objects

Picture of the patient is Carries forward a symptom the patient corrected, or Wrong disposition; serious
wrong invents history not given

Controls:

• Engineered: a deterministic red-flag rule, outside the generative component, that issues emergencycare advice for specified symptom patterns and cannot be withdrawn later in the conversation. This
removes the generative component's contribution for the covered patterns. Atypical presentations
outside the rule's coverage remain.
• Human: the patient, acutely symptomatic and without independent means to judge cardiac risk,
does not meet the conditions in 4.2 to provide appropriate risk controls.

Result:

• Rigor: residual severity includes death or serious injury, so evidence is at the highest level.

in2being — Comment on FDA-2026-N-7874 Page 9 of 12
 • Evidence type (Direct):
◦ disposition correctness across full multi-turn conversations, including atypical presentations and
patients who push back;
◦ stability of emergency advice once given;
◦ human factors validation that intended users understand and act on the advice.
• Example operating assumptions:

Assumption Indicator Observed by

User population matches the Distribution of user age and other reported Manufacturer
validated population characteristics

Conversations stay within the Number of turns before a disposition is given Manufacturer
validated length

The red-flag rule behaves as validated Rule firing rate compared with baseline Manufacturer

Example B: Initiating a thrombolytic therapy order set in a stroke workflow
Function: A function within a stroke workflow that places a thrombolytic therapy order set in the EHR,
with clinician supervision, as described in the paper. It does not control drug administration; clinical staff
prepare and administer the drug. A function that drove the infusion pump directly would be a different,
higher-risk function.

Who it affects: The order set goes into the EHR and is then administered by clinical staff to the patient.
The function's picture of the patient comes from the record: imaging results, onset time, medications
and laboratory values.

Delegation level: Act-supervised defaults to Act-autonomous. The harm from inappropriate
thrombolysis (intracranial hemorrhage) cannot be undone, so supervision earns no credit. Recommend
redesigning to Direct: it proposes the order set, and a clinician must affirmatively place it.

Hazard type Example in context Potential harm

Not provided No order set proposed for an eligible patient Lost treatment window;
serious disability

Provided when unsafe Order set proposed despite hemorrhage on imaging, Hemorrhage; death
anticoagulation, or onset outside the window

Too early Proposed before imaging has excluded hemorrhage Hemorrhage; death

Too late Proposed after delays that narrow the benefit Reduced benefit; serious
disability

Wrong sequence Order set includes antithrombotic orders that should be Hemorrhage; death
withheld after thrombolysis

Applied too long Order left active after new information contraindicates it Hemorrhage; death
(e.g., a later imaging read shows hemorrhage before
administration)

Picture of the patient is Wrong "last known well" time; stale medication list; Inappropriate treatment;
wrong misread imaging report death

in2being — Comment on FDA-2026-N-7874 Page 10 of 12
Controls:

• Engineered: deterministic contraindication checks, segregated from the generative component and
verified. They block the order unless structured fields confirm:

◦ hemorrhage excluded on a finalized imaging read;
◦ no disqualifying anticoagulation;
◦ onset within the window.
These remove several unsafe "provided" and "too early" paths. Paths that depend on incorrect
structured data remain.

• Human: the confirming clinician may meet the conditions in 4.2. They examine the patient, see the
imaging, and confirm before the order is placed. But time pressure and generalist versus specialist
expertise limit their capacity. Credit requires human factors validation under realistic time pressure
with seeded errors.

Result:

• Rigor: residual severity includes death, so evidence is at the highest level.
• Evidence type (Direct after redesign):
◦ correctness of order proposals across the timing and sequence hazards above;
◦ the function's handling of missing or conflicting record data;
◦ validation of the confirming clinician's capacity.
• Example operating assumptions:

Assumption Indicator Observed by

Clinicians independently review Time from proposal to confirmation; rate of proposals Deploying
before confirming confirmed without change organization

Required structured fields are Rate of missing "last known well" or imaging status at Deploying
complete the time of proposal organization

Imaging is read before a proposal is Proposals generated before a finalized read (should be Manufacturer
made zero)

Example C: Autonomous antibiotic prescribing for confirmed strep throat
Function: A function that autonomously prescribes antibiotics for confirmed streptococcal pharyngitis,
as described in the paper.

Who it affects: The prescription goes to a pharmacy, and the patient takes the medication. The
function's picture of the patient comes from the test result, allergy list, age, weight and current
medications.

Delegation level: Act-autonomous.

in2being — Comment on FDA-2026-N-7874 Page 11 of 12
 Hazard type Example in context Potential harm

Not provided Confirmed positive result produces no prescription and Untreated infection;
no referral complications (potentially
serious)

Provided when unsafe Penicillin-class drug for a patient with a documented Anaphylaxis; death
allergy

Provided when unsafe Incorrect weight-based dose for a child Toxicity or treatment failure

Provided when unsafe Prescription when the result was ambiguous or Unnecessary antibiotics (nonmisattributed serious per patient);
resistance and adverse
events at population level

Wrong duration Course too short Treatment failure

Picture of the patient is Result attributed to the wrong patient Wrong treatment; potentially
wrong serious

Controls: All engineered, segregated and verified:

• every confirmed positive result produces either a prescription or a referral to a clinician;
• allergy and interaction checks block contraindicated drugs;
• dose and duration limits come from a fixed formulary;
• patient identity is verified against the result.

These remove the serious harm paths.

Result:

• Rigor: residual harm is non-serious (unnecessary or suboptimal treatment), so premarket evidence is
proportionate.
• Evidence type (Act-autonomous):
◦ testing of the action itself and its containment;
◦ verification of the engineered controls;
◦ handling of ambiguous and incomplete inputs.
• Postmarket surveillance plan, because errors would repeat across many patients without anyone
seeing each case:

Assumption Indicator Observed by

Prescribing tracks confirmed infection Prescribing rate relative to the positive-test rate and to Manufacturer
regional baselines

Inputs are complete and correctly Rate of results with missing weight, allergy or identity Manufacturer
attributed data

No unexpected harm signal Adverse reaction and repeat-visit reports Manufacturer,
with deploying
organization

in2being — Comment on FDA-2026-N-7874 Page 12 of 12