Under FDA’s change-control model, the AI device a hospital validates will not stay the one it runs

The week

On January 7, 2025, the Food and Drug Administration published notice of draft guidance titled “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations.” The agency had announced it the day before. Draft guidance is FDA’s way of telling industry how it currently expects to apply the rules, published for comment before it becomes final. Comments were due by April 7, 2025, and FDA scheduled a webinar on the draft for February 18.

Suppose a hospital buys a piece of software that reads chest scans and flags the ones a radiologist should look at first. The clinical team tests it carefully, signs off and switches it on. A year later, it may no longer be the software they tested, and the first week of 2025 made that official.

Why FDA wrote it

FDA said in its announcement that it had already authorized more than 1,000 AI-enabled devices through its established premarket pathways. Most of the tools on its public list were in radiology, with cardiology and neurology well behind. Until this draft, no single FDA guidance set out what a marketing submission for such a device should contain.

A marketing submission is the package a company sends FDA to get permission to sell a medical device. For most AI tools that meant a 510(k), which shows the device is substantially equivalent to one already on the market. Novel lower-risk devices used the De Novo route, and the highest-risk devices needed premarket approval.

Reviewers and sponsors had worked from general software guidance plus a run of principles papers. FDA’s 2019 discussion paper on modifying AI and machine learning software was the first of them. An action plan followed in January 2021. Good machine learning practice principles, written with Health Canada and the United Kingdom’s MHRA, came that October. Joint principles on change control plans followed in 2023 and on transparency in 2024. The January draft pulled that thinking into one document.

What the draft asked for

The document described what manufacturers should include in a submission across what FDA calls the total product life cycle. Its sections covered the device description, user interface and labeling, risk assessment, data management, model description and development, validation, device performance monitoring, cybersecurity and the public summary FDA posts after authorization.

Two recommendations stood out for hospitals. FDA encouraged reporting of performance across patient subgroups, meaning how well the tool works for different groups, as well as on average. The draft listed sex, age, race, ethnicity and disease severity, and also clinical site and the equipment that collected the data. It also suggested a model-card-style summary for users: a short fact sheet describing what the AI model does, what data shaped it and where its limits are. An appendix gave an example card, and FDA said such cards were optional.

Other details mattered to buyers too. Test data should be independent of training data, generally drawn from different clinical sites and kept away from the developers. The device description should list compatible input devices and acquisition protocols, and any settings a user can configure, such as alert thresholds. The software version history should explain any difference between the model version tested and the one released.

On monitoring, the draft said plainly that real-world performance “may change or degrade over time.” It named data drift, where the systems feeding the device change in ways users may not see. It recommended a postmarket performance monitoring plan. But it also said FDA generally does not require such a plan for a 510(k) device unless a device-specific special control calls for one. For a De Novo device it might become a special control, and for premarket approval a condition of approval.

The cybersecurity section went beyond general software risks. It named threats specific to AI, including data poisoning, model inversion or theft, and model evasion through crafted inputs. It tied them to the cyber device requirements Congress had added to the Food, Drug, and Cosmetic Act in late 2022.

The December plan it built on

The draft built on final guidance FDA had issued in December 2024 on predetermined change control plans, often shortened to PCCPs. Congress gave FDA explicit authority for such plans in the Food and Drug Omnibus Reform Act of December 2022. The plans let manufacturers describe in advance how an AI device may be modified after authorization without a new submission.

A plan has three parts: a description of the intended modifications, a protocol for developing, validating and rolling out each one, and an assessment of their impact. In effect, the company tells FDA up front how it plans to update the product and how it will check each update. If FDA agrees, those updates can ship without going back for fresh permission.

The same week FDA released separate draft guidance on using AI to support regulatory decisions for drugs and biologics. It proposed a risk-based framework for judging whether an AI model’s output is credible for a given use. A sign that the agency was working through AI across its whole remit, it appeared in the Federal Register on the same day as the device draft. On January 6, HHS had also formally published its proposed overhaul of the HIPAA Security Rule, so health system security and compliance teams had a crowded first week.

