AI Regulatory Sandboxes Meet FDA: What Utah's Experiment Means for Clinical AI Developers
October 27, 2026Utah is testing how clinical artificial intelligence (AI) can operate under negotiated exceptions to state professional practice requirements. For developers, these experiments offer a way to evaluate defined clinical functions with state oversight. They also raise a separate question: when does the software itself fall under the U.S. Food and Drug Administration’s (FDA) medical device authority?
The distinction matters before a pilot begins. An agreement addressing clinical practice or professional supervision under Utah law does not establish whether an AI product may be commercially distributed or clinically tested under federal law. Developers should plan for both issues as they design the product, negotiate state relief, and build evidence for clinical use or broader deployment.
How Utah’s AI Sandbox Works
Utah’s Office of Artificial Intelligence Policy works with the relevant state regulator to negotiate regulatory mitigation agreements. Under Utah’s AI Policy Act, these agreements can permit specified AI uses despite otherwise interfering state requirements, provide time to cure violations before penalties, or reduce civil fines. The agreement sets the conditions and safeguards for that relief.
The resulting permission is specific to the participant, activity, and terms negotiated with the state. Utah’s program FAQ explains that the initial demonstration period can last up to 12 months, with up to two 12-month extensions. Extensions are not automatic, and the state may terminate participation. An agreement does not establish a permanent license or a state endorsement of the technology.
The Pilots Span Several Types of Clinical AI
Utah’s authorized pilot register shows how the program reaches beyond prescription renewals. As of October 19, 2026, the portfolio includes the following examples.
The range matters for developers. The relevant analysis, including whether the software also qualifies as a medical device and is therefore subject to FDA regulatory oversight, depends on what the AI does, the patients it serves, and how clinicians supervise it. A program covering several clinical specialties does not create one regulatory classification or a uniform level of permitted autonomy.
Why State Practice Relief Leaves FDA Authority Intact
Utah expressly states that its agreements address state professional practice and administrative requirements and do not override FDA jurisdiction. The Nolla Health agreement, for example, preserves unmodified legal obligations and remedies for injured users. Participants remain responsible for obtaining permissions from other agencies with jurisdiction. Developers should read the relief schedule alongside the remaining obligations, including responsibility for patient harm.
The federal analysis turns on the product’s intended use and functions. Software that diagnoses a condition, analyzes a medical image, or directs treatment can present different device questions from software that organizes information for a clinician. Neither the label “sandbox” nor a physician’s name on a prescription resolves those questions. The public pilot materials alone do not establish the FDA status of any named participant’s product.
FDA Criteria for the Clinical Decision Support Exclusion
Federal law excludes certain clinical decision support (CDS) software functions from the definition of a medical device only when all four criteria discussed in FDA’s Interpretation of Criteria in Section 520(o)(1)(E) of the FD&C Act are satisfied. The function must:
- Not be intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal-acquisition system;
- Be intended to display, analyze, or print medical information about a patient or other medical information, such as peer-reviewed clinical studies or clinical practice guidelines;
- Be intended to support or provide recommendations to a healthcare professional about prevention, diagnosis, or treatment; and
- Be intended to enable that professional to independently review the basis for the recommendation rather than rely primarily on it when making a clinical decision.
If a pilot function fails any criterion, it does not qualify for this statutory non-device CDS exclusion and must be evaluated under FDA’s device framework.
How Clinician Oversight Affects the CDS Analysis
As we explained in CDS Software Final Guidance Carries Real Consequences for Manufacturers, FDA’s analysis is function-specific and turns on how the software actually operates. The degree of automation, the specificity of the output, the information given to the clinician, and the time available to review it all affect whether the clinician can independently evaluate the basis for a recommendation. Product claims, interface design, and access to supporting information should therefore match the intended regulatory position. In a Utah pilot, prospective review, retrospective audits, and sampling do not provide equivalent safeguards. A function that may fit the non-device CDS exclusion during an early phase with meaningful clinician review may require reassessment as oversight decreases or the software becomes more autonomous. Functions that analyze medical images or provide patient-facing diagnostic or treatment outputs require separate analysis and should not automatically be treated as non-device CDS.
FDA’s January 2026 Clinical Decision Support Software guidance explains how the agency applies the four statutory criteria and helps developers determine whether each software function in a pilot remains outside the device definition or is subject to FDA oversight. Under the guidance, a function that gives a specific diagnostic or treatment directive, analyzes a medical image or certain signals, or does not allow meaningful independent clinician review may fall outside the exclusion. Patient-facing functions cannot qualify for this particular exclusion merely because a clinician participates elsewhere in the workflow. Other statutory exclusions or FDA policies may still apply, but human involvement alone is not a universal exemption. Developers should therefore assess each pilot function, phase, and level of autonomy separately and revisit that assessment whenever the workflow or clinician’s role changes.
Pilots May Also Require a Clinical Investigation Analysis
If a sandbox pilot is a clinical investigation of a device, developers must separately evaluate the applicable investigational device exemption (IDE), institutional review board (IRB), and informed consent requirements. State authorization does not determine the study’s federal status.
FDA’s IDE approval process distinguishes significant risk studies, which require FDA IDE approval and IRB approval before beginning, from nonsignificant risk studies, which generally proceed under abbreviated IDE requirements with IRB approval. Some investigations are exempt from IDE requirements. The appropriate route depends on the product and study; participation in a state sandbox does not itself create an exemption.
Where Utah’s Experiments Meet FDA’s GenAI Discussion
As discussed in our alert on FDA’s generative AI discussion paper, FDA is considering how autonomy and the severity of potential harm should inform oversight of generative AI-enabled devices. Its August 2026 discussion paper also explores performance evaluation, monitoring, third-party foundation models, and management of changes. Our alert explains why increasing autonomy and variable outputs call for careful validation and controls throughout the product lifecycle. For a sandbox participant, those concerns extend to recognizing when a case exceeds the permitted task and escalating safely to a clinician. The discussion paper solicits input; it does not establish binding requirements or a new authorization pathway.
Utah’s phased demonstrations could help developers gather evidence relevant to those questions. Comparisons with clinicians, analysis of escalation failures, and monitoring after model changes may reveal risks that a static benchmark misses. But agreement rates alone do not establish clinical safety or effectiveness. Developers seeking an FDA authorization should determine whether the pilot’s population, endpoints, oversight, and software versions will support that submission, preferably before data collection begins.
What Clinical AI Developers Should Do Now
Developers considering a clinical AI pilot should take four steps:
Key Takeaway for Clinical AI Developers
Utah offers a practical setting for carefully bounded clinical AI experiments. Developers can use that opportunity to test workflows and collect evidence, while addressing FDA device status, investigation requirements, and the path to broader commercialization from the outset.
“State permission to test clinical AI does not resolve the federal device question. Developers should assess each software function and revisit that analysis as clinician oversight changes.”
Brynn Stanley, Associate Attorney
How Gardner Law Can Help
Gardner Law helps AI developers integrate FDA regulatory strategy into product development, beginning with assessments of whether software functions qualify as medical devices and what requirements apply. Drawing on experience in engineering, quality systems, and clinical research, we advise on design and development controls, risk management, validation, and FDA submissions. For regulated medical devices, we help manufacturers establish and maintain quality systems aligned with the Quality Management System Regulation (QMSR), address registration and listing obligations, and implement complaint handling and adverse event reporting processes.
When clinical trials are needed, we assist with regulatory strategy, IDE submissions, clinical trial agreement drafting and negotiation, informed consent documents, and sponsor and investigator obligations, including clinical safety reporting. Our support connects product development, clinical evidence, and ongoing compliance throughout commercialization and the product lifecycle.