Introduction
Most organizations evaluating AI vendors in 2026 are running a 2019 playbook. They send a standard security questionnaire, request the SOC 2 report, check the ISO 27001 certificate, and call it due diligence. Then they sign.
According to McKinsey's 2025 State of AI survey, 47% of organizations reported at least one negative consequence from GenAI use — yet governance hasn't kept pace with adoption.
That standard process misses the risks that actually matter with AI:
- What data trained the model
- Whether your data will retrain it for someone else
- How the system behaves when inputs are adversarial
- What happens when the model drifts months after go-live
This guide is written for boards, audit and risk committees, CISOs, General Counsel, and enterprise leaders in regulated sectors. It covers what a defensible AI vendor risk assessment includes, how to structure the process, which frameworks govern AI vendors in 2026, and the mistakes that leave organizations exposed.
TL;DR
- Standard vendor due diligence (SOC 2, ISO 27001) doesn't address training data exposure, model drift, prompt injection, or AI-specific regulatory obligations
- A defensible assessment covers six domains: data handling, model governance, security controls, compliance alignment, AI supply chain, and operational resilience
- AI systems change faster than traditional software, so continuous monitoring and annual reassessment are the floor, not the ceiling
- Boards should receive a plain-English AI vendor risk posture, not just a completed questionnaire
- Financial services, healthcare, and retail face layered obligations — EU AI Act, NIST AI RMF, HIPAA, SR 11-7 — that must be mapped before contracts are signed
What Is an AI Vendor Risk Assessment — and Why Traditional TPRM Falls Short
An AI vendor risk assessment is a structured evaluation that goes beyond financial stability and security certifications. It examines how a vendor's AI models are trained, what data they process, how outputs are governed, and whether adequate controls exist to prevent harm, compliance failures, or operational disruption.
The Limits of Standard TPRM
Traditional Third-Party Risk Management (TPRM) was built for deterministic software. A SOC 2 audit verifies controls around availability, confidentiality, and processing integrity. It says nothing about:
- Whether training data was lawfully obtained
- How the model behaves under adversarial inputs
- Whether your data will be used to improve models for other clients
- How the vendor detects and responds to model drift
A vendor can be fully SOC 2 compliant and still carry significant AI-specific risk. The OWASP LLM Top 10 identifies prompt injection, training data poisoning, sensitive information disclosure, and supply-chain vulnerabilities as primary LLM risks — none of which fall within the scope of standard security certifications.
What Changes With AI Vendors
Assessing an AI vendor requires AI-specific addenda, model cards where available, and governance questions many vendors aren't prepared to answer. That unfamiliarity is itself a signal. A vendor that can't explain when their model is likely to fail, or can't identify their AI subprocessors, hasn't done the governance work required for enterprise use.
That governance gap on the vendor side also exposes a gap on yours. Organizations without a dedicated CISO or internal AI governance function should bring in a board-level advisor early: one who can set risk thresholds, build the assessment framework, and ensure findings reach the board as defensible reporting — not just a completed spreadsheet.
How to Conduct an AI Vendor Risk Assessment
A rigorous AI vendor risk assessment follows four sequential phases. Shortcutting any phase doesn't reduce risk — it relocates it to your organization.
Step 1: Scope and Tier the Vendor
Not all AI vendors carry the same risk. A vendor running AI over customer PII to automate credit decisions is categorically different from one using AI to summarize internal meeting notes.
Tier vendors by three factors:
| Factor | High Criticality | Low Criticality |
|---|---|---|
| Data sensitivity | PII, PHI, financial records | Internal non-sensitive documents |
| Autonomy level | Fully automated decisions | Human-reviewed outputs |
| Business impact | Core operations, customer-facing | Internal productivity tools |
Tiering determines assessment depth:
- High-criticality vendors: Full technical review, independent audit evidence, contractual AI governance provisions, ongoing monitoring
- Low-criticality vendors: Abbreviated assessment using trust center documentation and prior certifications
Focus board visibility on the top 10–20 vendors by business impact. The rest belongs in management reporting.
Step 2: Issue the AI-Specific Questionnaire
The questionnaire must go beyond standard security domains. Cover:
- Training data: Sources, ownership, legal basis for use, data collection methods
- Model explainability: How decisions are made, whether model cards exist
- Bias testing: What demographic segments were tested, when, and by whom
- Your data use: Will your inputs be used to train or improve models for other clients?
- AI subprocessors: Which foundational model providers, cloud services, and data enrichment vendors have access to your data?
- Incident response: What's the protocol for AI failures, harmful outputs, or model compromise?
- Regulatory alignment: EU AI Act, NIST AI RMF, ISO/IEC 42001 — does the vendor map their practices to any of these?
What acceptable looks like: The vendor produces model cards, identifies specific bias testing methodologies and results, names their AI subprocessors and confirms governance obligations flow downstream, and describes specific failure modes with associated controls.
What insufficient looks like: Vague statements like "we follow industry best practices," inability to confirm whether client data trains the model, or no documentation of third-party AI dependencies. Treat vague responses as a signal about the vendor's governance maturity, not an administrative gap to chase down later.
Step 3: Validate Evidence, Not Just Statements
Vendor assertions are a starting point. What matters is the evidence behind them. Request and review:
- SOC 2 Type II reports — check the scope carefully for AI-specific controls
- Penetration testing results scoped to AI systems, including adversarial testing
- Third-party bias audit findings
- Data lineage documentation
- Subprocessor agreements confirming AI governance obligations extend downstream
Once evidence is collected, weight it against the vendor's specific risk profile:
- Security controls weighted highest for vendors handling sensitive data
- Compliance documentation weighted highest for regulated use cases
- Model governance weighted highest for autonomous decision systems
The output should be a risk posture you can report to a board or audit committee with confidence — one that stays current, not one that sits in an archived spreadsheet.
Step 4: Establish Ongoing Monitoring and Reassessment Triggers
AI systems change faster than traditional software. Model updates, retraining on new data, changes to underlying foundation models, and regulatory shifts all create new risk after initial assessment.
Minimum reassessment cadence: Annual. That cadence assumes nothing significant changes — but several events should force an earlier review.
Out-of-cycle triggers:
- Vendor security incident or breach notification
- Significant model update or retraining event
- Material change in data use policy
- New regulatory obligation affecting the use case
- Vendor's underlying foundation model provider changes
Between formal reassessments, maintain visibility through ongoing signals rather than waiting for an annual checkpoint.
Continuous monitoring between cycles:
- Track external signals — regulatory enforcement actions, breach notifications, public model failures
- Monitor model performance against agreed SLAs
- Confirm fallback procedures remain viable as the vendor's AI architecture evolves
Key Risk Domains Every AI Vendor Assessment Must Cover
Data Handling and Provenance
Assessors must understand where training data originated, how it was collected, and whether your organization's data will be used to improve or retrain models for other clients. IBM's 2025 Cost of a Data Breach Report found 97% of organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% lacked AI governance policies.
Key questions:
- Does the vendor have legal rights to the training data they used?
- What is the contractual restriction on using your data for model training?
- How is data segregated between clients?
- Does data handling comply with GDPR, CCPA, and HIPAA as applicable?
Model Governance and Explainability
Any AI vendor handling decisions that affect customers, employees, or regulated processes must document how decisions are made. Request model cards, bias testing results across relevant demographic segments, and audit log capabilities.
If a regulator asks your organization to explain an AI-driven decision, "we don't know how the vendor's model works" is not a defensible answer. Under the EU AI Act's deployer obligations, it's not a compliant one either.
Security Controls Specific to AI Systems
MFA, encryption, and SOC 2 certification cover the baseline. AI systems require a separate layer of defenses on top of those:
- Input validation to prevent prompt injection
- Output filtering to prevent data leakage through model responses
- Rate limiting on API access to prevent training data extraction
- Adversarial testing specific to model vulnerabilities
Stanford HAI's 2025 AI Index reported 233 AI-related incidents in 2024, a 56.4% increase over 2023. The attack surface is growing faster than most vendor security programs are adapting.
Third-Party AI Supply Chain
Most AI vendors don't build everything in-house. They rely on foundational models from major providers, cloud infrastructure, and data enrichment services. Each layer adds risk your standard vendor questionnaire won't surface.
Consider what happened in March 2023: a bug in an open-source library caused ChatGPT users to see titles from other users' chat histories, with payment-related information exposed to 1.2% of ChatGPT Plus subscribers during a nine-hour window. That breach originated at the platform provider level, entirely outside the deploying organization's control.
That's the supply chain problem in practice.
Require full documentation of the AI supply chain:
- Which foundational model providers are used?
- Which subprocessors have access to your data?
- Do contractual governance obligations flow downstream to those subprocessors?
Operational Resilience and AI-Specific SLAs
Service level agreements for AI vendors must cover accuracy and model reliability — not just uptime. A model that's available but producing incorrect outputs is worse than no model at all.
AI-specific SLA provisions should include:
- Model performance thresholds (accuracy, false positive/negative rates)
- Retraining and update notification requirements with defined lead times
- Fallback to manual processes when model performance degrades
- Liability provisions for AI-generated errors in regulated contexts
Compliance Frameworks Governing AI Vendors in 2026
EU AI Act
The AI Act became generally applicable on 2 August 2026. Key milestones: prohibited practices and AI literacy rules applied from 2 February 2025; general-purpose AI model obligations from 2 August 2025.
Organizations using third-party AI are deployers under the Act , not just passive customers. Article 26 obligations for deployers of high-risk AI systems include:
- Implementing technical and organizational measures to use systems per instructions
- Assigning human oversight to competent persons
- Monitoring operation and maintaining logs where under their control
- Informing providers or authorities when serious risks are identified
High-risk categories under Annex III include biometrics, employment and worker management, access to essential services, and law enforcement — precisely where many enterprise AI deployments land.
NIST AI Risk Management Framework
For US-based organizations, the NIST AI RMF provides the most operationally useful structure. Its four functions map directly onto vendor assessment stages:
- GOVERN: Establish risk appetite, accountability, and policies for AI vendor use
- MAP: Identify how the vendor's AI fits into your processes and what risks it introduces
- MEASURE: Assess and track those risks using the evidence collected in the assessment
- MANAGE: Prioritize remediation, monitor ongoing performance, and respond to incidents
The RMF explicitly covers third-party and supply-chain risks, which means you can use its language directly in vendor conversations — requesting specific governance documentation and benchmarking vendor practices against your organization's stated risk tolerance.
Sector-Specific Obligations
Regulated industries face additional AI obligations layered on top of general frameworks:
Healthcare: AI vendors handling PHI must be covered under Business Associate Agreements. HHS guidance confirms that a cloud service provider handling encrypted ePHI is a business associate , and that obligation extends to AI subprocessors.
Financial services: The OCC issued revised model risk management guidance on 17 April 2026 (Bulletin 2026-13), updating the 2011 SR 11-7 framework. The guidance states generative AI and agentic AI models are "novel and rapidly evolving" and outside its current scope — which means organizations have no prescribed standard to fall back on and must define their own model risk approach for these systems.
Retail: California's AB 2013 required AI developers to post training data summaries by 1 January 2026. The California Privacy Protection Agency's rulemaking addresses automated decision-making technology, cybersecurity audits, and risk assessments under CCPA.
Contracts as a Compliance Mechanism
Across all of these frameworks, contracts are the primary lever organizations actually control. Boilerplate vendor agreements rarely include adequate provisions, and they must be negotiated before signature, not after an incident:
- Mandatory AI use disclosure: What AI is used, for what purpose
- Data use restrictions: Explicit prohibition on using client data for model training without consent
- AI audit rights: Right to request and review AI-specific evidence between renewals
- Regulatory change notification: Defined timeframes for notifying clients of changes affecting compliance
- Indemnification: For AI-specific compliance failures and errors
Common Mistakes and Red Flags in AI Vendor Assessments
Treating AI Vendor Risk as an IT Procurement Decision
The most common organizational failure is routing AI vendor selection entirely through procurement or IT. AI vendors that access sensitive data, automate regulated decisions, or touch customer-facing workflows represent a category of risk that belongs on the audit committee agenda.
Board-ready AI vendor reporting should include:
- A plain-English risk posture (not just a score)
- What changed since the last review
- Specific decisions the board needs to make versus what's delegated to management
- Open exceptions with owners, due dates, and consequences if deadlines slip
Accepting Compliance Claims Without Evidence
Vendors claim to be "SOC 2 compliant," "GDPR aligned," or "bias-tested" regularly. That language is not evidence. It's marketing copy.
The specific documentation that must be requested and reviewed :
- SOC 2 Type II report — not just confirmation that one exists
- Penetration test results scoped to AI systems
- Bias audit findings from a third party
- Data lineage documentation
- Subprocessor agreements
Missing evidence is a high-risk indicator regardless of how the rest of the assessment scores. The FTC has made clear that AI companies must honor privacy and confidentiality commitments — and that remedies can include requiring deletion of models built with unlawfully obtained data.
Post-Onboarding Risk: Model Drift and Ongoing Monitoring
Verifying a vendor at onboarding is necessary — but it's not sufficient. Many organizations close the file after contracts are signed. Model drift, changes to training data, updates to underlying foundation models, and new regulations all create material risk that emerges well after the assessment is complete.
A structured ongoing monitoring posture includes:
- Scheduled performance reviews against agreed SLA thresholds
- Tracking external signals — breach notifications, regulatory enforcement, public model failures
- Confirmed fallback procedures tested at least annually
- Defined escalation path to the board or risk committee when monitoring surfaces anomalies
Five signals should trigger out-of-cycle escalation:
- A vendor security incident
- A significant model update
- A data use policy change
- Deteriorating model performance metrics
- A new regulatory mandate affecting the use case
Frequently Asked Questions
What makes AI vendor risk assessment different from standard vendor due diligence?
AI vendors introduce risks that standard questionnaires and certifications weren't built to catch: training data exposure, output unpredictability, algorithmic bias, and attack vectors like prompt injection and data poisoning. SOC 2 and ISO 27001 address operational security controls — they don't evaluate model governance, bias testing, or AI supply chain dependencies.
Which compliance frameworks apply to AI vendor risk assessments in 2026?
The primary frameworks are EU AI Act, NIST AI RMF, and ISO/IEC 42001. Sector-specific obligations layer on top — HIPAA for healthcare, SR 11-7 (updated via OCC Bulletin 2026-13) for financial services, and CCPA/state equivalents for retail. Which combination applies depends on your industry, geography, and the specific AI use case.
What questions should boards ask about their AI vendor risk posture?
Boards should expect clear answers to four questions:
- Which AI vendors have access to sensitive data?
- Are training data restrictions contractually enforced — and verified?
- What's the fallback if an AI vendor fails or produces harmful outputs?
- Has the risk posture changed since the last briefing, and if so, why?
How often should AI vendor risk assessments be updated?
Annual reassessment is the minimum. Out-of-cycle reviews should be triggered by: a vendor security incident, a significant model update or retraining event, a material change in data use policy, or a new regulatory obligation affecting the use case.
What are the most critical red flags that an AI vendor is not ready for enterprise use?
Watch for: inability to explain how the model makes decisions, refusal to confirm whether client data trains the model, absence of AI-specific security testing, no compliance mapping to relevant regulations, and no documented incident response plan for AI failures.
How should regulated industries approach AI vendor risk differently?
Regulated organizations must map AI vendor capabilities to sector-specific requirements before contracting — BAA coverage for healthcare AI subprocessors, SR 11-7-aligned model risk documentation for financial services, and data minimization verification for consumer-facing retail AI under CCPA. Generic vendor questionnaires won't surface these gaps. Deliberate adaptation is required.
