The Scale of the Gap
IBM's 2025 AI Governance in the Enterprise report, which surveyed 3,400 IT and business leaders across twelve industries, found that 71% of employees who regularly use AI tools for work report using at least one tool that IT has not approved. Gartner's parallel survey of enterprise security leaders put the figure at 65%, with variance driven largely by whether the organization had deployed a sanctioned AI tool that employees actually found useful. Both studies used self-reported usage data, which means the real figures are probably higher — people underreport behavior they suspect might be frowned upon.
The cost differential matters more than the usage gap. IBM's 2025 Cost of a Data Breach report found that incidents involving unsanctioned AI tools carried an average remediation premium of $890,000 over comparable incidents involving IT-governed deployments. The premium reflects investigation complexity: when a tool isn't in the asset inventory, forensics takes longer, scope is harder to bound, and regulatory notification timelines get compressed. In federal environments, where breach notification requirements under FISMA and agency-specific data handling rules add procedural overhead, that premium compounds.
These figures explain the structure of the gap. Use them that way, not as alarm bells.
The Three-Tier Model
Most mature AI governance frameworks organize tools into three tiers, and the logic is straightforward enough that buyers will recognize it immediately.
Approved tools are fully sanctioned, IT-governed, and auditable. They're integrated with the organization's identity infrastructure, their data handling terms have been reviewed, and there's a documented owner. Employees can use them without restriction within their normal data classification boundaries.
Limited tools are permitted, but with constraints attached. The constraints might be use-case specific (competitive analysis only, not customer data), data classification specific (unclassified work only, nothing touching CUI), or user population specific (available to the AI Center of Excellence pilot group, not the broader workforce). Limited means governed with guardrails calibrated to the tool's specific risk profile, not merely tolerated.
Prohibited tools are blocked, with documented rationale. The documentation matters. In federal procurement conversations, "we blocked it" is a much weaker answer than "we evaluated it against our data handling requirements, determined it couldn't meet our CUI handling standards, and documented that determination in our AI tool registry." The second answer survives an audit. The first one creates one.
The Request-to-Allowlist Lifecycle
The three tiers only work if there's a functional process for getting tools into them. Without that process, shadow AI persists as a rational response to a vacuum.
The lifecycle runs like this: a business team identifies an AI tool they want to use. They submit a request through IT's intake process, which should exist and should be findable in under five minutes. IT evaluates the request against a defined set of criteria — vendor security posture, data handling terms, contractual liability, use case fit, and data classification compatibility. Based on that evaluation, the tool gets placed in a tier. Access is then provisioned according to that tier's constraints, or the request is denied with a written explanation that includes what would need to change for reconsideration.
That last piece is underappreciated. A denial without a path forward teaches employees that the process is a dead end. A denial that says "this tool would qualify as Limited if the vendor signs a data processing agreement consistent with our CUI requirements" teaches them that the process works and gives the vendor a clear action item.
The research finding worth anchoring your buyer conversations to: in organizations where sanctioned AI tools are genuinely useful and accessible within two weeks of request submission, unauthorized tool usage drops by roughly half. The governed path wins when it's competitive, not just mandatory.
Okta Concept Mapping
The provisioning problem maps directly to application lifecycle management in IDAM — the same evaluate-tier-provision sequence that governs SaaS app onboarding. Where the analogy holds: Okta's application catalog and access request workflows are structurally identical to what AI governance requires. Where it breaks: traditional app onboarding assumes the application is a stable entity with a fixed integration surface. AI tools are not. A tool that qualified as Limited six months ago may have added data retention features, changed its terms of service, or expanded its training data practices in ways that push it into Prohibited territory. The provisioning decision isn't one-time — it requires a review cadence that traditional IDAM workflows weren't designed to trigger automatically.
The buyer who understands this stops asking "how do we block shadow AI" and starts asking "how do we make the governed path faster." Gateway enforcement — the technical layer that makes the policy real — is a separate discussion, and it comes after this one.