How to Build an AI Tool Approval Process Before Shadow AI Builds One for You

The average organization is now running about 15 generative-AI apps at any given time, up from 13 just three months earlier, and Netskope Threat Labs found that over half of that adoption is shadow AI: tools nobody signed off on, running against company data, discovered after the fact instead of approved before the fact. If your company doesn't have a way to say yes to a new AI tool quickly, your team isn't waiting for one. They're just not asking.

Why "we don't have a policy yet" is already a policy

Only 28% of organizations report having a formal, comprehensive policy for AI use, according to ISACA. That gap doesn't mean AI adoption pauses at the other 72%, it means the default approval process at most companies is "whoever wanted to use it first." We already covered what actually stops shadow AI once it's spread through a team: give people a sanctioned tool that's as good as the one they found on their own. This post is the piece that comes before that, how you decide what gets sanctioned in the first place, fast enough that nobody feels the need to go around it.

An approval process isn't a memo. It's a short, repeatable decision path: someone requests a tool, someone checks a fixed set of things about it, and someone says yes or no within days, not months. Below is the version we'd actually run for a team under 50 people.

The four checks, in order of how much they should slow you down

Most AI tool requests fail at exactly one of these checks, so front-load the fast ones and only escalate the ones that genuinely need it.

• **What data will touch it?** Public web content and your own already-published material is low risk. Customer PII, financials, source code, or anything under an NDA is high risk and should route to a full review every time, regardless of how good the tool looks.
• **Does the vendor sign a data processing agreement?** If the tool touches personal data and the vendor won't sign a DPA covering the obligations set out in GDPR Article 28, subprocessor disclosure, breach notification timelines, deletion rights, that's a hard no, not a "let's ask legal eventually." A vendor's willingness to sign one is also a decent proxy for how seriously they take security generally.
• **Does it support SSO, and does someone own the account?** A tool paid for on a personal card with a personal login is the single most common way an "approved" tool quietly turns into shadow AI again, because nobody can revoke access once that person leaves.
• **Does something approved already do this?** Before greenlighting a fourth transcription tool because someone's favorite newsletter recommended it, check what's already sanctioned. Most "new tool" requests are actually "I didn't know we already had one" requests, and the fix there is a visible list, not another review cycle.

Fast-track versus full review

Not every request needs the same multi-week cycle. Split intake into two lanes from day one, or the review process itself becomes the reason people go around it.

The mistake most small teams make is running every request through the full-review lane out of caution. That's exactly what pushes usage underground, because a two-week wait for a free tool that only touches public data isn't caution, it's friction with no safety benefit attached to it.

What the intake request should actually ask

A request form with more than five fields doesn't get filled out honestly, it gets filled out fast and wrong. Keep it to what a reviewer actually needs to make the call:

• Tool name, vendor, and pricing tier
• What problem it solves that isn't already solved by an approved tool
• What data categories it will touch, using the same categories as your data classification, not free text
• Who owns the account, and who loses access when they leave
• A link to the vendor's DPA or security page, if one exists

That last field does double duty: if a vendor doesn't have a security or DPA page you can link to, that's information too.

Who owns this, and how often it gets revisited

At a team under 50 people, this doesn't need a committee. One person, usually the founder or an ops lead, owns the fast-track lane and can approve most requests solo. Anything hitting the full-review lane gets a second set of eyes from whoever owns security or finance. The list of approved tools should be genuinely visible, not buried in a wiki nobody opens, and it should get revisited on a fixed quarterly cadence, not "whenever someone remembers," since Intuit's 2026 AI Impact Report found 77% of small businesses are already using AI daily. The tool landscape under a fast-moving team changes faster than an annual policy review can track.

The process is the point, not the paperwork

None of this is about slowing your team down or building a compliance department nobody asked for. It's about making the fast path to "yes" faster than the path to signing up with a personal email and a company credit card, because that's the actual competition. A request that takes two days and gets a clear answer beats a policy nobody read, every time. That's the operating muscle we build out fully in AI Leadership for Founders: not just the policy language, but the actual intake-to-approval workflow, the data classification tiers, and how to run it without adding enough friction that your team quietly stops asking.