The FDA Is Reading Your Release Notes

Here is what twelve weeks of FDA activity on AI-enabled medical devices looked like:

August 18. The Digital Health Center of Excellence published its first discussion paper on regulating generative AI-enabled devices.
September 17. FDA formalized its refusal to let experienced radiology AI makers skip the 510(k) for their next device.
September 25. Draft guidance for robotically-assisted surgical devices arrived, followed on November 6 by a discussion paper on robots with autonomous or remote capabilities.
October 1. CDRH’s fiscal 2027 guidance agenda put the final AI lifecycle guidance and the all-device PCCP guidance at the top of the list.
Early October. A warning letter told a software device maker that a retrained model and a move to the web each required a new 510(k).

Read one at a time, these look like five separate stories. Read together, they make one argument. FDA cares less about how good your model was on the day it was cleared, and more about whether you can show what has changed since, why, and how you know it is still safe. For engineering and software leaders, that moves the regulatory conversation out of the submission binder and into the repository.

Timeline of FDA actions on AI-enabled devices, August through December 2026

A version bump is a regulatory event

Start with the warning letter, because it is the one most likely to describe your own team.

O.N. Diagnostics makes VirtuOst VFA, software that analyzes spine CT images to identify and grade vertebral fractures. It was cleared through a 510(k) in 2017. After a March 2026 inspection, FDA concluded that version 3.0.0 had gone beyond what was cleared and asked the company to stop distributing it. FDA named three changes, and said each one on its own required a new submission: a new machine learning model for vertebral landmarking, a move from a desktop application to a web platform, and a technology platform migration that called for re-verifying the whole codebase, including third-party libraries whose software bill of materials FDA had never reviewed.

On the model change, FDA’s reasoning is worth reading twice. A model trained on different data, with a different architecture or a different objective, can behave differently across patients, scanners and clinical settings. In the agency’s words, such a change “fundamentally changes how the device performs, fails, and affects patients.” Whether the company meant it as an improvement did not enter into it. And the evidence came from the company’s own release notes, plus its own acknowledgment during the inspection that the web move had widened its attack surface.

None of this is exotic. A better model, a modern deployment, a framework upgrade: that is the ordinary life of a software product. That is exactly why it matters. Teams building with AI coding assistants are shipping more changes per quarter than they were two years ago. If the decision about whether a change needs a submission happens at release time, in someone’s head, it will eventually be wrong. It has to happen when the change is made, against the specification, with a record that survives an inspection.

Experience is not evidence

The second story is about a shortcut FDA declined to offer.

In October 2025, a petition filed on behalf of Harrison.ai asked FDA to exempt certain radiology computer-aided detection, diagnosis and triage devices from 510(k) review when the maker already held a clearance in the same family and committed to a postmarket monitoring plan. FDA denied it by letter in April, and the final order published September 17 closes the process. Every new device of these types still needs its own 510(k).

FDA’s reasons read like a review checklist. A clearance judges one device against one predicate; it does not certify a company’s process for the next one. Detection, diagnosis and triage tools do different jobs and fail differently. The methods for establishing ground truth do not travel between indications; the agency’s own example is that a reference standard built for dental caries tells you little about detecting a large vessel occlusion. And a postmarket plan designed by the manufacturer, at a scale the manufacturer chooses, would in FDA’s view reverse the statutory burden.

The detail that should stop every engineering leader: FDA reported that among all 510(k)s cleared under one computer-aided detection product code over several years, every single one had been placed on hold, with deficiencies in performance testing methodology or results among the reasons. In many of those cases the sponsor already had a prior authorization. Experience did not carry the file. Evidence did.

FDA’s suggested alternative was the Predetermined Change Control Plan. That is the thread running through this whole quarter.

Generative AI gets a first framework

The August discussion paper is not guidance, and FDA says so plainly. It is still the clearest picture yet of how reviewers will think about devices built on large language models and foundation models.

The core is a two-axis risk grid. One axis asks how independently a function acts, from non-directive information, to action-directing information, to supervised action, to fully autonomous action. The other asks how severe the consequences of a wrong output would be. Evidence expectations scale with a device’s position on the grid, not with the mere presence of an LLM. Two details matter for anyone writing an intended use statement: FDA judges directiveness on substance, so a “talk to your doctor” disclaimer does not move an action-directing output to the left, and patient-facing functions can sit higher on the consequences axis because patients cannot independently check the output.

FDA's proposed two-axis risk grid for generative AI-enabled devices, with evidence expectations rising toward autonomous action and severe consequences

If that grid looks familiar, it should. It follows the same logic as the green, yellow and red review ladder we teach in workshops with medtech R&D teams: the more an AI output directs action, and the worse a wrong answer would be, the more independent and formal the review. It is encouraging to see the agency draw the same picture.

On top of the grid, FDA proposes evaluating these devices the way medicine evaluates clinicians, through competency. That means benchmarking the device in its deployed configuration across safety behaviors, clinical proficiency and generalizability: resistance to prompt injection, staying within scope, knowing when to defer, and holding up across demographics and dialects. Agentic systems get their own element, which asks whether the system plans within a safety envelope, recognizes when a tool call has failed, and keeps a human checkpoint before irreversible actions. Benchmarking is paired with clinical confirmation, which FDA says will not always require a prospective study.