The significance for hospitals was easy to miss. Together, the two device documents describe a product designed to keep changing after it is sold, and they put much of the job of noticing those changes in the buyer’s hands.

Hospitals usually read FDA device guidance as the manufacturer’s concern. That instinct makes sense for a scalpel or an infusion pump: once the device is approved and delivered, it behaves the same way on day 500 as on day one. For AI-enabled devices that habit is costly.

Taken together, the January draft and the December 2024 change-control guidance describe a product designed to change after it is sold. A radiology triage tool or a sepsis model may be retrained, recalibrated or have its thresholds adjusted while it runs in a hospital’s workflow, and FDA had built a pathway to allow exactly that.

From the hospital’s side, every post-purchase change to an AI device’s behavior falls into one of three kinds. The manufacturer changes the model without a new FDA review, usually within a pre-authorized plan. The manufacturer changes it in ways that need new FDA review. Or the model stays the same while the hospital’s own environment changes around it. Each kind arrives differently and needs its own control.

The sections below start with why an AI device can change at all and where FDA’s oversight stops. They then take the three kinds in turn and follow one hypothetical device through a year. Next comes what is at stake, including how it differs between a teaching hospital, a community hospital and a federal one. The last three sections cover reading a vendor’s change notice, the habits that hold the controls together, and the questions a leadership team can ask this quarter.

What an AI device is, and why it can change

Most software follows explicit rules a programmer wrote: if the number is above 100, show a warning. An AI model works differently. It is built by showing a computer thousands or millions of examples, such as past scans labeled by experts, until it learns its own statistical patterns for telling one case from another. The result is called a model, and the process of building it is called training.

Because a model learns from data, it can be improved by giving it more or better data. This is called retraining. A manufacturer might also recalibrate it, adjusting how confident its scores are. Or it might change the threshold, the cut-off above which the tool says “flag this patient.” Each of these is a small technical step. Each can change which patients get flagged.

An AI device resembles a new clinician who keeps learning on the job, which is a good thing; nobody wants a doctor frozen in their first-year knowledge. But a hospital would want to know when a colleague’s judgment had shifted in a meaningful way, and would want to check it. AI devices need the same oversight, only more deliberately, because the change happens inside software nobody can watch thinking.

Locked models, and why change still arrives

The devices FDA has authorized are generally “locked.” They do not learn by themselves from the patients they see in a hospital. A locked model gives the same output for the same input until someone replaces it. Change therefore arrives as a new version shipped by the manufacturer, which is exactly what the change-control route was built to govern.

That is reassuring in one way and misleading in another. The model does not drift on its own, so a hospital can know what version it has. But the same input rarely stays the same. Scanners, documentation and patient mix all move, and a locked model meeting new inputs behaves differently even though nothing inside it changed.

Where FDA’s line falls

Not every clinical algorithm a hospital runs is an FDA device. The 21st Century Cures Act of 2016 excluded some clinical decision support software from the device definition. Broadly, it covered software that shows information to a clinician, supports rather than replaces their decision, and lets them review the basis for the recommendation independently. Software that analyzes medical images or signals stays a device regardless.

So a hospital typically runs three kinds of algorithm under three regimes. Imaging AI is almost always a regulated device. Many deterioration and sepsis scores built into the electronic health record have been marketed as non-device decision support, though FDA did authorize a sepsis diagnostic tool through the De Novo route in April 2024. Home-grown models built by a hospital’s own data scientists fall under neither the device rules nor a vendor contract.

A fourth layer applies to the record itself. ONC’s HTI-1 rule required certified health IT developers to support “decision support interventions,” with source information users can review for predictive tools, from the start of 2025. That rule binds the record vendor, not the hospital, and it does not reach a standalone imaging device.

The three kinds of change described below apply to all of these tools. The FDA documents matter because they cover the devices with the most formal paperwork, and because they set the vocabulary a hospital can borrow for the rest.

Where the hospital fits

