AI Vendor Due Diligence: Practical Guide for SaaS Teams

AI vendor due diligence works when it converts a proposed use into a defensible operating decision. A SaaS team should understand what the AI service does, which data and people it affects, who supplies its models and infrastructure, how performance and security were tested, which legal role each party holds, what the contract guarantees, and how changes will be monitored. The result is not a completed questionnaire. It is an approval, conditional approval, limited pilot, escalation, or rejection with reasons and named owners.

There is no single universal “AI vendor due diligence” checklist in the EU AI Act. The necessary depth depends on the system, intended purpose, risk classification, role in the AI value chain, data processing, and sector rules. A meeting-note assistant and a model used to rank job applicants should not receive the same review. Begin with the use case, then ask the vendor for evidence proportionate to the consequences.

Why ordinary vendor review is not enough

Traditional SaaS review often concentrates on access control, encryption, uptime, subprocessors, breach handling, and deletion. Those questions remain important, but an AI service adds dependencies and failure modes that can change without a conventional software release.

A vendor may route requests among models, add retrieval sources, change safety filters, use prompts or outputs to improve services, or depend on another model provider. Output quality may vary by language, user group, input pattern, or workflow. A feature described as “decision support” may become practically decisive when employees trust it under time pressure.

The review therefore needs two connected views:

• the supplier view: company, hosting, subprocessors, model providers, security, contract, support, and continuity;
• the system view: intended purpose, users, affected people, data, model behavior, human oversight, integrations, outputs, and downstream actions.

Reviewing only the supplier misses the actual deployment. Reviewing only the feature misses the supply chain. The manual vendor-review problem becomes especially acute when evidence, exceptions, and reassessments live in separate inboxes.

When enhanced AI diligence is needed

Use a short intake to place the proposal into a risk tier. Enhanced review is usually appropriate when one or more of these conditions applies:

• personal, confidential, regulated, security-sensitive, or customer-controlled data enters the service;
• an output influences employment, credit, access, eligibility, safety, legal rights, or another consequential decision;
• the service acts autonomously, triggers external actions, writes to production, or communicates with customers;
• the team fine-tunes a model, connects proprietary knowledge, or embeds the service into a customer product;
• users cannot readily detect or reverse an incorrect output;
• the vendor provides limited information about models, evaluations, data use, subprocessors, or changes;
• failure would create material operational, contractual, reputational, or compliance harm.

A low-risk drafting assistant using public information may justify a lightweight review and clear usage restrictions. A customer-facing agent with account access needs more. A system used in a potentially high-risk AI Act context needs legal classification and detailed technical evidence before deployment.

Do not infer classification from the vendor’s marketing label. Under the AI Act, obligations depend on intended purpose and role. Article 25 also matters across the value chain: rebranding a high-risk system, making a substantial modification, or changing its intended purpose in a way that makes it high-risk can shift provider responsibilities. Providers and third parties supplying components for high-risk systems must cooperate and exchange needed information under written arrangements, subject to safeguards for intellectual property and trade secrets.

As of 30 August 2026, much of the AI Act is applicable, while the amended dates for high-risk rules are 2 December 2027 for Annex III use cases and 2 August 2028 for high-risk systems tied to regulated products. Those transition dates are preparation windows, not reasons to postpone inventory, classification, contracts, or evidence design.

The evidence to request

Avoid sending every vendor the longest questionnaire. Ask for evidence that answers the risks raised by the intended use.

1. System and supply-chain documentation

Request a concise system description covering the service boundary, models and providers, hosting regions, integrations, retrieval sources, subprocessors, supported use cases, prohibited uses, and material limitations. Determine whether the customer can select or change a model and whether the vendor silently routes traffic to alternatives.

Capture version identifiers and change channels. A static model card is not enough if the deployed service can change independently of it.

2. Data lifecycle and privacy

Map prompts, uploads, retrieved content, outputs, feedback, metadata, logs, and support data. For each class, record purpose, location, access, retention, deletion, model-training use, and onward disclosure. Check tenant isolation and whether customer controls actually override consumer defaults.

Where the vendor is a GDPR processor, Article 28 requires more than accepting a data processing addendum. The controller must use processors providing sufficient guarantees. EDPB guidance describes this as a case-by-case and continuing assessment that can consider expertise, reliability, resources, policies, audit reports, and certifications. The processor contract must match the real service and subprocessor chain.

3. Security and resilience

Request relevant assurance reports, control scope, penetration-test summaries, vulnerability and incident processes, encryption details, identity controls, tenant separation, secure development practices, recovery objectives, and service dependencies. For generative AI, include prompt injection, data leakage, unsafe tool use, model or retrieval poisoning, output handling, and abuse controls where relevant.

NIST’s voluntary AI RMF specifically calls for policies covering third-party AI and data, documented controls, contingency processes for high-risk third-party failures, and regular monitoring. Its generative AI profile identifies procurement diligence, service levels, assurance reports, and supply-chain transparency as possible controls. These are useful design references, not proof of legal compliance.

4. Performance and impact evidence

Ask what the vendor tested, on which populations and languages, against which baseline, with what acceptance threshold, and under which operating conditions. Obtain known limitations and failure patterns, not only headline accuracy.

