AI Technical Due Diligence Checklist

Direct answer

AI diligence should separate what is real, demonstrated, unverified, vendor-dependent, manually assisted, or not yet ready to scale.

The demo is often clearer than the evidence behind the demo.

Practical framework

Use this as the decision model.

List each material AI claim.
Tie each claim to evidence, demonstration, data, vendor, and owner.
Inspect evaluation methods and failure behavior.
Review architecture, data rights, model dependencies, cost, and security posture at the agreed level.
Assess team capability and release maturity.
Identify post-transaction priorities.

Examples

How the issue shows up.

A product may appear autonomous while relying on manual review that is not priced or staffed.

Manual assistance can be acceptable, but it must be visible, costed, and staffed.

A model claim may depend on a vendor, private data, or prompt workflow that cannot be transferred easily.

The diligence question is whether the dependency changes transferability, cost, or scale.

Claim taxonomy

Separate claims before evaluating them.

Claim class	Meaning	Diligence question
Demonstrated	Shown working under realistic conditions with evidence the reviewer can inspect.	Does the demonstration match actual production behavior?
Documented	Supported by architecture, evaluation, operational, financial, or legal records.	Do the records support the claim and remain current?
Inferred	Reasonably concluded from surrounding evidence but not directly proven.	What assumption is being made, and how fragile is it?
Vendor-dependent	True only while a third-party provider, contract, rate limit, model, or platform remains available.	What changes if the vendor cost, terms, or capability changes?
Manually assisted	Partly produced by human work, operational review, services effort, or demo preparation.	Is the human work visible, costed, staffed, and scalable?
Roadmap-dependent	Not true today; depends on future build, hiring, data access, model improvement, or integration work.	What must happen before the claim becomes real?
Unverified	Asserted but not supported by available evidence.	Should the claim be excluded, discounted, or turned into a diligence condition?

Evidence request list

Ask for artifacts, not only explanations.

Architecture diagrams showing product, data, model, orchestration, observability, and manual-operation boundaries.
Model and vendor inventory, including model providers, orchestration tools, hosting, data stores, and critical contracts.
Evaluation records, failure examples, regression history, and production test cases.
Production metrics for reliability, latency, usage, cost, incident history, and rollback where available.
Data-rights documentation covering ownership, licensing, consent, retention, training permissions, customer dependencies, and portability.
Incident history, support records, escalation paths, and known failure classes.
Cost and usage data by successful workflow or customer outcome, not only by token, request, or API call.
Team responsibilities across AI, data, product, infrastructure, security, privacy, and operations.
Manual operating procedures, review staffing, exception workflows, and services work that supports the product.
Security and privacy materials appropriate to the transaction scope.
Roadmap assumptions, hiring plan, architecture runway, and dependencies required for stated future capability.

Manual-assistance assessment

Find the human work hidden behind AI claims.

Hidden human work

Compare demos, logs, review queues, support procedures, and customer-specific operating notes to identify work that is being performed outside the software.

Demo-specific preparation

Ask which examples were preselected, cleaned, or manually configured before the demonstration.

Unsupported fallback

Check whether the company relies on informal human intervention when the product fails, stalls, or reaches an ambiguous case.

Services as product

Separate software capability from implementation, onboarding, managed service, or expert-review labor.

Unit economics

Manual review may be necessary, but diligence should show whether staffing and review time still work at expected usage levels.

Vendor-dependency assessment

Understand which parts are proprietary, replaceable, or exposed.

Critical providers

Identify model providers, orchestration platforms, observability tools, cloud services, data vendors, and any provider whose outage or pricing change would materially affect the product.

Replaceability

Separate proprietary company technology from replaceable third-party components and document switching costs.

Contract restrictions

Review usage rights, data handling terms, rate limits, privacy obligations, exclusivity, and termination exposure.

Usage-cost exposure

Model how cost changes with successful customer usage, heavier workflows, larger context, more review, or higher-quality model choices.

Vendor-shaped technical debt

Look for architecture that assumes one provider's response format, tool behavior, evaluation stack, or operational constraints.

Data-rights review

Data advantage is only valuable when it can legally and operationally be used.

Area	What to inspect
Ownership	Who owns source data, derived data, labels, embeddings, prompts, logs, and customer-specific outputs.
Consent and licensing	Whether the company has permission to collect, process, train on, retain, and transfer the data.
Retention and deletion	Whether deletion, retention, and customer-specific restrictions are implemented in the system.
Training permissions	Whether data may be used for model training, fine-tuning, evaluation, or only operational processing.
Cross-border restrictions	Whether geography, sector, or customer contracts restrict processing or vendor choice.
Customer dependencies	Whether the product depends on one customer's data, workflow, contract, or integration pattern.
Data portability	Whether data can move after investment, acquisition, vendor change, or customer churn.

Finding severity

Classify findings by decision consequence.

Critical

The issue undermines a central claim, creates material transaction risk, or requires a change to valuation, terms, transaction path, or go/no-go decision.

High

The issue is fixable but changes first-100-day priorities, staffing, budget, architecture, contract terms, or product scope.

Moderate

The issue is a meaningful maturity gap that should be planned and monitored but does not control the transaction by itself.

Low

The issue is a normal diligence observation with limited near-term consequence if it is tracked and assigned.

Unverified

The evidence is not available or not sufficient. The claim should not be treated as demonstrated until access or evidence changes.

First 100 days

Good diligence should change the operating plan.

Immediate risk controls for claims, data access, model behavior, review paths, and customer exposure.
Hiring priorities for AI, data, product, infrastructure, security, privacy, or operations gaps.
Architecture work required to reduce vendor dependence, improve observability, harden integrations, or support scale.
Evaluation improvements that turn demos into repeatable release evidence.
Contract or vendor actions for data rights, provider terms, rate limits, privacy, or switching risk.
Product-scope changes where current capability cannot support the sales or roadmap story.
Operating-model changes that clarify ownership, incident response, review staffing, support, and learning loops.

Decision criteria

Questions that make the next action clearer.

Can the target reproduce the claimed behavior with realistic cases?
Are data rights and vendor dependencies documented?
Does the roadmap assume capability the team has not demonstrated?

Common errors

What to avoid.

Reviewing AI claims without reviewing evaluation cases.
Treating a demo as proof of production reliability.
Ignoring cost behavior, vendor lock-in, and manual operations.

Sources and related content

This article uses first-hand operating judgment.

This framework is based on the Bato Labs release evidence model and Christopher Petrino's operating experience.

Request Technical Diligence

Choose the closest route. The contact form will preserve the context so the first reply can focus on the right decision.

Find what is blocking an AI release Put one workflow into production Explore fractional leadership Evaluate a company, product, or AI claim Discuss executive advisory Discuss an executive or board opportunity Discuss a founding or venture-building opportunity Not sure yet

AI technical due diligence checklist