An AI device is often purchased by a clinical department, installed by IT, used by clinicians and supported by a vendor. Its outputs feed into decisions: which scan is read first, which patient gets a sepsis check. If the model changes, those decisions can change without anyone at the bedside knowing why.

Traditional devices have a home in clinical engineering, the team that keeps the inventory, tracks recalls and schedules maintenance. Software that runs on hospital servers or in a vendor’s cloud often falls between that team and IT. Neither team, on its own, is set up to judge whether a sepsis model’s alert rate is clinically right.

Kind one: changes that ship without new FDA review

A predetermined change control plan lets a manufacturer describe in its submission what it may modify, how it will validate each modification and how it will assess impact. Once FDA authorizes the plan, changes within it can ship without a new submission. It is a sensible way to let devices improve without years of delay.

The plan is specific. FDA expects it to list the modifications the manufacturer intends, such as retraining on additional data or improving performance within stated limits. The protocol says what data will be used, what tests each update must pass and how it will be rolled out. The impact assessment weighs the benefits and risks of each change, singly and together. A change outside those bounds does not qualify.

It also means a hospital may validate version A and, months later, run version C without any regulatory event to flag the difference. Nothing is wrong, legally or clinically. But the hospital is now running something it did not test.

Changes that never reach FDA at all

Change-control plans are the visible half of this kind. The other half is older. For any device, a manufacturer can make changes that do not significantly affect safety or effectiveness without a new submission, documenting its reasoning under its own quality system. FDA’s 2017 guidance on software changes to existing 510(k) devices sets out how manufacturers make that call.

For a hospital, the two routes look the same. A new version appears, and no FDA notice accompanies it. The controls are therefore the same, too, and the contract should not care which route the manufacturer used.

The contract and the governance group

The control is contractual and procedural. Contracts should require notice before any modification, with a plain description, the manufacturer’s validation results and updated performance figures, including by subgroup where the guidance encourages them. They should say whether the change was made under an authorized plan and identify the new version.

Internally, a governance group should decide in advance which kinds of change trigger local re-verification. A threshold adjustment on a triage tool used in the emergency department probably does. A change to the user interface probably does not. Deciding this ahead of time means nobody has to improvise when a notice lands on a busy Friday.

Such a group usually needs a small, fixed membership. It might include the chief medical information officer, the clinical lead for the service using the tool and nursing informatics. Quality and patient safety, clinical engineering, IT and information security complete it. It does not need to meet often. It needs a standing rule for which changes it sees, and the authority to say “not yet.”

A practical way to set the rule is to tier changes by what they could do to patients. Changes to thresholds, calibration, training data or intended population sit in the top tier and need local re-checking. Changes to display, speed or integration sit in the middle and need a test of the interfaces. Fixes with no effect on outputs need only a record.

Versions, records and re-checks

Version numbers should be visible in the device and recorded alongside its outputs, so that a later review of an adverse event can establish which model produced the result. If a patient is harmed and the question is “what did the software say, and why,” the first thing anyone needs to know is which version was running.

FDA’s draft points the same way. It noted that a new unique device identifier is required when a device has a new version, for devices that must carry one. Capturing that identifier, or at least the version string, in the result stored in the picture archive or health record is a modest interface task. It is far harder to reconstruct after the fact.

Local re-verification need not be a research project. The usual method runs the new version in the background on recent cases and compares its outputs with the old version and with clinicians’ reads. The hospital agrees in advance how many cases it needs and what difference would stop the rollout. For a rare condition, that sample may take weeks to gather, which is another reason to agree the plan before the notice arrives.

When the model lives in the cloud

Hosting changes the mechanics. “Cloud-hosted” means the software runs on the manufacturer’s computers and the hospital reaches it over the internet, rather than installing it on its own servers. When the model runs in the manufacturer’s cloud, an update can take effect overnight with no local installation for IT to schedule or notice.

For cloud-hosted devices, the notice clause matters more, and so does a contractual right to delay adoption of a new version for a short verification window. Without it, the hospital’s first sign of a change may be a shift in output patterns that a radiologist notices weeks later.

