A demo gets you the meeting. Diligence decides whether the round closes on the terms in the term sheet, and for an AI company the technical review has become a larger share of that process. Investors have seen enough thin products with impressive demos that they now send someone to look underneath.
If you are asking how to prepare an AI startup for technical due diligence, the short answer is: a reviewer is trying to answer five questions, and you should have written evidence for each before anyone asks.
- What is actually yours? What part of the system would be hard for a competent team to rebuild in a quarter?
- Can you prove it works? Not a demo. Measured results on a defined test set, tracked over time.
- Do you have the rights to the data and the models? Training data, customer data, model licences.
- What does one unit of value cost you to deliver, and how does that change with scale?
- What breaks if a vendor changes price, terms, or the model itself?
Security, scalability, and team process sit underneath those. The reviewer typically has one to two weeks, a data room, and a few calls. They are not going to read your whole codebase. They are going to sample, and they will extrapolate from what they find, so the quality of what you hand over matters as much as the quality of the system.
How a technical review usually runs
Processes vary, but the common shape is: a document request list, a walkthrough of the architecture with the technical lead, a deeper session on evaluation and data, a look at the repository and deployment pipeline (sometimes screen-shared, sometimes read access), and a short written report to the investment team with findings rated by severity.
Two things follow from that format. First, the reviewer's report is read by non-engineers, so clear findings, good and bad, carry more weight than nuance. Second, anything you cannot produce within a day or two is recorded as "not available," which reads as "does not exist."
1. Architecture: what is yours
Building on a foundation model API is not a problem. Almost everyone does. The problem is being unable to say what you add.
What reviewers look for:
- A current architecture diagram showing data flow from user input to output: retrieval, prompts, model calls, post-processing, storage, and every third-party service in the path.
- A plain statement of where the differentiation lives. Credible answers include proprietary data with clear rights, an evaluation set and feedback loop competitors do not have, fine-tuned models with measured gains over the base, domain-specific validation and workflow logic, or integrations that are slow to replicate.
- Prompts, schemas, and model configuration kept in version control and deployed through the same process as code. Prompts edited in a vendor console or a database row with no history are a finding.
- A model abstraction layer, so that the choice of provider is a configuration change and not a rewrite.
The question to rehearse: "If your model provider shipped this as a feature next quarter, what would you still have?" An honest, specific answer is better than a defensive one.
2. Evaluation evidence: can you prove it works
This is where most AI startups are weakest, and where a prepared company stands out fastest. We have written separately about the three measurements every production LLM system needs. Diligence is where not having them becomes expensive.
What reviewers look for:
- A defined test set. Representative of real usage, with known-correct answers or a documented grading rubric. Reviewers will ask how it was built, how large it is, and whether it is kept separate from any data used for tuning prompts or training models. If it is not separate, your numbers are inflated and an experienced reviewer will assume so.
- A baseline. Your system against the obvious alternative: the raw foundation model with a simple prompt, the incumbent process, or a human. A score without a baseline tells the reader nothing.
- Results over time. Scores per release, so the reviewer can see that changes are measured and that quality is moving in the right direction. A single snapshot taken the week before diligence is noticeably less convincing.
- Failure analysis. A categorized list of how the system fails and how often. Every AI system has failure modes. A company that can enumerate its own is a company that has looked.
- Production monitoring. How you would know if quality dropped next Tuesday. Sampling and review of live outputs, user feedback signals, alerts.
- Evidence behind marketing claims. If the website says "95% accurate," expect to be asked: on what data, measured how, as of when? A claim you cannot reproduce in front of the reviewer is worse than no claim.
If you use a model as an automated grader, show how you checked the grader against human judgment on a sample. Reviewers increasingly ask.
3. Data rights and handling
Legal diligence covers contracts, but the technical reviewer will check whether practice matches paper.
What reviewers look for:
- Provenance of training and evaluation data. For each dataset: where it came from, under what licence or agreement, and whether that permits commercial use and model training. Scraped data with unclear terms is a finding that can affect valuation, because it attaches to the asset the investor is buying.
- Customer data terms. Do your customer agreements permit what you actually do with their data, especially using it to improve the product? Is it opt-in or opt-out, and can you honor a deletion request, including in fine-tuned models and evaluation sets?
- Third-party processor terms. Which providers receive customer data, under which agreements, with which retention and training settings. Be ready to show the actual configuration, not just the policy.
- A data flow map. What personal or confidential data goes where, what is logged, how long it is kept, who can read it. Logs of prompts and completions are frequently the largest unmanaged store of sensitive data in an AI company.
- Tenant isolation. How one customer's data is kept out of another customer's retrieval results, caches, and fine-tunes. Reviewers will ask how you tested it.
- Model licences. If you build on open-weight models, know the licence for each. They differ: some are permissive, some carry attribution or naming requirements, acceptable-use policies, or thresholds above which a separate commercial licence is needed. Have a one-page summary.
4. Unit economics per request
Investors want to know whether gross margin improves or collapses with growth. For an AI product, that depends on inference cost per unit of customer value, and many founders only know the monthly total.
Work it out per unit. The structure is simple:
cost per task = (input tokens x input price)
+ (output tokens x output price)
+ retrieval, embedding, and tool-call costs
+ retries and fallbacks (failure rate x cost of a retry)
+ human review (review rate x cost per review)Then tie it to revenue: tasks per customer per month, cost per customer per month, against what that customer pays.
What reviewers look for:
- Cost per task measured from production logs, not estimated, broken down by step for multi-call pipelines and agents. Agent loops with unbounded steps are a specific concern.
- The distribution, not just the mean. A small number of heavy users or very long documents often account for a large share of spend. Know your top percentile.
- Whether pricing protects you: usage-based components, fair-use limits, or tiering, so that one customer cannot make themselves unprofitable.
- A cost-reduction roadmap grounded in measurements: caching, prompt reduction, routing easy requests to smaller models, batch processing, or moving steady high-volume workloads to self-hosted models. If that last option is on your roadmap, show the break-even math. Our self-hosted versus API cost comparison lays out the inputs, and the Blueprint planner will size the hardware.
- Sensitivity: what happens to margin if your provider's price rises, or if a committed-use discount ends.
5. Vendor dependency
What reviewers look for:
- A switching test. Have you actually run your evaluation set against a second provider or an open-weight model? "We could switch" is an assertion. A table of scores across two or three models is evidence, and it also demonstrates that the evaluation harness is real.
- Pinned model versions. You call dated snapshots, you know the deprecation schedule, and you have a documented process for validating and migrating to a new version.
- Rate limits and quotas. Your current limits against your peak usage, and against the usage in the growth plan you are pitching.
- Failure behavior. What users experience when the provider is slow or down. Timeouts, fallbacks, queues, graceful degradation.
- Terms-of-service fit. Your use case is permitted by the provider's usage policies, including any restrictions on the sector you sell into or on using outputs to train other models.
6. Security
A startup is not expected to have an enterprise security program. It is expected to have the basics and to have thought about AI-specific risks.
- Standard hygiene. Secrets in a manager and not in the repository, single sign-on and multi-factor authentication on critical systems, least-privilege access to production, dependency scanning, backups that have been restored at least once.
- Prompt injection and tool use. If the model reads untrusted content (web pages, emails, uploaded files) and can also take actions or access data, show how those are separated. What can the model do with its credentials if fully manipulated? The right answer is "very little, and here is why."
- Output handling. Model output is treated as untrusted input wherever it is rendered, executed, or passed to another system.
- Abuse and cost controls. Per-user rate limits and spend caps, so a leaked key or a scripted attacker cannot run up an inference bill.
- Compliance status, stated accurately. "SOC 2 Type I complete, Type II observation period under way" is fine. Claiming a certification you do not hold will be discovered and will cost far more than the gap itself.
- Incident history. What has gone wrong and what changed afterwards.
7. Scalability and operations
- Load test results at a multiple of current peak, with latency percentiles, not only averages. For streaming products, include time to first token.
- Identified bottlenecks: provider rate limits, vector database, a single-instance component, GPU capacity.
- Deployment pipeline, rollback procedure, and how prompt and model changes are gated by evaluation results before release.
- Observability: tracing through multi-step pipelines, cost and token dashboards, alerting.
- Reproducibility for any model you trained: the code, data version, configuration, and the ability to produce the same artifact again.
- Key-person risk. If one engineer holds the whole system in their head, write it down before diligence begins. Documentation produced during the review reads exactly like what it is.
The evidence pack
Assemble this before the round opens. Most of it is a few pages each.
| Document | Answers |
|---|---|
| Architecture diagram and data flow map | What is yours, where data goes |
| Third-party services list with purpose, data shared, and contract terms | Vendor dependency, data handling |
| Evaluation report: test set description, method, baseline, results by release | Does it work |
| Failure-mode summary and production monitoring description | Do you know where it fails |
| Evidence file for each public performance claim | Are the claims true |
| Data inventory with source, licence, and permitted uses | Data rights |
| Model licence summary | Rights to the models you build on |
| Unit economics worksheet from production logs | Margin now and at scale |
| Multi-model comparison on your evaluation set | Switching cost |
| Load test report and capacity plan | Scalability |
| Security overview, access policy, incident log, compliance status | Security posture |
| Known issues and technical debt register with a plan | Candor and judgment |
That last item is deliberate. Reviewers find the problems regardless. A company that lists them first, with priorities and rough effort, gets credit for judgment. A company that gets caught leaving them out loses credibility on everything else in the data room.
Red flags that slow a round down
- No evaluation set, or one assembled the week before diligence.
- Accuracy claims on the website with no reproducible source.
- The test set overlaps with data used to tune prompts or train models.
- Training data of unknown or scraped origin.
- Customer data used for model improvement without clear contractual permission.
- Cost per request unknown, or gross margin that excludes inference cost.
- A single model provider, never tested against an alternative, called through a floating alias.
- Prompts that live outside version control.
- A demo environment that behaves differently from production, or a demo path with hard-coded responses.
- Production secrets in the repository history.
- One person who is the only one able to deploy or explain the system.
None of these is fatal alone, and most can be fixed in weeks. Several together tell the reviewer that the company has been optimizing for the demo.
If the round opens in a month
Week 1. Freeze an evaluation set from real usage, with a separate holdout. Run the current system and a simple baseline. Write down the method.
Week 2. Pull per-request cost from logs and build the unit economics worksheet. Run the evaluation set against one alternative model. Pin model versions if you have not.
Week 3. Write the data inventory and licence summary. Check that processor settings match your privacy policy. Fix the obvious security gaps: secrets, access, rate limits.
Week 4. Draw the architecture and data flow diagrams, write the known-issues register, run a load test, and have someone outside the team read the pack and ask the awkward questions.
If you want an outside read on your evaluation evidence or unit economics before a reviewer sees them, that fits within the assessment work on our services page.
