The Shadow AI Inventory Checklist

Ask a portfolio company's CTO for a list of every AI system running inside the business, and the usual answer is a guess followed by a promise to check. A company that does not know which AI systems it runs cannot govern them. At the next diligence process or board review, someone will ask for that list, and "we're looking into it" is not an answer anyone wants to give.

Shadow AI is the ordinary result of SaaS vendors adding models to their products and employees opening free-tier accounts on their laptops. None of it required a purchase order. Most of it never went through procurement, security review, or the CTO's desk. It accumulated the way shadow IT always has. The difference is that these tools can read sensitive data, generate output that looks authoritative, and act on production systems without anyone signing off.

The first step in building AI governance that holds up under scrutiny is an inventory of every AI system in the business. The checklist below covers how to run that sweep.

Where to look for shadow AI

SaaS features with embedded LLMs. The support desk, the marketing platform and the analytics tool are typical examples. Most SaaS products a company already pays for have added an AI feature in the last eighteen months, often switched on by default. Nobody re-reviewed the data processing terms when that happened.

Browser extensions and individual-seat tools. ChatGPT, Copilot, Claude, and a dozen others, used by staff on personal or unmanaged accounts. These are the hardest to find because they leave no line item and no admin console. The only trace is a browser extension or a personal login.

AI features inside vendor products. The ERP, the CRM and the HR platform are the usual cases. Vendors are adding AI-assisted features under contracts that were signed before those features existed. The vendor relationship was approved, but the AI feature inside it usually was not.

Internal scripts, notebooks, and agents connected to production data or APIs. Engineering and data teams build things fast. A typical example is a notebook that calls a model API against a customer database. Another is an internal agent that started as a proof of concept and now runs a production process. Neither usually appears on any architecture diagram.

Model APIs called directly from the codebase. Grep the repo. A common result of a first sweep is an API key for a model provider, used by a service that nobody ever documented as "an AI system."

Data pipelines feeding any of the above. For each system, record what data flows into it and whether that includes PII, customer records, or anything contractually restricted. That data flow is usually undocumented in the same places the systems are.

What to capture per system

A list of tool names is not an inventory. For each system found, the catalog needs:

• Purpose. What business function it serves and who asked for it.
• Data touched. What it ingests or outputs, flagged explicitly if that includes PII or other sensitive data.
• Business owner. The person accountable for it, not the person who happened to set it up.
• Approval status. Sanctioned, informally tolerated, or genuinely unknown until this sweep found it.
• Vendor or provider. Who operates the model, and whether it's a name-brand provider or a smaller tool with thinner data practices.
• Whether the vendor trains on your data. This single term, buried in most vendor agreements, determines whether proprietary or customer data is leaking into someone else's model weights.
• A rough risk tier. Not a full assessment, just enough to know what needs attention first versus what can wait for the next pass.

How to run the sweep this week

This doesn't require a six-month engagement to start.

1. Pull the SaaS and expense list. Finance and procurement records surface most of the sanctioned and semi-sanctioned tools in an afternoon.
2. Survey the teams. A short, direct question to department heads gets more complete answers than a security bulletin: "what AI tools does your team use, including the ones nobody approved?"
3. Scan the codebase for model-API calls. A search for the major providers' SDKs and API key patterns across every repo takes an engineer a day.
4. Check identity and SSO logs. Application access logs will show sign-ins to AI tools that never went through procurement, including free-tier and personal-account usage on company devices.

Cross-reference the four sources. The resulting list is almost always longer than expected, and that is normal. The sweep is designed to find the systems nobody knew about.

The inventory is step one

Building the list does not fix anything by itself, but every later fix depends on it. Once every system is named, owned, and tagged with the data it touches, the estate can be scored against a maturity model. It can also be checked against the EU AI Act where it applies, and against whatever a board or an acquirer's diligence team asks next. Every system on the list is also a line of spend nobody has been tracking. That spend is the base layer of the six-layer model of AI spend in the AI Cost Optimization Framework.

The next step is to score the estate once it is visible. The AI Governance Quick Scan gives a fast result, and the full AI Governance Readiness Assessment gives the complete score. For companies that need the inventory built and the roadmap that follows it, the AI Governance Program runs that work end to end, starting with Discover.