Then run your own use-case tests. Vendor evaluations rarely reproduce your data, instructions, integrations, reviewers, and consequences. Include difficult inputs, unsupported requests, uncertainty, override, escalation, and recovery. For consequential workflows, involve people who understand both the domain and affected users.

5. Governance and accountability

Identify the vendor owner for security, privacy, AI governance, incidents, and customer notices. Ask how models and datasets are approved, how complaints and harmful outputs are investigated, how customers report issues, and which records remain available after termination.

Internally, name a business owner and a risk owner. Procurement cannot own output quality, and security cannot decide whether a use is legally or ethically appropriate by itself. The questions for adopting internal AI tools help connect supplier evidence to day-to-day use.

Contract terms should follow the evidence

Do not treat the contract as a separate legal stage after technical approval. Evidence gaps often need contractual controls.

Depending on risk, address:

• permitted purpose, users, data, and prohibited uses;
• customer-data use for training or service improvement;
• named model providers and subprocessors, locations, and change notices;
• security measures, incident notice, cooperation, audit evidence, and remediation;
• documentation and information needed for classification, instructions, impact review, and customer obligations;
• performance commitments, known limitations, human-oversight expectations, and support;
• notice before material model, feature, safety-control, or data-practice changes;
• service continuity, model retirement, portability, deletion, and exit assistance;
• responsibility, indemnity, liability, and insurance proportionate to the deal and applicable law.

A contract cannot repair an unsuitable system. It can allocate responsibilities, preserve information rights, and create remedies. Confirm that negotiated terms are technically configurable and operationally owned.

A repeatable approval workflow

Step 1: Describe the proposed use

Document purpose, users, affected people, inputs, outputs, integrations, automation, human review, and downstream action. Separate the current use from possible future expansion.

Step 2: Assign a preliminary tier and legal roles

Screen AI Act classification, provider or deployer roles, GDPR roles, transfers, sector requirements, customer commitments, and internal policy. Record uncertainty rather than forcing a premature conclusion.

Step 3: Request proportionate evidence

Use a reusable evidence library, but select questions by risk. Accept current documents where they answer the issue; do not demand custom prose for its own sake.

Step 4: Test the real workflow

Test the configured product with representative data that is lawful and safe to use. Verify access, retention, deletion, monitoring, human override, failure handling, and output behavior. Record versions and results.

Step 5: Resolve gaps and decide

For each gap, choose remediation, a compensating control, restricted scope, time-limited pilot, executive risk acceptance, or rejection. State the owner and deadline. Conditions should be testable: “no personal data” needs an enforced control or credible monitoring, not a slide.

Step 6: Monitor change

Set review triggers for a new intended purpose, integration, model, provider, subprocessor, data category, geography, autonomy level, incident, material performance issue, or regulatory change. Also set a periodic review date. This is how AI governance changes SaaS compliance expectations: customers increasingly expect evidence that stays current after signature.

What the decision record should contain

Keep one concise record with:

• vendor, product, version, owner, and review date;
• approved use, prohibited use, users, data, integrations, and geography;
• system boundary, model providers, and relevant subprocessors;
• risk tier, legal roles, classification rationale, and open assumptions;
• evidence reviewed, tests run, findings, and unresolved gaps;
• contract controls and operational restrictions;
• final decision, approvers, conditions, deadlines, and risk acceptance;
• monitoring owner, metrics, incident route, and reassessment triggers.

Link to source documents instead of copying them into the record. Preserve the version reviewed so a later vendor update does not overwrite the evidence behind the decision.

Common mistakes

Starting with the vendor questionnaire. The team collects pages of answers before defining the use, so it cannot distinguish relevant evidence from noise.

Accepting certifications as the conclusion. Certifications and audit reports can support assurance, but scope, date, exceptions, and the AI workflow still need review.

Reviewing a brand instead of the configured service. Enterprise and consumer tiers may have different retention, training, access, and support terms.

Treating a pilot as risk-free. Pilots can expose real personal data, connect production systems, or influence real decisions. Limit data, users, duration, integrations, and downstream reliance.

Approving once and forgetting. Models, features, subprocessors, and intended uses change. Without notices and internal triggers, the original review quickly describes a service that no longer exists.

FAQ

What is the practical purpose of AI vendor due diligence?

It creates a defensible decision about whether and how a specific AI service may be used. It should reveal material gaps early, allocate controls, and preserve the evidence needed for customers, audits, incidents, and later reassessment.

When does it apply to SaaS teams?

Use at least a lightweight review whenever a third-party AI service enters company or product workflows. Increase depth with sensitive data, consequential decisions, autonomy, customer integration, limited reversibility, uncertain suppliers, or potentially regulated use.

What should a team document first?

Document the exact intended use: users, affected people, inputs, outputs, data, integrations, human review, and downstream action. Without that boundary, neither the vendor’s answers nor the legal classification can be evaluated reliably.

What is the biggest mistake?

Treating diligence as a one-time document exchange. Strong diligence connects scoped evidence, testing, contracts, approval conditions, monitoring, and explicit triggers for reassessment.

AI vendor due diligence should let a team move faster because the decision path is predictable. Scope the use, tier the risk, gather targeted evidence, test reality, close or own gaps, and monitor change. That turns procurement from a questionnaire queue into a repeatable AI governance control.