Your shadow AI inventory is stale before you finish it

Someone gets handed shadow AI detection as a project. They spend three weeks pulling CASB logs, OAuth grants, and browser telemetry, and they produce a spreadsheet with 140 rows in it. Everyone is impressed. Two months later the spreadsheet is wrong and nobody can tell you which rows went bad.

I have written before about building that first inventory as amnesty instead of audit. That post is about getting an honest list. This one is about the thing that happens next, which is that the honest list goes stale faster than any inventory you have run before, and for reasons that are structural rather than sloppy.

Why this inventory decays faster than asset inventories

A server inventory ages slowly. Servers get built deliberately, by someone with a ticket, and they sit there. An AI inventory ages on a different clock, because of where the AI comes from.

Most new AI in your environment does not arrive as a new vendor. It arrives as a feature inside a vendor you already approved. Your CRM shipped a summarizer. Your ticketing system added a suggested-reply model. Your document platform turned on a chat sidebar and defaulted it to on. None of that crosses procurement. None of it changes your vendor list. Your SaaS inventory is identical this morning and the data flow underneath it is not.

The second source is identity, not software. A developer with a personal API key. A marketing contractor whose OAuth grant to a summarizing app is still live nine months after the project ended. A departed employee's token that nobody revoked because token cleanup was never part of offboarding. Those are not applications you can scan for. They are grants.

The third is model swaps under a stable name. A vendor you cleared last quarter switches which model backs the feature, or which region it runs in, or turns on a training default. The product name on your spreadsheet did not change. The retention answer did.

That is three different decay mechanisms, and only one of them is visible to the discovery tooling most teams buy first.

Snapshot versus control

The distinction worth holding is between a snapshot and a control.

A snapshot answers what was running on a date. It is useful once, for scoping and for shock value, and it is genuinely worth producing. But it cannot answer the question anyone actually asks you later, which is whether anything changed since.

A control answers the delta. It has an owner, a cadence, a defined input, and a defined action when something new shows up. The difference is not sophistication, it is whether there is a next run and whether that run produces a diff instead of a new list.

Most shadow AI programs I have seen stall at the snapshot, then quietly rot, because the spreadsheet had no owner after the project closed.

Four inputs that catch the three decay paths

You do not need a platform to do this. You need four feeds and a diff.

Identity provider OAuth and app grants. This is the highest-yield feed and the one most teams skip, because it catches the case where the application was never installed on anything. Pull the grant list monthly, diff it against last month, and look at what is new and what belongs to someone who left. Scope matters more than app name: a grant that reads all mail is a different row from one that reads a calendar.

Egress to model endpoints. Your proxy, SSE, or DNS logs already know which hosts your endpoints are reaching. Destinations that are model API endpoints, distinct from the consumer web interfaces, tell you where code is calling a model directly, which is the personal-API-key case. Consumer interface traffic tells you where people are pasting.

Vendor feature changes on things you already approved. This one is manual and it is the one nobody assigns. Once a quarter, walk your top twenty SaaS vendors and ask what AI features shipped, whether they are on by default, and whether the retention or training answer moved. Your existing vendor contacts will tell you if you ask.

Expense and card data. A recurring charge to an AI vendor that is not on your approved list is a row, and it is a row with a name attached, which makes the follow-up conversation short.

Four feeds. A monthly diff on the first two, quarterly on the second two.

The row format that survives contact with a regulator

The reason most inventories cannot be used later is that they captured the app name and not the facts that decide anything. A row is useful if it answers, without a follow-up meeting:

What application, and what specific AI feature inside it. Who or what is the identity using it, a person, a service account, or an OAuth grant. What class of data can reach it. Whether there is a signed agreement behind it, and where regulated data is involved, a BAA. What the retention window is and whether inputs train the model. Whether the session is logged anywhere you can review. And when it was last seen, which is the field that makes the whole thing a living document instead of an archive.

That last column is the one people leave off and it is the one that makes a diff possible.

What to do with the new rows

A diff is only a control if something happens when it is non-empty. Keep the triage crude, because a crude rule that runs beats a nuanced one that does not.

If the row touches regulated data and has no contract and no logging, it gets dealt with this week. That is the fire.

If it touches regulated data and has a contract, it gets a real review and probably a sanctioned path.

If it touches no regulated data, it gets recorded and left alone. Spending your limited attention on an unapproved meeting-notes tool that never sees a patient record is how the program loses credibility with the people you need honest answers from.

And any row that keeps reappearing after you remove it is not a compliance problem. It is a task your sanctioned tooling does not cover, and it belongs on a roadmap rather than in a remediation queue.

The part that decides whether this survives

Name an owner and put the diff on a calendar. Not the inventory, the diff.

Every shadow AI program I have watched fail, failed at the same place: the project ended, the person moved on, and the artifact became a file with a date in the name. Every one that worked had somebody whose job included looking at the delta on a fixed cadence and saying either nothing new or here are four things.

The inventory is not the deliverable. The second run is.