# Vendor Contracts for AI: What to Check [Skip to content](#lm-inhoud)Network/[NL](/en/vendorcontracten-voor-ai-waar-je-op-toetst)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%2Fvendorcontracten-voor-ai-waar-je-op-toetst&text=Vendor%20Contracts%20for%20AI%3A%20What%20to%20Check)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fvendorcontracten-voor-ai-waar-je-op-toetst)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fvendorcontracten-voor-ai-waar-je-op-toetst&title=Vendor%20Contracts%20for%20AI%3A%20What%20to%20Check)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fvendorcontracten-voor-ai-waar-je-op-toetst&text=Vendor%20Contracts%20for%20AI%3A%20What%20to%20Check)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fvendorcontracten-voor-ai-waar-je-op-toetst)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fvendorcontracten-voor-ai-waar-je-op-toetst&title=Vendor%20Contracts%20for%20AI%3A%20What%20to%20Check)[](#) # Vendor Contracts for AI: What to Check By Ivo Donker — compiled with AI assistance (Claude & Gemini) · August 16, 2026 Procuring AI services, foundation model APIs, and ready-made software-as-a-service applications differs fundamentally from traditional software contracts. Where classic software is characterized by deterministic logic, fixed source code, and predictable uptime, generative and probabilistic models introduce unique operational and legal risks. A model can change behavior without warning, data can inadvertently be used for training, and output can infringe on third-party rights. When an organization deploys external AI technology, the vendor contract serves as the primary control instrument against data breaches, compliance violations, and unforeseen costs. Standard terms of service from major tech vendors are primarily designed to protect the vendor and place substantial risks on the customer. In this article, we walk through the critical contractual clauses that every procurement and legal review should focus on. ## 1. Data Rights, Reuse, and Model Training The most important provision in any AI contract concerns what the vendor may do with submitted prompts, contextual data (such as documents in a RAG pipeline), and generated output. Many consumer and entry-level plans contain provisions that allow the vendor to use interactions to train or fine-tune base models. For business use, this is unacceptable in nearly all cases due to confidentiality and privacy. During legal review, look for an explicit, unconditional commitment: "Vendor shall not use Customer Data, Prompts, or Outputs to train, retrain, fine-tune, or improve any public or proprietary machine learning models." Pay close attention to hidden exceptions. Some contracts exclude model training but retain the right to analyze data for quality improvement, abuse detection, or system maintenance. If human reviewers can spot-check prompts, a data leak risk for sensitive business information still exists. Read in the article on [drafting an AI policy for your organization](https://consultancy.llmnet.nl/en/ai-beleid-opstellen) how you translate these internal principles into binding procurement frameworks that align with your business objectives. ## 2. Intellectual Property in Prompts, Context, and Generated Output Copyright and ownership rights around AI systems are complex. A robust contract must provide complete clarity on three separate components: the input data (prompts and context), the underlying model with its weights, and the generated output. The customer must remain the owner of all input data and the intellectual property rights contained within it at all times. For generated output, the contract should establish that all rights, titles, and interests, to the extent legally permitted, are transferred directly and exclusively to the customer. If automatic transfer of ownership is not legally feasible, the vendor must grant a worldwide, perpetual, royalty-free, and exclusive license to exploit, adapt, and sublicense the output for any conceivable purpose. A contract must not contain any claims by the vendor on derivative works created by the customer using the AI assistant. It should also be checked whether the vendor imposes restrictions on using output to train its own internal models (so-called non-distillation or anti-benchmarking clauses), as such restrictions can block future developments. ## 3. Model Lifecycle, Deprecation, and Unforeseen Model Changes Classic APIs often contractually guarantee backward compatibility: a REST endpoint keeps functioning according to spec until a formal version deprecation takes place. With AI models, there are two risks: formal deprecation (discontinuing a model version) and silent drift (changed behavior due to unannounced fine-tuning or guardrails from the vendor). The contract should establish that specific model versions (so-called pinned model versions or snapshots) remain available for a guaranteed minimum period, for example at least twelve months. The vendor must be required to maintain a minimum notice period of at least six months before a model version is deprecated or changed. Aspect | Standard Vendor Term | Desired Requirement in Custom Contract | Model Changes | Vendor may continuously modify models without prior notice. | Models are pinned at the snapshot level; updates require active opt-in. | Notice Period | 30 days, or immediate deprecation in the event of security incidents. | At least 180 days of prior written notice before deprecation. | Quality Guarantee | No commitment whatsoever regarding accuracy, latency, or consistency. | Measurable benchmarks for latency and availability per model class. | Fallback Mechanism | Customer is solely responsible for downtime during model outages. | Automatic routing to equivalent backup endpoints at no additional cost. | ## 4. Service Level Agreements (SLAs) for Probabilistic Software Traditional SLAs measure only network availability (such as a 99.9% uptime guarantee). For AI models, this is insufficient. An API endpoint can return an HTTP 200 status code while the model performs severely slower due to capacity shortages (increased Time to First Token) or enforces rate limits that cause applications to stall. A complete AI SLA therefore tests performance indicators that go beyond pure uptime: - Latency and throughput: Maximum limits on Time to First Token (TTFT) and minimum tokens per second (TPS) under peak load. - Capacity reservation: Committed throughput capacity (for example, guaranteed Provisioned Throughput Units) that is not subject to dynamic rate limiting during peak hours. - Error rates: Threshold values for the percentage of server errors (HTTP 500/503) and timeouts, measured over rolling five-minute windows. For specific performance clauses and service agreements, also see the overview on [what to watch for in a contract with an AI vendor](https://consultancy.llmnet.nl/en/ai-contracten-en-sla). ## 5. Liability, Hallucinations, and IP Indemnification Almost every standard vendor agreement categorically excludes liability for the accuracy of generated output. Because models operate probabilistically, they can make factually incorrect statements (hallucinations) or produce code with vulnerabilities. The contract must explicitly manage the balance between operational risk and vendor responsibility. A critical point is the IP indemnification (intellectual property indemnification). If a base model incorporated copyrighted material during pre-training and the generated output infringes on third-party copyrights, the vendor must fully indemnify the customer against damage claims, legal costs, and settlements. Check for the following catches: - Does the indemnification apply only if the customer has continuously activated the vendor's specific filters and safety settings? - Is the indemnification limited by a general liability cap, such as the total subscription fees paid over the past twelve months? An effective IP indemnification requires so-called uncapped liability or a separately raised cap. - Does the vendor exclude intentional or recognizable imitation through targeted prompting? (This is a reasonable requirement from the vendor, provided it is clearly defined). ## 6. Data Storage, Retention, and the Data Processing Agreement (DPA) Under the General Data Protection Regulation (GDPR), the AI vendor qualifies as a processor in most B2B scenarios. The standard Data Processing Addendum (DPA) must closely match the technical reality of the processing. Check specifically for the retention policy for operational logging. Many model providers apply a default retention period of 30 days for all prompts and responses for the purpose of abuse detection (abuse monitoring). For organizations working with medical data, financial transactions, or strictly confidential trade secrets, such a retention period is undesirable. The contract should establish that logging is deleted immediately after completion of the API request (zero data retention or ZDR), or that data is processed exclusively locally in RAM without persistent disk storage. For a deeper analysis of retention periods and audit rights, see the guide on [assessing retention policies at AI vendors](https://consultancy.llmnet.nl/en/data-retentie-en-ai-leveranciers). ## 7. Subprocessors, Data Sovereignty, and EU AI Act Transparency Large AI platforms often rely on a chain of subcontractors: specialized cloud hosting parties, external data annotators, and external content moderation APIs. The contract must provide full transparency about this chain. The customer must have the contractual right to be informed of changes to subprocessors, with an explicit right of objection or free termination. In addition, the geographic location of both data storage and data processing must be contractually pinned within the European Economic Area (EEA) if data sovereignty is required. Note: some vendors store data in the EU but dynamically route inference requests to data centers in the United States during peak times. Under the European AI Act, specific transparency obligations apply to providers of General Purpose AI (GPAI) models. Ensure that the contract requires the vendor to provide timely documentation, risk assessments, and technical specifications needed for the customer's own compliance files. ## 8. Autonomous Agents and Extended System Access When AI systems evolve from passive chatbots into task-driven agents that independently execute API calls, query databases, or run code, the contractual risks change dramatically. Errors in model output then lead not only to a wrong answer on screen, but to direct mutations in operational systems. Contracts for agent-based platforms must include clear provisions on authority limits, authorization matrices, and liability for unintended actions (such as overwriting records or sending unauthorized communications). The vendor must demonstrate that the platform has built-in mechanisms for human-in-the-loop verification for high-risk actions. Read in the analysis on [the rise of agentic AI](https://nieuws.llmnet.nl/en/agentic-ai) which new systemic risks and liability questions arise when models independently perform actions in connected business environments. The internal organization must also be prepared for these contractual frameworks. Discover in the dossier on [AI adoption in teams](https://consultancy.llmnet.nl/en/ai-adoptie-teams) how contractual usage restrictions affect the daily workplace and how employees need to be trained to operate within the agreed guidelines. ## 9. Exit Clauses, Data Extraction, and Vendor Lock-In A contract is only complete when the end of the collaboration has been carefully arranged. AI solutions create substantial dependencies: accumulated fine-tuning weights, evaluation datasets, vector embeddings, and prompt templates represent significant business value. The contract should contain clear agreements on the exit phase: - Data extraction in open standards: All historical logs, embeddings, feedback data, and fine-tuning datasets must be made available free of charge within thirty days of termination in a widely supported format (such as JSONL or Parquet). - Destruction of data: Written confirmation that all customer data, including backups and any fine-tuning checkpoints, is permanently deleted from all servers and storage media of the vendor and its subprocessors within an agreed period. - Transition period: The option to continue the service at existing rates for a transition period of at least three to six months to enable an orderly migration to an alternative provider. ## 10. Practical Scoring Matrix for Contract Review To systematically assess vendor contracts before signing, the scoring matrix below can serve as a guide during the procurement process. Assessment Domain | Red (Reject / Renegotiate) | Yellow (Mitigate via Addendum) | Green (Ready to Sign) | Data Use for Training | Data may be used for public model improvement; no opt-out available. | No training on business data, but human review for abuse control remains active. | Complete ban on training and human review; contractually guaranteed zero data retention. | Copyright & IP Indemnification | No indemnification for third-party rights infringement; customer bears all risk. | Indemnification present, but capped at paid subscription amount (liability cap). | Full, uncapped IP indemnification, including reimbursement of legal costs and settlements. | Model Stability | Vendor may change or remove models at any time without notice. | Notice of changes at least 30 days in advance, no guaranteed snapshot pinning. | Fixed snapshots available with a minimum guaranteed lifespan of 12 months and 180 days of deprecation notice. | SLA & Availability | Only generic network uptime without latency or capacity guarantees. | 99.9% uptime guarantee with financial service credits for outages, no latency limits. | Defined TTFT and token/s guarantees per model class, including reserved capacity. | Geographic Storage & Processing | Data is processed globally without visibility into specific data centers or subprocessors. | Data storage within the EU, but inference requests may be routed outside the EEA. | Strict guarantee that both storage and active model inference take place exclusively within the EEA. | ## Conclusion A well-considered AI vendor contract prevents technological innovation from leading to unmanageable legal and operational risks. By setting strict requirements upfront for data use, intellectual property, model stability, and exit scenarios, the organization retains control over its data and business processes. Use the criteria and scoring matrix above as a standard part of the vendor selection and procurement process.