AI Vendor Due Diligence: Questions Companies Still Miss

# AI Vendor Due Diligence: Questions Companies Still Miss

This article is step 1/3 of the AI procurement process: vendor assessment. Step 2 (contract clauses) is covered in `governance-ai-procurement-contract-clauses`, and step 3 (process gates) in `governance-ai-procurement-controls`.

Buying an AI solution is not the same as buying classic SaaS. For traditional tools, we usually ask about security, availability, support, and cost. In AI, you must additionally ask about model behavior, training quality, data-use boundaries, update mechanics, and accountability for error consequences. If these questions are not addressed before signing, the company buys not just a feature but also hard-to-estimate risk.

That is the essence of AI vendor due diligence: you are not only checking the provider as a company. You are checking whether its operating, technical, and contractual model can be safely embedded in your business process. Procurement and legal are essential because they convert business ambition into enforceable terms.

The central thesis of this playbook is simple: AI due diligence must cover data, model behavior, security, auditability, accountability, subprocessors, and exit plan - not just a security checklist and license price. Only then can an organization scale AI use without accumulating operational and legal risk.

Why classic procurement is not enough

Many organizations start AI through fast pilots, then involve formal procurement later. This works only until the solution is ready for production, influences customer/employee decisions, or processes sensitive data. That is when unanswered questions appear.

Does the vendor use our data for further model training? How are model versions and behavior changes managed? Can we reconstruct why the system produced a given answer? Who is accountable if a faulty recommendation causes financial loss? How quickly will the vendor report a security incident? Do we know which subprocessors access data and in which jurisdictions?

These are not "extra" questions. They are baseline risk-management conditions. Under NIST AI RMF, AI risk management should cover the full lifecycle: selection, deployment, monitoring, and change. OECD AI Principles emphasize transparency, accountability, and robust security as prerequisites for trusted AI. The EU AI Act further raises expectations around demonstrable compliance and supply-chain control for higher-risk systems.

Procurement and legal must become part of AI governance. If they enter too late, the company quickly reaches a point where deployment is technically possible, but contractually and regulatorily indefensible.

When to trigger AI Vendor Due Diligence

The full due diligence playbook is not required for every experiment at the same depth. It should be mandatory when at least one condition applies: the solution enters production, handles confidential/personal data, affects customer/employee decisions, integrates into a critical process, or is scaled across multiple business units.

For low-risk use, a lighter path is acceptable. For medium and high risk, full assessment is required: security, privacy, model behavior, contract, SLA, subprocessors, exit plan, and audit mechanisms. The key is differentiated pathways, not one heavy process for everything.

Practical rule: if model error can affect people, finances, or company reputation, due diligence must be full and documented. If use is internal and assistive, the process can be lighter, but must still include minimum data security, terms of use, and accountability.

8-domain AI Vendor Due Diligence framework

The most useful structure for procurement and legal is eight domains of questions. Each domain ends with a decision: accept, conditional accept, renegotiate, reject, or pilot with constraints.

### 1) Training Data and Customer Data

Establish which data trained the model, what license/legal restrictions apply, and whether customer data is used for further training. The contract should clearly define: processing purpose, retention, tenant isolation, deletion rights, and prohibition of secondary use without consent.

Control questions: - Will our data be used to train base or derivative models? - What are retention terms for prompts, logs, and outputs? - Does the vendor guarantee complete deletion at contract end?

### 2) Security and Operational Resilience

A classic security review must be expanded with AI-specific threats: prompt injection, context-based data leakage, model-permission abuse, weak environment separation, and supply-chain risk. A security certificate alone is not enough without operating practices and clear incident accountability.

Control questions: - Which controls prevent data leakage through inputs/outputs? - What is the incident detection and reporting process? - What are guaranteed response and remediation times?

### 3) Auditability and Decision Explainability

The vendor should support auditability: event logs, model-version trace, prompt/system-prompt changes, and the ability to reconstruct decision context. Auditability is necessary for disputes, complaints, and incident handling.

Control questions: - Can we reconstruct which model version generated a given output? - Do logs include enough data for internal audit? - How long are logs retained, and in what format?

### 4) SLA, SLO, and Service Quality

In AI, API availability alone does not describe service quality. You need agreements on latency, output stability, cost limits, escalation on quality degradation, and model-version change mechanisms.

Control questions: - Does the SLA include quality parameters, not only uptime? - How does the vendor communicate model changes and behavior impact? - What are rollback and fallback rules?

### 5) Liability and Risk Allocation