Vendors resist that right for a real reason: running several versions for many customers costs money and complicates their own quality system. A workable compromise is a short window during which the hospital can test the new version in a staging environment before it goes live. A hospital that cannot win that should at least get a version endpoint it can query, so that its own systems log which model answered.

Kind two: changes needing new review

Changes outside the authorized plan, or significant enough to affect safety, effectiveness or intended use, require a new FDA submission. They are less frequent and more visible. The hospital’s exposure here is timing and continuity. A manufacturer may pause features, ship a new product line rather than update the old one, or end support for the authorized version while the new one is under review.

Any of those moves can leave a clinical service stranded. A stroke team that has built its overnight workflow around an AI alert does not want to learn, mid-contract, that the version it relies on will no longer be supported.

Why the timing is hard to predict

A new 510(k) or De Novo request takes months, and longer if FDA asks for more information. Manufacturers often do not announce submissions, for competitive reasons. A change to the intended use, such as extending an adult tool to children or a new body part, almost always lands in this kind.

So does a move to a fundamentally different model. Replacing an older image classifier with a larger model trained on far more data is unlikely to fit within a change plan written years earlier. From the buyer’s seat, the product may simply be renamed and resold.

Problems that force a change

A second route into this kind is a problem. If a device has a defect, the manufacturer may correct it in the field or remove it, and must report many such actions to FDA under its corrections and removals rule. FDA may classify the action as a recall. The hospital then receives a notice, usually through clinical engineering or the supply chain team.

Recall processes in most hospitals were designed for physical products with lot numbers. They work less well for software that has no lot number and no box to quarantine. Someone has to translate “version 3.2 is affected” into which departments, workflows and past results that touches.

Contract terms and fallbacks

Contracts should address these possibilities. Useful terms include advance notice of planned submissions that affect the hospital’s use and a commitment to support the authorized version for a defined period. The hospital should also keep the right to remain on a validated version until it has verified the new one. End-of-support terms should cover access to historical outputs and audit logs after the product is retired.

For devices embedded in clinical pathways, such as stroke triage or mammography support, the hospital should also have a documented fallback if the device must be withdrawn from use. The fallback is usually simple, the way the service ran before the tool arrived, but it needs to be written down, staffed and known.

The risk grows with time. A department that has used a triage tool for three years may no longer have the staffing pattern or the habits that made the old workflow safe. Testing the fallback once a year, as hospitals already do for record downtime, keeps it real.

Kind three: same model, different hospital

The third kind is the one most likely to be missed, because nothing about the device changes. The hospital replaces a CT scanner, changes an imaging protocol, merges with a system that serves a different population, or alters a workflow so clinicians see the output at a different moment. Any of these can shift the device’s real-world performance. No manufacturer notice will arrive, because the manufacturer does not know.

A new scanner matters because an AI model learns patterns from the images it was trained on. Different equipment can produce images with subtly different brightness, sharpness or noise. To a human eye the images look the same; to a model they may not. FDA’s draft made the same point from the other direction, warning that models can learn features unique to particular scanners or sites. The same is true of documentation templates feeding a sepsis model, or a patient population that differs from the one the model learned from. Engineers call the resulting slide in performance “drift.”

Where the inputs move

For imaging tools, the inputs move in several places. Scanner replacements are obvious. Less obvious are software upgrades on existing scanners, changes to reconstruction settings or slice thickness, new contrast protocols and changes to how images are compressed or routed. Each is decided by radiology or imaging physics, usually for good reasons unrelated to AI.

For record-based models, the inputs move with documentation. A new nursing flowsheet, a changed lab analyzer with different reference ranges, a new triage protocol that changes when vital signs are taken, or a coding change can each alter what the model sees. Order sets matter too, because they change which tests are done at all.

Population and prevalence

Population shifts change performance even when the inputs look the same. A useful example is prevalence, the share of patients who actually have the condition. A tool with fixed sensitivity and specificity will produce more false alarms per true case when the condition becomes rarer. A sepsis alert tuned in winter, when infections are common, may feel noisier in summer without any fault in the model.

