- Most AI risk conversations fixate on unsanctioned "shadow" AI. That is one lane of three, and the other two are just as exposed.
- The three lanes are the AI your people bring, the AI you approved, and the AI that runs on its own without a person at the keyboard.
- You cannot protect, monitor, or report on any of it until you can name it. That is what the Identify step in the NIST frameworks is for, and it is the one most teams skip straight past.
- Seeing everything is not the same as blocking everything. The goal is a live inventory, not a wall.
In almost every conversation I have with a security leader about AI, we end up in the same place. They tell me they have a shadow AI problem, meaning staff pasting things into ChatGPT that should never leave the building. They are right, and it matters. But when I ask what else is running, the room goes quiet. The approved copilot that finance switched on last quarter, the API key a developer wired into a side project, the agent someone spun up to triage support tickets over the weekend. None of that is shadow AI in the usual sense, and almost none of it is on anyone's list.
That gap is the whole problem. We have collectively decided that "AI risk" means "employees using tools we did not sanction," and in doing so we have drawn the map too small. There are three distinct kinds of AI usage in a normal organization today. Each one carries real exposure. Most security teams can see one of them clearly, glimpse the second, and have no idea the third exists.
The map everyone is missing
Here is the framing I keep coming back to. Forget tools and vendors for a moment and sort AI usage by who is driving it and whether you signed off. You get three lanes.
Unsanctioned
AI your people brought in on their own, without asking. The classic "shadow AI."
Sanctioned
AI you approved and rolled out, and then quietly filed under "handled."
Programmatic
Agents, API keys, and service accounts acting on their own, with no human at the keyboard.
The reason this matters is not tidiness. It is that your controls, your policies, and your regulator all care about the activity, not the label on the app. If you only govern one lane, you are governing a third of your real footprint and reporting on it as if it were the whole thing.
Lane one: the AI your people bring
This is the one everyone means when they say shadow AI, so I will keep it short. Someone in HR pastes a batch of CVs into a chatbot to rank them. A finance analyst drops a spreadsheet into a free tool to have it explained. None of it is malicious. People are trying to get their work done with tools that are genuinely good at helping.
The instinct is to ban it. In my experience a ban does not remove the usage, it just moves it somewhere you can no longer see, onto phones and personal laptops and home accounts. I have written about that trap at more length in The Valley of Shadow AI. The point for this piece is narrower: even if you handled this lane perfectly tomorrow, you would still be blind to the other two.
Lane two: the AI you approved
This is the lane that quietly worries me the most, because it hides behind a decision that already got made. You ran a procurement process, you signed a contract, you switched on a copilot or an approved assistant, and everyone moved on. Approved became a synonym for safe, and the file got closed.
The trouble is that a sanctioned tool is not a static thing. A copilot inherits the access of whoever is using it. Point it at a mailbox, a document store, or a chat history and it can read everything that person can read, which is usually far more than anyone realized when the tool was approved. It can summarize a channel it was never meant to be in, surface a file from a folder someone forgot to lock down, or pull a sensitive thread into an answer for a colleague who should never have seen it. Nobody broke a rule. The tool did exactly what it was designed to do, across a data footprint no one mapped.
Approved is not the same as governed. Approving a tool is a decision you make once. Governing it is something you have to keep doing, because the data it touches and the people using it change every week.
Lane three: the AI that acts on its own
This is the lane most inventories do not list at all, and it is growing the fastest. An agent that triages tickets. A script that calls a model through an API key to enrich records overnight. A service account wired into a workflow that summarizes and routes documents without anyone watching. This is AI usage with no human at the keyboard, and it behaves in ways that should make a security team pay close attention.
It authenticates, often with a long-lived key or a service account that never sleeps. It persists, running on a schedule or a trigger rather than a person opening a browser tab. And it chains actions together, reading one system, deciding something, then writing to another. In most organizations not one of them appears on the AI inventory, because there is no AI inventory.
Why "Identify" comes first
None of this is a new problem in security, which is oddly reassuring. The frameworks already tell us where to start. Both the NIST Cybersecurity Framework and the NIST AI Risk Management Framework begin in the same place, with the unglamorous work of knowing what you have.
In the CSF it is the Identify function. In the AI RMF it lives in the Map function, understanding the context and cataloguing the systems in play. Different words, same instruction: inventory before you protect, detect, or respond.
The reason this step comes first is not bureaucratic. Every control you put in place afterwards depends on it. You cannot write a meaningful AI policy for usage you cannot see. You cannot monitor a tool you never listed. You cannot report to a board, or an auditor, on a footprint you have only partly counted. Skip Identify and everything downstream becomes a guess dressed up as a control. The organizations that struggle with AI governance are almost never short on policies. They are short on an accurate picture of what is actually running.
What a real AI inventory answers
You do not need a platform to start. You need a picture. If you cannot answer these six questions today, that is your first project, ahead of any policy or purchase. For every bit of AI activity in the organization, across all three lanes, can you say:
- Who is using it. A named person, a team, or an automated identity.
- Through what. Which tool, model, or interface the activity flows through.
- On what data. What the AI can actually reach, not what you assumed it could reach.
- Sanctioned or not. Whether you approved it, and whether that approval still reflects how it is used.
- Human or automated. Whether a person is driving each interaction or a key and a schedule are.
- Can you show it. Whether you could produce a record of what happened if someone asked, calmly, next week.
Most teams can answer two or three of these for lane one and almost none of them for lanes two and three. That is not a failing, it is just where the field is. But it is the honest starting line, and naming it beats pretending the shadow AI conversation covers the whole ground.
Where this leaves you
The point of seeing all three lanes is not to slam the brakes on any of them. Innovation and control are not opposites here, and the framing that pits them against each other is how organizations end up either reckless or paralyzed. The teams that keep pace are not the ones who said no. They are the ones who could answer a simple question on any given morning: what AI is running here, and what is it touching. Get that picture first. Everything else, the policy, the tooling, the reporting, gets easier once you can see the whole board instead of one lane of it.
See all three lanes, not one
Unseen gives security teams a live inventory across unsanctioned, sanctioned, and programmatic AI, with a record you can stand behind.
See a Demo