Your AI arrived in a release note, not a purchase order

Ask two people in your organization for the list of AI in production and you get two lists of different lengths.

The governance committee’s list contains the things that went through a committee: the ambient documentation pilot, the deterioration model, the imaging triage tool, the coding assistant. Every one of them has a business case, a security review and a named sponsor, because every one of them required somebody to buy something.

The list your change advisory board could assemble from twelve months of upgrade tickets is longer. The extra items are not projects. They are features: a score that appeared as a column in a quarterly EHR release, a drafting button that turned up in the inbox, a ranking added to the population-health module by a vendor’s routine update, a triage suggestion enabled by default in the patient portal. Nobody concealed any of it. It was in the release notes, which is to say it was disclosed to an application analyst on a Tuesday.

The second list is longer because the first list is built from the wrong event.

The intake is attached to procurement

Almost every AI governance process in operation today is triggered by a purchase. Someone requests a tool, the request routes to a committee, the committee tiers the risk and assigns an owner, and the registry entry is created as a condition of the contract. That machinery works. It is why the deterioration model is on the list, correctly tiered, with a named executive against it.

It is also, by construction, silent about anything that did not require a purchase order.

Enterprise clinical software has stopped selling AI as a separate thing to buy. It ships inside the maintenance you already pay for, in the release train you already accepted when you signed. The commercial logic is ordinary: features that arrive inside a renewal are stickier than features that have to survive a procurement cycle. The operational consequence is not ordinary at all. The event that introduces a new model into a clinical workflow is now a version upgrade, and the person closest to that event is a systems analyst working through a regression test plan.

Look at what that plan asks. Does the interface load, do the interfaces pass, does the report still run, did anything break. It is a very good checklist for the question it was written to answer, which is whether the upgrade damages what already worked. There is no line on it that asks whether the upgrade added something that generates a prediction, and no route to send the answer if there were.

So the model goes live having been tested for breakage and never assessed for judgment. It has no risk tier, because tiering happens at intake and no intake occurred. It has no baseline, because baselines are locked at deployment and nobody recorded a deployment. It has no owner, no threshold and no review cadence, which means it cannot degrade in any way that will reach a person with the authority to switch it off. It is not that these features are dangerous. It is that they are the only things in your environment producing output a clinician acts on with no one accountable for the quality of that output, and they got there through the door marked routine maintenance.

The frameworks specify the artifact and skip the plumbing

Everyone with a published opinion agrees the inventory comes first. The NIST AI Risk Management Framework, published by NIST in January 2023, puts inventorying AI systems inside its MAP function, ahead of measurement and management, for the obvious reason that you cannot measure a system you have not listed. The Joint Commission’s September 2025 guidance with the Coalition for Health AI names governance structures and an inventory of AI in use. CHAI’s governance playbooks of 28 May 2026 say the same. When the Joint Commission announced its Responsible Use of AI in Healthcare certification on 1 June 2026, the inventory sat at the front of the shape those documents describe.

None of them tells you where to put the trigger. That is not a criticism — frameworks specify artifacts, and where an intake hook attaches inside a particular organization is a local design problem — but it explains a pattern worth naming. A register can be populated and still not be complete, and the difference between the two is entirely a question of what event creates a row. An assessor’s first question is to see the register. The harder second question is how it was compiled, because that is the one that tests whether the document will still be true after your next upgrade cycle.

There is a number that belongs in this section: the share of production AI in a typical health system that arrived without a purchase order. I do not have one I would stand behind, and inventing a plausible one would be self-defeating in a piece whose entire argument is that you should go and count. The structure holds without it. Two lists, different lengths, one trigger attached to the wrong event.

One thing genuinely worth asking your own people rather than a newsletter: ONC’s HTI-1 final rule, published in December 2023, introduced source attribute disclosure for predictive decision support interventions in certified health IT. Whether what your EHR vendor publishes under that heading gives you a usable list of what is switched on in your build is a question for your health IT leadership and your regulatory counsel. It may be a shortcut. Treat that as a question to ask, not an answer to assume.

What this means Monday

You do not need a new committee, a new tool or a budget line. The surface you need already exists and already meets weekly.

Your change advisory board sees every vendor release before it reaches production. It has a standing agenda, a form, a quorum and the authority to hold a change. It is the only body in the organization that reliably encounters the event that now introduces most new AI into your workflows. It has simply never been asked to look for one, because when its process was written, software that made judgments came with an invoice attached.

The governance committee cannot fix this by asking harder at its own meeting. Everyone in that room is downstream of an intake that already failed to fire.

The one thing to do

Add a question to the change advisory board’s standard form, and make an answer mandatory before a change is approved:

Does this release enable, modify or retire any feature that produces a prediction, a score, a ranking, a risk flag or drafted text that a person will act on?

If the answer is yes, the change does not ship until there is a registry entry with a named owner and a risk tier. If the analyst cannot tell from the release notes, that is itself the answer, and the question goes to the vendor before the upgrade window rather than after it.

That is one field on a form your organization already uses. It costs a sentence of process design and no money at all. And it changes what the register is: not a list of what you bought, which is a historical document, but a list of what is running, which is the only version an assessor, a board or a bad quarter will ever ask you for.