There’s a pattern playing out in organizations everywhere right now. A marketing team starts using an AI writing assistant. Finance adopts a copilot to summarize reports. A developer integrates an AI-powered code reviewer. Each team moves fast, solves a real problem, and reports back to no one. Before long, your organization has dozens of unvetted AI tools processing sensitive data, connecting to corporate systems, and operating entirely outside of IT oversight.
This is shadow AI — and unlike shadow IT of years past, the stakes are considerably higher. These tools don’t just store files in unauthorized locations. They ingest business data, generate outputs that influence decisions, and in some cases, take autonomous actions. Building a formal intake and approval process before this sprawl takes hold isn’t bureaucratic friction. It’s a security and governance necessity.
Why Shadow AI Is Different from Shadow IT
Traditional shadow IT — personal cloud storage, unauthorized SaaS subscriptions — was largely a data governance problem. Shadow AI is that, plus an accountability problem. When an employee uses an unapproved AI tool to summarize customer contracts or generate internal communications, you face questions traditional IT governance was never built to answer: What data was used to train the model? Where does input data go? Who is liable if the tool produces inaccurate or harmful output?
AI tools also move faster than most procurement cycles. A new copilot or agent can be running in a browser tab within minutes. If your approval process takes six weeks, departments will stop asking. The goal isn’t to slow adoption — it’s to make the approval process fast, visible, and trustworthy enough that teams actually use it.
Build an Intake Process with a Purpose-Built Request Catalog
The first step is creating a clear front door. Teams need a simple, low-friction way to submit AI tool requests — and IT and security teams need a structured way to receive and evaluate them.
If your organization runs on ServiceNow, this is a natural fit for a dedicated AI Tool Request catalog item. Capture the essentials upfront: what the tool does, what data it will access, which business function is requesting it, and what integrations are required. Route submissions automatically to security and architecture reviewers, and use ServiceNow’s workflow engine to enforce review SLAs so requests don’t disappear into a queue.
For teams running Jira Service Management, the same model applies — a purpose-built request type with required fields, automated triage, and approval workflows tied to specific reviewer groups. Either way, the intake form should ask the hard questions at submission: Does the tool require OAuth access to Microsoft 365? Does it process PII or regulated data? Does it offer a BAA or SOC 2 report? Answering these at intake — not after deployment — is what prevents the bad outcomes.
Govern Identity and Access from the Start
One of the most common failure modes in AI tool adoption is identity sprawl. A team approves a tool informally, someone creates a shared service account, and six months later no one knows what that account has access to or whether the tool is still in use.
Products like Entra ID can serve as the enforcement layer for any approved AI tool that touches your Microsoft environment. Requiring that AI tools accessing Microsoft 365 data be registered as enterprise applications gives you visibility into what permissions each tool holds, who authorized them, and when they were last used. Conditional Access policies can further restrict these applications to managed devices and compliant network conditions.
For tools that use OAuth consent, enforce admin consent requirements rather than allowing users to grant permissions individually. This single change prevents a wide category of shadow AI. Pair it with Entra ID’s access reviews to periodically confirm that approved tools still have appropriate access and are still in active, sanctioned use.
Define a Tiered Approval Model
Not every AI tool request requires the same level of scrutiny. A browser-based writing assistant with no data integrations is a different risk profile than an autonomous agent with API access to your ERP. A tiered model lets you move quickly on low-risk requests while applying rigorous review where it matters.
A practical three-tier structure:
Tier 1 — Low Risk: No corporate data access, no integrations, general productivity use. IT review only. Target turnaround: 48 hours.
Tier 2 — Medium Risk: Accesses non-sensitive internal data, requires SSO or read-only API access. IT and security review. Target turnaround: 5 business days.
Tier 3 — High Risk: Processes regulated data, requires write access to core systems, or involves autonomous decision-making. Full review by IT, security, legal, and architecture. Target turnaround: 15 business days.
Publish these tiers and timelines. When departments know what to expect, they’re far more likely to submit a request than work around the process.
Start Before You Think You Need To
If your organization hasn’t formalized an AI tool approval process yet, the right time to start is now — not after a security incident surfaces an unmanaged tool that has been processing customer data for months. The model doesn’t need to be perfect at launch. A basic request form, a defined reviewer group, a published approved-tools catalog, and clear turnaround times is enough to establish the habit and the expectation.
Shadow AI grows in the absence of a better option. Give your teams a process that’s faster and easier than going around you, and most of them will use it.
Not sure where your organization stands — or where to start? We help IT and security teams design AI governance frameworks built around the tools you already use, including ServiceNow, Jira Service Management, and Entra ID. Schedule an AI strategy consultation and we’ll help you map your current exposure, define your approval workflow, and put the right controls in place before the sprawl sets in.