Why Shadow AI Requests Need a Real Process
At some point, an employee is going to walk up to you — or more likely ping you on Slack — and ask if it’s okay to use an AI tool they found. Maybe it’s a writing assistant, a meeting summarizer, or something they saw demoed at a conference. If your answer is “sure, just don’t put anything sensitive in it,” you’ve just approved a tool you haven’t evaluated, with no record that you did it, and no way to revisit that decision when the vendor changes their data practices six months from now.
That’s how shadow AI spreads. Not through rogue employees hiding things — through well-meaning people getting informal sign-offs that never make it into any system of record. A lightweight shadow AI tool intake process closes that gap without turning every request into a six-month procurement exercise.
This post walks through the four pieces of that process: a request form, a triage rubric, an approval or denial with documented rationale, and an inventory update. None of it requires enterprise GRC software or a dedicated compliance team.
What to Capture in an AI Tool Request Form
The form doesn’t need to be long. It needs to capture enough information for you to make a defensible decision in a reasonable amount of time. Aim for five to eight fields, not twenty.
The essentials: the tool name and URL, the department and requestor, a plain-English description of the intended use case, and a rough estimate of the data types that will flow through it. That last one is the most important. There’s a significant difference between a team using an AI image generator for marketing assets and an HR manager who wants to paste job application data into an AI sourcing tool. The form forces the requestor to articulate the use case, which often surfaces data handling concerns before you’ve spent any time evaluating the vendor.
Add two more fields and you’ve covered most of what you need: whether the tool will connect to internal systems via integration or API, and whether the requestor has reviewed the vendor’s privacy policy. You’re not requiring a legal opinion — you’re establishing that someone looked. If they haven’t, that’s part of the triage.
A shared Google Form, a Typeform, or a simple intake queue in your ticketing system all work fine for this. The tool is not the point. Consistency is.
Risk Triage: How to Prioritize Shadow AI Requests Without Overcomplicating It
Once the request comes in, you need a fast way to sort it into one of three buckets: low risk, elevated risk, or high risk. This is not a full AI risk assessment — it’s a filter that tells you how much evaluation effort the request actually warrants.
Low-risk requests share a few common traits: no personal data, no internal system access, a vendor with a published privacy policy that doesn’t claim training rights on user inputs, and a contained use case like drafting marketing copy or summarizing public news. These can usually move through approval in a day or two.
Elevated-risk requests involve one or more of these factors: employee or customer personal data, integration with internal tools, a free-tier vendor where the business model isn’t clear, or a use case that touches regulated information — health data, financial records, legal documents, HR records. These need a closer look at the vendor’s data processing terms before you sign off.
High-risk requests — think tools that process sensitive personal data at scale, connect to core business systems, or make automated decisions that affect employees or customers — warrant a more formal AI vendor risk review before any approval. If your organization has EU exposure, the EU AI Act’s risk classification scheme is worth mapping against this tier; tools that would qualify as high-risk systems under that regulation should get proportionate scrutiny regardless of whether you’re formally subject to it.
You don’t need a scoring matrix for this. A one-page rubric with those criteria, shared with the IT team and any security-adjacent staff, gives you consistent triage without reinventing the wheel for each request.
Approval and Denial: Document the Rationale, Not Just the Decision
Most informal AI approval processes fail at this step. Someone says yes or no, the conversation ends, and there’s no record of why. Three months later, no one can remember whether that tool was approved, denied, or just never followed up on.
When you approve a tool, document the approval with three things: the date, the conditions (if any), and the data use scope. Conditions matter because a tool might be acceptable for one use case and not another. You might approve a general-purpose AI writing assistant for marketing while explicitly excluding it from customer communications or anything involving contract language. Scope the approval, don’t just grant it.
When you deny a request, document the reason in plain language. “We can’t verify how this vendor handles training data, and the use case involves employee records” is a complete rationale. It respects the requestor’s time by being honest, and it gives them something to bring back to you if the vendor’s terms change. A denial with no explanation tends to generate workarounds — the employee assumes IT is being difficult and finds a way around the restriction. A denial with a reason creates a conversation.
If a request is borderline, conditional approvals with a review date are better than indefinite deferrals. Set a 90-day checkpoint and add it to your calendar. AI vendor data practices change. What was acceptable under one set of terms may not be acceptable after a policy update.
How to Keep Your AI Tool Inventory Current After Approval
Approval without an inventory update is just paperwork. The whole point of a shadow AI tool intake process is that every approved tool ends up in a register where you can see what’s in use, who approved it, under what conditions, and when it’s due for review.
The AI tool register doesn’t have to be complex. The core fields are: tool name, vendor, business owner, date approved, data types in scope, integration dependencies, review date, and current status (active, under review, retired). That’s enough to give you an accurate picture of your AI tool inventory at any point in time and to answer questions when an auditor, a customer, or your legal team asks what AI tools you’re using.
The discipline that kills most tool inventories is batch updating — people intend to update the register quarterly and never do. Tie the inventory update to the approval itself. When the approval email goes out, the register entry goes in at the same time. If your intake lives in a ticketing system, build the register update as a required step in the ticket closure workflow. The register only stays current if updating it is part of the approval motion, not a separate task someone has to remember.
This also applies to denials and retirements. When a tool is denied, log the denial. When a tool is removed from use, update its status. An inventory that only tracks approvals isn’t an accurate picture of your AI governance posture.
Do This Week: Stand Up a Minimal Intake Queue
If you don’t have any formal process right now, here’s where to start. This week, build a five-field request form — tool name, requestor, department, intended use case, and data types involved. Route submissions to a shared inbox or a ticketing queue so requests don’t get lost in someone’s DM history. Send a brief note to department heads letting them know the process exists and that informal “is this okay to use?” questions should now come through the form. You don’t need executive sponsorship for this step. You just need a consistent front door.
At the same time, pull together a list of AI tools you’re already aware of — anything that’s been requested informally, anything you’ve seen in browser extension audits, anything that came up in your last software spend review. That’s the seed of your AI tool register. Even a rough list with ten entries is better than nothing, because it establishes that the process is active and gives you a baseline to build from.
If you want a register template you can use immediately, download the free AI tool register template — it’s set up for exactly this kind of lightweight intake process and requires no GRC platform to run.
For teams that want a structured queue rather than a managed inbox, InfoDefenders’ tool intake queue gives IT a single place to review employee AI tool requests, log decisions with rationale, and push approved tools directly to the inventory — without building the workflow from scratch.
The point of all of this is not to make AI tool requests harder. It’s to make the decisions visible, documented, and revisable. Employees who understand that there’s a real process — not a wall — are generally willing to use it. And when they do, you stop inheriting risk you never agreed to take on.
Related Reading
If you’re still building out the discovery side before formalizing intake, how to build an AI tool inventory without enterprise software covers the detection and enumeration steps that feed a register like this one. And if you want to see what unchecked shadow AI actually looks like before anyone puts a process in place, 43 shadow AI tools found in 48 hours is a useful reference point.