Mergers and new service lines change the patient mix more abruptly. A model validated in a suburban adult hospital may meet a different age profile, different disease severity or different languages in the record after an acquisition. Subgroup figures from the manufacturer help here only if the hospital knows its own patient mix.

Change management and monitoring

The control is the hospital’s own change management. Changes to imaging equipment, protocols, documentation templates or patient intake should carry a checklist question: which AI devices consume this input? Where the answer is yes, a short re-verification should follow, such as a silent comparison against clinician reads for a defined sample. “Silent” means the tool runs in the background and its answers are compared with clinicians’ judgments without being shown to anyone treating patients.

Answering the checklist question requires a map. The device register should record, for each AI tool, which systems feed it: which scanners and protocols, which interfaces, which record fields. Without that map, the question on the change form gets answered with a guess.

Ongoing monitoring adds a second line. Tracking the rate of positive outputs, override rates by clinicians and error reports over time reveals drift whatever its cause. A simple monthly chart per device, reviewed by its owner, is enough to start. If a triage tool that usually flags a steady share of scans suddenly flags far more or far fewer, something has changed, whether in the model, the scanner or the patients.

Better monitoring adds checks on the inputs themselves, such as the share of images from each scanner model or the rate of missing fields. Where outcomes are available, it adds periodic comparison with the final answer, such as the signed radiology report or a sample of chart reviews. Those comparisons lag and cost reviewer time, so most hospitals will run them quarterly or after a trigger rather than continuously.

Monitoring has a known trap. A tool that works changes the outcomes it predicts: patients flagged early get treated and do not deteriorate. Crude outcome comparisons can then make a good model look worse over time. Monitoring plans should lean on input checks and clinician agreement, and treat outcome-based figures with care.

A sepsis alert, spring and autumn

Suppose a regional hospital uses an AI sepsis alert in its emergency department. Sepsis is the body’s dangerous overreaction to infection, and early treatment matters, so the alert is popular with clinicians.

In the spring, the vendor sends a notice: under its authorized change plan, it has retrained the model and adjusted the alert threshold. Because the hospital’s contract requires notice, validation results and subgroup figures, the governance group reviews the package. The threshold change is on its pre-agreed list of triggers, so the hospital runs the new version silently alongside the old one for a short period before switching.

The silent run shows the new version firing somewhat more often, mostly in older patients. The emergency department lead tells nurses and physicians what to expect before the switch. Alert volume rises after go-live, but override rates stay steady because nobody was surprised.

In the autumn, the hospital updates its nursing documentation template. Nobody thinks about the sepsis alert, because the vendor has changed nothing. But the monthly chart shows the alert firing noticeably less often. The device owner traces it to the template: a field the model relied on is now recorded differently. The fix is a small template change, made before any patient is missed.

Run the same year without those controls. The spring update arrives overnight, and nurses notice more alerts within a week. Some start dismissing them. In the autumn the alert rate falls, and with alert fatigue already setting in, nobody remarks on the relief. The device has become less useful twice, and no record shows when or why.

Notice what made the difference in each case. In the spring, it was a contract clause and a decision taken months earlier about which changes matter. In the autumn, it was a chart and a person whose job included looking at it. Neither required new technology or a large budget; both required the hospital to treat the tool as something that could change.

Neither event was dramatic. Both were caught because someone owned the device, the contract required information, and a simple chart was reviewed every month.

Safety, liability, fairness and cost

Patient safety. An AI device that changes behavior without notice can change which patients get attention first. The issue is clinical quality, not IT. Quality and patient safety teams should treat a material change in an AI tool’s output rate as a reportable safety signal inside the hospital, the same way they treat a spike in falls.

Device reporting. Hospitals already carry federal device reporting duties. As device user facilities, they must report device-related deaths to FDA and the manufacturer, and serious injuries to the manufacturer, within ten work days of learning of them. Few hospitals have thought through how that duty applies when the device is software and the harm is a delayed or missed flag. Risk management should settle that interpretation before it is needed.

