Dieser Artikel ist derzeit auf Englisch verfügbar.

Investment Advisory 10 min read 2026

AI Due Diligence: The Questions Investors, Buyers, and Regulators Are Asking in 2026

Whether you are buying an AI company, selling to enterprise customers, or preparing for regulatory examination, the AI due diligence questions are now standardised enough to prepare for. Here are the 40 questions that matter and what good answers look like.

Key Takeaways

AI due diligence has standardised significantly in 2025-2026 — whether from PE/VC investors, enterprise procurement teams, or regulators, the core questions are now consistent enough to prepare for systematically.
The four categories of AI due diligence questions: governance (do you have documented AI management?), data (what are your training data sources and how are they governed?), technical (how is your AI validated and monitored?), and legal/regulatory (what are your obligations and are you meeting them?).
The single most differentiating answer in AI due diligence is the data provenance response — organisations that can demonstrate clear, documented, legally sound training data provenance stand out sharply from the majority that cannot.
Enterprise procurement AI due diligence is particularly intense in regulated industries — a bank or insurer buying an AI product will ask all the questions their regulator will ask them about the AI, plus questions about the vendor's operational stability and long-term product roadmap.
Preparing for AI due diligence is not just a transactional exercise — organisations that have built genuine AI governance capabilities sail through due diligence because the answers are real, documented, and demonstrable, not assembled under time pressure.

"Nur zu Informationszwecken. Dieser Artikel stellt keine rechtliche, regulatorische, finanzielle oder professionelle Beratung dar. Konsultieren Sie einen qualifizierten Spezialisten für spezifische Beratung."

The AI due diligence questions enterprise procurement actually needs to ask

Most enterprise procurement processes are not yet equipped to assess AI vendor risk. Vendor security questionnaires designed for traditional software miss most AI-specific concerns. AI vendors have learned to answer marketing-level questions in ways that say nothing substantive about their actual practices. The result: enterprises sign AI contracts that create regulatory, security, and operational exposure their procurement teams cannot see.

This article provides the specific questions enterprise procurement should ask AI vendors, what good answers look like, and what red flags should trigger deeper investigation or vendor rejection.

Why generic vendor questionnaires don't work for AI

Standard third-party risk questionnaires were designed around traditional software risks: data security, business continuity, financial stability, regulatory compliance, sub-processor management. These remain relevant but insufficient for AI. AI introduces new categories of risk — model behaviour, training data, prompt injection, model drift, bias, hallucinations, IAM for non-human actors — that standard questionnaires do not capture.

An AI vendor can pass a SOC 2 Type II audit, hold ISO 27001 certification, and have appropriate insurance, yet still expose your organisation to material AI-specific risks. The audit and certification frameworks were not designed to assess these. ISO/IEC 42001:2023 is the first widely adopted certifiable standard specifically addressing AI management systems, and BS ISO/IEC 42006:2025 establishes auditor competency requirements — but adoption is still building.

The 30 questions that actually matter

Data handling (questions 1-7)

1. Will my data be used to train your models? The most consequential single question. For consumer-tier AI tools, the default is often yes. For enterprise-tier offerings from major vendors, the default should be no — with a contractually binding commitment to that effect. Verify in the Data Processing Agreement, not in the vendor's marketing pages.

2. How long is my data retained? Look for specific retention periods, not "as needed." For most AI processing, retention should be limited to the session or to a defined short period.

3. Where is my data processed and stored? Specific jurisdictions, not vague claims about global cloud infrastructure. For regulated industries or specific jurisdictions, this may determine whether the vendor can be used.

4. Who has access to my data? Vendor staff (which roles), sub-processors (with disclosure), government authorities (under what circumstances). Detailed answers; vague answers are red flags.

5. What sub-processors do you use for AI processing? Foundation model providers (OpenAI, Anthropic, Google) are often sub-processors for AI applications. Cloud providers (AWS, Azure, GCP) are typically sub-processors. List should be current and notification process for changes documented.

6. What is your data deletion process? Specific procedures, verification mechanisms, timeframes. "Data deleted on request" is not enough; how is deletion verified?

7. Do you have a Data Processing Agreement we can review? If a vendor cannot provide a DPA, that is itself a signal. The DPA captures contractually what marketing pages say.

Model behaviour and performance (questions 8-14)

8. Can you provide a model card or technical documentation? Substantive vendors document their models: training data sources, intended use, evaluated performance, known limitations, demographic representation, biases identified, mitigations applied.

9. What demographic groups were represented in your testing? Bias testing requires explicit demographic representation. "We tested for bias" without details is not adequate evidence.

