Running technical DD yourselves with AI: materials, steps, sample questions, limits, and when to call an expert

With AI, investment teams and corporate development teams can do much of a technical due diligence (technical DD) themselves. Before outsourcing, run the first pass yourselves and narrow down the issues that need an expert’s judgment. In that order, the scope is clear if you do outsource, and the basis for your decision is on record if you do not.

This article gathers the steps into a single practical guide. Details of each evaluation axis are left to existing articles; here we cover what to prepare, in what order to proceed, and where to stop.

1. Who this guide is for

• VC and CVC teams evaluating software or AI startups at roughly seed to Series B
• Corporate teams considering a partnership or a small acquisition
• Organizations without an in-house CTO or technical advisor, or that cannot call on one every time

Large M&A, deals involving IT system integration, and hardware or deep-tech deals are beyond this guide’s scope. Plan for expert involvement from the start in those cases.

2. Dividing work between AI and people

Stage	What AI can take on	What people do
First pass	Reading and summarizing materials, listing issues per evaluation axis	Deciding the scope and axes
Organizing evidence	Mapping claims to evidence, spotting contradictions across documents	Judging how reliable the evidence is
Preparing questions	Drafting follow-up interview questions	Choosing the questions and running interviews
Verifying reality	(Cannot)	Talking with engineers, checking screens, logs, and code
Deciding	Drafting the classification of findings	Making the final walk-away / conditional / acceptable call, and owning it

AI is a tool for quickly listing what needs to be checked. It does not mean anything has been checked. That distinction underlies this whole guide.

3. Materials you need

Split them into what you request from the target and what you collect from public sources. You will rarely receive everything, so record what you did not receive as well.

Request from the target

1. System architecture and infrastructure (cloud services used, how environments are separated)
2. Main technology stack, external services, and OSS components
3. Engineering organization (headcount, roles, outsourcing, tenure of key members)
4. Development process (review, testing, deployment frequency and method)
5. Major outages and security incidents over the past one to two years, with response records
6. Technical roadmap and the list of known technical debt
7. For AI products: models used, evaluation data and procedure, inference cost over time (see the gross margin structure of LLM products)

Public sources

• Careers pages, engineering blog, conference talks, public repositories
• Terms of service and privacy policy
• Status page and history of disclosed incidents

For a complete list of what to request, use the complete technical due diligence checklist.

4. Five steps

Step 1: Decide the scope and weighting

Write in one sentence what this deal needs you to decide. Whether it is “can the product sustain the next two years of growth” or “can this team execute the business plan” changes which axes carry weight. See the full picture and seven evaluation axes for the axes and stage-based weighting.

Where AI helps: Have AI read the business plan and the materials and list the technical conditions the plan assumes. People then set the priority of the axes.

Step 2: Read the materials and map claims to evidence

Extract what the target claims and check whether each claim has evidence.

Where AI helps: Have AI build a table like this from the materials.

Claim	Supporting document and location	Type of evidence	Still unconfirmed
e.g. Handles 1M requests per month	Architecture diagram, p.3	Self-reported	No load test results provided

Classifying evidence as self-reported, third-party record, or directly verified makes the later judgment easier.

Step 3: Confirm through interviews

Use interviews to check what Step 2 left unconfirmed. Even without reading the source code, well-designed questions reveal a lot; see reading technical capability without the source code. For the organization, use how to evaluate the health of an engineering organization.

Sample questions

• When the last production incident happened, who did what from detection to recovery? Can we see the record you kept?
• Did any change released this month reach production without review?
• If someone left today, who would bring development to a halt? Can anyone cover their work?
• Name three things you consider technical debt. When and how do you plan to pay each down?
• (For AI products) When you change models, how do you confirm quality has not dropped?

Where AI helps: Have AI draft follow-up questions from contradictions or vague passages. People choose which questions to ask and whom. Asking the CEO and the engineers the same question and comparing answers is effective.

Step 4: Classify the findings

Sort findings into walk away, proceed with conditions, or acceptable. The criteria and domain examples are in the technical DD red flag catalog. For patterns that tend to surface after the deal, see 10 technical risks that surface after investment.

Where AI helps: Give AI the list of findings and have it draft a classification against the red flag criteria, with reasons. Decide based on whether you agree with those reasons.

