Your AI Stack Is Your Cap Table: Investors Audit This

Most AI founders think technical due diligence means "can your system handle traffic." It doesn't. The question serious investors are asking in 2025 is: how exposed are you when a vendor reprices, deprecates, or gets acquired? That's a business risk question dressed in an engineering costume, and if your answers live only in your head, you're going to bleed valuation points in the data room.

I've been on both sides of this — building systems that get audited and advising teams preparing for that process. The pattern I keep seeing: founders over-invest in product demos and under-invest in the documentation that makes an investor trust the demo. Here's the framework I use to get teams ready.

The Stack-as-Liability Mental Model

Every dependency in your AI stack is a contingent liability. Not theoretically — literally. If OpenAI changes the GPT-4o pricing structure (which it has, multiple times), your unit economics shift without any code change on your part. If your vector database vendor gets acquired (it happens), your SLA guarantees may evaporate overnight. Investors doing serious diligence in 2025 map your stack the way they once mapped your customer concentration: they're looking for the one thing that, if it moves, moves your entire business.

The useful mental model: draw a line between commoditized dependencies (things you can swap in days — most embedding models, most object storage, most queuing infrastructure) and sticky dependencies (things that would take months to replace because they're baked into your data schema, your training pipeline, or your customer contract). Investors penalize the latter if you haven't acknowledged them. They're fine with the former as long as you have.

Undocumented vendor dependencies are one of the fastest ways to kill a deal at term-sheet stage — not because the dependency is necessarily fatal, but because the lack of awareness signals that your team hasn't stress-tested the architecture. I've watched it happen to technically solid teams.

The Four Documents Every AI Startup Needs Before Raising

Most teams arrive at due diligence with a GitHub repo and a Notion wiki. That's not enough. Here's what actually needs to exist:

1. Dependency Risk Register

A structured table of every AI vendor in your stack — model providers, vector DBs, orchestration layers, inference infrastructure — with three columns filled in:

• Switching cost: days to replace on a scale of 1–5, with notes
• Data exposure: what do they see? PII? Proprietary domain data?
• Contractual protection: do you have an enterprise agreement, or are you on consumer ToS?

If you can't fill this table in an hour, you have a real problem. If you can fill it in an hour but it's never been written down, you have a due-diligence problem.

2. Unit Economics Model by AI Component

Not just overall gross margin — a breakdown of cost per transaction (or per user, depending on your model) that isolates your AI spend from your infrastructure spend from your labor. Investors want to know: if your LLM token cost doubles tomorrow, what happens to your margin? If you can't answer that from a spreadsheet in the room, you've lost credibility on the financial model entirely.

The numbers that matter: tokens in vs. tokens out ratio per core workflow, p95 latency for your critical path, and the percentage of your COGS that's model inference vs. retrieval vs. orchestration overhead. If inference is more than 60% of your variable cost, that's a flag investors will probe.

3. Model Versioning and Drift Log

This one surprises founders every time. Investors — especially those with technical advisors — will ask: "When the underlying model was updated, what happened to your outputs?" If you don't have eval results across model versions, you don't have an answer. You want to be able to show that you run evals on every model change, that you have a baseline test suite, and that regressions get caught before they reach production.

This isn't just a technical hygiene point. It's a signal that your team treats AI as engineering, not magic. Teams that can't show eval history are implicitly saying: "We ship vibes and hope the model doesn't change." That's not a fundable posture at Series A.

4. Compliance and Data Lineage Map

If you're operating in a regulated vertical (fintech, healthtech, legal, HR) or in a jurisdiction with data residency requirements — and if you're in MENA or EU, you likely are — you need a document that shows: what data flows where, when it leaves your infrastructure boundary, and what controls exist at each hop.

The DIFC and ADGM data protection frameworks in the UAE both have material requirements around data processing agreements and cross-border transfer. Investors with regional exposure will ask. "We're compliant" without documentation is not an answer.

The Evaluation Framework Investors Are Actually Using

After sitting through enough due diligence sessions, I've mapped the implicit scoring rubric most technical advisors apply:

Area	What they're scoring	Red flag
Model dependency	Can they swap LLMs? Do they know the cost to do so?	Single-model, no evaluation harness
Data moat	Is proprietary data shaping model behavior?	Pure prompt engineering on a public model
Observability	Do they know when the system is degrading?	No evals, no tracing, no alerting
Cost predictability	Can they forecast AI spend at 10x users?	Token cost modeled as fixed percentage of revenue
Vendor concentration	Are they one API deprecation from a crisis?	Core workflow depends on a beta API

The highest-scoring teams are almost never the ones with the most sophisticated architecture. They're the teams that have thought through the failure modes and documented them. Maturity signals louder than cleverness.

What "AI Moat" Actually Means to a Technical Investor

Every AI founder claims they have a moat. Almost none of them can articulate it technically. Here's the breakdown of what actually constitutes defensibility:

Real moats:

• Proprietary fine-tuning data that you own, that improves model performance meaningfully on your domain task, and that competitors can't buy
• Feedback loops that get tighter with usage — the system gets measurably better as you process more transactions
• Integration depth that creates switching cost on the customer side (not just on your side)
• Latency or cost advantages from custom inference optimization at scale

Not a moat:

• "We use GPT-4o with a really good system prompt"
• "Our team is very experienced with AI" (this is a team moat, not a technical moat — worth something, but different)
• "We're first to market" (speed is a head start, not a moat)
• A RAG pipeline over your customer's own documents (they can replicate this in weeks)

The test I apply: if someone with your entire codebase and a $500K budget could reproduce your core capability in six months, that's not a moat. If your proprietary training data, your customer feedback loops, or your domain-specific eval framework means they still couldn't match you in a year — now we're talking.

Platform Risk: The Conversation You Must Have Before Investors Do

Platform risk is no longer theoretical. OpenAI's deprecation of its Agent Builder product — announced with limited runway for existing users — is a clean recent example of how fast the ground can shift under a workflow you've built into production. The question isn't whether your vendor will change the rules; it's when, and how ready you are.

Imagine a founder who built their core onboarding automation on top of a platform API that enters public beta, ships fast, gets traction — and then gets deprecated or restructured nine months later because the vendor pivoted priorities. The technical rebuild isn't the crisis. The crisis is explaining to investors mid-raise why the architecture just changed. I've seen this pattern play out more than once across teams I've worked with and advised.

Before any fundraise, run this exercise internally: pick your three most critical vendor dependencies and write a one-page "what we'd do if this vendor deprecated our core API tomorrow." Not a full migration plan — a triage playbook. What breaks first? What's the workaround? How long until customers notice?

If you can't write that document, your architecture has a hidden single point of failure. Investors won't necessarily walk away from single points of failure — but they will walk away from founders who haven't found them yet.

What to Actually Do

1. Build the dependency risk register this week — one row per vendor, three columns (switching cost, data exposure, contractual protection). If your team can't fill it in two hours, you have discovery work to do before the data room opens.

2. Separate your AI cost line items in your financial model — inference, retrieval, orchestration, and fine-tuning should each be their own variable. Model what happens to unit economics at 2x and 10x current token volume.

3. Stand up an eval harness if you don't have one — even a lightweight pytest suite with 50 golden test cases and a score threshold is enough to demonstrate engineering maturity. This ships in days, not weeks.

4. Write your moat in one paragraph, technically — if you can't explain why your system gets harder to replicate over time in concrete engineering terms, your pitch will get picked apart in the technical Q&A.

5. Run the platform-risk tabletop — pick your highest-dependency vendor, assume they break or reprice materially, and map the blast radius. Document it. Investors who find this document in your data room will trust you more, not less.

The founders who lose points in due diligence aren't the ones who made bad technical choices — they're the ones who made reasonable choices and never wrote them down. Documentation isn't bureaucracy. In a fundraise, it's the difference between a clean close and a retraded term sheet.