10. What is your process for detecting and addressing model drift? AI models degrade over time as the underlying data distribution changes. Vendors need defined monitoring methodologies.

11. What is the model's known failure modes? Every model fails in characteristic ways. Vendors should be able to describe failure modes for the specific use case being procured.

12. What is your adversarial testing methodology? Prompt injection, jailbreak, data exfiltration testing for LLM-based applications. APRA's 30 April 2026 letter named adversarial testing as a regulatory expectation.

13. What is your accuracy benchmark for this use case? Defined, measurable, with realistic limitations. Vendor marketing accuracy ("99% accurate") is rarely the real-world benchmark.

14. How do you handle model updates and versioning? Material model updates can affect your operational outcomes. Notification, version control, rollback capabilities matter.

Regulatory compliance (questions 15-21)

15. Have you classified this system under the EU AI Act? Provider or deployer? Annex III high-risk or not? Technical documentation available? Conformity assessment status (where applicable)?

16. Are you ISO/IEC 42001 certified? If not, why not, and what alternative governance evidence do you have? Increasingly expected by enterprise procurement.

17. What is your SOC 2 Type II status? Type II (not Type I) — and recent. Type I is point-in-time; Type II covers a period of operation and provides more useful evidence.

18. How do you handle GDPR Article 22 / UK Articles 22A-D / Australian ADM transparency? For AI systems making significant decisions about individuals, the vendor must support your regulatory compliance.

19. For US use cases, how do you handle EEOC, CFPB, FTC compliance? Hiring AI must support disparate impact testing; credit AI must support adverse action notices; consumer AI must avoid unfair or deceptive practices.

20. For Australian financial services, can you confirm CPS 230 contract compliance? Material AI vendors are not in the limited NTSP exempt categories. Full CPS 230 contractual provisions apply.

21. For EU financial services, how do you support DORA compliance? ICT third-party risk requirements apply to AI vendors. Audit rights, sub-outsourcing rules, exit provisions.

Operations and resilience (questions 22-30)

22. What is your definition of a significant incident, and what is your contractual commitment for notifying us? Standard breach notification provisions need extension to AI-specific failures.

23. Have there been any significant incidents in the past 12 months involving this system? Honest answer is informative; "no incidents" should be tested.

24. What are your service availability SLAs? Specific uptime commitments, response times, escalation procedures.

25. What is your business continuity and disaster recovery plan? Plans that exist on paper versus plans that have been tested.

26. Who owns the model and its outputs? IP rights are not always obvious in AI relationships. The vendor's model, your prompts, the AI outputs — IP ownership and licensing should be explicit.

27. What does our data and model configuration look like at termination? Data return, deletion, transition period, alternative provider support.

28. What is the financial stability and ownership of your company? AI vendors face funding pressure; ownership changes can affect your service. Financial review for material vendors.

29. Can you provide references from comparable customers? Customers in your sector with similar use cases. Talk to them.

30. What is your indemnification and liability framework? Standard liability caps are often inadequate for AI-specific risks. IP infringement (training data litigation creates downstream exposure), regulatory fines, data breach scope.

How to score and weight responses

Not all 30 questions matter equally for every procurement. Risk-based weighting:

For material AI vendors (CPS 230, DORA, AI Act Annex III deployment), all 30 questions matter. Score against documented benchmarks. Verification of responses required — references, audit reports, contract terms.

For significant AI vendors (customer-facing, regulated process, material business activity), questions 1-7 (data), 15-21 (regulatory), 27 (exit) are critical. Questions 8-14 (model behaviour) matter where outputs are consequential.

For non-material AI vendors (peripheral tools, low-risk uses), questions 1-7 (data) and 15-17 (basic compliance) are the minimum. Use standard procurement processes with AI-specific provisions.

Red flags that should trigger deeper investigation

Specific patterns in vendor responses signal trouble: vague answers to specific questions (procurement should require substantive answers); inability to produce DPA, model card, security attestations on request; refusal to commit to no-training contractually; concentration of training data ownership in a small set of foundation model providers without provider-level transparency; recent or active litigation about training data (most foundation model providers face significant copyright litigation); high vendor concentration in your sector (creates concentration risk that may not be acceptable); ownership or funding changes that may signal financial stress.

What to do with the answers

Vendor responses become part of the procurement file. The questions, answers, scoring, and verification are evidence of due diligence — for internal governance, regulator review, and any future incident investigation. The discipline of structured AI vendor due diligence is itself a regulatory expectation increasingly built into governance frameworks.