Step 5: Record the decision

Finally, put the record in a form the investment decision can use. At minimum, keep these four:

1. What you set out to decide (the sentence from Step 1)
2. What you confirmed, and the type of evidence
3. What you could not confirm (materials not provided, vague interview answers)
4. The classification of findings and your decision on each

Item 3 matters most. If a problem surfaces later, you can tell whether it was missed or knowingly left unconfirmed.

5. Handling evidence

Evidence management tends to get loose when teams run DD themselves. Set these rules first:

• Store every document received in one place, with date received and provider
• Record each interview’s date, participants, questions, and a summary of answers
• For any AI-generated summary or table, keep a pointer to the source passage (do not treat AI output itself as evidence)
• Separate the information you used for the decision from what you did not use

6. Confidential information and code when using AI

Most DD materials are the target’s confidential information under NDA. Before using AI, confirm the following:

1. NDA and consent: Whether entering materials into an external AI service is permitted by the NDA. Obtain the target’s consent if needed.
2. The tool’s data handling: Check the terms and data settings: whether inputs are used for training, and where and for how long they are stored. Use tools your organization has approved.
3. Remove before entering: Strip credentials (API keys, passwords, connection strings), personal data, and customer names.
4. Source code: Even if you receive code, do not paste it in wholesale. Limit it to what is needed and handle it in the way agreed with the target.
5. Records: Log what you entered, when, and into which tool.

If you cannot meet these conditions, limit AI use to public information and documents you produced yourselves. For the security assessment itself (authentication, authorization, encryption), see security basics for decision-makers.

7. The limits of AI-based assessment

Do not decide on AI output alone under these conditions:

Condition	Why	Human verification
Relying only on submitted materials	The target chose those materials	Interviews with engineers on the ground
Not having seen the code or production environment	AI cannot see gaps between design documents and implementation	Look at the code and configuration
Assessing how operations really run	Incident response and deployment practice are rarely written down	Specific questions, checking logs and tickets
Assessing people and the organization	Key-person dependency and attrition risk do not show up in documents	Individual conversations with several people
Assessing an AI product’s performance claims	Demos and self-reported numbers may not be reproducible	Disclosure of evaluation data and procedure; rerun if possible
Relying on current technology or vulnerability information	AI knowledge has a cutoff	Check primary sources (official announcements, vulnerability advisories)

AI can produce plausible but wrong explanations (what hallucination is). Always check numbers and proper nouns against the source.

8. When to bring in an expert

If your own work lands on any of these, consider bringing in an expert:

1. The investment committee or co-investors require an independent third-party assessment
2. Some issues cannot be judged without a specialist review of code, infrastructure, or security
3. An AI product must be assessed down to its models, data, and evaluation setup
4. You suspect a walk-away red flag but cannot judge it yourselves
5. Evaluating in-house would create a conflict of interest, or you cannot spare the time

If you do, hand over your record so far, especially what you could not confirm. The narrower the scope, the faster both sides can work.

Case study: evaluating a Series A SaaS investment (illustrative)

The following is an illustration of the steps, not a specific deal.

• Step 1: The question was written as “can the current engineering organization handle the customer count the plan projects two years out?” Weight went to scalability (see warning signs of scalability limits) and the engineering organization.
• Step 2: The AI-built claims-and-evidence table showed that “almost no outages” rested only on self-reporting, and no incident records had been provided.
• Step 3: The CEO and two engineers were asked the same question. On the latest incident, the CEO said “it was fixed right away”; the engineers said “only one person can touch production.”
• Step 4: Key-person dependency was classified as conditional, with a plan to spread access after the investment as the condition.
• Step 5: The missing incident records were logged as “could not confirm.”

Here the team’s own work narrowed the issues to key-person dependency and missing incident records. If a specialist review of the infrastructure is judged necessary, an expert can be engaged for that scope alone.

Summary

• AI speeds up the first pass and evidence organization; people verify reality and decide
• Five steps: decide the scope, map claims to evidence, confirm in interviews, classify, record
• Handle confidential information and code only after checking the NDA, consent, and the tool’s data handling
• If issues remain that you cannot judge, narrow them down and bring in an expert for that scope

For related evaluation axes, see also how technical DD changes in the AI era and how AI product quality is assured.