Why Most AI Tool Approvals Are Just a Rubber Stamp
Somewhere in your organization right now, someone is signing up for an AI tool using a work email. Maybe they already have. The approval process — if there is one — usually amounts to a manager saying “sure, give it a shot” and IT finding out later. That’s how shadow AI spreads, and it’s also how you end up with sensitive business data sitting in a vendor’s training pipeline you never audited.
The fix doesn’t require a formal AI risk registry or a compliance team. It requires three questions, asked before anyone gets a license key.
Question 1: Where Does the Data Go?
This sounds obvious, but most people don’t actually know the answer for the tools they’re already using. “Where does the data go” isn’t asking about the vendor’s marketing copy — it’s asking: does your input get stored on their servers, and for how long? Is it used to train their model? Is it shared with third-party subprocessors? Can you get it deleted if you offboard?
The answers live in the vendor’s privacy policy and, more specifically, their data processing agreement (DPA). If a vendor doesn’t offer a DPA, that’s your answer — they’re not ready for enterprise use, regardless of how good the product looks in a demo.
For tools that touch anything regulated — HR data, financial records, client information, anything subject to GDPR or state privacy laws — you need to know where data is physically processed, not just where the vendor is headquartered. A US-based SaaS company can still route data through EU infrastructure (or vice versa), and that matters for your compliance posture.
If the vendor is EU-facing or you have any EU customers, Article 28 of the GDPR makes DPA requirements explicit. Bookmark that and use it as your baseline.
Question 2: Who Has Access to Your Inputs?
AI tools are not passive software. When an employee pastes a customer contract into a summarization tool, or runs client data through an AI analytics platform, that content doesn’t just disappear. Someone, or something, can access it — and your AI tool approval checklist needs to surface who.
Ask the vendor directly: do your support engineers have access to user-submitted content? Is content reviewed for safety or quality by humans? What access controls exist on your tenant’s data? These aren’t hostile questions — any vendor worth using can answer them in plain English.
This also applies internally. When you approve an AI tool, you’re not just approving it for the person who asked. You’re creating a new data pathway that other employees may start using, often without telling IT. That’s why an AI tool inventory — even a simple one — matters from day one. You can’t govern access to tools you don’t know exist.
Unapproved AI tools are already your biggest exposure here. Once a tool is approved with clear scope, you can enforce it. When it’s not approved and employees are using it anyway, you have no visibility and no controls.
Question 3: What Happens If This Vendor Is Breached?
Every AI vendor in your stack is a third-party risk. You’re trusting them not just with uptime, but with data that may include confidential business information, PII, or proprietary processes embedded in the prompts your team is writing.
A breach at the vendor level can expose inputs your employees submitted weeks or months earlier. So the question isn’t just “are they secure” — it’s “what are they contractually obligated to do when something goes wrong?”
Look for: incident notification timeframes (72 hours is standard under GDPR; many contracts are looser), indemnification language, and whether the vendor carries cyber liability insurance. If they can’t produce a SOC 2 Type II report or equivalent, treat that as a risk flag in your AI vendor risk assessment, not a dealbreaker by itself — but document it.
For smaller vendors pitching cutting-edge tools, this is where the risk is highest. The product might be impressive; the security program might be six months old.
What to Do This Week
Pull up the last three AI tools your team requested or started using. For each one, find the privacy policy and DPA (or note that no DPA exists), then write down one sentence for each of the three questions above. You don’t need a formal system to do this — a shared spreadsheet works. What you’re building is the beginning of an AI tool register: a running record of what tools are in use, what data they touch, and what you know about the risk.
Once you’ve done that exercise even once, the gaps become obvious. You’ll find tools with no DPA. You’ll find inputs going to vendors you assumed were isolated. You’ll find breach notification language buried in terms of service that no one read.
If you want a structured starting point rather than a blank spreadsheet, download InfoDefenders’ free AI tool register template — it’s built around exactly these three questions and gives you a format you can hand to a vendor or share with a department head without reinventing the wheel.
The Goal Isn’t to Block Tools — It’s to Know What You’re Agreeing To
None of this is about becoming the team that says no to everything. AI tools are genuinely useful, and blocking them entirely just pushes usage underground. The goal is to make the approval process take thirty minutes instead of zero, and to make sure that when something goes wrong, you have a record that shows you asked the right questions.
Three questions. Every tool. Before the license gets approved.
