The M&A market for deep tech assets is growing faster than the frameworks used to evaluate them. AI-native platforms, hardware-software hybrids, biotech informatics systems, robotics, and compute-intensive research tools are all finding their way into PE and strategic acquisition pipelines — and being assessed with technology due diligence methodologies that were designed for a different era.

Traditional TDD frameworks do several things well. They assess code quality, architectural coherence, scalability under load, security hygiene, team capability, and IP ownership. For a SaaS platform built on conventional software engineering, these dimensions cover most of the material risk.

For deep tech, they leave the most important questions unasked.

What “deep tech” actually means in an M&A context

Deep tech is a broad term. In a due diligence context, it refers to assets where the core value is embedded in something other than the software itself — in trained models and the data used to build them, in the integration of software with physical hardware, in proprietary algorithms that are genuinely difficult to replicate, or in a research programme that has produced protectable IP.

What these assets share is that their value is not legible through a code review. You can read every line of a deep tech codebase and still fundamentally misunderstand what you are acquiring.

Where traditional frameworks break down

The IP is in the model, not the code. Standard TDD includes an IP assessment that covers assignment agreements, contractor work-for-hire clauses, and open source licence compliance. For a conventional software asset, this covers the main exposure.

For an AI-native platform, the most valuable IP is often the trained model weights and the dataset used to produce them. Neither of these appears in a code repository. Neither is covered by a standard licence scan. The questions that matter — who owns the training data, what were the terms under which it was collected, does the dataset include third-party material used without appropriate consent, and do the model weights themselves carry provenance obligations — require a fundamentally different assessment methodology.

Under the EU AI Act, acquirers of high-risk AI systems also inherit compliance obligations that were the seller’s responsibility before close. If those obligations are undocumented or unmet, the cost of remediation transfers unconditionally.

Security assessments miss the new attack surface. A conventional security TDD focuses on the OWASP top ten, authentication weaknesses, dependency vulnerabilities, and infrastructure exposure. These remain relevant for deep tech assets. They are also insufficient.

AI systems introduce a distinct class of security risk that traditional penetration testing does not address. Model extraction attacks allow a well-resourced adversary to replicate a proprietary model’s behaviour through query access alone. Data poisoning can corrupt model behaviour in ways that are difficult to detect after the fact. For large language model-based products, prompt injection represents a live and actively exploited attack vector. Adversarial examples — inputs crafted to produce predictable misclassifications — are a material risk for any AI system used in a consequential decision pipeline.

None of these appear in a standard security assessment. All of them can affect the value of what is being acquired.

Scalability assumptions don’t transfer. Conventional scalability assessment asks whether the platform can handle more users or more transactions. For AI-native assets, the relevant questions are different: what does inference cost at scale, and what are the economics of retraining as data accumulates? A model that runs efficiently at current volumes may become prohibitively expensive at the scale implied by the investment thesis. Compute cost is a structural variable for AI platforms in a way it simply is not for conventional software — and most TDD frameworks treat it as an afterthought.

Team assessment requires domain specialists. Evaluating whether an engineering team can maintain and extend a conventional software platform is something a senior software architect can do independently. Evaluating whether an AI research team has the depth to sustain a proprietary model programme, or whether the platform’s AI capability is genuinely defensible or a temporary lead that better-resourced competitors can close, requires domain expertise that most generalist TDD providers cannot bring.

What a deep tech TDD needs to include

The additional dimensions are not exotic. They are a direct extension of what conventional TDD already does, applied to the actual sources of value and risk in deep tech assets:

• Dataset and model IP assessment — provenance, consent, third-party rights, licence obligations on model weights
• AI regulatory compliance — EU AI Act classification and compliance status, documentation obligations, human oversight requirements
• AI-specific security assessment — model robustness, adversarial testing, prompt injection exposure for LLM-based systems, data pipeline integrity
• Compute and inference economics — marginal cost at scale, retraining cost and frequency, dependency on third-party foundation models and the contractual terms governing that dependency
• Research programme assessment — sustainability of the IP-generating capability, not just the current state of the IP itself

None of this replaces the conventional dimensions. Architecture, code quality, team capability, and standard security hygiene all remain relevant. Deep tech TDD extends the framework rather than replacing it.

The acquirer’s risk in getting this wrong

The asymmetry is significant. Acquirers who apply a conventional TDD framework to a deep tech asset may receive a clean report on dimensions that were never the source of material risk. The training dataset that forms the basis of the platform’s AI capability may carry undisclosed third-party rights. The model’s security posture against adversarial attack may never have been tested. The compute economics at the target scale may make the unit economics of the investment thesis unworkable.

These are not edge cases. They are predictable failure modes that follow directly from applying the wrong framework to the wrong type of asset.

As deep tech assets move further into mainstream acquisition pipelines, the TDD frameworks applied to them need to move with them. The firms that get this right — that commission assessments built for the asset in front of them rather than the assets their providers have always assessed — will make better-informed decisions at the deal table.

At VeryDiligent, we assess deep tech assets across all of these dimensions, including AI-specific security, model and dataset IP, and regulatory compliance. If you are approaching a transaction involving an AI-native platform or other deep tech asset, we would be glad to discuss what a proportionate engagement looks like.

Related reading: What PE Firms Should Demand from Technology Due Diligence | Red Flags in Startup Codebases: A Technology Due Diligence Guide | Technology Due Diligence: Operational and Strategic Value Creation