A standard SaaS vendor risk assessment covers security posture, financial stability, contractual terms, data handling, and infrastructure concentration. It was designed for a portfolio of SaaS applications. It was not designed for AI tools, and the difference matters in ways that create specific compliance exposure if the assessment stops at the standard checklist.
AI tools carry risk dimensions that no traditional SaaS review was built to catch: clauses about whether your data is used to train the vendor's model, regulatory obligations that apply specifically because the tool uses AI, and contractual exit rights that need to be far more specific than a standard termination clause. Every AI tool procurement and every retroactive review of an existing AI tool needs these checks layered on top of the standard assessment.
This guide covers what those checks are, what red flags to stop for, and how to apply the assessment to tools already in use without a formal contract.
What Makes an AI Vendor Risk Assessment Different From a Standard SaaS Review
An AI vendor risk assessment is an extension of the standard five-dimension vendor assessment, covering security, financial stability, contractual terms, data handling, and infrastructure concentration. It adds a second layer of AI-specific checks that the standard methodology does not address.
The core difference is in how AI tools interact with your data. A standard SaaS tool processes and stores company data under agreed terms. An AI tool may also use that data to train or improve its models, operate under acceptable use policies that restrict certain categories of use, and carry regulatory classifications under the EU AI Act that create obligations beyond standard data protection requirements.
Verizon's 2026 Data Breach Investigations Report found that 48% of confirmed breaches now involve a third party, up 60% from the prior year. IBM puts the average cost of a third-party breach at $4.91 million. For AI tools specifically, the exposure compounds: IBM found that incidents involving unsanctioned AI tools cost on average $670,000 more than standard third-party breaches. The additional assessment layer is not procedural overhead; it is the mechanism that closes the gap standard reviews leave open.
For the general five-dimension vendor assessment methodology, see What Is a SaaS Vendor Risk Assessment and How Does It Work?. This piece covers what you add on top of that for AI tools specifically.
Six AI-Specific Checks Every Assessment Should Include
These six checks apply to every AI tool under assessment, whether at the point of procurement or as part of a retroactive review of tools already in use.
1. Data training and model improvement clauses
The most consequential AI-specific check is whether the vendor uses your inputs to train or improve its models. Many AI tools include clauses permitting this in their standard terms, often buried in the acceptable use policy or privacy policy rather than the main contract. The check requires reading the actual terms, not relying on the vendor's summary.
Where a training clause exists, confirm whether an opt-out is available, what the mechanism is, and whether opting out affects the tool's functionality. For enterprise tiers, negotiate an explicit clause prohibiting use of your data for any model training or improvement purpose, with a corresponding deletion obligation.
2. EU AI Act risk classification
The EU AI Act classifies AI systems by risk level. High-risk categories include AI tools used in HR decisions, financial risk assessment, credit scoring, medical diagnosis support, and critical infrastructure management. If the tool being assessed falls into a high-risk category under the Act, the company has obligations: conformity assessments, transparency disclosures, and human oversight mechanisms.
The vendor should be able to confirm whether their tool falls into a regulated category and whether they have completed the required conformity documentation. A vendor that cannot answer this question for a tool operating in a regulated domain is a risk flag in itself. For how these regulatory obligations apply to mid-size companies specifically, see Why AI Tools Are Your Fastest-Growing Compliance Risk.
3. Data residency and AI inference jurisdiction
AI tools often have a split between where data is stored and where AI inference runs. The inference infrastructure may operate in a different jurisdiction from the data storage layer, and both jurisdictions carry regulatory implications under GDPR and data localisation rules.
The check covers two questions: where is company data stored, and in which jurisdiction does the AI processing actually happen? The vendor's privacy policy and data processing addendum are the primary sources. Where the inference jurisdiction creates a compliance conflict with the company's operating markets, that conflict needs to be resolved contractually before the tool is deployed.
4. Acceptable use policy alignment
AI vendors publish acceptable use policies that restrict how their tools can be used. These restrictions are not always visible at the point of purchase and may prohibit specific use cases that the company intends to deploy the tool for: generating content in regulated industries, processing certain data types, or automating specific categories of decision-making.
Confirm that the company's intended use case is explicitly permitted under the vendor's AUP. Where the AUP is ambiguous, get written confirmation from the vendor before signing. An acceptable use violation discovered after deployment creates liability without the protections of a properly scoped contract.
5. Model transparency and explainability
For AI tools used in decisions that affect individuals, including performance management, credit-related processes, or resource allocation, the ability to explain how the model reached a decision is both a regulatory requirement under the EU AI Act and a practical risk management need.
The check covers whether the vendor can provide an explanation of the model's decision logic for a given output, whether audit logs are available and retained for a sufficient period, and whether the contract grants the company the right to request this information. A vendor that cannot support explainability for a high-stakes use case is not a compliant deployment option for that use case.
6. Contractual exit and data deletion
The exit clause for an AI tool needs to go further than a standard SaaS termination clause. It should cover: data deletion across all vendor systems including any training datasets the vendor may have derived from company inputs; output purging if the vendor's model was trained on company data; confirmation of deletion in writing; and a timeline that is reasonable for the company's data retention obligations.
Where the tool was used without a contract and is now being retroactively reviewed, the first priority is to obtain a DPA and a data deletion confirmation as a condition of continuing use. For how DPA gaps accumulate across an ungoverned AI portfolio, see AI Tool Governance for Mid-Size Companies.
Red Flags That Should Pause an AI Tool Procurement
Six conditions warrant stopping the assessment and resolving the issue before any contract is signed or any further use of the tool proceeds.
No data processing agreement available. Any AI tool processing personal data without a DPA is non-compliant under GDPR by default. A vendor that does not offer a DPA is not a compliant option for any use case involving personal data.
Data training clause with no opt-out. A clause permitting the vendor to use company inputs for model training, with no mechanism to opt out, means the company's data is contributing to a model it has no visibility into or control over. This is an unacceptable term for any tool processing sensitive or confidential data.
No current SOC 2 Type II or ISO 27001 certification. These are the baseline security certifications for enterprise AI tool vendors. Their absence does not mean the vendor is insecure, but it means no independent third-party audit has verified the security controls. For tools accessing sensitive data, the absence of certification is a disqualifying condition without additional compensating evidence.
EU AI Act high-risk classification with no conformity documentation. A vendor whose tool falls into a high-risk category under the EU AI Act but cannot produce conformity documentation is non-compliant with the Act. Deploying that tool creates regulatory exposure for the company.
Vendor cannot confirm data residency or inference jurisdiction. If the vendor cannot tell you where your data is stored and where AI inference runs, you cannot assess whether the deployment is compliant with your data protection obligations. This is a fundamental gap, not a minor documentation issue.
Acceptable use policy prohibits the intended use case. Using a tool in a way that violates the vendor's AUP typically voids the contract protections and creates liability without remedy. Confirm alignment before signing.
Find Out Which AI Tools in Your Portfolio Have Never Been Through a Vendor Risk Assessment
CostRoom maps every active AI, SaaS, and cloud tool across your portfolio, identifies the tools running without a reviewed contract or DPA, and delivers a prioritised plan for vendor risk remediation.
How to Apply This Assessment Retroactively to AI Tools Already in Use
For most mid-size companies, the AI tools carrying the highest risk are not the ones being procured today. They are the tools already in active use that were never assessed at all. Flexera's 2026 State of ITAM Report found that only 31% of organisations have accurate AI software visibility. The tools outside that 31% are running unassessed, and a proportion of them will fail one or more of the six checks above.
The retroactive assessment starts with the inventory: a complete list of every active AI tool, built by reconciling finance, IT, and expense management data. Without the inventory, the assessment is operating on an incomplete picture of the portfolio. For how to build this inventory in practice, see the full framework in AI Tool Governance for Mid-Size Companies and the uncontracted spend reconciliation approach in SaaS and Cloud Vendor Risk Management: The Complete Guide for Mid-Size Companies.
Once the inventory exists, apply the six AI-specific checks in risk-tier order: tools accessing sensitive data, operating in regulated environments, or connected to core systems first. For each tool assessed, the outcome is one of three: formalise with a reviewed contract that addresses all six check areas; restrict data access to a compliant scope until the gaps are closed; or discontinue.
The approval process that prevents new tools from entering without assessment is covered in How to Build an AI Tool Approval and Review Process Without a Dedicated IT Team. CostRoom's Spend Analysis and Optimisation delivers the AI software inventory and contract compliance review as an integrated engagement, identifying where each of the six AI-specific checks has not been completed across the full portfolio.
Run an AI Vendor Risk Assessment Across Your Full Portfolio
CostRoom identifies every active AI tool, maps the contract and DPA gaps, and delivers a prioritised vendor risk remediation plan covering spend and compliance together.
Frequently Asked Questions
What is an AI vendor risk assessment? An AI vendor risk assessment is a structured review of an AI tool vendor across the standard five dimensions of vendor risk: security posture, financial stability, contractual terms, data handling, and infrastructure concentration. It adds six AI-specific checks that standard SaaS assessments do not address: data training and model improvement clauses, EU AI Act risk classification, data residency and inference jurisdiction, acceptable use policy alignment, model transparency and explainability, and contractual exit and data deletion terms. The assessment applies both at the point of procurement and retroactively to AI tools already in active use without a formal review.
What is the difference between an AI vendor risk assessment and a standard SaaS vendor review? A standard SaaS vendor review assesses security posture, financial stability, contractual terms, data handling, and infrastructure concentration. An AI vendor risk assessment covers all five of those dimensions and adds AI-specific checks that the standard methodology does not address. The key additions are: whether the vendor's contract permits using company data to train its AI models; whether the tool falls into a high-risk category under the EU AI Act; where AI inference processing occurs in addition to data storage; whether the vendor's acceptable use policy permits the company's intended use case; whether the model can provide explainable outputs for high-stakes decisions; and whether the exit clause includes data deletion and output purging obligations.
What should I check in an AI vendor contract before signing? Before signing an AI vendor contract, confirm: the data processing agreement covers how personal data is stored, retained, and deleted; the contract explicitly addresses whether company data is used for model training, with an opt-out if so; data residency covers both storage and inference jurisdiction; the acceptable use policy permits the company's intended use case; the vendor holds current SOC 2 Type II or ISO 27001 certification; the exit clause includes deletion of all company data and any derived training data, with written confirmation; and, for tools that may fall into EU AI Act high-risk categories, the vendor has completed the required conformity documentation.
How do you assess AI tools that are already in use without a formal contract? Apply the same six AI-specific checks retroactively, working through the AI software inventory in risk-tier order: tools accessing sensitive data or operating in regulated environments first. For each tool, the outcome is one of three: formalise with a reviewed contract that addresses all six check areas; restrict data access to a compliant scope until the gaps are closed; or discontinue. The first priority for any tool identified as high-risk is to obtain a data processing agreement and data deletion confirmation. Continuing to use an identified tool without a contract after it has been flagged creates documented compliance exposure.
