Technical Due Diligence: 11 Red Flags That Kill AI Startup Deals

Most AI startup deals don't die in term sheet negotiations. They die in the two weeks after a VC says "we're excited" and hands you a due diligence checklist. I've sat on both sides of that table — as the person building the system and as the person stress-testing someone else's. The patterns that kill deals are remarkably consistent, and almost none of them are about the idea.

Here's the uncomfortable truth: a mediocre product with clean architecture raises faster than a brilliant product built on a shaky stack. Investors aren't buying your demo. They're buying their confidence that the thing won't fall apart at scale.

These are the 11 red flags I look for — and that any serious technical diligence process will surface.

Red Flag 1: "Our AI" Is Just an API Wrapper With No Moat

The single fastest way to kill a deal is to have a founding team that describes their core technology as "we use GPT-4 plus our proprietary prompts." If your entire technical differentiation lives in a system prompt that OpenAI can replicate in a product update, you don't have a defensible business — you have a distribution play dressed up as a tech company.

What investors want to see instead: fine-tuned models on proprietary data, RAG pipelines trained on data competitors can't access, or agent architectures with non-trivial orchestration logic. The moat has to be somewhere in the stack. If it isn't, own that and pitch it as a GTM play — don't dress it up as deep tech.

Red Flag 2: No Evals, No Regression Testing, No Benchmarks

If I ask "how do you know when your model gets worse?" and the answer is "our users tell us" — that's a red flag. In AI systems, silent degradation is the norm, not the exception. Model providers update endpoints, context window handling changes, temperature defaults shift. Without automated evals, you are flying blind.

Minimum bar for a serious AI product in 2025: a suite of task-specific evals that run on every deployment, a golden dataset of expected inputs and outputs, and a dashboard showing eval trends over time. Tools like Braintrust, LangSmith, or even a well-structured pytest harness get you there. The engineering to build this is measured in days, not weeks. If it doesn't exist, that tells me the team is shipping on vibes.

Red Flag 3: Hallucination Risk in a High-Stakes Domain With No Guardrails

Building an AI product in legal, medical, financial, or compliance domains with no hallucination mitigation strategy is a liability bomb, not a startup. I'm not saying these domains are off-limits — I'm saying the diligence reviewer will ask exactly one question: "what happens when it's wrong?" If the answer doesn't include output validation, confidence scoring, human-in-the-loop checkpoints, or structured output constraints, the deal is in trouble.

This is fixable. Structured outputs via JSON schema, retrieval grounding, citation requirements, and refusal classifiers are all standard patterns now. The fix takes days to implement. The risk of not having it is existential.

Red Flag 4: Infrastructure That Only Works at Demo Scale

I've seen demos run perfectly on a laptop that would collapse under 100 concurrent users. When I ask about load testing, autoscaling strategy, or p95 latency under real traffic, I want to see numbers — not reassurances. "We'll scale when we need to" is not an architecture decision. It's a wish.

For AI workloads specifically: LLM inference is expensive and latency-sensitive. A system that calls GPT-4 synchronously on every user action, with no caching, no async queuing, and no fallback, will crater under load and drain the runway doing it. Show me your token budgets, your caching layer, and your async task queue. If none of those exist, we have a problem.

Red Flag 5: No Observability Into the AI Layer

Standard application observability (uptime, error rates, response times) is table stakes. For AI systems, you also need trace-level visibility into what your model is doing: what prompts are being sent, what responses are coming back, where in a multi-step chain a failure occurred, and what the token cost per request looks like. Without this, debugging production issues means guessing.

LangSmith, Helicone, Weights & Biases, and Arize are all production-ready options. If your team is running blind in production, that's not a resource problem — it's a discipline problem.

Red Flag 6: Single Points of Failure on Third-Party AI Providers

Building your entire product on a single model provider with no fallback is a concentration risk that diligence reviewers flag immediately. OpenAI has had outages. Anthropic has had outages. Every provider has. If your product goes to zero when the API goes down, you need a mitigation strategy: a secondary provider, graceful degradation, or at minimum a circuit breaker that fails cleanly instead of failing silently.

The routing and fallback patterns here are well-understood. Libraries like LiteLLM make multi-provider routing straightforward. The engineering is not the blocker — the decision to prioritize it is.

