AI Vendor Due Diligence Checklist: 12 Essential Calm Checks

If you’re buying AI in 2026, you’re not just buying “a model.” You’re buying a behavior that will touch your data, influence decisions, and quietly shape how your team works. That’s why an AI vendor due diligence checklist is no longer procurement theater—it’s operational survival. The moment your copilots become agents, your vendors stop being “tools” and start being part of your control plane.

This guide is built for the people who actually have to live with the decision: founders, product leaders, IT/security, ops, analysts, and the tech-driven knowledge worker who ends up owning the workflow after the demo is over. The goal is calm, not paranoid: a repeatable AI vendor due diligence checklist that helps you buy reliability, protect optionality, and avoid getting trapped by vague promises.

Why an AI vendor due diligence checklist suddenly matters more

AI procurement used to be about features and pricing. Now it’s about risk shape. When a vendor can see your tickets, drafts, internal docs, customer records, or meeting transcripts, you inherit new failure modes: data exposure, prompt injection through untrusted inputs, silent retention, vendor lock-in, and “confident wrong” outputs shipped into real workflows.

Most teams feel this shift first as anxiety: the demo looked brilliant, but you can’t explain where the data goes, what gets logged, or how to unwind the integration if the vendor changes terms. A practical AI vendor due diligence checklist turns that anxiety into questions you can actually verify—before you sign.

And yes, this connects directly to how serious teams are scaling agentic work: separating recommendation from execution, adding review gates, and treating governance like infrastructure. If your org is already thinking in that direction, the patterns in agent governance rules and workflow orchestration apply cleanly to vendor selection too.

How to use this AI vendor due diligence checklist without slowing down

Due diligence fails when it becomes a 90-question spreadsheet nobody reads. The trick is to run this AI vendor due diligence checklist as a gated workflow—fast at the top, deeper only when the deal is real.

Gate 1: The 15-minute “can we even consider them?” screen

Ask for three artifacts upfront: a security overview, a data handling summary, and an architecture diagram. If they can’t produce them quickly, you’ve learned something important.

Gate 2: The 60-minute risk map

Walk through the 12 checks below and score each as Green / Yellow / Red. Your goal is not perfection; it’s clarity. Most vendors are Yellow in some places. The question is whether the Yellow areas are acceptable in your context.

Gate 3: The contract-aligned verification pass

Anything that matters must be written down. “We don’t train on your data” is not a vibe. It’s a clause, a control, and an audit story. A mature AI vendor due diligence checklist ends with enforceable commitments.

AI vendor due diligence checklist: 12 essential calm checks

These checks are organized into four pillars: Security, Data & Rights, Reliability, and Commercial Reality. You can run them in order or start with your biggest risk area.

1) Identity, access, and tenant isolation

Start where breaches usually start: access. Ask how the vendor enforces identity and separates customers. You want clear answers on SSO/SAML, MFA, role-based access control, and tenant isolation (logical and, if relevant, physical).

Key questions:

• Do you support SSO/SAML and granular RBAC by default?
• Is data isolated per tenant, and how is isolation enforced?
• Can we restrict which admins can view prompts, logs, and outputs?

If the vendor can’t explain isolation in plain language, treat it as a red flag. It means your AI vendor due diligence checklist is doing its job early.

2) Data routing: what leaves, what stays, what’s optional

Most “AI vendors” are actually a routing layer across models, tools, and storage. Ask for a simple map: what data is sent to third parties, what stays in their systems, and what stays in yours.

This is where a privacy-first posture becomes practical, not ideological. If your workflows include sensitive context, the principles in local-first routing help you decide what should never leave your environment.

Key questions:

• Which subprocessors handle our data, and for what purpose?
• Can we force certain workloads to run in a specific region?
• Can we disable optional telemetry and analytics collection?

3) Data retention and deletion you can verify

