Tech DD today must also check AI risk

Architecture, team, technical debt, security, scalability, key-person risk and the credibility of the roadmap remain the core of every technical due diligence. AI doesn't replace that. AI adds a layer on top of every one of these areas. Skip it, and you fail to fully assess either the target's risk or its opportunity.

Across the 50-plus technical due diligences we've run, the most common gap wasn't missing expertise in the classic topics. It was that nobody on the DD team consistently folded the AI-specific questions into the existing review framework. They either never came up, or showed up as an isolated add-on section the investment committee skims past.

The reason is usually a skills gap: a DD team with a classic architecture and security background rarely has the same hands-on experience with model dependency or agent operations as a team that works with these systems in production. That experience can't be substituted with a checklist. It has to come from real operational practice.

When core product functions run through a single model provider's API, that provider is a critical supplier, with everything that implies for a diligence: switching cost, price risk, roadmap risk, availability. Check whether an abstraction layer exists that allows a vendor switch without a rebuild, or whether API calls are hard-wired into the code.

Equally relevant: what happens contractually and technically if the provider changes pricing, deprecates a model, or discontinues the service in the region used? A product whose unit economics rest on one provider's current prices carries a risk that had no place in classic diligence.

A team that has already solved this before diligence usually shows it on its own: a thin abstraction layer that makes model providers interchangeable, contracts with more than one provider, and cost monitoring that surfaces a provider price jump immediately. Missing all of that doesn't automatically mean the product is badly built, but it does mean a risk in the business case has so far gone unpriced.

Has the company trained or fine-tuned models on data with unclear legal standing, such as customer data without explicit permission, web scraping, or content uploaded by contractors? That question belongs in every IP and data protection review today, because it touches both warranty and liability questions in the purchase agreement.

The other direction matters too: do the target's customer contracts and supplier contracts even allow customer data to be used for training or as context for AI systems? A clause that rules this out but is ignored in practice is a contract risk that only surfaces on close inspection.

This check overlaps with classic data protection review but doesn't replace it. GDPR-compliant data processing says nothing about whether the same data may also be used for AI training or as context for an agent. That's a separate permission question that should be addressed explicitly in the purchase agreement.

A team that ships AI-generated code without sufficient review discipline builds up a different kind of technical debt than a team with classic legacy baggage, but it's just as real. Checkpoints include how PR size has trended over time, review depth, test coverage, and the incident rate since adopting AI development tools.

An additional signal: is there an eval or regression suite specifically for AI-assisted features, or does the team rely on manual spot-checking? Without such a suite, the claim that "the feature works" is hard to verify, a risk for any data-room claim that rests on those features actually functioning.

Agents with write access to production systems, retrieval systems that accidentally surface sensitive data in a response, and prompt injection via user input or external content are attack surfaces that don't show up in a classic security review. Check concretely what actions an agent can actually take, how those permissions are bounded, and whether a documented incident process exists for agent misbehavior.

One commonly overlooked point: many of these integrations run through third-party plugins or external tools the agent is allowed to call on its own. Every one of these connections is an additional trust anchor that needs review, not just the core integration with the model provider itself.

Can the team actually operationalize AI, or does it stay at the pilot stage? Is there a solid toolchain, documented processes, and the organizational roles a production agent operation needs? This assessment directly affects how credible the AI-driven parts of the business plan are. A growth plan that leans on automation is only as solid as the team's ability to actually deliver it. Anyone familiar with the agentic operating model will quickly spot whether owner, approval limits and audit trail are even defined for the agents already in place, or whether the construct falls apart on the first follow-up question.

A simple test reveals a lot: ask the team to walk a single production agent from idea to current operation: who decided, who runs it today, what metric shows its quality. A team with genuine agentic readiness answers that in minutes. A team with only pilots gets lost describing the technology without ever reaching operations.

A tech DD that only hunts for risk delivers an incomplete picture. Just as important is a sober assessment of AI upside: which of the automation potential named in the business plan is actually achievable with the existing data and system landscape, and which assumes a system replacement or data cleanup the plan doesn't mention?

This assessment prevents two opposite mistakes: a buyer missing real AI potential because the management team never articulated it, or a buyer carrying an overly optimistic AI-driven growth plan into their valuation unchecked. Both happen more often in practice than a pure risk review would suggest.

The findings from these checkpoints belong not just in the report but in contract structuring. Model dependency and data provenance are classic topics for warranties and indemnities in the purchase agreement. Missing agentic readiness is an argument for tying part of the purchase price to defined post-closing milestones instead of making it fully due at signing.

For the 100-day plan after closing, these same findings are the starting point: a risk flagged in the DD report as "fix medium-term" belongs in the first weeks of integration, not in a later roadmap discussion that easily slips out of view amid day-to-day business.

The right place for these checkpoints isn't a separate "AI chapter" sitting in isolation next to architecture, security and team. It's an additional section within each classic chapter: the architecture chapter gets a section on model dependency, the security chapter a section on LLM attack surfaces, the team chapter an assessment of agentic readiness. That keeps the assessment in the format the investment committee already expects, without hiding the new risks.