Most organizations can produce a list of their servers. Many can produce a list of their vendors. Very few can produce a list of the AI systems operating inside the business right now: which ones, used by whom, touching what data, holding what permissions.
That gap has a name. Shadow AI is the AI in use across an organization that nobody has recorded, reviewed, or assigned an owner. It is worth understanding clearly, because it is not a new category of risk. It is an old problem, asset inventory, appearing on a new surface. And it quietly makes every other risk number less reliable.
Shadow AI is three problems, not one
The assistants people use. Employees paste code, customer records, contract language, and forecasts into consumer and enterprise AI tools. Some of that use is sanctioned. Much of it is not, and the organization has no log of what left, when, or to where. A pasted document cannot be recalled.
The agents systems run. Coding agents, workflow automations, and in-house builds increasingly hold real credentials and take real actions against real systems. When one of them behaves badly, whether through a bug, a bad instruction, or a deliberate manipulation, most organizations cannot reconstruct what it touched.
What those agents run on. Models, connectors, plugins, skills, and packages get assembled at speed, often from public sources, usually without review. This is the least discussed of the three and the most familiar in structure. It is supply chain risk. The difference is that a component can be added in an afternoon, and some of those components arrive carrying instructions that a model will read and follow.
This is an inventory problem, not a new risk category
The instinct when AI arrives is to stand up a separate AI risk program. A separate assessment, a separate register, a separate budget line, a separate slide in the board pack.
That instinct should be resisted, and the reason is not philosophical.
AI does not introduce a new physics of loss. It lands on controls the organization already has or already lacks. When an assistant leaks customer data, that is data classification and data loss prevention failing on a new egress path. When an agent with over-broad credentials damages a production system, that is privileged access management. When a poisoned document redirects an agent into an action nobody authorized, that is input validation and least privilege on a surface where neither was designed in from the start. When a third-party AI feature quietly processes regulated data, that is supplier management.
The correct treatment is to score AI on the controls it actually lands on and report it inside the same exposure number as everything else. The alternative produces two numbers that cannot be added together and a board that has to decide which one to believe.
This is how Core3 handles it in practice. The AI risk surfaces on Know are scored as control effectiveness on the same footing as every other area, and in the illustrative scenario shown there the weakest surface is third-party AI subprocessors, which is the same supplier management gap the roadmap already addresses. No separate register, and no separate budget line.
But controls can only be scored on systems that are known to exist. Which is why inventory comes first.
You have done this before
In industrial environments, the first genuinely useful step in quantifying cyber risk is almost always asset discovery across operational technology and control systems. Not because an inventory reduces risk on its own. It does not. It is foundational because an exposure model built on a partial asset list produces a confident number that happens to be wrong, and a wrong number is worse than no number when a board is allocating capital against it.
The AI layer sits at exactly that stage today. The modeling is available. The frameworks exist. What is usually missing underneath is a defensible list of what is actually running. If the underlying method is unfamiliar, cyber risk quantification covers how exposure gets expressed in dollars in the first place.
Three questions worth asking
An executive should be able to get a straight answer to each of these. The answers, not the existence of a policy, are the measure of whether AI governance is real.
- Which AI systems are in use, by which teams, for what purpose? Not which ones are approved. Which ones are in use.
- What data is leaving the business, and to whom? Including the third parties behind the tools, and the subprocessors behind them.
- If an agent did something wrong last quarter, could we reconstruct what it did? This is the one that tends to be answered honestly only after an incident, and the honest answer is usually no.
Most of what this requires, you already have
The objection raised first is almost always effort. This sounds like a large discovery project layered on top of everything else already underway.
Usually it is not. Identity provider logs show which AI services people authenticate to. Expense and procurement records show which subscriptions are being paid for and which vendors have quietly shipped AI features into products already in use. Network and proxy telemetry shows where traffic is going. Code repositories record which models, libraries, and connectors were added, and by whom.
Almost everything needed is information the organization already keeps. The work is assembling it into one view and scoring it, not generating it from nothing. That distinction is the difference between a six-week project and a six-month one.
Where this sits in a program
Know. Establish the picture. Build the inventory from data that already exists, identify where AI touches sensitive data and privileged systems, and express what that exposure is worth in dollars, inside the same model as every other category.
Own. Run the governance program. Acceptable use, supplier and subprocessor review, logging and monitoring on the AI surface, oversight of agents that hold credentials, and mapping to whichever framework applies to the business, whether that is the NIST AI Risk Management Framework, ISO 42001, or the EU AI Act where it is in scope.
Prove. Demonstrate it worked the same way every other control area is demonstrated. The AI contribution to exposure moves down, and it shows up in the one number the board already tracks. No separate AI scorecard, because a separate scorecard is how a risk category gets managed in isolation and funded on sentiment.
The question to ask in the next meeting
Not do we have an AI policy. Most organizations now do, and a policy without an inventory is a statement of intent.
Ask instead: how many AI systems are operating in this business, and how do we know that number is right?
If the answer is a specific number with a documented basis, the program is real. If the answer is an estimate, a range, or a pause, that is not a failure. It is the work, correctly located. It is also the least expensive part of the program, and the part everything else depends on.