--- # === IDENTITY === id: business/ma/ai-due-diligence-checklist/2026 canonical_question: "What is the AI/ML due diligence checklist for acquiring a tech company?" aliases: - "AI due diligence M&A" - "ML due diligence checklist" - "AI acquisition assessment" - "tech company AI evaluation" entity_type: concept domain: business > ma > AI due diligence checklist region: global jurisdiction: global temporal_scope: 2023-2026 # === VERIFICATION === last_verified: 2026-02-28 confidence: 0.86 version: 1.0 first_published: 2026-02-28 # === TEMPORAL VALIDITY === temporal_validity: status: evolving last_breaking_change: "2025-08-01" next_review: 2026-08-27 change_sensitivity: high # === CONSTRAINTS === constraints: - "EU AI Act enforcement began August 2025 for prohibited AI systems and February 2026 for general-purpose AI — compliance status is now a material diligence item" - "Training data provenance and licensing is the single highest-risk area — many AI companies cannot prove they have rights to all training data" - "Third-party model dependencies (OpenAI, Anthropic, Google APIs) create vendor concentration risk that does not exist in traditional software" - "AI model performance degrades over time (model drift) — point-in-time evaluation during diligence may overstate operational capability" - "AI talent is the scarcest resource — key person risk is extreme, with founding ML engineers often essential to model maintenance" skip_this_unit_if: - condition: "User needs general M&A due diligence rather than AI-specific assessment" use_instead: "business/ma/due-diligence-framework/2026" - condition: "User needs AI regulatory compliance rather than M&A diligence" use_instead: "software/compliance/eu-ai-act-overview/2026" # === AGENT HINTS === inputs_needed: - key: ai_maturity question: "What is the target company's AI maturity?" type: choice options: - "AI-native company (AI is the core product)" - "AI-enhanced product (AI features embedded in SaaS)" - "AI infrastructure company (MLOps, data platform)" - "Traditional company with emerging AI capabilities" # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/business/ma/ai-due-diligence-checklist/2026" suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-02-28)" # === RELATED UNITS === related_kos: related_to: - id: "business/ma/due-diligence-framework/2026" label: "M&A Due Diligence Framework" - id: "business/ma/valuation-methods-compared/2026" label: "M&A Valuation Methods Compared" often_confused_with: [] depends_on: - id: "business/ma/due-diligence-framework/2026" label: "M&A Due Diligence Framework" solves: [] alternative_to: [] # === SOURCES === sources: - id: src1 title: "AI and Machine Learning Due Diligence (+ Checklist Download)" author: Fast Data Science url: https://fastdatascience.com/ai-due-diligence/ type: industry_report published: 2025-08-01 reliability: high - id: src2 title: "M&A Technology Due Diligence Checklist for 2026" author: L40 url: https://www.l40.com/insights/m-a-technology-due-diligence-checklist type: industry_report published: 2026-01-10 reliability: high - id: src3 title: "AI Due Diligence Checklist (2025 Update)" author: Lumenalta url: https://lumenalta.com/insights/ai-due-diligence-checklist-updated-2025 type: industry_report published: 2025-09-15 reliability: high - id: src4 title: "M&A Checklist: Supplemental AI Due Diligence Checklist" author: Bloomberg Law url: https://www.bloomberglaw.com/external/document/XFS1E72O000000/m-a-checklist-supplemental-ai-due-diligence-checklist type: official_docs published: 2025-10-01 reliability: authoritative - id: src5 title: "AI Due Diligence: What It Is & Impact on M&A (Full Guide)" author: Datasite (Dealroom) url: https://dealroom.net/blog/ai-due-diligence type: industry_report published: 2025-11-20 reliability: high - id: src6 title: "Tech Due Diligence Checklist: What to Evaluate in 2026" author: PatSnap url: https://www.patsnap.com/resources/blog/articles/tech-due-diligence-checklist-2025/ type: industry_report published: 2026-01-05 reliability: moderate_high --- # AI/ML Due Diligence Checklist ## Definition AI/ML due diligence is a specialized extension of technology due diligence that evaluates the intelligence layer of a target company — its model architecture, training data provenance, third-party AI dependencies, MLOps maturity, inference economics, regulatory compliance (particularly EU AI Act), and key person risk among ML engineers. As AI becomes embedded across SaaS products, understanding the quality, ownership, and risk profile of AI capabilities has become as important as reviewing the software codebase itself. This checklist supplements, not replaces, the standard 8-workstream M&A due diligence framework. [src2] [src5] ## Key Properties - **Seven Assessment Pillars**: Model Architecture, Training Data, IP & Licensing, Performance & Reliability, Infrastructure & MLOps, Regulatory Compliance, AI Talent [src1] - **Highest Risk Area**: Training data provenance — most AI companies cannot fully prove they have commercial rights to all data used in model training [src4] - **EU AI Act Impact**: Prohibited AI systems enforcement began August 2025; GPAI model obligations from February 2026 — compliance status is a material deal risk [src3] - **Third-Party Dependency**: Heavy reliance on OpenAI/Anthropic/Google APIs creates vendor concentration risk with unpredictable pricing and terms-of-service changes [src2] - **Inference Economics**: Compute costs for running AI models in production can represent 30-60% of COGS for AI-native companies — unit economics depend heavily on inference optimization [src5] - **Key Person Risk**: AI/ML teams often have extreme knowledge concentration — loss of 1-2 founding ML engineers can render a model unmaintainable [src1] ## Constraints - AI model evaluation requires hands-on technical access (model weights, training code, data pipelines) that sellers may resist providing in early-stage diligence [src1] - Point-in-time model performance metrics do not capture model drift — request 6-12 months of production performance data to assess degradation patterns [src3] - Open-source model components (Llama, Mistral, Stable Diffusion) have licenses that may restrict commercial use or require attribution — licensing terms are evolving and vary by model version [src4] - AI patent landscape is extremely active with frequent claim conflicts — freedom-to-operate analysis is essential but costly ($50K-$200K) [src6] - Transfer learning and fine-tuning create derivative data rights questions that existing IP frameworks do not clearly address [src4] ## Framework Selection Decision Tree ``` START — Acquirer evaluating target with AI/ML capabilities ├── How central is AI to the target's value? │ ├── AI IS the product (core IP) │ │ └── Full AI due diligence required ← YOU ARE HERE │ ├── AI enhances an existing product (features) │ │ └── Moderate AI diligence + standard tech DD │ ├── AI used internally only (operations/analytics) │ │ └── Light AI assessment within standard tech DD │ └── AI capabilities claimed but minimal actual deployment │ └── Validate claims → likely marketing, not IP value ├── Does the target build its own models? │ ├── YES → Full model architecture + training data + IP review │ └── NO (API wrappers / fine-tuned third-party models) │ └── Focus on vendor dependency + differentiation sustainability ├── Does the target process personal data in AI models? │ ├── YES → GDPR/EU AI Act compliance review critical │ └── NO → Standard IP/licensing review sufficient └── Is AI talent the primary acquisition driver? ├── YES (acqui-hire) → Key person assessment, retention packages, non-compete enforceability └── NO → Standard HR diligence with AI talent overlay ``` ## Application Checklist ### Step 1: Map the AI stack (proprietary vs. third-party) - **Inputs needed**: Architecture diagrams, model inventory, third-party API contracts, open-source component list with licenses - **Output**: AI stack map showing what is proprietary, what is licensed, what is open-source, and what is third-party API-dependent - **Constraint**: If >50% of AI functionality relies on third-party APIs (OpenAI, Anthropic), the "AI moat" is a wrapper, not proprietary technology — adjust valuation accordingly [src2] ### Step 2: Assess training data provenance and rights - **Inputs needed**: Training data catalog, data sourcing agreements, web scraping logs, data licensing contracts, consent records for personal data - **Output**: Training data rights assessment — clean title, licensed, gray area, or high-risk categories - **Constraint**: This is the highest-risk diligence area. If the target cannot demonstrate clear rights to training data, potential liabilities include copyright infringement claims (NY Times v. OpenAI precedent), GDPR violations, and contractual breaches — any of which can be deal-breakers [src4] ### Step 3: Evaluate model performance and reliability - **Inputs needed**: 6-12 months of production performance metrics, A/B test results, model drift reports, failure mode documentation, SLAs - **Output**: Model reliability assessment, performance trend analysis, identification of failure modes and edge cases - **Constraint**: Request raw performance data, not management summaries. Model accuracy on held-out test sets often overstates real-world performance by 10-20% due to distribution shift between training and production data [src3] ### Step 4: Assess infrastructure and inference economics - **Inputs needed**: Cloud infrastructure costs (AWS/GCP/Azure), GPU allocation, inference latency metrics, MLOps pipeline documentation, scaling architecture - **Output**: Inference unit economics model (cost per prediction/generation), infrastructure scalability assessment, MLOps maturity rating - **Constraint**: Compute costs scale non-linearly with usage for many AI models — project 3-year inference costs under the acquirer's expected growth trajectory, not the target's current volume [src5] ### Step 5: Regulatory and IP compliance review - **Inputs needed**: AI risk classification under EU AI Act, patent portfolio, freedom-to-operate analysis, AI ethics policies, automated decision-making documentation - **Output**: Regulatory compliance gap analysis, IP ownership confirmation, freedom-to-operate opinion, EU AI Act risk classification - **Constraint**: EU AI Act compliance is not optional for companies operating in the EU — prohibited systems (social scoring, real-time biometric surveillance) carry fines up to EUR 35M or 7% of global turnover [src3] ## Anti-Patterns ### Wrong: Accepting AI capability claims at face value Many companies market themselves as "AI-powered" when their actual AI deployment is minimal — a rules-based system with a machine learning label, or a thin wrapper around a third-party API. Due diligence must verify the depth and propriety of AI capabilities. [src5] ### Correct: Demand technical access and independent evaluation Request access to model architecture, training code, and production metrics. Engage independent ML engineers to evaluate the AI stack. Ask: "If we removed all third-party API calls, what AI capability would remain?" The answer reveals actual proprietary value. [src1] ### Wrong: Ignoring training data rights because "everyone uses the same data" Some acquirers dismiss training data provenance concerns because "all AI companies face the same issues." This reasoning fails when a specific lawsuit targets the acquired company, or when an enterprise customer requires data provenance certification that the target cannot provide. [src4] ### Correct: Categorize training data into risk tiers Create a training data risk matrix: Tier 1 (clear rights — licensed datasets, proprietary data), Tier 2 (gray area — publicly available data, ambiguous ToS), Tier 3 (high risk — scraped copyrighted content, personal data without consent). Quantify exposure per tier and secure representations and warranties accordingly. [src4] ### Wrong: Valuing AI talent without retention analysis Acqui-hires often fail because key ML engineers leave within 12-18 months. Standard employment due diligence (compensation analysis, org charts) does not assess whether critical AI knowledge is documentable, transferable, or locked in individual engineers' heads. [src1] ### Correct: Conduct knowledge concentration and retention risk assessment Map which individuals have sole knowledge of model architecture, training pipelines, and deployment systems. Assess code documentation quality, bus factor (minimum team size for model maintenance), and design retention packages that vest over 2-4 years tied to model performance milestones. [src5] ## Common Misconceptions - **Misconception**: Traditional technology due diligence adequately covers AI assets. **Reality**: Traditional tech DD evaluates code quality, architecture, security, and infrastructure. AI DD adds training data provenance, model performance validation, inference economics, EU AI Act compliance, and MLOps maturity — none of which are covered in standard tech assessments. [src2] - **Misconception**: Using open-source AI models means no IP risk. **Reality**: Open-source AI model licenses vary widely. Llama (Meta) has commercial use restrictions above 700M monthly active users. Some models trained on copyrighted data may transfer that liability to commercial users. Each open-source component must be individually assessed for license compatibility with the acquirer's intended use. [src4] - **Misconception**: High model accuracy on benchmarks means the AI is production-ready. **Reality**: Benchmark accuracy often overstates real-world performance due to distribution mismatch, data leakage in evaluation sets, and lack of adversarial testing. Production reliability requires assessing performance on real customer data, edge case handling, failure mode documentation, and model monitoring capabilities. [src3] ## Comparison with Similar Concepts | Concept | Key Difference | When to Use | |---|---|---| | AI Due Diligence | Specialized assessment of AI/ML assets, training data, and inference economics | Target has material AI/ML capabilities | | Technology Due Diligence | Broader IT assessment — code, architecture, security, infrastructure | Every tech company acquisition | | Standard DD Framework | Full 8-workstream diligence | Every M&A transaction | | AI Vendor Assessment | Evaluating an AI supplier (not acquiring) | Procurement, not M&A | ## When This Matters Fetch this when a user asks about evaluating AI capabilities in an acquisition target, assessing training data rights during M&A, conducting technology due diligence for an AI company, or understanding EU AI Act implications for transactions. Also relevant when discussing acqui-hires, AI IP valuation, or model performance validation. ## Related Units - [M&A Due Diligence Framework](/business/ma/due-diligence-framework/2026) - [M&A Valuation Methods Compared](/business/ma/valuation-methods-compared/2026) - [100-Day Post-Merger Integration Plan](/business/ma/100-day-integration-plan/2026)