Português

AI Approval Gates and Vendor Review: A Scalable Framework for CIOs

A new AI tool request lands in your inbox every week. Your sales team wants an AI call recorder. Finance wants an AI expense categorizer. Marketing wants an AI content tool that requires OAuth access to your customer database. And your IT audit last month turned up six tools employees are already using that no one reviewed.

The instinct for a chief information officer (CIO) is to tighten controls: require security review for everything, add more sign-offs, slow the pipeline. That instinct is understandable and wrong. A review process too slow to complete drives shadow AI. The engineers will use the tool anyway. They'll just hide it.

The goal isn't to say no to everything. It's to build a fast, credible approval process that employees actually trust and follow. Gartner research found that organizations without pre-approved tool catalogs experienced three to five times higher rates of shadow AI adoption, which is precisely the outcome a slow, opaque review process produces. This article is the operational companion to Building Your AI Use Policy, which defines the boundary rules the approval gates enforce.

Why AI vendor review is different from traditional SaaS procurement

Key Facts: AI Vendor and Shadow AI Risk

  • Organizations without pre-approved tool catalogs experience 3-5x higher rates of shadow AI adoption, according to Gartner research; the approval process that's too slow to use drives employees to bypass it entirely (Gartner, 2025)
  • 78% of knowledge workers use personal AI tools at work without explicit employer approval; most of these tools have no enterprise data processing agreements (Microsoft Work Trend Index, 2024)
  • Gartner predicts that over 40% of agentic AI projects will be canceled by end of 2027, with governance framework failures, not technical failures, as the leading cause (Gartner, 2025)

Traditional SaaS procurement asks: does this tool do what it claims? What does it cost? Does it integrate with our stack? Does the vendor have SOC 2?

AI vendor review has five additional questions that traditional SaaS procurement doesn't cover.

Training data practices. Does this vendor use your employee inputs, your customer data, or your proprietary content to train or fine-tune their models? This matters enormously. A vendor that improves its models on your data is extracting value you didn't price into the deal, potentially leaking competitive information into shared model weights, and creating a GDPR (General Data Protection Regulation) exposure if any of that data includes personal information about your customers.

Model transparency. Which model is this tool built on? Is it a proprietary model, an open-source fine-tune, or a wrapper around GPT-4o or Claude? This affects your ability to get consistent outputs, your audit trail for decisions, and your exposure if the underlying model is deprecated.

Data residency. Where does data go when an employee submits a prompt? Many AI tools process data through US-based cloud infrastructure even when you're operating in Germany or Australia. That may conflict with your data residency requirements, particularly in healthcare or financial services.

Model update notification. When the vendor updates their model, do they notify you? A behavioral change in an AI tool that affects customer-facing outputs or scoring decisions is a material change to your operation. You need to know when it happens.

Incident response SLA. If the AI tool sends incorrect information to your customers, makes a discriminatory decision, or exposes protected data, what is the vendor's contractual obligation? What's their notification timeline? What remediation do they owe you?

None of these questions appear in a standard vendor security questionnaire. And none of them are optional.

The AI Vendor Security Questionnaire

Before routing any AI tool to formal review, require the vendor to complete a written questionnaire. This creates a paper trail, speeds up the technical review, and ensures procurement, legal, and security are evaluating the same information.

Key questions to include:

Data and training

  • Does this product use customer-submitted data (prompts, documents, or outputs) to train or improve the underlying model? If yes, can customers opt out?
  • Describe your data processing pipeline. Where is data stored during and after inference?
  • What is your data retention policy for customer inputs and outputs?

Security and compliance

  • What SOC 2 Type II scope does your most recent report cover? When was the last audit completed?
  • Do you have HIPAA (Health Insurance Portability and Accountability Act) Business Associate Agreement (BAA) available? GDPR Data Processing Agreement (DPA) available?
  • Describe your access controls for employee access to customer data held by your systems.

Model governance

  • How do you notify customers when the underlying model is updated in a way that may affect outputs?
  • What is your vulnerability disclosure and incident response SLA?
  • Can you provide model cards or documentation on known bias evaluations?

Integration and data flow

  • What API permissions or OAuth scopes does this tool require?
  • Does this tool store API keys, tokens, or credentials on your infrastructure or theirs?
  • What data does this tool send to third-party sub-processors?

