# AI technical due diligence: what the evidence needs to show

A technical diligence framework for AI software investments and vendor decisions: request the right evidence, test material claims and prioritize findings.

Author: TeqEngine
Published: 2026-09-11
Updated: 2026-09-12
Canonical: https://teqengine.ai/insights/ai-technical-due-diligence

## The decision

AI technical due diligence evaluates the software business or product, including the AI-specific dependencies that affect reliability, cost, control and maintainability. Start with the investment or vendor decision, trace material claims to evidence, and separate verified findings from unresolved questions.

- Review the system and its operating evidence, not just a model demo.
- Distinguish severity from confidence and coverage.
- Turn findings into decision conditions and verifiable remediation.

## Define the decision and the scope of access

This guide concerns technical diligence of an AI software product or business. It is not a guide to using AI to summarize a deal room. The distinction matters: an automated document summary can speed information retrieval without establishing that the underlying software works as claimed.

The review should answer a concrete question. An investor may need to understand technical liabilities and the effort required to execute a roadmap. An acquiring company may need to evaluate integration and continuity. A CTO selecting a development partner may need evidence about architecture, delivery and ownership. The same repository can support different conclusions depending on the decision.

Agree the product boundary, access, review period, known exclusions and intended audience. Distinguish a document review from repository inspection, an authorized runtime assessment and an independent security test. Do not imply that a short diligence exercise covers every vulnerability, license issue or operational condition.

Build a claim register. For each material claim, record what is asserted, why it matters, which artifact could substantiate it, what was actually inspected and what remains unknown. This makes the review less vulnerable to either an impressive presentation or an unexplained suspicion.

## Request evidence that can answer the decision

**Initial technical evidence request**

| Area | Artifacts to request | Question the evidence answers |
| --- | --- | --- |
| Architecture and dependencies | Current diagrams, service inventory, deployment topology and critical third-party dependencies. | What must work for the product to deliver its core capability? |
| Repository and delivery | Authorized source access, build instructions, CI results, release history and environment configuration. | Can the current product be reproduced, changed and deployed reliably? |
| Models and AI behavior | Model/provider inventory, prompts and tool contracts, evaluation datasets, results and known failure categories. | How is useful behavior established, measured and maintained? |
| Data and permissions | Data provenance, flows, retention settings, access policies and relevant approved agreements. | What data is required, who may use it and where can it travel? |
| Security and operations | Access controls, dependency findings, incident history, runbooks and recovery evidence. | How are failures prevented, detected and contained? |
| Economics and scale | Usage records, infrastructure and provider spend, workload distribution and performance measurements. | What happens to margin and reliability as use changes? |
| Ownership and continuity | Asset inventory, contributor arrangements, dependency licenses and handoff documentation. | Which assets and responsibilities transfer, and which depend on external parties? |

Handle sensitive material through an approved review environment and access process. Keep live credentials, customer records and confidential documents out of unapproved analysis services. Request redacted or synthetic examples when they can answer the question, and record when that substitution limits the conclusion.

NIST’s Secure Software Development Framework can help structure supplier conversations about development practices. A framework reference is not evidence that the practices are implemented. Inspect a release, a failed build or a remediation record to see how the process works.

Sources: [NIST SP 800-218: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final).

## Examine the dependencies that AI adds

AI-specific diligence extends normal software diligence. It does not replace the need to understand databases, identity, deployment, testing and product architecture. A sophisticated model cannot compensate for missing access control or an unreproducible release process.

- Model dependency: identify the provider, selected model, configuration, availability assumptions and what happens when behavior or terms change.
- Evaluation quality: inspect what success means, how cases were chosen, what is held out and which failures are excluded from reported scores.
- Tool authority: determine what the system can read or change, where permissions are enforced and which actions require approval.
- Data dependency: assess provenance, freshness, customer-specific permissions and the work required to keep retrieval or training inputs usable.
- Human work: measure review, correction and escalation rather than assuming every apparent success was autonomous.
- Unit economics: include retries, paid tools, retrieval, review, monitoring and maintenance in cost per successful task.

When reviewing performance claims, ask for the exact workload, time period, software version and denominator. A peak throughput result is not the same as sustained operation at the required latency. A high accuracy figure on a curated test set is not equivalent to measured task completion across live customers.

For an agent, inspect the final state of the environment as well as the response and tool trace. Anthropic’s evaluation guidance explains why a transcript that says an operation succeeded can differ from the outcome that actually exists.

Sources: [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).

## Review generated code by its properties and ownership

A codebase built with agents deserves the same concrete questions as any other codebase: does it implement the required behavior, enforce boundaries, have useful tests, support changes and have a clear provenance and ownership story? The presence of generated code alone does not answer those questions.

- Reproduce a build from the documented inputs and inspect differences between development and live configuration.
- Trace one important workflow through the interface, API, authorization checks, state changes and error handling.
- Inspect tests that could catch a material regression, not merely a large test count or coverage percentage.
- Check dependencies, committed secrets, exposed administrative paths and the process for addressing findings.
- Review where generated changes entered the delivery process and what verification was required before release.
- Route licensing, contributor rights and contractual ownership questions to the appropriate legal review; technical inspection supplies the artifact inventory and provenance evidence.