“We delete data” is meaningless unless you can define what data, when, and how. Your AI vendor due diligence checklist should force precision: prompt logs, embeddings, uploaded files, tool outputs, transcripts, and admin-access logs.

Key questions:

• What is the default retention period for prompts, files, and outputs?
• Can we set retention to 0 or a short custom window?
• How does deletion work across backups and downstream systems?

If the vendor can’t offer configurable retention, your risk posture becomes “trust us forever.” That is not calm; it’s fragile.

4) Training and tuning: the “do you learn from us?” truth test

This is the question leadership asks, but it’s usually answered with marketing language. Ask for the exact policy: do they train foundation models on customer data, do they fine-tune, do they create aggregate learnings, and what is the opt-out mechanism?

Key questions:

• Do you train any models on our inputs or outputs? If not, is that contractual?
• Do you use our data to improve prompts, routing, or evaluation systems?
• What is the process to verify the setting is applied to our tenant?

In a strong AI vendor due diligence checklist, this becomes a written commitment plus a control you can validate in admin settings or an audit letter.

5) Tool permissions and least-privilege design

The risk explodes when the AI can act. If the vendor offers agents, ask how they scope permissions: read-only vs write, field-level restrictions, allowlists, and confirmation gates.

This mirrors the practical guardrails in prompt injection controls: you don’t let untrusted text trigger high-impact actions, and you don’t let a model “inherit authority” just because it can.

Key questions:

• Can we run in “recommend-only” mode by default?
• Do you support allowlists for tools, domains, and actions?
• How do you prevent an agent from escalating scope mid-run?

6) Prompt injection resilience (especially indirect injection)

Indirect prompt injection is the risk most buyers underestimate: the model reads an email, a ticket, a webpage, or a PDF that contains hidden instructions—and follows them. Your AI vendor due diligence checklist should test how the vendor separates “data” from “instructions.”

Key questions:

• Do you have an instruction hierarchy and content-isolation safeguards?
• Do you scan retrieved content for suspicious instructions?
• Do you limit retrieval size and sanitize tool outputs?

If they claim “our system prompt prevents it,” treat that as an answer from 2023.

7) Audit logs that survive a real incident

When something goes wrong, you need an explanation you can defend: what was retrieved, what was sent, what tool calls happened, and what changed. Logging is not bureaucracy; it’s how you make automation debuggable.

Key questions:

• Do you provide tool-call logs with parameters and timestamps?
• Can we export logs to our SIEM?
• Can we see admin access events and data export events?

A calm AI vendor due diligence checklist treats observability as a first-class feature.

8) Evaluation and quality control: how they measure “working”

Vendors love to show outputs. You want to know how they measure outcomes. Ask what evaluation harness they use: regression tests, scenario suites, groundedness checks, and how they handle drift when models update.

Key questions:

• Do you run automated evals before changing models or prompts?
• Can we add our own test cases and acceptance criteria?
• Do you support human review workflows for high-risk outputs?

This connects to the reality explained in AI tool limitations: fluency is not reliability, and “seems right” is not a metric.

9) Reliability: uptime, latency, rate limits, and graceful failure

AI vendors often hide reliability behind “best effort” language. If the tool is in a core workflow, ask for real numbers and real failure behavior. What happens when the model fails, the tool fails, or the integration fails?

Key questions:

• What is your uptime SLA, and what is excluded?
• How do you degrade gracefully during outages or throttling?
• Do you provide status history and incident postmortems?

Your AI vendor due diligence checklist should treat reliability as a product requirement, not a support issue.

10) Compliance posture: evidence, not badges

Many vendors wave compliance badges and hope you stop asking questions. Don’t. Ask for the evidence that matters to your use case: SOC 2 report scope, ISO alignment, data processing addendum, and regional commitments.

Helpful anchors for this conversation include widely used risk frameworks and security community baselines, such as the OWASP LLM application risk mapping (OWASP Top 10 for LLM Applications) and risk management guidance like the (NIST AI RMF).