Ask these upfront, before scheduling a demo. Vendors who can't answer them in writing aren't ready for enterprise deployment.

"A vendor evaluation process that takes three months doesn't prevent shadow AI. It produces shadow AI. The goal isn't to say no to everything. It's to build a process fast enough that employees prefer to use it rather than work around it." (Rework)

The 3-Tier AI Approval Gate

A tiered review framework that matches the depth of security review to the risk level of the AI tool, preventing governance bottlenecks while maintaining accountability. Tier 3 (Auto-Approve): pre-vetted tools on the approved registry with no system integration and no customer-facing capability; employees self-serve. Tier 2 (Department Head Approval): tools with system integration, Tier 2 data access, or Generate capability reviewed externally; two-week review timeline with IT security involvement. Tier 1 (Full Security Review): tools with customer PII access, customer-facing Execute capability, regulated data handling, or autonomous agent capability; four-to-six-week review with CIO, legal, and CISO sign-off. The 3-Tier Gate ensures that a Grammarly plug-in doesn't spend six weeks in the same review queue as an AI system that can send customer communications autonomously.

The 3-tier approval framework

Not all AI tools carry the same risk. A Grammarly plug-in for internal documents has a categorically different risk profile from an AI system that can Execute actions in your CRM or generate customer-facing communications. Treating them identically wastes your review capacity on low-risk tools while creating the illusion of governance.

The solution is a tiered system where risk level determines the review depth and the time it takes.

Tier 3: Auto-approve (pre-vetted tools on the approved list)

These are tools your team has already reviewed and approved. Any employee can use any Tier 3 tool without requesting a review.

The approved tools registry (more on this below) is your Tier 3 list. Quarterly refresh ensures it stays current.

Typical Tier 3 tools: productivity AI tools with no integration to company systems, writing assistants used only for personal drafting, presentation tools that don't access company data.

Criteria for Tier 3: no integration to internal systems, no access to customer data, no customer-facing output capability, no Execute capability.

Tier 2: Department head approval (standard review, two weeks)

A department head plus a designated IT security contact can approve these without full CIO involvement.

Criteria for Tier 2: uses Tier 2 data (internal operational data, non-personal employee data), OR has system integration but no access to customer data, OR uses Generate capability that employees review before sharing externally.

The two-week timeline exists because security review of a system integration requires actual technical evaluation. It can't be done in two days and done responsibly.

What the review covers: vendor questionnaire responses, data flow diagram, OAuth scope review, DPA review if EU personal data is involved, assessment against your data classification framework.

Tier 1: Full security review (four to six weeks, CIO plus security)

These are the tools with the highest risk profile. The longer timeline reflects the depth of review required, not bureaucratic delay.

Criteria for Tier 1: accesses customer personal data or Tier 1 confidential data, has customer-facing Execute capability (can send communications, issue refunds, make decisions that affect customers), handles regulated data (protected health information [PHI], personally identifiable information [PII] in financial context, attorney-client communications), has autonomous agent or agentic loop capability. The Generate vs. Execute boundary is the primary decision point for whether a tool lands in Tier 1 or Tier 2.

The review includes all Tier 2 requirements plus: legal review of DPA and BAA (if applicable), penetration testing or review of vendor's most recent pentest results, reference calls with existing enterprise customers, explicit contractual clauses on model update notification and incident SLA, sign-off from your chief information security officer (CISO) or legal counsel.

NIST AI RMF alignment note: this three-tier structure maps directly to the NIST AI Risk Management Framework's Govern and Map functions. Tier 1 corresponds to NIST's "high impact" AI uses; Tier 3 corresponds to "minimal risk" uses. The NIST framework recommends that organizations "establish processes and mechanisms to maintain trustworthiness of AI systems." A tiered approval gate is the operational implementation of that principle.

Building the approved tools registry

The approved tools registry is a living list of every AI tool that has been reviewed and approved, along with the conditions of that approval.

Each entry in the registry should include:

  • Tool name and vendor
  • Date of approval and expiration date (quarterly refresh)
  • Tier assignment
  • Approved data tier permissions (what categories of data this tool is approved to access)
  • Who approved (name and role)
  • Known conditions or restrictions (e.g., "approved for internal use only, not for processing customer PII")
  • Renewal reminder date (three weeks before expiration, trigger an automated notification to the approver)

