You Cannot Write a Policy for AI Tools You Have Not Named

A survey crossed my desk this week with a number in it that is easy to skim past and worth sitting with. A majority of healthcare providers and payers report that employees are already using unauthorized AI tools. Fewer than 40% have a detailed policy governing that use. About a third say they feel prepared for AI-assisted attacks.

Read those three numbers together and the shape of the problem is clear. The AI is already inside. The governance is not. And the usual response, another policy memo to all staff, does not close the gap, because you cannot write an enforceable policy for tools you have not named.

This is the part most governance conversations skip. They jump straight to policy language, approval workflows, and acceptable-use rules, all of which assume you already know what people are using. In a regulated environment, you almost never do. The scribe app a clinician found that transcribes visits. The chatbot someone in billing pastes claims into. The browser extension that summarizes patient messages. None of that shows up in a procurement record, because nobody procured it. It arrived one download at a time, solving a real problem faster than the sanctioned tooling ever did.

Shadow AI is a demand signal, not a discipline problem

The instinct is to treat unauthorized AI use as a compliance failure and reach for the stick. That instinct is wrong, and it makes the problem worse.

People adopt shadow AI for the same reason people have always adopted shadow IT. The official path is slow, or missing, and the work is due now. A nurse using an unapproved transcription tool is not trying to violate policy. She is trying to get home before nine. Every shadow tool on your network is a place where sanctioned tooling failed to show up, and punishing the person who found a workaround guarantees the next one stays hidden.

Which leads to the single most important design decision in this whole exercise. Your first pass has to be amnesty, not audit. If admitting to a tool gets someone written up, your inventory will be a work of fiction, and a fiction is worse than nothing because it feels like coverage. You want the messy, honest list. You get the honest list by making it safe to tell the truth.

The first artifact is an inventory, not a policy

So before the policy, build the inventory. One row per tool per use. It does not need software, a platform, or a consultant. A shared spreadsheet and one honest question to each team lead gets you started: what are your people actually using to get work done?

The inventory only earns its keep if each row captures the things that decide risk. In a regulated setting, two columns carry most of the weight.

The first is sensitive-data touch. Does this tool see PHI, PII, PCI, or other regulated data, in either the prompt or the output? A tool that rewrites marketing copy is a different animal from one that ingests a patient note, even if it is the same underlying model. The data it touches sets the stakes.

The second is whether a contract stands behind it. Is there a signed agreement, and where PHI is involved, a Business Associate Agreement? A sanctioned enterprise tool with a BAA and a no-training clause is a managed risk. The same model reached through a personal free account, with inputs retained and used for training, is an unmanaged one. Same technology, opposite risk posture, and the only thing that tells them apart is the paperwork.

Add a few more, retention and training behavior, whether the use is logged anywhere you can review, whether access runs through managed identity or a personal login, and whether you have a kill switch, and you can rank the whole list. The rows that touch regulated data with no contract and no logging are your fire. Start there. Not with the tool that is merely unapproved, but with the one that is unapproved and pointed straight at your most sensitive data with nothing standing behind it.

Then the policy, short enough to be read

Only once you can see the real inventory does policy become useful, and the useful version is short. A policy nobody reads governs nothing. A handful of statements people can actually hold in their heads will outperform a twelve-page standard every time.

Register before you use. No regulated data in unsanctioned tools. Personal accounts are not work accounts. Assume vendor retention until the contract says otherwise. Every sanctioned tool has a named owner and a kill switch. And the one that makes the rest work: report, do not hide. Surfacing a tool is expected and safe. Quiet use is the risk.

That last line is not a courtesy. It is the control that keeps the inventory alive. The moment reporting a tool feels dangerous, your map goes stale, and a stale map of your AI exposure is exactly the document you do not want to be holding when a regulator, an incident, or a board member asks what you are running.

This maps to a framework you already have

None of this is novel. It maps cleanly onto the NIST AI Risk Management Framework, specifically the Govern and Map functions, which is why the worksheet columns are tagged to those outcomes. If you have started down ISO/IEC 42001, the inventory feeds it too. The point of anchoring to a real framework is not to sound rigorous. It is so the inventory is not a one-off spreadsheet that dies in a drawer, but the first input to a governance program that keeps going.

And it has to keep going, because shadow AI is not a mess you clean up once. New tools arrive every month. Run the inventory quarterly, treat each pass as amnesty, and watch which categories keep reappearing. Those recurring rows are telling you where your sanctioned tooling is still failing to show up. That is not a governance failure. That is a roadmap.

Where to start

We put the worksheet and the minimum policy language in the CarbeneAI AI Governance Toolkit, free, under a Creative Commons license, no sign-up. It is a one-page inventory mapped to NIST AI RMF, plus the six policy statements above. You can read it, fork it, and adapt it to your organization in an afternoon.

The Shadow AI Inventory and Policy Kit sits alongside the maturity self-assessment and the full governance framework template. Start with the inventory. Run it as amnesty. Name what you are running before you try to govern it.

A template does not govern anything. People do. But naming the tools is where the honest work begins.

The rest of the framework

The inventory is the entry point, not the whole program. Once you can see what you are running, you need somewhere to put the decisions that follow, and that is what the full framework template is for.

The AI Governance Framework Template is the second document in the same repository. It is a complete, adaptable governance program: a governance structure and accountable owners, ethics principles, a four-tier risk classification, an end-to-end AI lifecycle, data governance, a security threat model, a section on agentic AI where the failure mode moves from a wrong answer to a wrong action, vendor evaluation, regulatory mapping, workforce readiness, and metrics. You search and replace one placeholder for your organization name and delete the sections that do not apply.

If you are not sure where to begin, the same toolkit includes a maturity self-assessment: ten questions across six dimensions that give you a directional read in five minutes, so you spend your effort on the weakest area instead of the loudest one. Run the assessment, use the inventory to see your shadow AI, then pull the framework sections that match where you are exposed.

All three are free, CC BY 4.0, and gated behind nothing: github.com/CarbeneAI/AI-Governance-Toolkit.