The AI diligence request will not ask whether you have "AI governance." It will ask for evidence. Who owns AI risk? Which systems are running? What testing backs the claims in your deck? What vendor rights do you have? What training data did you use? What happens if your primary model provider changes terms?
Most founding teams can answer pieces of those questions. Few can answer them as a package. That gap matters, because diligence is not a neutral information request. It is a leverage event.
A serious reviewer in 2026 is increasingly likely to ask at least some of these questions, especially of AI-native companies or companies making material AI claims. When the request arrives mid-deal and the evidence is scattered across vendor email threads, code comments, and a policy doc no one has touched since launch, your team spends two weeks pulling it together instead of running the business. The reviewer extends the timeline. The conversation restarts, with them knowing more about your gaps than you planned to show.
This article gives you a 7-section AI Diligence Package to build that file before anyone asks, score your current gaps, and walk into a deal conversation with your leverage intact.
The 7-Section AI Diligence Package
Each section maps to a reviewer lens, names the NIST AI RMF 1.0 (the National Institute of Standards and Technology AI Risk Management Framework, which structures AI governance around four functions: Govern, Map, Measure, and Manage) function it reflects, and lists the three evidence items a reviewer will actually look for. Score each item on the 0-5 scale below before any external review.
Score guide: 0 = does not exist; 1 = identified but not documented; 2 = partially documented, gaps present; 3 = documented but not recently updated; 4 = complete and current but not organized for external review; 5 = complete, current, and accessible to a reviewer without explanation.
Section 1: Governance Evidence
Reviewer lens: All three (investor, enterprise buyer, acquirer). NIST function: Govern.
| Evidence Item | Self-Score (0-5) |
|---|---|
| Named AI risk owner: a specific person, not a team, with a written role and reporting line | |
| Board or management review record: board minutes or agenda items showing AI risk discussions, with dates, on a documented quarterly cadence | |
| Incident and escalation register: documented AI failures, output errors, or customer escalations, with response timelines |
Can a reviewer walk your board calendar and find documented AI risk discussions? Is there a named person who owns it? If the answer to either question is no, Section 1 is incomplete, and that is the first thing a reviewer notices.
Put the quarterly AI risk report on the board calendar now. That plus a named owner gives you two artifacts, a week's work, that answer the most common governance question across every deal type.
Section 2: Systems Inventory and Mapping
Reviewer lens: All three. NIST function: Map.
| Evidence Item | Self-Score (0-5) |
|---|---|
| Full inventory of AI systems in use: products and internal operations, each named by use case, model or vendor, deployment date, and feature scope | |
| Per-system risk categorization: model risk, data quality risk, vendor dependency risk, and regulatory exposure | |
| Regulatory applicability mapping: which systems trigger EU AI Act Article 50 transparency obligations, and which are subject to applicable state and sector laws, mapped or on a roadmap |
The EU AI Act classifies obligations at the system level, not the company level. A content-generation feature may trigger Article 50; an internal scheduling tool probably does not. Your file has to answer this one system at a time. A company-wide compliance statement means nothing to a reviewer. A feature-level answer with implementation evidence does.
Section 3: Testing and Performance Evidence
Reviewer lens: Technical buyer and acquirer (high priority); investors (moderate priority, particularly for AI-native companies). NIST function: Measure.
| Evidence Item | Self-Score (0-5) |
|---|---|
| Testing protocol: bias testing, accuracy benchmarks, robustness testing, and for content-generation features, hallucination rate and factual accuracy testing | |
| Recent test results: performance metrics, edge cases, documented failure modes | |
| Monitoring evidence: dashboards or logs showing ongoing model drift detection and output quality tracking |
For an AI-native company claiming differentiated performance, no testing record is a real diligence flag. The ISO/IEC 42001:2023 AI Management System standard is an emerging credential here. It is not required by law, but it is starting to show up in enterprise procurement questionnaires from buyers who already hold ISO 27001 or SOC 2.
Section 4: Controls and Mitigations
Reviewer lens: All three. NIST function: Manage.
| Evidence Item | Self-Score (0-5) |
|---|---|
| Vendor contract documentation rights: if your product integrates a GPAI model (a general-purpose AI model, such as a large language model accessed via API from a third-party provider), your contract should give you practical access to the documentation your upstream provider is expected to make available under Article 53 and Annex XII (the EU AI Act provision listing the technical documentation a GPAI provider must maintain and share with downstream deployers) of the EU AI Act | |
| Incident response protocol: detection trigger, escalation path, and communication timeline for AI system failures | |
| Remediation records: documented fixes, policy updates, and completion dates from past AI incidents |
Many current MSAs do not address the documentation-access question cleanly. A reviewer who finds that your contract gives you no practical access to vendor technical documentation has found a gap in how you allocated vendor risk, and one worth closing before a deal clock starts.
Section 5: IP and Training-Data Provenance
Reviewer lens: Acquirer (highest priority); enterprise buyer (high for AI-native products); investor (moderate).
| Evidence Item | Self-Score (0-5) |
|---|---|
| Dataset provenance: source-by-source trace for significant training datasets, with executed licensing agreements and consent records for user-generated content | |
| IP registration disclosures: if you've registered copyrights covering AI-assisted works or hold patents where AI contributed to the invention, confirm disclosures are consistent with U.S. Copyright Office guidance (88 Fed. Reg. 16,190, March 16, 2023) and USPTO AI inventorship guidance (November 2025) | |
| Written IP litigation posture: a document describing your training-data copyright exposure, what you've licensed, and how you've addressed known contested areas |
U.S. courts have not settled whether training AI on copyrighted content is fair use. The question is live in several major cases, including Thomson Reuters v. Ross Intelligence (Third Circuit, on appeal), Andersen v. Stability AI (N.D. Cal.), and NYT v. OpenAI (S.D.N.Y.), where fair use arguments remain contested and unsettled. Getty Images' June 2026 content partnership with OpenAI is a directional signal that licensing infrastructure around AI content is developing.
The IP posture document in your file does not need to assert a clean bill of health. It needs to show you have mapped the exposure and made informed decisions. A reviewer who finds no summary assumes you have not thought about it.
Section 6: Regulatory Compliance
Reviewer lens: All three (mandatory for EU-facing products; important for U.S. companies given FTC and SEC enforcement postures).
| Evidence Item | Self-Score (0-5) |
|---|---|
| EU AI Act Article 50 implementation: per-feature audit showing which products trigger transparency obligations, with evidence of implementation (disclosure language, UI screenshots, implementation date) | |
| AI capability-claim substantiation file: a document naming each material AI claim in pitch decks, marketing, or investor materials, with the internal evidence behind it | |
| State AI law applicability map: a feature-level and jurisdiction-level screen of whether any AI system implicates state or local AI rules, covering employment, consequential-decision, biometric, consumer-disclosure, automated-decision, and sector-specific requirements. Flag obligations that apply now versus those pending but relevant, and name the owner of the implementation roadmap (representative regimes: Colorado's AI Act, California's ADMT rules, Texas's TRAIGA, NYC Local Law 144, Illinois AI employment rules) |
If your pitch deck says "AI-powered" or "AI-native," a diligence reviewer will ask what that claim is based on. The SEC enforcement actions against Delphia (USA) Inc. ($225,000 penalty, March 2024) and Global Predictions Inc. ($175,000, March 2024) both turned on unsubstantiated AI capability claims in investor materials. A single document naming each material claim and the evidence behind it is the kind of substantiation record a Section 5 inquiry looks for, and it answers the data-room question in one artifact.
The state map is the scope screen and roadmap a reviewer wants, not a fifty-state survey. It shows which of your features touch which regimes, what is in force versus pending, and who owns getting compliant. State and local AI rules now reach employment screening, consequential decisions, biometric data, and consumer disclosure, and the obligations differ by jurisdiction, so a credible map is built feature by feature and state by state rather than as a single company-wide statement.
Section 7: Vendor Dependency and Risk Allocation
Reviewer lens: Enterprise buyer and acquirer (highest priority); investors (moderate, particularly for AI-native companies with concentrated vendor exposure).
| Evidence Item | Self-Score (0-5) |
|---|---|
| Provider and model inventory: full list of GPAI providers and models in use, with percentage of product functionality dependent on each | |
| Concentration assessment: a written analysis if a significant share of your product functionality depends on a single GPAI provider, including what happens if pricing changes or the model is deprecated | |
| Exit, deprecation, deletion, and indemnity review: key contract terms documented per provider, with gaps identified |
If your primary provider doubles pricing or sunsets a model, does the company have a credible alternative written down? A contract with no defined data-deletion procedure on exit, no model deprecation provisions, or no clear indemnification scope for training-data claims is a gap a technical buyer's legal team will find.
How to Score Your Package
Run the 7-section framework with the 0-5 scale at least six months before a planned raise or sale. Any section below a 3 is a gap you would rather find now than during a live deal.
A few questions worth putting to your team before a deal process begins:
Can you name the person accountable for AI risk right now? Not a team. A named person with a written role and reporting line. If the answer is "it's kind of shared," your Section 1 is incomplete.
Have you made any AI capability claims that internal testing documentation does not back up? In pitch decks, customer materials, investor updates. If yes, that is a Section 6 gap and potential FTC or SEC exposure. Fixable now; much harder to fix during a live deal.
What happens to your core product if your primary GPAI vendor changes pricing or sunsets a model? If you do not have a documented answer, your Section 7 is a real risk flag for any technical buyer.
Staged completeness, scored honestly, is more credible to a reviewer than performative completeness. A package that describes controls clearly not in operation is a different kind of problem.
What Changed in 2026
Four developments explain why reviewers are asking these questions in the form they are asking them now.
NIST AI RMF 1.0 gave reviewers a vocabulary. The framework's four functions, Govern, Map, Measure, and Manage, produce concrete artifacts: accountability structures, systems inventories, testing records, controls documentation. The 7-section package above maps to those functions because that is what reviewers are trained to look for.
EU AI Act deadlines turn feature-level mapping into evidence. The GPAI provider obligations under Article 53 began applying on August 2, 2025. August 2, 2026 is when Article 50 transparency obligations, market-surveillance authority, and penalty and enforcement consequences for GPAI Chapter V violations come into full effect. The EU Digital Omnibus, provisionally agreed in May 2026 and pending formal adoption, defers certain high-risk Annex III system deadlines; it does not move the Article 50 transparency obligation or the August 2, 2026 GPAI enforcement window.
FTC and SEC enforcement make AI-claims substantiation mandatory. The FTC's Operation AI Comply, launched September 2024, targets companies making false or unsubstantiated AI capability claims. The SEC's actions against Delphia and Global Predictions, and against Presto Automation (January 2025) for describing human-dependent processes as AI-driven, established that the gap between an AI claim and the internal evidence behind it is an enforcement target.
Training-data litigation makes provenance a deal issue. Fair use for AI training remains contested across several major cases, and acquirers cannot model it as settled law. That uncertainty has moved training-data provenance from a legal footnote to a Section 5 diligence priority.
Which Sections Matter Most for Your Deal Type?
For Founders Pre-Raise (Series A through Series C)
The package is a fundraising asset, not just a governance artifact. An investor finding your gaps in week two of diligence is a worse outcome than you finding them six months earlier. Start with Sections 1 and 2; they are the most universally tested and the fastest to build. Section 6, specifically the AI capability-claim substantiation file, is the one most founders underestimate, because it means going back through old decks and investor updates.
For Founders Pre-Acquisition or Pre-Sale
In M&A, the data room is where representations and warranties are born. Every item you cannot score at a 4 or 5 is a potential basis for a post-closing indemnity claim, a price adjustment, or an escrow holdback. Section 5 is where acquirers in AI-native deals are spending the most time right now, and it is the section most founders have the least documentation for. Build it before you are in exclusivity.
For GCs and Boards
The board's job is to confirm that Section 1 reflects what is actually running, not what someone wrote in a policy document. Board minutes showing AI risk discussions, a named accountability structure, and a documented review cadence are what make the governance evidence credible to a reviewer. Without those records, the policy document is a liability rather than an asset.
Practical Takeaways
- Build the package at least six months before a planned raise or sale. Assembling it during a live deal costs time, reveals gaps under pressure, and hands the reviewer an advantage you should not give up. The preparation window is the leverage window.
- Map AI systems to regulatory obligations at the feature level, not the company level. One feature can trigger Article 50 transparency requirements; another in the same product may not. A feature-level audit of your Section 2 inventory is what makes Sections 2 and 6 useful to a reviewer rather than a box-checking exercise.
- Substantiate every material AI capability claim before a deal process opens. Build a single document naming each claim in your pitch decks, investor updates, and marketing, with the internal evidence behind it. The FTC substantiation test and the SEC's AI-washing enforcement both key off the gap between the claim and the file. A week to build it now; months to reconstruct it under diligence pressure.
- Document training-data provenance and write an IP posture statement. Fair use for AI training is unsettled, and acquirers know it. The posture statement does not need to assert clean title. It needs to show you have mapped your data sources, know what is licensed versus contested, and made informed decisions before anyone asked.
- Review GPAI vendor contracts for documentation access, deprecation provisions, data-deletion rights, and indemnity scope. Many current MSAs do not address these cleanly. If your contract does not give you practical access to the technical documentation your upstream GPAI provider is expected to maintain under Article 53 and Annex XII, that is a gap worth closing before the August 2, 2026 enforcement window, and before a technical buyer's legal team finds it.
Frequently Asked Questions
What goes in an AI due diligence package for a startup?
An AI diligence package typically covers seven areas: governance evidence (named AI risk owner, board review records, incident register), systems inventory and mapping, testing and performance records, controls and mitigations, IP and training-data provenance, regulatory compliance documentation, and vendor dependency analysis. Each section maps to a function of the NIST AI Risk Management Framework 1.0 and addresses what investors, enterprise buyers, and acquirers actually test in a review.
When should I build an AI diligence file before fundraising?
Building the package at least six months before a planned raise or sale gives you time to identify gaps and close them without a deal clock running. Assembling the file mid-deal costs time, reveals gaps under pressure, and shifts leverage to the reviewer. Any section scoring below a 3 on a 0-5 completeness scale is a gap worth addressing well before a process opens.
Do investors ask for AI documentation in diligence?
A serious investor in 2026 is increasingly likely to ask, especially for AI-native companies or companies making material AI claims. Questions typically focus on who owns AI risk, what systems are running, what testing backs the claims in the pitch deck, what vendor rights exist, and what training data was used. The NIST AI RMF 1.0 has given reviewers a shared vocabulary that makes these questions more structured and consistent than they were even two years ago.
What happens if investors find gaps in my AI documentation during due diligence?
When gaps surface mid-deal, the reviewer extends the timeline, the conversation restarts, and your team spends weeks assembling documents instead of running the business. In M&A specifically, items you cannot score at a 4 or 5 on a 0-5 scale can become the basis for a post-closing indemnity claim, a price adjustment, or an escrow holdback. Staged completeness scored honestly is more credible to a reviewer than documentation that describes controls not actually in operation.
Does the EU AI Act require my company to have an AI diligence package?
The EU AI Act does not require a package labeled "AI diligence." It does impose specific obligations that produce the underlying documentation: Article 50 transparency obligations for content-generation and other covered features, Article 53 documentation duties for GPAI model providers, and the broader technical documentation and risk management requirements for high-risk AI systems. A company that has met those obligations will have most of the materials that go into a strong diligence package. For companies selling into EU markets, August 2, 2026 is the date when Article 50 and GPAI Chapter V enforcement consequences come into full effect.
Closing Perspective
In my experience, the gap between what most founding teams have assembled and what a serious reviewer expects has grown materially in the last 18 months. The enforcement calendar is real. The training-data litigation is actively moving. And the reviewers asking these questions now share a common vocabulary, the NIST AI RMF, that makes the gaps easier to name and harder to paper over.
A founder who builds the evidence file now controls the terms of the conversation when a deal arrives. A founder who starts assembling it in response to a diligence request is already behind.
The goal is not perfect documentation. It is evidence that reflects what you actually have, organized clearly enough that a reviewer can find their way through it without your help. The diligence package is the proof that a governance process is running, and the founders who treat governance as a continuous operating process rather than a pre-deal sprint are the ones who set the terms, not the ones who accept them.
Two cases will tell us where this is headed: the Third Circuit's decision in Thomson Reuters v. Ross Intelligence and the Andersen v. Stability AI district-court proceedings. Both will shape how acquirers price training-data risk into deal structures. Founders who have already built their Section 5 documentation will be in a far stronger position to have those conversations on their own terms.
This article is for informational purposes only and does not constitute legal advice. Every company's situation is different, and you should consult with qualified legal counsel before making compliance decisions based on the developments discussed here.