The registry should be accessible to all employees. When someone wants to use an AI tool, their first step should be to check the registry. If the tool is on it, they can proceed. If it's not, they know where to submit a review request.

Quarterly refresh doesn't mean re-reviewing every tool from scratch. It means confirming that: the vendor hasn't materially changed their data practices, no significant security incidents have occurred, and the tool's data access is still appropriate for its current use.

What to do about unapproved tools already in use

If your shadow AI audit found tools employees are already using without approval, you have two options. You can treat it as a compliance failure and mandate immediate cessation. Or you can treat it as a prioritization signal: these are the tools your team wanted badly enough to use without asking.

The second framing is more useful.

An employee who's been using an unapproved AI tool for three months is telling you that the approval process was too slow or unclear for their use case. Address that first. Then run the tool through the normal tier-appropriate review.

For high-risk Tier 1 tools that are already in active use, temporary use restrictions may be appropriate while the formal review runs. But for Tier 2 or Tier 3 tools that are already in use with no apparent incidents, the pragmatic approach is to run the review and backfill the approval rather than creating adversarial dynamics that damage the team's trust in the governance process.

The goal is a process employees voluntarily use because it's faster and clearer than working around it. If the process is slower than doing it without asking, employees will always find a way around it.

How this maps to building your AI use policy

The approval gate framework answers the question: "What's the process for approving a new AI tool?" But it assumes you've already answered a prior question: "What are employees allowed to do with AI tools at all?"

That prior question is your AI use policy. The use policy defines what's in scope, what requires approval, and what's prohibited outright. The approval gate framework is the operational mechanism that enforces the use policy for new tools.

Similarly, the vendor evaluation framework goes deeper on how to assess a specific vendor once the questionnaire has been completed. And the AI risk register is where approved tools get tracked against the risks identified during review.

The AI Pattern Vendor Landscape Map can help you understand which vendors serve which ACE patterns, so you can build a rationalized approved tool list instead of approving ad-hoc requests without understanding the full landscape.

The bottleneck test

Any approval process should be evaluated against one question: is the process fast enough that employees prefer to use it rather than work around it?

If Tier 3 auto-approval isn't being used because employees don't know the registry exists, fix the communications, not the process.

If Tier 2 reviews are taking four weeks instead of two, find the bottleneck. Usually it's the security team having too many concurrent reviews or the vendor questionnaire not being completed upfront. Fix the process, not the timeline target.

If Tier 1 reviews are taking three months, something is wrong with scope. Review only Tier 1 tools in that process. Don't let Tier 2 requests accumulate in the Tier 1 queue because someone is unsure of the classification.

The three-tier structure only works if tier assignment is consistent and fast. That assignment should happen within two business days of receiving a request, before the actual review begins. Employees should know within 48 hours which tier applies and what the expected timeline is.

Start with the registry

If you're building this process from scratch, start with the approved tools registry, not the questionnaire. Get a list of every AI tool that's already in use in your organization. Classify each one by tier based on its data access and Execute capability. Mark the ones that pass a basic inspection as provisionally approved. Then build the questionnaire and formal review process around the gaps.

A registry of 40 approved tools with proper data classification, available to every employee, does more to reduce shadow AI than a three-month security review process that no one can actually follow.

Bottlenecks drive shadow adoption. Speed and clarity are your primary governance tools.

But approving a tool is only half the job. Once an AI system is in production and taking actions, the question becomes: what happens when it does something wrong, and do you have the logs to prove what actually occurred?

Rework Analysis: Based on enterprise AI governance patterns, the 3-Tier AI Approval Gate most often fails at the tier assignment step, not the review step itself. Tier 2 requests accumulate in the Tier 1 queue because the person receiving the request isn't sure how to classify it. The fix is a 48-hour tier assignment decision (before the review begins) with a simple decision tree: Does the tool access customer PII or regulated data? Does it have customer-facing Execute capability? If yes to either, it's Tier 1. If no, continue to next question. A one-page decision tree, visible to all requestors and reviewers, resolves most classification ambiguity without requiring escalation.

See also: