23 AI tools is the average count from early-access scans of organizations joining the platform, with IT holding no formal record of them. These are not isolated policy exceptions. Most entered through channels that appear legitimate from the outside.
Shadow AI is often described as a security failure: an employee ignored policy and installed an unapproved product. That view pushes governance toward restriction. It also misses the actual routes. Unauthorized tools usually enter through ordinary business activity, not a hidden side door.
Path 1: Employee Adoption
By a wide margin, individual adoption produces the most volume. A worker discovers an AI writing tool, meeting transcription service, or code completion product, signs up with a work address, adds a browser extension or connects it to a productivity suite, and begins using it that day. There is no procurement ticket, security review, or inventory record.
The employee is usually trying to solve a real work problem, not evade controls. The tool may improve their output, but it also becomes an active data processor with possible access to sensitive material. The organization has no recorded controls, data review, or audit evidence for it.
Later, the employee may not classify a browser extension as an "AI tool" that requires reporting. That makes self-reporting predictably weak. People omit activity they do not view as reportable. Discovery must use signals, rather than relying on surveys.
Path 2: Vendor Bundling
A project management system, CRM upgrade, or document platform passes procurement review. Six months after launch, revised terms reveal that the supplier added an AI assistant, sometimes enabled by default. The original product was reviewed, but the later capability was not.
Manual controls often miss this route because the AI feature was absent from the initial review. Questions about data handling, model training, and retention for AI-processed content were never raised when the supplier looked like a conventional SaaS vendor. Once detected, the feature may have been live for weeks or months.
Enterprise discovery scans show the same pattern: an approved SaaS catalog is carefully documented, yet half its tools gained AI functions after review. The catalog describes the evaluated products accurately, but not how those products operate now.
Path 3: Procurement Bypass
A team needs an immediate fix, while standard procurement takes six to eight weeks. A manager finds an AI product with a free trial and charges its first month to a corporate card. By the time procurement notices, the tool is part of daily workflows and the team relies on it.
This reflects process design, not simply poor discipline. When formal purchasing moves slower than AI adoption, staff find another route. Products entering this way are often newer, with less established security practice, less clear data handling, and fewer answers ready for vendor questionnaires. They are also the products for which evaluation criteria are least developed.
The remedy is a quicker official route, not more obstacles around the bypass. Governance design determines whether adoption occurs through approved channels. Detection identifies tools already in use. Both functions matter, and neither replaces the other.
Path 4: Developer Experiments
Engineering and data teams bring AI into another part of the stack: LLM API connections, assisted code review, automated test agents, and fine-tuned models in development pipelines. These are not consumer SaaS purchases. A developer adding an LLM API key to GitHub Actions or a CI/CD pipeline follows a different route from a manager buying project software.
SaaS-focused governance often cannot see developer tools. Their signals live in API gateways and repositories, rather than identity-provider approval logs. The compliance questions also differ. AI-generated code raises intellectual property, license compliance, and model training data sourcing issues. Most governance programs have not yet handled these questions systematically.
The Shared Pattern
None of these four routes requires intentional policy evasion. Employees address productivity needs, vendors release promoted updates, business units move at operational speed, and developers use tools that make projects possible. In organizations that broadly adopt productivity software, this behavior is predictable.
That distinction should shape inventory design. Requiring review before AI use may redirect some requests, but it will miss vendor bundling, side-channel purchases made before detection, and developer APIs without build-environment visibility. Policy matters, but policy alone cannot discover the full environment.
Begin With Live Usage
An accurate AI inventory should begin with discovery, not employee declarations. Live signals show what is operating. Self-reported catalogs mainly show what employees think the organization expects them to disclose.
Approval remains useful. A faster official route can reduce unauthorized adoption by giving employees a practical alternative. But approval and inventory serve different purposes. The inventory must remain accurate even when approval is imperfect. Treating them as the same leaves governance with an incomplete view.
Link identity-provider logs, SaaS catalog records, and API gateway telemetry to see activity without relying on self-reporting. Those signals remain available regardless of entry route. They distinguish an inventory of approved tools from one that reflects what is running now.