The process for approving new AI tools is often uneven. Some receive detailed security reviews, while others pass quickly because similar tools were previously approved. Many bypass formal review altogether through employee accounts, vendor bundles, or developer tools that never reach procurement.
That variation creates the risk. If standards depend on the reviewer or the urgency of the request, your AI tool posture is difficult to defend. This checklist gives procurement and security teams one practical baseline that can be applied across tool types and requestors.
Data Handling: Processing and Data Destinations
Begin by asking what data the tool processes and where the vendor stores or sends it. Risk depends largely on the sensitivity of accessible data and on the vendor's treatment of that data after a session ends.
Record answers to these questions before approving an AI tool:
- Which enterprise data categories will the tool process? Personal information, financial records, health data, intellectual property, and internal communications have distinct risks and may create different regulatory duties.
- Will the vendor use customer data to train or improve its models? If so, what is the opt-out process, and is it automatic or request-only?
- Where does the tool process and store data: on-premises, in a specific cloud region, or on shared infrastructure? The choice affects data residency compliance, especially under GDPR, HIPAA, or sector-specific data localization rules.
- After a session ends, does the tool keep input data? If so, for how long, and which vendor personnel can access it?
If a vendor cannot answer precisely, its data handling cannot be properly assessed. Statements such as "we take security seriously" and general privacy-policy references do not replace documented data-flow details. Missing specifics are themselves relevant to the risk decision.
Access Scope: Visibility and Actions
Next, examine the tool's permissions in your environment. AI products often request broad access during setup. Reviewing those permissions first can prevent a writing assistant from receiving access to file systems or email archives.
- Which permissions does the tool seek during installation or onboarding? Record them explicitly instead of accepting defaults.
- Can deployment use a reduced permission scope? Some enterprise AI tools offer enterprise deployment modes that confine access to a defined boundary. Confirm whether this mode is available and its trade-offs.
- Will the tool require access to communication platforms such as Slack or email? Assess whether that access is necessary for the stated use case or is a data collection capability bundled into a productivity feature.
- What authentication mode does the tool use? Does it rely on your identity provider, or keep credentials in a separate store outside managed identity infrastructure?
Many rushed reviews break down at this point. A tool may sound limited in its description yet request extensive permissions during technical testing. The permission request is the more accurate account of the tool's reach. Reviewers should assess it directly instead of treating the marketing description as sufficient.
Vendor Audit Rights and Compliance Records
Review what the vendor will disclose about its controls and what rights you retain to verify those claims. Your AI governance posture partly depends on those vendors. If a vendor cannot show how its controls operate, your governance claims rest largely on self-attestation.
- Does the vendor maintain a current SOC 2 Type II report, and can customers review it under NDA?
- Did the vendor complete an ISO 27001 or ISO 42001 assessment? What were its scope and result?
- What audit rights does the contract provide? Can you request security assessments, or only review published reports?
- How will the vendor alert clients about security incidents affecting their data? What notification deadline does the contract set?
- How does the vendor handle subpoenas or government requests for customer data?
Not every AI tool has a SOC 2 report. Newer products and smaller vendors may lack current third-party assessments. The practical issue is whether the vendor provides enough visibility for an informed risk decision. With no control evidence, you accept greater risk with less information. The response might be conditional approval with a review date, limited deployment, or a requirement for a compliance assessment within a defined timeframe.
Data Retention and Deletion Rules
Retention is often ignored until a data subject request or litigation hold exposes a gap. Before approving a tool that handles personal or confidential business data, establish how long the vendor keeps it and what deletion rights you have.
- What standard retention period does the vendor set, and can it be configured per account?
- When a subscription ends, how and when is data deleted? What event starts that timeline?
- May you request deletion of particular records? When will the vendor confirm deletion?
- Does the retention policy cover all vendor infrastructure, or can backup systems keep data past the stated period?
This matters especially when an AI tool processes employee communications or creates outputs from proprietary data. Unclear retention terms create compliance risk that becomes harder to resolve after substantial data has accumulated in active use.
Applying the Checklist
A checklist creates a repeatable record of the criteria each tool met or missed, regardless of reviewer or business urgency. That record supports a reasoned choice between conditional approval, required safeguards, and rejection.
A tool that fails data-handling review but passes other checks presents a different risk from one that fails vendor audit rights and access scope together. Consistent records preserve those distinctions and document the decision for later compliance review.
The purpose is not to reject every tool with an imperfect security profile. Useful products may have incomplete documentation or limited audit rights, especially early in their enterprise-market development. A structured review supports conditions such as limited deployment, data restrictions, and a re-evaluation date tied to updated vendor documentation. An ad hoc approval records neither the reasoning nor the follow-up obligations.
Consistent approvals also establish a reliable AI tool inventory. When each approved tool has the same evaluation record, the inventory is documented as well as complete. That is a stronger basis for AI governance compliance than rebuilding a list from memory before an audit.