Liability and investigations. After an adverse event, a hospital will need to show what the device said, which version said it and how the hospital checked it. Without version records and monitoring, that story is hard to tell. Clinicians remain responsible for their decisions, and the manufacturer carries product liability for its software, but the hospital’s own records decide how clearly either can be shown.

Fairness obligations. The same record also supports the nondiscrimination duty that HHS placed on covered entities for patient care decision support tools, which took effect in May 2025. The Section 1557 rule applies to entities receiving HHS funding for health programs. They must make reasonable efforts to identify tools that use race, color, national origin, sex, age or disability as inputs, and to mitigate the risk of discrimination. Subgroup performance figures from the manufacturer and local monitoring are the raw material for showing that duty is being taken seriously.

Cost. Re-verification, monitoring and contract negotiation all take staff time. But the alternative cost is higher: a device withdrawn suddenly, a clinical review that cannot reconstruct what happened, or a service that has to be rebuilt around a missing tool. Modest, routine effort is cheaper than an emergency.

Clinician trust. Staff who are surprised by a tool’s behavior stop trusting it, and a tool nobody trusts delivers none of the benefit the hospital paid for. Telling clinicians about changes before they arrive, and showing them the monitoring, keeps confidence where it should be.

Operational continuity. Departments that build workflows around AI tools become dependent on them. Contract terms and fallbacks protect services when a vendor’s plans change.

Ownership. All three kinds need an owner. In many hospitals AI devices are bought by departments, installed by IT and used by clinicians, with no single person accountable for performance over time. Assigning one owner per device, with authority to suspend it and a standing link to the manufacturer, turns these controls into routine practice.

How it differs by type of organization

Academic medical centers usually have data scientists, imaging physicists and research informatics teams. They can run proper local validations and build monitoring dashboards. Their weakness is sprawl: departments buy tools independently, researchers build their own, and the register is incomplete.

Community and critical access hospitals rarely have any of those staff. They depend more on the vendor’s evidence and on simple monitoring. For them, contract terms carry more of the load, and the monthly output-rate chart may be the whole monitoring program. Even that is far better than nothing.

Multi-hospital systems face the third kind at scale. One tool may run across sites with different scanners, protocols and populations. Central governance has to decide whether a change at one site triggers re-checks everywhere, and site-level monitoring has to be comparable.

Imaging networks and teleradiology groups read for many facilities whose equipment they do not control. Input changes happen at client sites without notice. Their contracts with those sites need the same clause they want from AI vendors: tell us before you change the scanner.

Federal health systems such as the Veterans Health Administration carry an extra layer. Federal agency AI policy, set by the Office of Management and Budget, requires minimum risk practices for high-impact uses, including ongoing monitoring. Clinical AI in those settings will often meet that definition, so the controls here can double as evidence for that policy.

The case against doing this locally

The strongest objection is that FDA has already reviewed the device and its change plan, and the manufacturer has far more data than any hospital. Local re-checks on a few hundred cases, the argument runs, add noise and delay rather than safety.

The objection is right about statistics and wrong about scope. A hospital’s check is not meant to re-prove the device. It asks a narrower question: does this version behave as expected on our equipment, our documentation and our patients? Only the hospital can answer that, and FDA’s own draft acknowledged that inputs and context of use change after deployment.

A second objection is cost for small hospitals. Here the answer is proportion. A community hospital does not need a validation study for every update. It needs the notice, a tiered rule and one chart per device.

A third objection is bargaining power: a small buyer cannot force a large vendor to accept new contract terms. For a single hospital, that is often true. Purchasing groups, state hospital associations and system-level contracts carry more weight, and the terms in question are modest.

Reading a change notice without being a data scientist

When a vendor’s notice arrives, the people reviewing it will often not be AI specialists, and they do not need to be. A short set of plain checks will catch most of what matters.

What changed, in one sentence. A good notice says whether the model was retrained on new data, recalibrated, given a new threshold or changed only in how it displays results. If the vendor cannot say this simply, that is itself a finding.

Whether it was within the authorized plan. The notice should say whether the change falls under the predetermined change control plan FDA authorized, or whether it is something else. That determines which of the first two kinds the hospital is dealing with.

How it was tested, and on whom. The manufacturer’s validation results should describe the data used to check the new version. Subgroup figures show whether performance moved for some patients more than others. A model that improves on average but worsens for one group is not an unambiguous improvement. FDA’s draft asked for performance estimates with confidence intervals, and a notice that reports only a single headline number deserves a follow-up request.

Whether the test data look like us. The notice should say where the test data came from. A model checked on images from other scanner makes, or on a population unlike the hospital’s, tells the hospital less. This is where the device register’s record of local scanners and populations earns its keep.

What clinicians will notice. A higher or lower threshold means more or fewer alerts. Clinicians should hear about that before it happens, not discover it in the middle of a shift. Alert volume is closely tied to alert fatigue, the well-known tendency of busy staff to tune out warnings that fire too often.

When it takes effect, and whether the hospital can wait. For cloud-hosted tools, the answer may be “tonight,” which is why a contractual verification window matters.

A one-page template with these six checks, filled in by the device owner and signed off by the governance group, turns a technical notice into a decision a clinical leader can make with confidence.

When the notice is thin or missing

Some notices will be marketing release notes with no validation detail. The device owner should ask for the missing items in writing, and the governance group should decide whether to hold the update meanwhile. Repeated thin notices belong in the vendor’s performance review and in renewal negotiations.

Sometimes the first sign of a change is not a notice at all but a shift on the monthly chart. The owner should then ask the vendor directly whether anything changed, and record the answer. A vendor that cannot say which version is running has told the hospital something important.

Habits of a hospital in good shape

A hospital in good shape has a register of every AI device in use, each with a named owner. Its contracts require advance notice of changes, with validation and subgroup results, and preserve the right to stay on a verified version. It has agreed in advance which changes trigger local re-checking. Its change management process asks about AI dependencies whenever equipment, protocols or templates change. And each device has a simple monthly performance chart that someone actually reads.

The evidence a reviewer would ask for

An accreditation surveyor, a state inspector, a plaintiff’s expert or the hospital’s own internal auditor will ask for records, not intentions. The useful set is short. It starts with the register, with owners and input dependencies, and the governance group’s minutes and tiering rule. Then come each change notice with its completed checklist, re-verification results and the monthly charts with notes on any investigation.

Version logs complete the set. For any past result, the hospital should be able to show which model produced it. Keeping those records for as long as the related clinical records is the safe default, and counsel can advise on specifics.

The usual lapses

• Treating go-live as the finish line. Validation at purchase says nothing about version C.
• Assuming FDA oversight covers the hospital’s use. A pre-authorized change is lawful; it is not necessarily verified in your setting.
• Forgetting the hospital’s own changes. New scanners and templates can move performance as much as a vendor update.
• No owner. When everyone touches a device, nobody watches it.
• No version trail. Outputs stored without version numbers make later reviews guesswork.
• A register that stops at FDA devices. Record-embedded scores and home-grown models change too, and need the same three controls.
• Monitoring without a stop rule. A chart nobody is empowered to act on is decoration.

Who is watching each device

Leadership teams can test where they stand with a handful of direct questions. The answers will usually reveal one of the three kinds of change with no control attached.

1. How many AI-enabled devices are we using today, and who owns each one?
2. Which of them are covered by a predetermined change control plan, and do our contracts require notice before those changes ship?
3. Can we tell, for any past result, which version of the model produced it?
4. When we replace a scanner or change a template, does anyone ask which AI tools depend on it?
5. Who looks at each device’s performance every month, and what would make them suspend it?

A hospital that can answer all five has turned a regulatory design choice into ordinary operations. One that cannot is running software it last tested at purchase.

With hindsight

The January 2025 draft was still listed by FDA as a draft in October 2026. Draft guidance can remain unfinished for a long time, and in the meantime it signals the agency’s thinking without binding anyone. Hospitals that waited for a final version before acting were, in effect, waiting on a document that had not arrived.

The comment period closed in April 2025 as planned. By then the political setting had shifted. The new administration revoked the previous executive order on AI on January 20, 2025, and federal AI policy turned toward promoting adoption and reducing regulatory burden. FDA kept issuing AI-related documents through that change, but the emphasis moved toward speed.

The change control plan guidance, by contrast, was final and in use, so the first kind of change was an established route for AI device updates. FDA updated that final guidance in August 2025. Its public list of AI-enabled devices began marking some authorizations as coming “with PCCP,” including entries from late 2025 and mid-2026. Updates under these plans were not hypothetical; they were the normal way AI devices could evolve.

That makes the contractual and procedural controls for pre-authorized changes less a matter of anticipation and more a matter of routine. A hospital buying an AI device in 2026 should expect a change plan to come with it, and should expect version C to follow version A.

The regulator’s capacity

FDA faced staff reductions in 2025 that raised questions about review capacity. HHS announced a large restructuring in late March, and FDA was among the agencies that lost staff in the April reductions. For hospitals, the practical implication was not that oversight disappeared. It would simply be unwise to assume the regulator would catch problems that only show up in a particular hospital’s setting.

Monitoring stayed an open question

The clearest sign that postmarket monitoring was unresolved came in September 2025. FDA published a request for public comment on how to measure and evaluate the real-world performance of AI-enabled devices, including detecting drift. It asked which metrics matter, what should trigger a deeper review, which data sources to use and how human use of the tools affects performance over time. FDA said the request was for discussion, not guidance, and comments closed on December 1, 2025.

Those were the questions this article’s third kind of change turns on. FDA asking them in public, nine months after the draft, confirmed that no settled method existed for the regulator or the industry. Hospitals running devices in the meantime had to answer them locally, with whatever data they had.

FDA’s Digital Health Advisory Committee also kept generative AI on its agenda. After a November 2024 meeting on lifecycle questions for generative AI devices, FDA announced another in September 2025 on generative AI tools for mental health. Generative tools raise the change problem in a sharper form, because their underlying models are often updated by third parties.

The rules around the device

The manufacturers’ own quality rules changed underneath all of this. FDA’s amended quality system regulation, aligned with the international standard ISO 13485, took effect on February 2, 2026. The January draft had already flagged the switch. For hospitals, it changed little directly, but it shifted the vocabulary in which manufacturers describe how they manage change.

In January 2026 FDA reissued its clinical decision support and general wellness guidances, redrawing the line around software it would oversee as a device. Clinical decision support software is the broad family of tools that help clinicians decide, from drug interaction warnings to risk scores. Where FDA draws its line determines which tools come with device-style documentation and which do not, which in turn affects how much information a hospital receives from the maker.

Other obligations landed on the hospital side regardless. The Section 1557 duty on patient care decision support tools took effect in May 2025. Federal health systems also faced the Office of Management and Budget’s April 2025 memorandum on agency AI use, which kept monitoring among the minimum practices for high-impact AI. Neither depended on the FDA draft being finalized.

What held up

Post-purchase monitoring stayed on hospitals’ desks throughout. Whatever the regulatory status of a given tool, the hospital still runs it on its own patients, with its own equipment and workflows. The argument that a validated AI device will not stay the one a hospital runs held up. The change route was used, the monitoring question stayed open, and the regulator had fewer staff to look.

Less clear is how far the draft’s transparency ideas reached buyers. How many manufacturers put model cards or subgroup figures in front of hospital users is hard to judge from outside, and we would not claim the practice became standard. Hospitals that wanted that information still had to ask for it in contracts.

Of the three kinds of change, environmental change remains the least governed, because it arises inside hospitals’ own equipment and workflow decisions, where AI dependencies are seldom recorded. That is also where leaders have the most direct control. Adding one question to change management, which AI tools use this, costs almost nothing and closes the gap no vendor or regulator can close for them.