AI Due Diligence: 5 Data Room Gaps That Kill Funding Rounds

Most AI funding rounds don't die on valuation. They die in the data room, three weeks after term sheet, when a technical reviewer finds something the founder assumed was fine.

I've been on both sides of this — building the systems that get audited, and advising founders on what to clean up before the process starts. The pattern is consistent: the engineering team is talented, the product works, the demo is sharp. But the technical artifacts tell a different story. Investors aren't just buying your roadmap. They're buying your architecture's ability to scale, your cost structure's ability to survive growth, and your team's ability to maintain what they've built. When the data room doesn't reflect those things credibly, deals slow down or die.

Here's what actually gets scrutinized, and what to do about it.

The Five Layers a Technical Reviewer Audits

A competent technical due diligence reviewer — whether that's a hired CTO, a VC's engineering partner, or a strategic acquirer's tech team — works through five layers in roughly this order:

1. Architecture legibility — can they understand what you built without you explaining it?
2. Cost structure — does your unit economics math survive 10x volume?
3. Dependency risk — how many ways can a vendor decision crater your product?
4. Observability and ops maturity — do you know when things break, and how fast can you fix them?
5. Team and knowledge concentration — is the system in one person's head?

Most founders prep for layer 1 and ignore layers 2–5. That's where deals stall.

Architecture Legibility: Diagrams Don't Lie, But Missing Ones Do

The first thing a reviewer opens is your architecture diagram. If it doesn't exist, or if it's a napkin sketch that hasn't been updated since the seed round, that's an immediate yellow flag. Not because diagrams are sacred artifacts, but because their absence signals that the team hasn't had to explain their system to anyone who can push back.

What a good architecture diagram needs to show for an AI-native product:

• Every external API call (model providers, vector stores, third-party tools)
• Data flow: where does user data enter, where does it touch model context, where does it leave
• Async vs. synchronous paths — reviewers look for hidden synchronous bottlenecks
• Where state lives: database, cache, in-memory, or (worst case) the model's context window

If your system uses agents, the diagram needs to show orchestration boundaries explicitly. A reviewer who has seen agentic systems fail in production will immediately look for whether tool call boundaries and retry logic are documented. I've written about how agent retry logic becomes a silent cost multiplier — that same dynamic makes cost unpredictability a red flag during diligence.

The fix here takes days, not weeks. Get your lead engineer to spend two days in Miro or Excalidraw and produce something a smart non-engineer can follow. Then walk it through with someone outside the team and see where they get lost.

Cost Structure: The Unit Economics Stress Test

This is the layer that kills the most AI deals right now. Investors know that LLM inference costs are volatile — model providers reshuffled pricing multiple times in the past twelve months alone. What they're testing is whether you've built a cost structure that can survive that volatility, or whether your margin thesis is one vendor repricing away from collapse.

The stress test questions a reviewer will ask:

• What's your cost per unit of output at current volume? (Per document processed, per conversation completed, per booking made — whatever your atomic unit is.)
• What does that number look like at 10x volume? Is it sub-linear (good), linear (acceptable), or super-linear (dangerous)?
• What percentage of your COGS is LLM inference today?
• If your primary model provider raised prices 50%, or deprecated the model you're calling, what's your switching timeline and switching cost?

If you can't answer these with real numbers from your observability stack, you're not ready for diligence. "We use OpenAI and it's cheap" is not an answer. A credible answer looks like: "Inference is X% of COGS, we track cost-per-session in our dashboard, we've tested GPT-4o-mini and Gemini Flash as fallback paths, and a provider switch would take our team approximately two weeks to validate."

The model routing layer is where most of the leverage lives. Teams that have implemented intelligent routing — sending simpler tasks to cheaper models — have a structurally better cost story than teams running everything through the same frontier model.

Dependency Risk: The Vendor Concentration Problem