Key questions:

• Is your SOC 2 scope relevant to the AI features we will use?
• Do you have a DPA and list of subprocessors available now?
• Do you support customer audits or third-party assessments?

11) Commercial leverage: pricing, overages, and hidden lock-in

AI pricing is rarely simple. Usage-based billing, tokenization, per-seat fees, and “agent runs” can create surprise overages. Your AI vendor due diligence checklist should test for predictable cost and negotiable risk.

Key questions:

• What triggers overages, throttling, or forced plan upgrades?
• Do you offer cost controls, budgets, and usage alerts?
• Are features gated behind enterprise plans you’ll inevitably need?

Also ask the uncomfortable question: if the vendor’s margin depends on keeping you confused about usage, you’re not buying calm.

12) Exit strategy: portability of data, prompts, and embeddings

Most teams discover lock-in too late—after they’ve built a workflow library, shipped integrations, and stored embeddings or agent memory. This is where your AI vendor due diligence checklist earns its keep.

Key questions:

• Can we export prompts, configs, logs, and evaluation suites in usable formats?
• Can we export embeddings and the source documents used to create them?
• What happens to our data on termination, and how do we verify deletion?

If they can’t describe exit cleanly, assume the business model includes inertia.

A simple scoring model that makes decisions easier

After you run the 12 checks, don’t overthink it. Use a simple scoring rule:

• Green: clear, verifiable, contractable.
• Yellow: acceptable with compensating controls (review gates, redaction, limited scope).
• Red: vague, unverifiable, or misaligned with your risk category.

Then decide with an adult posture:

• Proceed only if all Reds are either eliminated or moved behind a strict boundary (read-only, sandbox, low-sensitivity data).
• Require contractual language for anything that affects data rights, training, retention, and breach obligations.
• Build a small pilot with real workflows, not “demo prompts,” and measure correction rate and rework time.

This is where orchestration thinking wins: the vendor is one node in a system, and your workflow design can absorb some risk—if you acknowledge it explicitly. That’s the same “process beats vibes” mindset behind orchestrated AI workflows.

Red flags that should stop procurement fast

Some signals are not “concerns.” They’re deal-breakers. If you see multiple of these, your AI vendor due diligence checklist should trigger a hard stop:

• They can’t explain data routing and retention without switching to sales language.
• They won’t provide a subprocessor list or a DPA until after signature.
• They claim prompt injection “is solved” without describing layered controls.
• They offer agents with broad write access but no confirmation gates or allowlists.
• They can’t produce export formats for prompts, logs, or embeddings.

None of these make them evil. They make them risky for your specific workflow maturity.

What to put in the contract when it matters

A lot of risk lives in the gap between “policy” and “obligation.” If the tool will touch sensitive data or high-impact workflows, your contract should explicitly cover:

• Data usage: no training on your data, no reuse beyond service delivery unless explicitly permitted.
• Retention: defined windows, deletion commitments, and treatment of backups.
• Security events: breach notification timelines and incident reporting.
• Subprocessors: disclosure, change notifications, and the ability to object.
• Auditability: access to logs, reports, and compliance evidence relevant to your use.

If your vendor can’t support this, you can still use them—just don’t pretend it’s a low-risk integration. Route accordingly, keep sensitive work local, and rely on controlled prompts and templates—habits that pair naturally with a prompt management system.

The calm advantage: buying reliability instead of promises

The best AI procurement outcome is not “the smartest model.” It’s the most stable workflow: clear boundaries, clear data handling, visible logs, and an exit path you can actually execute. That’s what a modern AI vendor due diligence checklist is for—turning excitement into a decision you can defend six months later.

Run the 12 checks, score them honestly, and design your rollout like infrastructure: recommend-first, verify always, and automate only when you can audit. That’s how you keep speed without chaos—and why your next vendor decision should start with an AI vendor due diligence checklist.