The contract must define liability for security breaches, rights violations, systemic errors, IP claims, and losses from defective behavior. Without clear allocation, risk defaults to the buyer.

Control questions: - What are liability caps and exclusions? - Who is liable for training-data and IP claims? - Is there an obligation to cooperate in audit/regulatory proceedings?

### 6) Subprocessors and Supply Chain

Many AI vendors depend on multiple sub-vendors for models, infrastructure, and monitoring tools. You must know who is in the chain, where they process data, and which security standards they apply.

Control questions: - What is the current subprocessor list, and how is it updated? - Does the customer have objection rights for new subprocessors? - In which jurisdictions does processing occur?

### 7) Regulatory Compliance and Documentation

The EU AI Act and standards such as ISO/IEC 42001 are not a single "compliant" checkbox. Organizations need evidence: policies, procedures, test records, risk assessments, monitoring mechanisms, user information, and response processes.

Control questions: - Which documentation artifacts does the vendor provide? - How frequently is system risk assessment updated? - Does the vendor support audits and regulator inquiries?

### 8) Exit Plan and Portability

This is the most frequently ignored domain. The organization should be able to migrate data, configuration, prompts, logs, and integrations. Without this, vendor lock-in grows faster than business value.

Control questions: - What does service termination look like, and what are data return/deletion timelines? - Can the customer export migration-critical artifacts? - What are the costs and constraints of exit?

Realistic scenario: fast pilot, slow scaling

A services company launches an AI assistant pilot for customer support. Month-one results look strong: faster responses and higher consultant productivity. Business pushes for scale. Only then do procurement and legal receive vendor documents.

It turns out log retention exceeds company policy, the subprocessor list is incomplete, and the contract offers no audit right and no full export at exit. In addition, the vendor plans model changes without hard prior-notice obligations. Operationally everything "works," but contractual and regulatory risk is unacceptable.

After full due diligence, the company does not cancel the project. It renegotiates terms: shorter retention, mandatory model-change notifications, audit rights, precise incident SLA, full subprocessor list, and a defined migration plan. Scaling starts three months later, but on terms that can be defended to auditors and the board.

The practical lesson: due diligence should not kill pilots. It should convert fast experiments into safe, scalable operating contracts.

Minimum process for procurement and legal

An effective process can be built in five stages:

1. **Intake and Risk Classification** Define use case objective, data type, decision impact, and risk class.

2. **AI-Specific Requirements Package** Send a standard 8-domain questionnaire with required evidence.

3. **Cross-Functional Review** Procurement, legal, security, risk, and business owner jointly evaluate responses.

4. **Negotiation of Critical Terms** Insert terms for data, audit, SLA, liability, subprocessors, and exit.

5. **Decision Gate and Post-Contract Monitoring** Decision: approve / approve with conditions / reject, plus review cadence after deployment.

Most importantly, due diligence does not end at signature. In AI, vendors and models evolve over time. Periodic reviews of contract terms, quality, and risk are mandatory.

Most common mistakes

First mistake: treating AI like standard SaaS. Second: asking only for certificates and not operating practices. Third: lacking one shared procurement-legal-security-risk pathway, which creates conflicting decisions.

Fourth: no clauses on model changes and service impact. Fifth: ignoring subprocessors. Sixth: no exit plan or portability test. Seventh: scaling before contractual conditions are closed.

Each mistake is fixable, but after deployment the cost of repair rises. That is why due diligence should operate as a stage gate before production, not as an after-incident audit.

What to do now

If the organization lacks AI vendor due diligence, leadership should start with one shared 8-domain checklist and a simple role split: procurement leads process, legal negotiates liability and data terms, security/risk evaluates controls, and business owners accept trade-offs.

Next, connect this checklist to procurement and AI governance workflows: no positive assessment, no production go-live. For existing vendors, run retrospective reviews starting with systems that have highest impact on customers, employees, and financial decisions.

Finally, boards should require an annual review for key AI vendors: subprocessor updates, model changes, incidents, SLA level, compliance status, and exit-plan readiness. This is the simplest way to keep risk under control while AI use scales.

Executive Takeaway

What changed? AI procurement is no longer just buying technical functionality. It is buying model behavior, supply-chain exposure, regulatory risk, and contractual accountability.

Why does it matter? Without AI-specific due diligence, organizations only appear to scale faster. Exposure to incidents, legal disputes, lock-in, and post-launch remediation cost grows.

What should leaders do? Implement a shared procurement/legal playbook across 8 domains: data, security, auditability, SLA, liability, subprocessors, compliance, and exit plan - then tie it to a pre-production stage gate.