Do not use stylistic impressions to infer who wrote a file or whether it is safe. A familiar framework, extensive comments or polished folder structure can coexist with important defects. A small synthetic example can illustrate a concern, but a finding about the reviewed product needs evidence from that product.

[Agent-built codebase checklist](https://teqengine.ai/resources/agent-built-codebase-checklist). Use the shorter inspection checklist when you need an initial pass before defining a deeper review.

## Write findings with severity and confidence separately

Severity describes the consequence if the finding applies. Confidence describes how strongly the available evidence supports it. Coverage describes what was examined. Keeping all three visible prevents a limited-access review from becoming either falsely reassuring or excessively alarming.

**A synthetic diligence finding**

| Field | Example |
| --- | --- |
| Observation | In an authorized staging test, retrying a timed-out create operation produced a second record. |
| Evidence | The request trace and database records show the same intended action completed twice under the tested sequence. |
| Potential impact | If the live workflow behaves the same way, a retry could duplicate a business action. Impact depends on the operation. |
| Confidence and limits | High confidence in the staging result; equivalence with the live system has not been established. No claim about all write paths. |
| Decision condition | Verify the live path and contain the affected operation before enabling unattended writes. |
| Remediation acceptance | Repeat the failure sequence and show one valid action or a documented reconciliation outcome, with regression coverage. |

Avoid describing every missing document as a defect in the software. Missing evidence may be a diligence limitation, an operational risk or a sign that further testing is necessary. State which one the available facts support. Likewise, a known issue with an effective containment measure can warrant a different decision from the same issue left unbounded.

## Make the report useful to the investment or vendor decision

- A short executive assessment tied to the actual decision, with material conditions and uncertainties.
- A current architecture and dependency map, with the parts actually inspected identified.
- A claim-to-evidence register separating observed results, documents, assertions and unavailable evidence.
- Prioritized findings with consequence, confidence, coverage and proposed verification.
- An operating-cost and scaling assessment with explicit workload assumptions.
- A remediation sequence that names dependencies, responsible parties and acceptance conditions.
- A record of access limitations and work that needs a separate specialist assessment.

The report should not become a list of every improvement an engineer could imagine. Prioritize the issues that change the decision: a critical boundary that fails, a capability that cannot be reproduced, a dependency that threatens continuity, or an economic assumption that does not survive measured use.

Separate required remediation from useful future investment. For example, a missing authorization check may need resolution before launch; a more elegant service decomposition may be appropriate later. Explain the reason for the ordering so leadership can allocate attention and funds.

[Inspect a reproducible release decision](https://teqengine.ai/insights/evaluation-release-gate-example). A runnable fixture shows how explicit critical conditions block a high aggregate task score.

## Close the loop with verifiable follow-through

Diligence is most useful when it changes an action. Possible outcomes include proceeding, proceeding with defined conditions, narrowing the scope, obtaining additional evidence or stopping the investment. Technical findings inform that decision alongside commercial, legal and financial review; they do not replace those disciplines.

For each material condition, define what evidence closes it. “Improve testing” is vague. “Add a regression case for the observed retry sequence and demonstrate correct behavior in the target environment” can be checked. Preserve the original finding, the change and the verification result together.

If the system changes materially after the review, identify which conclusions need revisiting. A model replacement, new write-capable tool, different deployment boundary or acquisition integration can invalidate previous assumptions. A dated report should make those dependencies visible.

[Technical and AI diligence](https://teqengine.ai/diagnostic). TeqEngine reviews architecture, implementation and operating evidence to support a specific technical decision. The scope and access determine what the review can establish.

## Questions this guide answers

### What should AI technical due diligence deliver?

A decision-oriented record of findings, evidence, confidence, impact and next steps. It should distinguish what was reproduced from what was reported, and identify the limits of the review. Architecture, security, evaluation quality, operating economics and transferability matter to the extent that they can change the investment or vendor decision.

### How should a buyer assess impressive scale or accuracy claims?

Ask for the workload, period, software configuration and denominator behind each claim. Distinguish a peak result from sustained operation and a curated test score from accepted user outcomes. When underlying evidence cannot be shared, record that limitation and assess any permitted substitute without treating it as independent confirmation.

### How can diligence proceed without exposing customer data?

Use an approved review environment and access process, with redacted or synthetic examples where they can answer the question. Record when those substitutions limit a conclusion. Keep credentials and confidential records out of unapproved analysis services, and request only the access needed for the agreed review.

## Sources and scope

Technical references inform the cited statements. The decision frameworks and synthetic examples are TeqEngine’s editorial guidance.

- [NIST SP 800-218: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

## Continue reading

- [Choose a development partner](https://teqengine.ai/insights/choosing-ai-agent-development-company)
- [Evaluate an agent release](https://teqengine.ai/insights/ai-agent-evaluation-framework)
- [Published healthcare platform work](https://teqengine.ai/case-studies/healthcare-ehr-platform)