Red Flag 7: Data Provenance Nobody Can Explain

For any AI product that trained on, fine-tuned on, or retrieves from a dataset — I want to know where that data came from, whether you have the rights to use it, and how it was cleaned. "We scraped the web" is a legal exposure. "We used a Kaggle dataset" without checking the license is a legal exposure. "Our users generate the training data" needs a clear data rights clause in your ToS.

This is increasingly where deals die in regulated markets. The EU AI Act and emerging US frameworks are making data provenance a compliance requirement, not just a best practice. If the team can't produce a data lineage document, that gap needs to be closed before diligence, not during.

Red Flag 8: Security Posture That Ignores AI-Specific Threat Vectors

Prompt injection is a real attack vector. If your AI system takes user input and passes it, unvalidated, into a system prompt that has access to internal tools or APIs, you have a privilege escalation vulnerability. I've seen demos where a user could type "ignore previous instructions" and exfiltrate data from the retrieval layer. That's not a theoretical concern — it's a known class of attack.

Beyond prompt injection: are API keys hardcoded anywhere? Is your vector store access-controlled? Are you logging conversations in a way that could expose PII? AI systems have a larger attack surface than traditional apps, and the security review needs to reflect that.

Red Flag 9: The Architecture Only One Person Understands

If the technical co-founder leaves, does the system become unmaintainable? Bus factor of one is a red flag in any startup diligence, but it's especially sharp in AI systems where the "magic" is often tribal knowledge about why a particular prompt structure works, why a specific chunking strategy was chosen, or why the retrieval pipeline is configured the way it is.

Documentation isn't bureaucracy — it's what lets the next engineer not break the thing. If the ADRs (Architecture Decision Records) don't exist, if the prompt versioning is a Google Doc with no history, if the model selection rationale lives only in someone's head — that's a risk that gets priced into the deal or kills it.

Red Flag 10: Cost Structure That Doesn't Survive Growth

Unit economics for AI products are non-linear in ways that surprise founders who haven't run them at scale. Inference costs, embedding costs, retrieval costs, and reranking costs all compound. A product that's profitable at 500 users can be deeply underwater at 50,000 if the cost architecture doesn't scale.

I want to see: cost per conversation, cost per API call, token budget per feature, and a model of how those change with volume. Optimization levers like prompt compression, response caching, smaller models for simpler tasks, and async processing should be part of the architecture — not an afterthought for "when we have scale problems." Waiting until you have scale problems is too late; by then the burn rate has already made the decision for you.

Red Flag 11: A Roadmap Built on Features, Not Foundations

The most dangerous kind of AI startup is the one where the roadmap is a list of user-facing features with nothing about reliability, evaluation infrastructure, data quality, or security. Features are easy to promise. Foundations are what determine whether the product can be trusted at scale.

If I look at a roadmap and there's no quarter where the team is paying down technical debt, hardening the eval suite, improving observability, or addressing data quality — that roadmap is a fantasy. Investors who know what they're looking at will see it too.

The one-liner worth keeping: Investors don't fund your AI model — they fund their confidence in your engineering judgment.

What to Actually Do

If you're preparing for a technical diligence process, here's the concrete checklist:

1. Run your own red flag audit before they do. Go through all 11 above and write a one-paragraph honest answer for each. The gaps you can't answer honestly are the ones to fix first.
2. Build your eval suite now, not later. If you don't have automated evals running on every deployment, block out a week and build them. Use Braintrust, LangSmith, or even pytest — pick the one your team will actually maintain.
3. Document your data provenance. Produce a one-page data lineage document: sources, licenses, cleaning steps, and any consent or rights considerations. This document does not take long to write and its absence is a disproportionate deal risk.
4. Add a fallback provider and a circuit breaker. Route through LiteLLM or equivalent, add a secondary model provider, and make sure your system fails gracefully when the primary API is down. This is a weekend of engineering work.
5. Write the ADRs retroactively if you have to. Document why you made the key architectural decisions — model selection, chunking strategy, retrieval approach, prompt versioning. One page per decision. Do it before diligence starts.

The deals I've watched die in diligence almost never died because the product was bad. They died because the team couldn't demonstrate that they'd thought rigorously about the risks. That's a fixable problem — if you fix it before the VC's technical advisor starts asking questions.