Applied AI
Clinical AI Regulation
Five separate authorities govern a clinical AI product in the United States, and each asks a different question at a different moment. This paper is the map: what makes clinical software a device under the four criteria FDA rewrote in January 2026, which route it then takes and what that route does and does not ask you to prove, how a model that changes is handled under the predetermined change control plan statute, and the four other bodies of law that attach once the software is running in a hospital. It covers software on its own and software inside hardware, because they are governed by the same statute and the differences show up in evidence rather than in a separate rulebook. Written from the statute, the regulation, the guidance documents and the published studies rather than from commentary, with every status and date as at October 2026 and every draft and proposal identified as such.
What’s inside
- Five authorities over one product, what each regulates, and which of them asks its question before you ship
- The four criteria in section 520(o)(1)(E) as FDA now reads them, with the agency’s own worked examples, including one function moved across the line twice without touching the model
- The January 2026 enforcement discretion for a single clinically appropriate output: what it covers, and the limits that are always inputs or urgency
- Why patient-facing software cannot use the exclusion at all, and what that does to a consumer product roadmap
- The premarket distribution counted from FDA’s own list, and what substantial equivalence does not ask
- De Novo special controls, and the two district court decisions that now attach a liability consequence to pathway choice
- Two routes to automated insulin delivery: why the same clinical function is Class III in one architecture and Class II in another
- Documentation level, assessed before risk controls, and the categorical triggers that are recommendations rather than rules
- Section 515C and the three parts of a change control plan, the arithmetic trap in its monitoring half, and how rarely it is used
- The quality, risk and usability standards: QMSR in force, AAMI CR34971, IEC 62366-1, and why a warning in the manual is a weak control
- Section 524B, the software bill of materials, and the three supply chain realities generic security work misses in a training stack
- The four places a clinical AI system touches HIPAA, only one of which is usually in a design review
- 45 CFR 92.210, the predictive decision support source attributes and state disclosure law: the obligations that bind the hospital rather than the vendor
- What the new adverse event system can and cannot see, with every figure from the Epic Sepsis Model validation quoted accurately
- FDA’s generative AI framework, and the patient-facing language model device cleared eight months before the paper proposing it
- Twenty questions, ten for your own product and ten for a vendor, and a glossary of the two dozen acronyms
Request this resource
Related insights
- Article · Applied AI
Clinical AI regulation: intended use determines the path
Intended use decides, not the architecture and not the accuracy. FDA rewrote the four criteria in January 2026, and three of them now read differently.
· 22 min read - Article · Applied AI
Imaging AI: six handoffs between the scanner and the chart
An imaging AI deployment is not one integration. It is six, each governed by a different standard, and the two nobody scopes are the last two: what the radiologist did with it, and who pays.
· 9 min read
