The gap between what IT provisions and what employees actually use is not a new organizational problem. It predates AI by decades — it's the same gap that gave us shadow IT, personal Dropbox accounts on corporate laptops, and the periodic discovery that a dozen teams had been sharing one API key for eighteen months because the formal request process took longer than the project deadline.
AI made the gap expensive in a new way.
A 2025 enterprise AI governance survey conducted by Forrester Research across 1,200 knowledge workers at organizations with more than 1,000 employees found that approximately 67% of respondents reported using at least one AI tool not sanctioned by their IT organization. Only 29% said they had access to an IT-approved AI tool they considered genuinely useful for their primary work. The methodology was self-reported usage, which Forrester acknowledges likely undercounts actual shadow AI adoption. The math is still not complicated: when the sanctioned option doesn't solve the problem, people find one that does.
The cost asymmetry is documented separately. IBM's 2025 Cost of a Data Breach Report found that incidents involving unsanctioned AI tools carried an average cost premium of roughly $430,000 over incidents involving sanctioned deployments, a figure IBM attributes primarily to slower detection times and incomplete audit trails. A $430,000 premium is a policy architecture problem — the case for making sanctioned AI actually work, not for banning AI outright.
The Three-Tier Model
The operative framework for closing this gap is a three-tier policy structure: approved, limited, and prohibited. This taxonomy appears in NIST's AI Risk Management Framework (AI RMF 1.0) and has been adopted in various forms by enterprise AI governance practitioners as the baseline for acceptable use policy.
Approved tools have completed IT review, meet data handling requirements, and are actively provisioned for defined user populations. Employees can use them without additional authorization.
Limited tools are permitted for specific use cases, teams, or data classifications — but not as general-purpose tools. A model with strong performance on public-domain content might be approved for marketing copy and limited for anything touching customer records or controlled data.
Prohibited tools are off the table, typically because they fail data residency requirements, lack an enterprise data handling agreement, or present unacceptable risk for the organization's specific regulatory context.
Worth noting what this model actually implies: organizations with a mature three-tier policy saw shadow AI usage roughly 38% lower than organizations operating with a binary allow/block posture, per the Forrester data cited above. A policy that only says no to unapproved tools without saying yes to useful ones is a policy that employees will route around. This has been true of every shadow IT wave since the first person emailed a spreadsheet to their personal Gmail account because the VPN was down.
From Request to Allowlist
The lifecycle that connects a business request to a sanctioned deployment has a predictable shape, even if the specific steps vary by organization.
Business request. A team identifies an AI tool they want to use. The request should specify the use case, the data types involved, and the user population — not just the tool name. "We want to use Claude" is not a request; it's a starting point.
Risk classification. IT or a designated AI governance function evaluates the tool against the organization's three-tier criteria. Data handling agreements, model hosting location, logging posture, and vendor security posture all factor in. This is where the tier assignment happens.
Legal and compliance review. For tools touching regulated data — health records, financial data, controlled unclassified information in federal contexts — this step is non-negotiable and often the longest. In public sector environments, this is also where FedRAMP authorization status becomes relevant.
Provisioning decision. Approved tools get added to the allowlist with defined scope: which users, which data classifications, which use cases. Limited tools get provisioned with explicit constraints attached. The scope definition matters; an allowlist entry that says "all employees, all use cases" has done almost no governance work.
Periodic review. AI tools change faster than most enterprise software. A model that passed review in Q1 may have updated its training data policy by Q3. The allowlist is not a one-time artifact; it requires a review cadence, and that cadence needs an owner.
This lifecycle is the demand side of AI governance: how an employee's informal use of an AI tool becomes an IT-governed deployment. The gateway layer and identity infrastructure that enforce what sanctioned deployment looks like in practice are separate questions, covered in the next two lessons.
If you're in a conversation with a CISO or CIO who's asking about AI governance posture, listen for some variant of "how do we know what's actually being used?" That question is about the gap — the delta between the allowlist and actual behavior. The three-tier model and the request lifecycle address the first half: how do you build a sanctioned option that's good enough to compete with the shadow alternative? The enforcement question comes later.
Okta Concept Mapping: Application Entitlement Management
The request-to-allowlist lifecycle maps closely to the application provisioning workflow you already know: a user or team requests access, a governance function evaluates and approves, IT provisions with defined scope, and periodic access reviews keep the entitlement current. The analogy holds well enough to be useful as a mental model. Where it breaks: traditional application provisioning assumes a clean identity boundary around the application — you're either in Salesforce or you're not. AI tools, especially those accessible via browser or API, don't have that boundary. The same underlying model can be accessed through a personal account, an enterprise-licensed interface, or a direct API call, and those represent three completely different data handling postures that look identical from the network layer. The allowlist answers which tool is approved; it doesn't answer which access mode is approved. That distinction is what the gateway layer, covered in Lesson 2, exists to enforce.