The paper also takes on the problem most teams building on third-party models have been quietly avoiding. When the foundation model vendor ships a new version, the device has changed, and the sponsor still owns the regulatory consequence. FDA floats a voluntary Foundation Model Device Master File so vendors could share architecture, training data provenance, failure modes and update commitments confidentially with FDA for sponsors to reference.

Comments closed October 19 with more than 500 submissions, and the field is split. Major industry groups pushed FDA to adapt its existing risk-based framework rather than build a new one, while others welcomed the competency approach. Several commenters argued that benchmarks should be independent of the manufacturer and treated as supporting evidence rather than a finish line.

Whatever shape the eventual guidance takes, three engineering requirements are already visible. An intended use statement that commits to a position on both axes and can defend it in the risk file. An evaluation set kept apart from the regression tests you rerun after every change, so it still means something on the tenth release. And a pinned, documented foundation model dependency, with a plan for the day the vendor deprecates your version.

Autonomy is next in line

Robotics is where software meets the patient most directly, and FDA moved there too. The September draft guidance for robotically-assisted surgical devices expects software documentation at the enhanced level, with verification and validation at the unit, integration and full-system levels, including how software, hardware, sensors, actuators and user interfaces interact. Comments are due November 24.

On November 6, CDRH followed with a discussion paper on benefit and risk for robotic devices with autonomous or remote teleoperation capabilities, ahead of a public workshop on December 2 and 3. Like the generative AI paper, it proposes no policy yet. Also like the generative AI paper, it signals that autonomy will be judged as a system property, which makes traceability from embedded firmware through cloud services a requirement rather than a nice-to-have.

What fiscal 2027 is set up to deliver

CDRH’s guidance agenda for fiscal 2027, published October 1, is short and pointed. The A-list, the documents CDRH intends to publish this year, includes the final version of the January 2025 AI-enabled device lifecycle guidance, the final version of the PCCP guidance for all device types, and a new draft on generative AI conversational devices for mental disorders, which would be FDA’s first guidance aimed at generative AI. The B-list adds a revised device software functions policy and a long-overdue rewrite of the 2016 postmarket cybersecurity guidance. Risk assessment for generative AI devices in general sits on the under-construction list.

Treat the agenda as a direction, not a calendar. CDRH says it published 7 of the 11 documents on last year’s list. Comments on priorities are open until November 30 under docket FDA-2012-N-1021.

One more data point landed on November 5. A research letter in JAMA Network Open looked at 163 AI devices cleared through the 510(k) pathway and found that about a third had received at least one algorithm update. Of those updated devices, 85.7 percent reported no clinical or organizational benefit in public FDA records. The study is small and limited to public filings, so it cannot say any device got worse. It does show updates are routine and the public evidence trail behind them is thin. A final PCCP guidance will make that gap far more visible.

Where we would start

For engineering and software leaders, here is where we would put effort this quarter.

Inventory every release since your last clearance. For each significant change, confirm it was either cleared or documented, at the time, as not requiring a submission. Pay special attention to model retraining, deployment architecture and third-party stack changes, the three categories FDA named.
Move change classification to the moment of change. Every change should trace to a requirement and carry a short impact note: does it touch the model, the architecture, the intended use or the software bill of materials? When specs, code and tests are linked, that record is generated by the work, not reconstructed for an auditor.
Design the PCCP alongside the roadmap. A PCCP is an engineering artifact: the modifications you plan, how you will validate them and the acceptance criteria that decide whether they ship. If you cannot write the acceptance criteria for a change, you are not ready to promise FDA you can make it safely.
Keep your evidence independent. Hold out an evaluation set that never enters the regression loop. For generative AI, treat the foundation model version as a pinned dependency in your SBOM, with a documented response plan for vendor updates.
Place every AI function on both axes now. Decide how directive each output is and how bad a wrong answer would be, then set review rigor to match before FDA does it for you.

None of this slows a good team down. It is the structure that lets AI-assisted development move quickly without generating changes nobody can account for later. It is how every sprint runs inside the Lab651 Proven Project Process™, and we wrote about the method behind it in Spec First, Agents Second.

The one question

If an FDA investigator opened your repository tomorrow, could every change since your last clearance explain itself?

If the honest answer is “mostly,” our Discovery Phase is built for that gap: a fixed-fee, 3- to 4-week independent review of how your team specifies, builds, verifies and documents software, ending in a gap analysis and a prioritized roadmap. If the gap is in the code itself, such as third-party libraries nobody has reviewed, our fixed-fee security audit is a faster place to start. Either way, start at lab651.com/contact. No sales pitch. A real engineer. We respond within one business day.

Preparing for an FDA review rather than a build? Our sister firm, Recursive Awesome, advises and trains medical device R&D, quality and regulatory teams on what FDA expects before you submit.

This post reflects our engineering perspective on public FDA documents and is not legal or regulatory advice.