The board wants a number for the AI rollout. The honest answer is “around 30 to 50 tools in active use, depending on how you count.” That number is conservative. Most CISOs I have talked to in the last quarter think the real number is north of 100 if you include browser extensions and shadow API keys. None of them can prove it. That is the problem.
Six months ago the average security team had a shadow IT problem that looked like SaaS sprawl. A few hundred SaaS apps, mostly sanctioned, with maybe 20 to 30 percent running outside the procurement process. The job was to discover them, score them, and either approve or block. Most teams had a tool for this. It mostly worked.
The same shape is back, but the surface is different and the discovery tools are not keeping up.
The inventory problem
A SaaS app is a fixed thing. It has a domain. It has a login page. It produces a specific type of traffic. Discovery tools can fingerprint it. CASB vendors built entire businesses on this fact.
An AI tool is harder to pin down. Some are SaaS. Some are API endpoints you call directly from a script. Some are local models running on a developer laptop. Some are wrappers that call other wrappers. The “AI” feature in your existing SaaS stack, the one in Notion or Slack or Salesforce, counts too, even though it is not a separate purchase. The line between “tool” and “feature” is blurry.
The result is that nobody has a reliable inventory. The CIO spreadsheet has the sanctioned tools. The security team CASB sees the SaaS-shaped ones. The data team AI governance has the foundation model contracts. None of them see the same set. None of them see all of it.
The data flow problem
The bigger issue is data movement. A SaaS app uploads documents to a server. You can see the upload. You can put a DLP rule on it. You can block it.
An AI tool takes a prompt. The prompt can be anything. A whole customer list, a confidential memo, a screenshot of an internal dashboard. The prompt goes to a model you do not control, on infrastructure you do not manage, in a jurisdiction you may not have thought about. The output comes back and gets pasted into a doc, a slide, a Jira ticket, a Slack message, or sometimes another AI tool for “polishing.”
The data flow is invisible to most DLP tools. The prompt leaves the browser, hits an API endpoint, and the model returns text. The transfer looks like any other HTTPS request to anyone watching the network. The semantic content is what matters, and that is where the existing tooling is weakest.
The compliance problem
Every AI tool is a new vendor with its own data processing agreement. Most of those agreements are not in place. The 2023 EU AI Act added documentation requirements that a lot of teams are still figuring out. The US state-level laws, including California AB 2013 and the Colorado AI Act, are now enforceable. The internal audit function is going to start asking, and the answers are going to be uncomfortable.
If your AI tool inventory is incomplete, your compliance posture is incomplete. The two are the same problem.
What the leading teams are doing
The teams that are getting this right have stopped trying to inventory the tools and started inventorying the use cases. A use case is a documented flow: who is using AI for what, with what data, in what workflow, with what output. The tools are downstream of the use cases. When a use case changes, the tool list updates. When a new tool is proposed, it gets mapped to an existing use case or a new one.
The practical version looks like a registry that is closer to a change management system than a SaaS catalog. It is owned by a product or platform function, not security. Security gets read access and writes risk annotations.
The other thing the leading teams are doing is breaking the AI surface into layers. Foundation models, the OpenAI and Anthropic and Google APIs, are one layer. Wrappers and copilots built on top of them are another. Internal fine-tunes and hosted models are a third. Each layer has a different risk profile. Each layer needs a different control. Trying to govern them as one category is how you end up with no governance at all.
The bottom line
The teams that figure out AI tool sprawl this year will be the ones who can answer the board question with a number and a risk profile. The teams that do not will be the ones answering it in front of a regulator in 2027. The shape of the problem is the same as SaaS sprawl. The data sensitivity is higher. The discovery tooling is behind. Pick whichever gap is widest in your org and start there.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers. Specific data points: EU AI Act obligations summary (European Commission, 2024). California AB 2013 training data transparency requirements (California Privacy Protection Agency, 2025). Colorado AI Act enforcement timeline (Colorado Department of Law, 2026). SaaS sprawl benchmark figures from the 2023 and 2024 Cisco and BetterCloud enterprise IT surveys.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