AI products in 2025 tend to have a lot of external dependencies: model APIs, vector databases, embedding providers, orchestration frameworks, cloud-specific services. Each one is a potential deal risk if the reviewer sees no switching path.

The dependency map exercise: list every external service your product calls in production. For each one, answer two questions:

1. What happens to your product if this service is unavailable for 4 hours?
2. What's the realistic time to switch to an alternative?

If either answer is "we break completely" or "six months," flag it. That doesn't mean you need to fix all of it before fundraising, but you need to show you've thought about it. A risk register that says "We're aware that our vector store is a single point of failure; we've scoped a migration path to an alternative that would take three sprints" is infinitely better than silence.

Model dependency is the highest-scrutiny item right now. If your product relies on a single closed-source model with no tested fallback, that's a risk item in every serious technical review. The Kimi K3 weights drop and the steady cadence of open-weight model releases mean that "we could self-host a capable model if needed" is now a credible hedge — but only if you've actually evaluated it.

Observability: If You Can't Show It, It Didn't Happen

A technical reviewer will ask for your production dashboards. Not a prepared slide. The actual dashboard you look at when something goes wrong at 2am.

The minimum bar for an AI-native product in a fundraise:

Signal	Acceptable	Not Acceptable
Request latency	p50/p95/p99 tracked per endpoint	"It feels fast"
Error rates	Tracked by error type, trended over time	"We have Sentry" with no review cadence
LLM call costs	Per-request cost tracked and alertable	Monthly bill as a surprise
Model output quality	At least one eval running in CI	"We test manually before deploys"
Uptime	SLA documented, incidents logged	No incident history

The eval story is the one most teams are missing. If a reviewer asks "how do you know a model update didn't degrade your outputs?" and the answer is "we'd notice in user complaints," that's a serious flag. You don't need a sophisticated eval framework — even a set of golden examples with expected outputs, running in CI, is credible. The point is that quality regression is caught by a system, not by accident.

Knowledge Concentration: The Bus Factor Audit

This one is uncomfortable to document, but investors always find it. The question is: how many people need to leave before your system becomes unmaintainable?

The signals reviewers look for:

• Is there a single person who owns the model integration layer, the infra, and the data pipeline?
• Are deployment procedures written down, or does someone "just know" how to do it?
• Can a new engineer get to a productive first commit in under a week, based on existing documentation alone?
• Is there a runbook for the most common production incidents?

For early-stage teams, some concentration is unavoidable and investors know that. What they're looking for is awareness and mitigation: documented systems, cross-training in progress, and a hiring plan that addresses the gaps. A founder who can say "our infra is currently concentrated in one engineer; here's the documentation they've produced, and here's when we plan to hire a second" is in a much better position than one who hasn't thought about it.

What to Actually Do

If you're 60–90 days from kicking off a fundraise, here's the sequence:

1. Run the five-layer audit yourself first. Go through each layer above and write down your honest answers. The gaps you find are the gaps an investor will find — better you find them first.

2. Produce the three artifacts reviewers always ask for: a current architecture diagram, a cost-per-unit breakdown with a 10x projection, and a dependency risk register. These can each be done in a day by the right person.

3. Get your observability dashboard to a state you'd be comfortable screen-sharing live. If you wouldn't share it unannounced, it's not ready. Fix the gaps — this is usually instrumentation work that ships in days.

4. Document one runbook per major incident type. Pick the three failure modes that have actually hit you in production and write down exactly what you do. This takes an afternoon and signals operational maturity immediately.

5. Test your model fallback path. Swap your primary model for your backup model in a staging environment and run your eval suite. Document the results. This single exercise closes the vendor dependency concern more credibly than any slide.

The technical data room isn't about showing perfection. It's about showing that you understand your own system well enough to know its risks — and that you're running it like engineers, not hoping for the best.

Investors fund judgment, not demos. The data room is where the difference shows up — and fixing it is an engineering problem, which means it's solvable in weeks if you start now.