AI vendor evaluation

AI Vendor Due Diligence: Pricing, Data, Retention, Contracts, and Failure Modes

A vendor evaluation workflow that maps real usage economics, data paths, retention, contract terms, controls, dependencies, failures, and exit requirements.

By WhichAI. Published 2026-07-12. Updated 2026-07-12.

Methodology: Editorial synthesis of workflow design patterns and implementation constraints. Public control references provide context, not proof of a deployment or legal advice. Where a versioned evidence pack appears, its evidence class, method, and limitations govern what the artifact can support. Read the full method. Report a correction.

Built for

Technology buyers, security and privacy teams, procurement, legal operations, finance, and workflow owners

The decision

Decide whether an AI vendor fits the exact workflow, risk boundary, economics, and exit needs before production adoption.

Answer first

Evaluate the vendor against a named workflow and real usage scenario. Trace data and subprocessors, verify retention and control claims, model unit economics, negotiate required terms, test failures, and prove that records and operations can exit.

Self-serve workflow planner

Start with this article's task

For Technology buyers, security and privacy teams, procurement, legal operations, finance, and workflow owners. Start a brief for this task: Decide whether an AI vendor fits the exact workflow, risk boundary, economics, and exit needs before production adoption.

Start this brief

The capacity leak

What the team is doing before anyone calls it a systems problem

Headcount pressure rarely starts with one giant task. It starts when ordinary work is split across inboxes, tabs, handoffs, and undocumented judgment calls. These are the signals to map first.

SIGNAL 01

Teams compare feature demos and seat prices without modeling usage, review, integration, or overage cost.

SIGNAL 02

Data flow, training use, retention, subprocessors, region, deletion, and support boundaries remain in scattered documents.

SIGNAL 03

Contract promises are evaluated separately from the technical configuration and workflow behavior they depend on.

SIGNAL 04

Failure, export, termination, and replacement paths are considered after the workflow becomes operationally dependent.

The implementation

The system should prepare the decision, not pretend the decision disappeared

A complete implementation connects the intake, context, transformation, review, and record. The output of one stage becomes the controlled input to the next. A human owns the exceptions and the final consequence.

Stage	Current drag	System responsibility	Human responsibility	Evidence kept
1. Workflow fit	The vendor is evaluated as a general platform rather than for one operating job.	Define inputs, outputs, volume, users, integrations, decisions, prohibited actions, and review requirements.	Approve the scope and identify non-negotiable operational boundaries.	Workflow brief, volumes, roles, consequences, exclusions, and approvers.
2. Economics	Pricing is reduced to a public seat or entry-tier number.	Model seats, units, tokens, storage, connectors, support, implementation, review, overages, and exit cost.	Validate usage assumptions and choose sensitivity ranges.	Pricing source, date, units, assumptions, scenarios, and reviewer.
3. Data and controls	Security questionnaires are disconnected from the actual data path.	Map collection, transmission, processing, storage, model use, retention, deletion, region, and subprocessors.	Verify evidence and decide whether controls satisfy the organization's requirements.	Data map, vendor evidence, configuration, gaps, owner, and decision.
4. Contract and operations	Legal terms and operational commitments are reviewed in separate queues.	Map required terms to service levels, support, change notice, audit, incident, deletion, and liability needs.	Qualified owners interpret and negotiate contract, legal, security, and procurement terms.	Term requirement, vendor response, approved exception, owner, and final agreement.
5. Failure and exit	The team assumes the vendor will remain available and exportable.	Test outage, rate limit, model change, bad output, escalation, export, deletion, and replacement procedures.	Approve residual dependency and the go, narrow, or reject decision.	Test result, fallback, export artifact, deletion evidence, decision, and review date.

What the human keeps

The goal is not zero humans. It is zero avoidable preparation around the judgment only a responsible owner should make.

Workflow owners prove operational fit and define volume, review, exception, and integration requirements.
Security, privacy, legal, procurement, and finance owners assess evidence and approve terms within their authority.
The accountable buyer decides whether measured utility, full cost, controls, and dependency justify adoption.

Controls before volume

A workflow is not ready because the happy path worked once. It is ready when access, review, fallback, and evidence are explicit.

Date every pricing, security, privacy, and contract source because vendor terms change.
Map policy claims to the exact product tier, configuration, region, and workflow data path.
Record approved exceptions and owners instead of treating questionnaire completion as acceptance.
Test export, deletion, outage, fallback, and replacement before production dependency forms.

Control references

National Institute of Standards and Technology: Privacy Framework Federal Trade Commission: Data Security Guidance

The scorecard

Measure capacity, not activity

A system can produce more messages and still make the operation worse. Measure movement through the workflow, the quality of review, and the load that still reaches a person.

Modeled cost per unit

Total vendor, infrastructure, review, implementation, support, and overage cost per representative work unit.

Evidence coverage

Share of required vendor claims supported by current product-specific documentation or contractual evidence.

Control gaps

Open data, access, retention, security, legal, support, and operational gaps by owner and consequence.

Exit readiness

Ability to export required records, verify deletion, run fallback, and replace the service within approved constraints.

What a fake implementation looks like here

These patterns create an AI demo while leaving the labor, risk, and accountability in the same place.

Buying from a strong demo and entry price without a real usage and review scenario.
Accepting company-level security claims without checking product tier and workflow configuration.
Assuming a privacy policy resolves contract, retention, subprocessor, and deletion requirements.
Discovering that data, prompts, audit history, or operations cannot be exported after termination.

Two ways to act

Use the path that matches the decision

Task-specific workflow brief

Plan this recurring task.

Start with this task draft, then complete the three-question brief:

Build AI vendor due diligence for one workflow covering full usage economics, data flow, training use, retention, deletion, subprocessors, product controls, contract terms, support, outages, model changes, export, fallback, and exit.

Choose a paid plan after reviewing your brief. WhichAI creates a plan and does not set up tools or accounts.

Start the brief

WhichAI Solutions

The workflow is becoming a company problem.

Use Solutions when the vendor will touch sensitive data, several departments, consequential decisions, core systems, negotiated contracts, or enough volume that dependency and operating economics matter.

Bring one bottleneck. We map the work under it, separate consequential judgment from mechanical drag, and decide whether the next move is a hire, a tool, or a rebuild.

See company solutions

Questions

What operators ask before they build

What should AI vendor due diligence start with?

Start with the exact workflow, data, volume, users, integrations, decisions, review, and prohibited actions. Vendor evidence is meaningful only against that operating boundary.

How should AI vendor pricing be compared?

Model full usage units, tiers, overages, storage, connectors, support, implementation, human review, and exit costs with dated sources and sensitivity ranges.

What is the minimum exit test?

Verify export format and completeness, retention and deletion procedure, audit-history access, fallback operation, integration replacement, contract assistance, and responsible owners.

Primary references

Controls should come from the specific operating environment

These are broad public control references, not article-specific evidence, vendor endorsements, or legal advice. Validate the current rules, contracts, system configuration, and organization-specific risk before deployment.

National Institute of Standards and Technology

Privacy Framework

A framework for identifying and managing privacy risk in products and operations.

Accessed 2026-07-14

Federal Trade Commission

Data Security Guidance

Business guidance on reasonable data security practices and reducing unnecessary risk.