The integration of Artificial Intelligence (AI) and Large Language Models (LLMs) within business processes offers unprecedented opportunities for efficiency and innovation. However, when you decide to select an AI vendor and enter into a partnership, you enter a domain that is fundamentally different from traditional Software-as-a-Service (SaaS) contracts. Traditional software is deterministic: a specific action always leads to the same, predictable result. AI models, on the other hand, are probabilistic; they generate output based on probability calculations. This requires a completely new approach to contracts, Service Level Agreements (SLAs), and liability clauses.
This article serves as an in-depth guide for the B2B market. We discuss the critical elements that must be present in your contracts with AI vendors to protect your data, intellectual property, and business operations. Please note: technological developments are rapid, and vendor terms change constantly. It is crucial to set up your agreements robustly, especially when making the transition from pilot to production.
1. Ownership and Right to Use Data
Data is the oxygen for any AI system. In a business context, absolute control over your company data is the most important pillar of the contract. There are three information flows that must be legally covered: the input (prompts and documents), the output (the generated result), and any refinement data (fine-tuning datasets).
Who owns the input and output?
In a standard B2B AI contract, it must be unambiguously established that your organization retains full ownership rights (or at least the exclusive, unrestricted usage rights) over the data you input, as well as the output generated by the AI model based on it. Some vendors claim a license to use generated content in their standard terms (especially in free tiers or trial versions). For business applications, this is unacceptable. The output must become the intellectual property (IP) of the customer, to the extent permitted by law.
Is your data used for model training?
This is perhaps the most critical question. Consumer models typically use user input to train future versions of their foundation models. If you upload confidential financial reports or personal data to such a system, there is a theoretical risk that this information will later be reproduced by the model for another user.
A solid B2B contract contains a so-called Zero Data Retention clause, or at least an explicit exclusion of the use of your data (input, output, and telemetry data) for training, retraining, or improving the vendor's general models. Check whether this opt-out is enabled by default, or if you need to enforce it through an Enterprise agreement.
Subprocessors and data location
AI architectures are complex. Often you buy an application from Vendor A, which under the hood uses an API from Vendor B (e.g., OpenAI or Anthropic), hosted on the cloud infrastructure of Vendor C (e.g., Microsoft Azure or AWS). From the perspective of the General Data Protection Regulation (GDPR), these are all (sub)processors.
The contract and the associated Data Processing Agreement (DPA) must be transparent about the entire chain of subprocessors. Where is the data stored? Where is the data processed (in-memory during generation)? You want the guarantee that data processing remains within the European Economic Area (EEA) if you work with sensitive customer data. For more details on how to set this up securely, you can consider collaborating with specialized AI security companies for businesses.
2. SLAs for Non-Deterministic Systems
A Service Level Agreement (SLA) for a traditional SaaS product is relatively straightforward: the system must be online 99.9% of the time, and if you click a button, there must be a response within X milliseconds. With Generative AI, this concept is more complex.
Uptime, availability, and capacity
If an AI vendor promises 99.9% uptime, what exactly does that mean? Does it mean the web interface is accessible, or that the API can actually successfully generate tokens? We often see that during peak times (high server load), the API is technically accessible (and therefore does not count as 'downtime' in the classic sense), but requests are throttled.
Therefore, modern AI SLAs must include agreements on capacity. Think of guaranteed Tokens Per Minute (TPM) or Requests Per Minute (RPM). If you deploy an AI chatbot for customer service, and it refuses service during peak hours due to rate limits at the vendor, your business process suffers damage. You need guarantees on throughput, not just server accessibility.
Response times: TTFT and Latency
The speed at which an AI model responds depends on the size of the prompt and the complexity of the model. Important metrics to include in an SLA are:
- Time To First Token (TTFT): How long does it take before the AI model starts streaming the response? For real-time chat applications, this should be in milliseconds.
- Tokens Per Second (TPS): How fast is the rest of the response generated after the first token is produced?
Ensure that the SLA uses specific, measurable thresholds for these latency metrics, linked to financial compensation (service credits) in case of structural underperformance.
What an SLA does not cover: Output quality
This is a crucial realization: no AI vendor will guarantee the factual accuracy of the generated output in an SLA. Because LLMs predict text rather than look it up, they can produce inaccuracies. You can read more about what exactly AI hallucinations are and why they happen, but contractually this means that you as the customer bear the ultimate responsibility for the quality of the output. An SLA guarantees the technical availability of the "thinking power", not the correctness of the thought.
3. Model Changes and Deprecation (Versioning)
When you build a software product or integration on top of a specific language model (for example, through intricate prompt engineering), your system becomes tuned to the nuances of exactly that model. However, models are regularly updated by vendors to be safer or faster.
The impact of 'Silent Updates' and Model Drift
Sometimes AI companies perform unannounced updates to their models. This is also known as model drift or silent updating. A prompt that worked perfectly yesterday to generate complex JSON structures suddenly yields messy text today because the underlying behavior has changed. The contract must contain clear agreements on transparency: the vendor must be obliged to announce changes in fundamental model weights or system prompts in a timely manner.
Deprecation Policy
What happens if the vendor decides to completely phase out (deprecate) a model version (e.g., Model-X.0) and replace it with Model-X.1? This forces your development team to retest and potentially rewrite their own software. A strong Enterprise contract contains version control clauses, where the vendor guarantees that specific model versions (endpoints) remain accessible and supported for a minimum period (for example, 6 to 12 months after announcement), so you can plan and execute the transition.
4. Liability and Indemnification
The deployment of Generative AI brings specific legal risks, particularly around copyright and erroneous decision-making. It is essential to understand how risks are distributed between you and the vendor. This must be an integral part when you start drafting an AI policy.
Liability for hallucinations and incorrect output
As mentioned earlier in the section on SLAs, vendors disclaim all liability for the consequences of using the AI output. If the AI system generates incorrect financial advice or writes offensive text that you then send to a customer, the liability in principle lies with your organization. This highlights the absolute necessity of *Human-in-the-Loop* processes, where human validation is built into the workflow, especially for business-critical or customer-facing processes.
Copyright Indemnification
What happens if the AI generates text or a piece of code that turns out to be an exact, literal copy of a third party's protected work, and you are sued for copyright infringement? High-quality AI vendors offer a *Copyright Indemnification* clause in their Enterprise contracts. This means that the AI vendor covers the legal costs and any damage claims, provided the infringement was caused by the model itself and not by your intentional actions.
However, read the fine print carefully: this indemnification is almost always voided if you intentionally directed the system with specific prompts to generate infringing material, or if you attempted to bypass the safety filters built in by the vendor (jailbreaking).
5. Exit Strategy and Data Portability
A contract has a beginning, but inevitably also an end. The phenomenon of 'vendor lock-in' is particularly risky with AI. Suppose you have stored all your company knowledge in the vendor's RAG (Retrieval-Augmented Generation) systems, stored as vector embeddings specifically tuned to their model.
Guaranteeing data portability
The exit clause must define how and in what format you will receive your data back upon termination of the partnership. Demand that source data be exported in common, open formats (such as JSON, JSONL, or CSV). Note that vector embeddings generated by Model A are often not usable in Model B. Therefore, ensure that you retain access to the original (raw) text data, so that you can generate new embeddings yourself with the next vendor in the event of a migration.
Concrete Questionnaire for the Vendor Meeting
Use these questions as a checklist during the procurement process or contract negotiations with a potential AI vendor:
- Data Usage: Does the contract explicitly exclude our company data (input, output, feedback, and metadata) from being used to train your foundational models?
- Ownership: Will we become the undisputed owner of all intellectual property rights to the generated output, to the extent permitted by law?
- Location & Subprocessors: Where exactly is the data processed and stored, and which third parties or cloud providers (including LLM API providers) are involved? Is everything located in the EEA?
- SLA & Capacity: What are the guaranteed Tokens Per Minute or Rate Limits, and what specific compensations apply if these throughput rates are not met?
- Latency: Does the SLA contain definitions or target values for response times (e.g., Time to First Token)?
- Version Control: How many days or months in advance are model deprecations or significant model changes (updates) announced?
- Fallback: How long does the old version of an API/model remain available after the introduction of a new version?
- Indemnification: Do you offer an explicit 'IP Indemnification' clause that protects us against third-party claims regarding copyright infringement by generated content?
- Liability: How are the liability limits structured in the event of data breaches in the AI infrastructure?
- Exit: In what file format can we export our built-up knowledge base, prompts, and raw documentation if we terminate the contract?
A contract with an AI vendor is the foundation of a successful, long-term integration. By focusing sharply on data ownership, understanding the limitations of non-deterministic SLAs, and making clear agreements on liability and exit strategies, you create a secure environment in which your organization can reap the benefits of the latest LLM technology without running unnecessary business risks.