Short answer: yes, and it already is in the better-run processes. The longer answer is about which parts belong in the technical assessment rather than the legal one, because getting that split wrong produces a report that satisfies nobody.
I write this as someone who runs technical due diligence for investors rather than as a lawyer. The distinction matters, and I will be explicit about where my competence ends.
What changed
Two years ago, AI in diligence meant asking whether the target’s AI claims were real. That question has not gone away - it remains the single most valuable thing a technical reviewer does - but it is no longer sufficient.
AI regulatory exposure now appears as its own line item in diligence scopes, and AI-specific warranties are becoming standard in transaction documents: warranties on training data ownership and licensing, on ownership of model outputs, on compliance with applicable AI regimes, and on the absence of unauthorised AI use by employees. Where those warranties exist, somebody has to do the work that supports or contradicts them, and a good deal of that work is technical rather than legal.
Meanwhile the underlying facts changed. Developers report that a large and rising share of code is now AI-generated or AI-assisted. That has consequences for IP provenance, licence contamination and code quality that did not exist when the standard diligence checklist was written.
The split that works
Legal counsel owns: whether the target’s systems fall in a regulated category, contractual allocation of provider and deployer roles, warranty and indemnity drafting, and the assessment of regulatory risk in money terms.
Technical diligence owns: whether the answers the target gives counsel are true, and whether the engineering reality can support the compliance position being claimed.
That second one is the point. A target can tell its lawyers it has data provenance records. A technical reviewer finds out whether those records exist, whether they cover the training runs actually in production, and whether anyone could reconstruct them under scrutiny. The gap between the represented position and the buildable evidence is exactly the risk the investor is paying to have measured.
What I now ask on every technical review
Six additions to the standard scope. None of them require a lawyer, and all of them can be answered from the codebase, the pipeline and an hour with the engineering lead.
What AI is actually in the product, and is the claim honest? Still the highest-value question. A meaningful proportion of “AI-powered” products are rules engines with a language model bolted to the edge. That is not fraud, but it changes the defensibility of the moat and it changes the regulatory analysis, because a system that does not make consequential decisions is not in a high-risk category.
Where did the training data come from? Ask for provenance on the data behind whatever is in production. Licences, collection dates, consent basis where personal data is involved. Inability to answer is common, and it is a finding: it means the IP warranty is unsupported and any future regulatory obligation will be expensive to retrofit.
Which third-party models and what do their terms allow? Model licences vary in ways that matter commercially. Some open-weight licences restrict commercial use or impose conditions at scale. A target building on a model whose licence does not permit their use case has a problem that survives the acquisition.
How much of this codebase was AI-generated, and what review did it get? Not to disapprove - we use these tools ourselves - but because the review discipline is the risk, not the tool. Ask whether there is a written policy, whether generated code is marked, and whether security-critical paths were human-authored. Our governance policy guide sets out what a credible answer looks like.
What would this system need to satisfy Articles 9 to 15 if it were classified high-risk? Even where the target is not currently in scope, this is a cheap way to price a future obligation. Logging that supports traceability, data lineage, meaningful human oversight, versioned models with rollback. Present or absent is a factual question. We have written up the engineering detail in what the AI Act changes about how you build software.
Is anyone using AI tools on material they should not be? Shadow AI is a real finding. Ask what is sanctioned, then look at whether anything suggests otherwise. Customer data or source code in consumer AI accounts is a live confidentiality and contractual exposure.
What this does to valuation
I am wary of the numbers circulating on this. Various advisory firms publish specific percentage discounts for AI regulatory risk; I have not seen methodology I would rely on, and I would not repeat those figures as fact.
What I will say from doing the work: the findings that move price are rarely the regulatory ones directly. They are the ones regulation exposes. A target that cannot document training data usually cannot document much else, and the remediation cost lands on the buyer - the same compounding problem we set out in the true cost of technical debt. A codebase where nobody knows which parts were generated usually has weak review discipline generally. Regulatory questions are an unusually effective probe for engineering maturity, which is what the investor is really buying.
The other price-relevant finding is remediation cost with a date attached. High-risk obligations under Annex III start on 2 December 2027.1 If a target is in that territory and has none of the groundwork, that is quantifiable work on a known deadline. That belongs in the model.
The regional picture for investors
EU targets. The classification question is unavoidable. The good news is that the timetable moved in July 2026: Annex III high-risk obligations shifted from August 2026 to December 2027.2 A target that looked non-compliant three months ago may now have adequate runway. Check the current dates rather than the ones in your last checklist.
UK targets. No AI Act, so no equivalent classification exercise. The exposure is data protection under existing law and, increasingly, contractual commitments made to EU customers. Read the customer contracts, not just the regulations.
US targets. The messiest picture. State laws in force since January 2026, more starting in January 2027, and a federal preemption effort under way.3 For diligence purposes, work from where the target actually sells and which use cases it touches, and expect the answer to change during your hold period.
Everywhere else. Gulf and most Asia-Pacific jurisdictions have lighter domestic regimes. The exposure travels with the customers, so a Dubai or Singapore target selling into Europe carries European obligations regardless of where it is domiciled.
What I would not do
I would not turn technical due diligence into a compliance audit. The investor is buying an assessment of whether the technology works, scales and can be maintained by the team that built it. AI regulatory exposure is one input to that, and a process that spends its time on regulatory checklists while missing a single-key-person dependency has failed at the job.
I would also not accept a compliance certificate as an answer. ISO/IEC 42001 certification tells you an organisation has a management system. It does not tell you the training data is licensed or the logging would survive an audit. Verify the artefacts.
If you are underwriting a technology business and want the AI questions handled properly inside the technical review rather than bolted on, that is what we do. Our due diligence checklist covers the standard scope, and this material now sits alongside it. Book a conversation if you have a live deal.
References
- European Commission - Regulatory framework for AI. Dates checked 20 August 2026.
- Orrick - EU AI Act Update: Digital Omnibus Finalizes 8 Compliance Changes, July 2026.
- The White House - Ensuring a National Policy Framework for Artificial Intelligence, December 2025.