# Due diligence on AI vendors: a practical guide [Skip to content](#lm-inhoud)Network/[NL](/en/ai-leveranciers-due-diligence)EN[Hubhub.llmnet.nlCompare models on task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organization, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence&text=Due%20diligence%20on%20AI%20vendors%3A%20a%20practical%20guide)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence&title=Due%20diligence%20on%20AI%20vendors%3A%20a%20practical%20guide)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence&text=Due%20diligence%20on%20AI%20vendors%3A%20a%20practical%20guide)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fai-leveranciers-due-diligence&title=Due%20diligence%20on%20AI%20vendors%3A%20a%20practical%20guide)[](#) # Due diligence on AI vendors: a practical guide By Ivo Donker — compiled with AI support (Claude & Gemini) · Last updated: 6 August 2026 When integrating artificial intelligence (AI) and large language models (LLMs) into business processes, the dependency on external vendors is considerable. Where traditional software vendors have relatively predictable risk profiles, AI vendors introduce new variables in the areas of data ownership, model obsolescence, intellectual property, and computational stability. Conducting a structured due diligence investigation is therefore essential before entering into a definitive partnership or contract. Definition: AI vendor due diligence is the in-depth, systematic investigation of the financial, legal, technical, and operational aspects of an AI provider. The goal is to identify risks before contractual obligations are entered into. ## Vendor selection versus due diligence It is important to make a clear distinction between the selection process and the due diligence process. When selecting a partner, the emphasis is on functional requirements, operational needs, and strategic fit with the organization. For this initial phase, the steps described in the guide for [choosing an AI vendor](https://consultancy.llmnet.nl/en/ai-leverancier-kiezen). Due diligence only begins once the preferred vendor (or a shortlist of candidates) has been identified, but before definitive contracts are signed. Where the selection phase answers the question, *"Can this vendor solve the problems?"*, due diligence answers the question, *"Does this vendor pose a structural risk to business operations, reputation, or compliance?"*. This investigation closely relates to the internal risk assessment that organizations must conduct themselves, as outlined in the dossier on the [AI risk analysis and DPIA](https://consultancy.llmnet.nl/en/ai-risicoanalyse-dpia). ## The four pillars of AI due diligence A complete due diligence investigation consists of four specific areas of research. Each area requires specific expertise from within the organization or from external advisors. ### 1. Financial investigation Many providers of innovative AI solutions are young companies or start-ups with a high 'burn rate' (the speed at which venture capital is consumed). The financial investigation must provide insight into the vendor's continuity in the medium term. Important checkpoints are: - Cash position and runway: Does the vendor have sufficient liquid assets to remain operational for the next 18 to 24 months without needing new investment rounds? - Revenue concentration: Is the vendor disproportionately dependent on one or two large customers for its revenue? The loss of such a customer can directly jeopardize the vendor's stability. - Pricing trends and infrastructure costs: AI models require significant computing power (GPU capacity). Investigate whether the vendor's margins are sustainable at scale, or whether price increases are to be expected in the short term. ### 2. Legal and compliance Legal due diligence focuses in particular on intellectual property, privacy legislation, and data provenance. This is one of the most complex areas due to the changing legislation surrounding AI systems. - Model licensing structures: Does the vendor use open-source models, proprietary models, or a hybrid form? It is crucial to understand the exact terms of the underlying systems. For an in-depth analysis of this, please refer to the article on [reading model cards and licenses](https://hub.llmnet.nl/en/modelkaarten-en-licenties-lezen). - Training data and copyright: Request written guarantees about the provenance of the data used to train the models. Is there any possible copyright infringement? Does the vendor offer full indemnification against third-party claims for intellectual property infringement? - GDPR roles: Determine who is the data controller and who is the data processor. How is data entered by users as prompts handled? Are these prompts used for further training of the vendor's models? The latter must always be excluded in business contexts. ### 3. Technical investigation The technical investigation examines the robustness of the software architecture, the integration options, and security. This goes beyond a standard software audit. - Architecture and dependencies: Is the system built modularly? What happens if an underlying API connection to a major LLM provider fails? - Information security: How is data at rest and data in transit encrypted? What mechanisms are in place to prevent prompt injection and other AI-specific vulnerabilities? See the article on [AI security for businesses](https://consultancy.llmnet.nl/en/ai-security-bedrijven). - Incident and uptime history: Ask for historical data on system outages and security incidents. ### 4. Operational investigation The operational pillar assesses the vendor's capacity to structurally support the delivered services as agreed. - Support and escalation paths: What support levels (SLAs) are guaranteed? Is 24/7 support available for business-critical processes? - Vendor lock-in and exit strategy: How easy is it to switch to another vendor? Can your own data, including metadata, prompts, and fine-tuned model weights, be easily exported? ## Technical verification in practice Verifying the technical claims of an AI vendor requires an active and critical attitude. Do not rely solely on marketing material or general presentations. A structured technical investigation uses the following steps: ### Evaluation of security certifications Certifications such as ISO 27001 and SOC 2 Type II are important indicators of a mature information security policy, but they are not a cure-all for AI-specific risks. ISO 27001 focuses on the information security management system in a broad sense. A SOC 2 Type II report provides more detail because it tests the effectiveness of controls over a longer period (usually at least six months). Specifically ask for the complete SOC 2 report, including the described controls, and not just the summary or the auditor's statement. Pay attention to whether the scope of the audit actually covers the AI service being procured, and not just the vendor's hosting environment. ### Penetration testing and vulnerability analyses Request recent penetration test reports (pen tests) conducted by an independent, certified third party. The test must not be older than twelve months. For AI applications, specifically check whether the pen test also covered API endpoints and AI-specific attack vectors, such as bypassing filters (jailbreaking) and unauthorized access to the underlying database (vector database). If the vendor refuses to share details, this may indicate an inadequate level of security. ### Data location and subprocessors Determine where the physical servers are located where the data is processed and stored. Strict rules for data transfers apply within the European Union (EU). If the vendor uses U.S. cloud infrastructure, check what additional safeguards have been put in place to comply with the GDPR (such as Standard Contractual Clauses). In addition, the list of subprocessors (third parties engaged by the vendor to deliver the service, such as API providers or hosting partners) must be carefully checked. Each subprocessor represents a potential risk in the chain. ## Contractual safeguards and exit scenarios The results of the due diligence form the basis for the final contract negotiations. A thoroughly conducted investigation enables the organization to include targeted clauses in the agreement. For detailed legal wording, we refer to the article on [AI contracts and SLAs](https://consultancy.llmnet.nl/en/ai-contracten-en-sla). ### Data portability and ownership The contract must explicitly stipulate that all entered data (prompts), historical interaction data, and customer-specific customizations (such as embeddings or fine-tuning datasets) remain the exclusive property of the customer. Upon termination of the agreement, the vendor must be obligated to deliver this data in a common, structured format (such as JSON or CSV). ### Model version management and deprecation policy AI vendors update their models regularly. This can cause the system's behavior to change or certain functionalities to disappear. Ensure contractual agreements in which the vendor is obligated to: - Offer new model versions in a test environment (sandbox) first before putting them into production. - Continue supporting older model versions for at least twelve months after the introduction of a new version (the so-called deprecation period). - Announce changes in model behavior or accuracy in advance, with accompanying impact reports. ### Continuity clauses in the event of acquisition or bankruptcy Consolidation in the AI market is high. The chance that a vendor will be acquired by a larger player or run into financial trouble is real. Therefore, include provisions that safeguard the continuity of the service. Consider a source code escrow (including model weights and training setups) or the right to terminate the contract immediately and free of charge in the event of an acquisition, while retaining all data. For concrete agreements regarding availability and performance, it is advisable to study the standards for service levels. More details on this can be found on the page about [SLAs and uptime with LLM providers](https://api.llmnet.nl/en/sla-en-uptime-llm-providers). ## Setting up the due diligence process A successful due diligence investigation follows a structured timeline and requires a clear division of roles within the organization. The process typically proceeds through the following phases: Phase | Activities | Responsible party | 1. Preparation | Drafting the NDA, determining the scope, setting up a secure data room. | Legal advisor / Project manager | 2. Request for information | Sending the questionnaire, requesting SOC 2 and ISO certificates, and pen tests. | Security officer (CISO) | 3. Evaluation | Analyzing the submitted documents, interviews with the vendor's technical staff. | Technical expert / Lead developer | 4. Reporting | Documenting risks, red flags, and advice for contracting. | Project manager / Risk analyst | ### Red flags During the due diligence investigation, certain signals can immediately give rise to concern or lead to halting the process. Watch out for the following 'red flags': - Refusal of transparency about training data: If the vendor refuses to explain in general terms how the model was trained and whether licensed data was used, the risk of copyright claims is unacceptably high. - Absence of version management: Vendors that push updates directly and unsolicited to the production environment without a test phase for the customer. - Unclear data storage locations: Being unable to specify at which server locations and by which subprocessors the data is processed. - Lack of liability: Contract proposals in which the vendor excludes all liability for the model's output and offers no indemnification whatsoever for IP infringement. ## Proportional due diligence for SMEs Conducting a full due diligence investigation as described above can be costly and time-consuming. For small and medium-sized enterprises (SMEs) with more limited budgets, it is important to scale the investigation proportionally. Not every process requires an external team of lawyers and auditors. For a lighter version, the following steps can be taken to mitigate the biggest risks: - Focus on data storage and GDPR: At a minimum, check whether the data is stored within the EU and whether the vendor agrees to a standard data processing agreement stating that the data will not be used for model training. - Ask for standard declarations: Ask the vendor for a written statement in which they guarantee that they hold the necessary rights to the training data and that they regularly have the software tested for vulnerabilities. - Use existing frameworks: Use freely available checklists and standards from organizations such as the National Cyber Security Centre (NCSC) to test baseline security. - Limit the scope: Conduct due diligence primarily on the components that directly affect the continuity of your own business operations. If the AI tool is merely supportive (such as editing internal texts), the investigation can be lighter than when the system directly handles customer contact. ## Further reading - [Choosing an AI vendor: The selection process](https://consultancy.llmnet.nl/en/ai-leverancier-kiezen) - [Drafting AI contracts and SLAs](https://consultancy.llmnet.nl/en/ai-contracten-en-sla) - [carrying out an AI risk analysis and DPIA](https://consultancy.llmnet.nl/en/ai-risicoanalyse-dpia) - [AI security for organizations](https://consultancy.llmnet.nl/en/ai-security-bedrijven) - [SLAs and uptime with LLM providers](https://api.llmnet.nl/en/sla-en-uptime-llm-providers) - [Reading and understanding model cards and licenses](https://hub.llmnet.nl/en/modelkaarten-en-licenties-lezen) llmnet.nl - B2B AI Consultancy