Ai-Procurement |

Your Vendor's "We Don't Train On Your Data" Promise Is a Sentence, Not A Data Architecture

Tue, 21 Jul 2026 00:00:00 +0000

Why the real exposure in generative, predictive, and agentic AI contracts lives in fine-tuning, logs, and retrieval, not in the one line everyone quotes back to legal

Every procurement team has now heard the sentence. A vendor says it, a sales deck repeats it, and somebody on the buying side writes it into the approval memo as if it closes the risk. It doesn’t. ”We don’t train on your data” answers one question out of at least seven, and it is usually the easiest one for a vendor to answer honestly while still leaving you exposed everywhere else.

I’ve sat through enough of these reviews to notice the pattern. Legal asks the training question, gets a clean answer, and moves on. Nobody asks what happens to the prompt after the model responds. Nobody asks whether the fine-tuned version of the model your team spent six months shaping now belongs to you, the vendor, or nobody in particular. That gap is where the actual risk sits, and it applies whether you’re buying a chatbot, a predictive underwriting model, or an autonomous agent that files its own tickets.

This isn’t a US problem or a government-procurement problem. Every organization signing a contract for a large language model, a predictive risk engine, or an agentic system, anywhere in the world, is buying into the same layered technical reality. The contract language just hasn’t caught up to it yet.

The Stack You Are Actually Buying

Nobody buys “an AI model”. They buy a stack: infrastructure, a foundation model, a fine-tuned or customized variant sitting on top of it, a retrieval layer pulling in your documents, configuration logic wrapped around all of it, and whatever governance tooling the vendor bolted on to make the whole thing auditable.

Each layer behaves differently under a contract. Infrastructure is usually the vendor’s own cloud tenancy or a hyperscaler’s. The foundation model is licensed, not owned, by almost everyone including the vendor selling it to you. The fine-tuned variant might be built specifically on your data, which raises an entirely separate ownership question. The retrieval layer touches your live documents at query time. Configuration is the thin, portable layer of prompts and rules sitting on top of everything else.

If your technical team hasn’t mapped which components are vendor-owned, which are shared across the vendor’s other customers, and which are dedicated to you, you can’t actually answer the questions that matter: where does data flow, what persists after the session ends, and what survives if you terminate the contract next year. Skipping that mapping step is how a well-intentioned procurement process ends up with a signed contract that protects nothing.

”Training” sounds like a single moment, something that happened once, in the past, before the vendor ever met you. It isn’t. Pre-training builds the base model on a huge, general dataset. Fine-tuning adapts that base model to a narrower domain, sometimes using your organization’s own data. Continuous improvement keeps adjusting the system after deployment, often using signals from how customers actually use it.

A vendor can tell you, accurately, that it does not use your data for pre-training, while quietly using it for fine-tuning or for reinforcement learning drawn from user interactions. Those are with different risk profiles, and a single blanket sentence in a sales deck rarely distinguishes between them.

This is why the specific verbs in your contract matter more than the general promise. If your data-use restriction only says ”train,” a vendor operating in good faith but reading narrowly can argue that fine-tuning, retraining, or adapting the model falls outside that one word. The fix is boring but effective: define the restriction to cover every verb in the lifecycle, explicitly. ”Train, fine-tune, retrain, adapt, or otherwise improve” closes the gap that a single word leaves open.

If the contract only prohibits ”training”,, you have not restricted anything except the one process the vendor was least likely to run on your data in the first place.

Fine-Tuning Creates Embedded Learning You Cannot Delete

Here’s the part that surprises people who come from a traditional IT background, where deleting a file usually means the data is gone. If your organization’s data was used to fine-tune a model, that data shaped the model’s internal weights. Erasing the original files afterward does nothing to reverse what the model already absorbed.

Think of it less like deleting a document and more like unteaching a person a skill they already learned. You can take away their notes, but the knowledge is still there. A deletion clause that only promises to remove ”stored files” is answering a much smaller question than the one you actually care about, which is whether the model itself still carries a trace of your organization’s patterns, terminology, or decision logic.

This forces a set of contract questions that most procurement checklists still skip: who owns the fine-tuned model once it exists, can the vendor reuse that tuned version for other customers, and does the tuned instance sit in a dedicated environment or a shared one where your patterns could bleed into someone else’s results. None of these are answered by a generic data-deletion promise, no matter how strongly it’s worded.

Retrieval-Augmented Generation Is Not Training, But It Still Needs A Contract Clause

A lot of confusion in this space comes from conflating retrieval with training. When a model pulls your documents from a vector database at the moment someone asks a question, that’s retrieval-augmented generation, commonly shortened to RAG. It’s dynamic reference lookup during inference, not a process that changes the model’s weights. Nothing about RAG teaches the model anything permanent.

That distinction matters, but it doesn’t mean RAG is risk-free. Your documents still have to live somewhere to be retrievable, and that ”somewhere” raises the same questions any data-storage arrangement raises: where is it hosted, who can access it, how long is it retained, and is the retrieval index shared across the vendor’s other tenants or isolated to you.

A frequently missed detail is what happens to embeddings, the numerical representations of your documents, after the contract ends. Deleting the original documents doesn’t automatically delete the embeddings derived from them, and a vendor’s data-processing agreement should say explicitly whether those vector representations are purged on termination or left sitting in the vendor’s infrastructure indefinitely.

Configuration Does Not Change Who Owns The Model

System prompts, controls, and behavior policies are the layer most teams spend the most hands-on time building, and it’s also the layer with the least legal weight. Configuring a model changes how it behaves for you. It does not change who owns the underlying weights or the model’s learned state.

The practical question worth asking here is portability, not ownership. Are your system prompts and guardrail configurations something you can export and take with you if you switch vendors, or are they stored in a proprietary format that locks you in without ever touching the core ownership question. Configuration data is usually retrievable. Model learning typically is not. Treat those as two separate exit-strategy problems, because they are.

Even a vendor that genuinely does not train on your data can still be sitting on a commercially valuable asset: the logs of everything you asked it and everything it answered. Prompts, outputs, usage patterns, and system telemetry all get stored somewhere by default unless the contract says otherwise.

This is where a useful three-way distinction from recent federal AI procurement debates translates well outside government contracting. There’s telemetry, which is basic operational data any vendor legitimately needs to keep a service running, such as response times and error rates. There’s what some call ”data dust,” the behavioral fingerprint left by how you actually use the system, which patterns you accept, which you reject, and what that reveals about your priorities and workflows. And there’s feedback, the corrections and ratings your users provide, which can improve the vendor’s product for everyone even when it never touches ”training” in the narrow sense.

Telemetry is fine to leave with the vendor. Data dust and feedback are where a systematic accumulation of insight into your organization’s operations can quietly become a competitive advantage for the vendor, entirely separate from anything resembling model training. Most contracts don’t distinguish between these three categories at all, which means most contracts are silent on the risk that actually matters most.

Segregable Versus Non-Segregable Components

It helps to sort everything in an AI contract into two buckets. Segregable and returnable components include the documents you fed into retrieval, your configuration prompts, your policy overlays, and any logs you specifically required the vendor to retain. These can, in principle, be exported, audited, and handed back to you.

Embedded and difficult-to-unwind components include the model weights after fine-tuning, whatever performance optimizations the vendor’s system learned from watching you use it, and any statistical adjustments baked into a customized model instance. These cannot be handed back in any meaningful sense, because they don’t exist as a discrete, transferable object. They exist as a shift in the model’s internal parameters.

Your procurement strategy needs to treat these two buckets completely differently. Ask for return and deletion rights on the first bucket. Ask for use restrictions, audit rights, and dedicated-instance guarantees on the second, because ownership language alone can’t reach something that was never a separable asset to begin with.

A Compliance Architecture Example: The Contract Review Vendor

Picture a mid-sized law firm buying an AI contract-review tool. The vendor fine-tunes a base model on a sample of the firm’s past contracts to improve accuracy on the firm’s specific clause language and drafting conventions. Six months in, the firm wants to switch vendors.

The firm’s data-processing agreement says the vendor will ”delete customer data upon termination.” That clause gets satisfied the moment the vendor wipes the original contract files from its storage. It says nothing about the fine-tuned model that now performs better specifically because it learned the firm’s drafting patterns, and it says nothing about whether the vendor can keep using that improved model for its next law-firm client.

A properly scoped contract would have specified, before signing, that the fine-tuned model instance is dedicated to the firm, that the vendor cannot reuse learned patterns from the firm’s contracts for any other customer, and that on termination the vendor must either delete the tuned model entirely or transfer it, not just delete the source documents. That’s the difference between a deletion clause that sounds protective and one that actually is.

The Literacy Gap Is The Real Vulnerability

Vendors understand their own model lifecycle in detail: where improvement loops run, which components are multi-tenant, and how data gets leveraged indirectly even when the direct answer to ”do you train on it” is no. Most buyers only ever see the runtime output, the chat window or the API response, and have no visibility into anything upstream of that.

That asymmetry is the actual negotiation risk, more than any single clause. A procurement or legal team that can’t distinguish fine-tuning from retrieval, or embedded learning from stored logs, can’t scope data rights precisely, can’t evaluate reuse risk, and can’t draft restrictions that actually hold up against how the system works. Frameworks like ISO 42001 for AI management systems, or the NIST AI Risk Management Framework’s actor categories for AI development, deployment, and operation, exist specifically to give non-specialist teams a shared vocabulary for this. Using that vocabulary in your own contract, rather than the vendor’s marketing language, is a meaningful first defense.

A Practical Contract Checklist

Before signing any generative, predictive, or t, confirm the following in writing, in the contract or the data-processing agreement itself, not in a sales deck or public FAQ:

Which categories of data are covered by any no-training promise: prompts, outputs, uploaded files, logs, and metadata should all be named explicitly, not implied.
Whether the promise applies to the specific product tier and region you’re buying, since consumer, business, and enterprise plans often carry different terms from the same vendor.
Retention periods for each data category, stated as a specific timeframe, not as ”as long as necessary.”
Who can access your data in plaintext, including the vendor’s own support staff and any subprocessors, and under what conditions.
Whether deletion on termination extends to fine-tuned model weights and retrieval embeddings, not only to the original source files.
Who owns any custom-built or fine-tuned model, and whether the vendor can reuse learned patterns from your data for other customers.
Whether audit rights, SOC 2 reports, or ISO 42001 certification are available for independent verification, rather than relying on the vendor’s own attestation.

Red Flags In The Wording

Watch for a few specific phrasings that sound protective but leave room to maneuver. ”We may use your data to improve our services” without a defined carve-out for confidential material is one. ”Anonymized” or ”de-identified” data use without a precise, contractual definition of what those terms mean is another, since de-identification standards vary enormously in practice.

Also watch for a training restriction that only covers a narrowly defined ”Customer Data” term while leaving prompts, outputs, or metadata sitting outside that definition entirely. And watch for any daylight between the vendor’s marketing page and the actual signed agreement. If the two disagree, the signed agreement wins in a dispute, and a marketing promise that was never in the contract protects nobody.

The Questions That Force An Honest Answer

Asking ”do you train on our data” invites a narrow, technically true, practically useless answer. These questions force the vendor to describe the actual data flow instead of reciting a slogan:

What exact data is excluded from any training, fine-tuning, or model-improvement process, named category by category?
What is the retention period for prompts, outputs, files, logs, and metadata, stated separately for each?
Who can access this data, including support personnel and subprocessors, and under what access controls?
Is this promise written into the signed contract or DPA, or does it only appear on a public webpage?
Does the promise apply to this exact plan, tenant, and region we are purchasing?
If we terminate, does deletion cover fine-tuned model weights and retrieval embeddings, or only the original source files?

A vendor that can answer all six specifically, in writing, has probably built real data governance into its product. A vendor that can only repeat the training slogan hasn’t, regardless of how confidently it says the sentence.

Where This Leaves You

Treat the no-training promise as necessary and clearly not sufficient. For anything involving client data, regulated information, or proprietary workflows, that means an enterprise-tier agreement with a real data-processing agreement attached, contract language that names every verb in the model lifecycle, and explicit terms covering fine-tuning ownership, embedding deletion, and log retention. None of that requires distrust of the vendor. It requires precision, because the underlying technology doesn’t leave room for vague promises to hold up later.

If you’re building or reviewing AI vendor contracts and want a second set of eyes on the language, or want the fuller checklist adapted to your specific stack, that’s exactly the kind of work worth doing before signature, not after. Subscribe below to get the next piece in this series, which walks through how to actually negotiate the fine-tuning ownership clause line by line.

By Prof. Hernan Huwyler, CAIO MBA CPA

About the Author

The frameworks, tools, and implementation guidance described in this article are part of the applied research and advisory work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.

Prof. Huwyler serves as AI GRC Consultancy Director, AI Risk Manager, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and internationally.

Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance, technical and business requirements.

His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at . His ongoing writing on Governance, Risk Management and Compliance appears on his blogger website at (more than 500k views).

Connect with Prof. Huwyler on LinkedIn at to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.

If you’re building an AI governance program, standing up an AI risk function, preparing for EU AI Act compliance, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.

AI Contract Clauses That Reduce Vendor, Data, and Liability Risk

Thu, 12 Mar 2026 00:00:00 +0000

How to Buy AI Systems Without Buying Hidden Risk

Most AI procurement failures start with a simple mistake.

The buyer focuses on the demo. The vendor focuses on the pitch. Procurement focuses on commercials. Legal focuses on contract language. Security focuses on controls. Compliance focuses on obligations. Nobody pulls those pieces together into one disciplined buying process tied to the business problem the AI system is supposed to solve. That is how organizations end up with tools that look strong in workshops and weak in real operations.

A strong AI procurement process needs more than a vendor comparison sheet. It needs clear business goals, industry-fit assessment, security and compliance scrutiny, bias and explainability review, robust contract terms, and a practical operating model for updates, support, drift, and exit. This post shows you how to build that process using a structured AI procurement control checklist that lawyers, procurement teams, compliance staff, and business owners can actually use.

Understanding the Core Framework for AI Procurement

AI procurement is the process of selecting and contracting for an AI system in a way that protects business value, legal compliance, operational fit, and long-term control.

The framework I use has four layers. Business fit, supplier assurance, contractual protection, and post-award governance. If one of these is weak, the deal usually creates more friction than value.

1. Business fit

This layer asks whether the vendor actually understands the business problem and whether the AI system fits the use case the organization is trying to solve.

A vendor may have a capable product and still be a poor fit if they do not understand the industry, data constraints, workflow realities, or user needs. AI procurement should begin with the business goal, not the tool category.

Implementation tip: Ask vendors to restate your use case in their own words and explain how their product addresses it. This quickly reveals whether they understand the problem or are pitching a generic story.

2. Supplier assurance

This layer checks whether the supplier is capable, credible, secure, and compliant. It includes track record, certifications, model governance maturity, security controls, privacy handling, explainability support, and bias management.

This is where many AI procurement processes stay too shallow. A vendor may have references and still fail on transparency, security integration, or update discipline.

Implementation tip: Evaluate the supplier’s operating maturity, not just the product feature list. Products are easier to improve than weak vendor practices.

3. Contractual protection

This layer turns procurement promises into obligations. It covers model rights, support commitments, audit rights, performance reviews, non-compliance remedies, drift management, exit rights, and pricing terms.

Without strong contract structure, even a good vendor relationship becomes fragile when something changes or goes wrong.

Implementation tip: Translate each key procurement concern into a contract clause, a reporting obligation, or an operational review point. Otherwise the concern will fade after signature.

4. Post-award governance

This layer makes sure the procurement decision stays valid after implementation. It includes reviews, updates, concept drift handling, support quality, retraining behavior, and adjustment to changing business needs.

A lot of procurement teams stop once the contract is signed. For AI systems, that is too early.

Implementation tip: Treat supplier performance review as part of procurement, not a later operations issue. AI services evolve too quickly to separate them fully.

Why AI Procurement Often Breaks Down

The most common issue is buying capability without buying accountability.

The vendor explains impressive functionality, but the buyer does not secure enough detail on data use, decision transparency, support, performance drift, or contract exit. The product may work. The governance does not.

Another issue is weak problem framing. Organizations sometimes ask vendors for “an AI solution” without a clear business objective, success metric, workflow boundary, or deployment context. That makes vendor selection noisy and contract requirements vague.

There is also a third-party risk gap. Some vendors rely heavily on subcontractors, external models, or layered cloud services, but the customer only reviews the top-level brand. That creates hidden dependency and resilience risk.

Implementation tip: Build the procurement review around the real operating model of the service, including subcontractors, third-party models, and underlying infrastructure where material.

Stage 1: Define the Business Goals Before You Issue Requirements

A good AI procurement process starts with internal clarity.

The responsible parties are the business sponsor, product owner, procurement, legal, AI governance, and relevant operational leads. Security, privacy, and compliance should be consulted early where the use case is sensitive or regulated.

The critical artifacts are the business objective statement, use case summary, success metrics, scope statement, and evaluation criteria. These should be ready before vendor conversations get too far.

What to implement: Define your business goals clearly and align them with the AI capabilities you want to procure. Describe the problem to be solved, the users involved, the workflow context, the expected outcomes, and the constraints that matter most. This helps you compare vendors on relevance instead of presentation style.

This stage should also identify what kind of AI capability is actually needed. Classification, summarization, predictive analytics, retrieval, ranking, automation support, recommendation, or generative output all create different procurement questions.

Without this clarity, the buying process becomes vulnerable to feature overload. Vendors will naturally emphasize breadth. You need to know what depth matters.

Implementation tip: Separate mandatory requirements from desirable features before the vendor evaluation begins. This keeps flashy extras from distorting the decision.

Stage 2: Assess the Vendor’s Industry Fit and Delivery Credibility

Not all strong AI vendors are strong for your context.

The responsible parties are procurement, the business owner, product, vendor management, and AI governance. Domain experts should review the vendor’s understanding of the business problem and workflow.

The critical artifacts are the vendor questionnaire, references, case studies, solution fit assessment, and implementation track record review.

What to implement: Assess the provider’s understanding of your industry and ask how the AI solution addresses your specific needs. Verify the provider’s track record with similar implementations. Request case studies, references, and practical examples of deployment in environments like yours.

This is also the point to challenge vague claims. Ask what data conditions the solution assumes, what user behavior patterns it expects, what level of configuration is required, and what measurable outcomes the vendor has achieved elsewhere. Generic claims such as “improves efficiency” or “works across industries” should not carry much weight without evidence.

A provider with a good technical product can still be a poor partner if they do not understand the operational reality of your environment.

Implementation tip: Use scenario-based vendor questioning. Ask how their system would handle one or two realistic edge cases from your workflow. That reveals depth quickly.

Stage 3: Review Security, Privacy, and Regulatory Readiness in Detail

This is where many AI buying decisions become serious.

The responsible parties are security, privacy, compliance, legal, procurement, and vendor risk teams. The product owner and business sponsor should stay involved because these decisions affect usability and deployment scope.

The critical artifacts are the security questionnaire, privacy review, regulatory compliance assessment, data flow diagram, incident response summary, and certification evidence.

What to implement: Evaluate the provider’s ability to comply with relevant regulations, including data protection and privacy laws. Ensure the provider has robust security protocols such as encryption, access controls, environment segregation, logging, and incident response plans. Request evidence of these controls, not only policy statements.

Third-party certifications can help here. Require certifications such as ISO 27001 where relevant, but do not treat them as a substitute for review. Certifications are useful signals. They are not proof that the specific AI service fits your risk profile.

Also examine data location, retention, model training rights, logging practices, subprocessors, and customer separation controls. If the service involves sensitive, regulated, or proprietary data, these details matter a lot.

Implementation tip: Ask one simple question in the security review. “What customer data can the provider access, keep, reuse, or expose during normal operation, troubleshooting, and model improvement?” The answer usually reveals the real risk posture.

Stage 4: Test Explainability, Bias Handling, and Responsible AI Maturity

AI procurement needs to assess how the provider manages the parts of AI that are hardest to evaluate from a product sheet alone.

The responsible parties are AI governance, compliance, legal, business owners, domain experts, and technical reviewers. Procurement should coordinate but not own the substance of this review.

The critical artifacts are the explainability statement, fairness and bias testing summary, model documentation, validation reports, and responsible AI controls overview.

What to implement: Require the provider to explain the system’s decision-making process and the level of transparency available to users, operators, and reviewers. This does not always mean full model interpretability, but it does mean the supplier should explain what the system is doing, what its major limitations are, and how users are expected to understand and govern its outputs.

Also assess the provider’s approach to bias. Ask how bias is tested, how representative data issues are handled, what mitigation methods are used, and how fairness concerns are surfaced after deployment. If the vendor cannot answer clearly, that is a real warning sign.

Responsible AI maturity also includes documentation, governance ownership, issue handling, and update discipline. A vendor that has no structured approach here will be harder to manage later.

Implementation tip: Require examples of real documentation such as model cards, system cards, risk summaries, or governance notes. A verbal explanation alone is usually too polished and too thin.

Stage 5: Use Contract Terms to Protect the Organization Over Time

This is where procurement becomes durable.

The responsible parties are legal, procurement, vendor management, privacy, security, AI governance, and the business sponsor. Product and operations should review terms that affect support, updates, and operational flexibility.

The critical artifacts are the main agreement, AI-specific addendum, data processing terms, security schedule, SLA, audit clauses, exit terms, and pricing schedule.

What to implement: Include clauses that require the provider to comply with relevant laws and undergo regular compliance audits where appropriate. Specify support, training, and update obligations so the system remains effective as your business evolves. Establish clear ownership terms for data and AI models, especially for provider insolvency, contract termination, or material service failure.

Outcome-based pricing can be valuable where the use case supports it, because it aligns incentives with business success. Still, it should be used carefully. AI outcomes can depend on both supplier and customer behavior, so the pricing model needs realistic attribution rules.

The contract should also include provisions for regular performance reviews, the ability to adjust terms for changing business needs, and clear escalation and remediation procedures for performance issues or non-compliance. This includes concept drift and data drift management where the AI system depends on changing input conditions.

Implementation tip: Build a short AI contract rider that covers data rights, model rights, support, update notice, audit rights, drift management, exit assistance, and non-compliance escalation. Standard SaaS clauses are usually not enough on their own.

Stage 6: Plan for Drift, Support, and Post-Signature Performance Management

Signing the contract is not the end of AI procurement. It is the start of supplier governance.

The responsible parties are vendor management, product owners, business operations, procurement, AI governance, and support teams. Security and compliance should stay in the loop where incidents or control reviews are possible.

The critical artifacts are the performance review calendar, support governance plan, drift management process, issue log, and contract adjustment workflow.

What to implement: Require the provider to have a plan for managing concept drift and adapting the AI system to new data and changing conditions. Define how support works, what updates are included, how performance is reviewed, and how the contract can be adjusted when the business changes.

This is especially important for AI because service quality can shift gradually. A strong procurement process should make room for regular performance reviews, service tuning, retraining support where appropriate, and contract updates if the use case expands or the risk profile changes.

Also make sure escalation and remediation procedures are clear. If performance degrades, if explainability is weaker than expected, or if compliance concerns appear, everyone should know what happens next.

Implementation tip: Schedule the first formal vendor performance review before the system goes live. Early review habits shape later accountability.

Set of Recommended AI Procurement Clauses

Note for the readers: These clauses are intentionally buyer-favorable. They should be adapted to:

the role of the supplier under the EU AI Act (provider, deployer, importer, distributor, product manufacturer, authorised representative);
whether the AI is prohibited, high-risk, limited-risk/transparency, GPAI/foundation model, or not regulated as such;
whether personal data is processed and whether a DPA/data processing agreement is required;
sector-specific laws (financial services, health, employment, public sector, critical infrastructure, etc.);
local law on liability, indemnities, and enforceability.

1. Definitions and Interpretation

1.1 Definitions

Clause Title: Definitions

Sample wording:

“AI System” means any machine-based system, model, service, feature, component, or functionality that infers from inputs how to generate outputs such as predictions, content, recommendations, decisions, scores, classifications, or other outputs capable of influencing physical or virtual environments.

“AI Laws” means all applicable laws, regulations, codes, standards, and regulatory guidance relating to artificial intelligence, automated decision-making, data use, privacy, cybersecurity, discrimination, product safety, consumer protection, and sector-specific compliance, including, where applicable, the EU AI Act and all implementing, delegated, or related measures.

“High-Risk AI System” means any AI system classified as high-risk under applicable AI Laws.

“Customer Data” means all data, content, prompts, inputs, instructions, records, personal data, confidential information, and other materials provided, submitted, transmitted, generated, or made available by or on behalf of Customer in connection with the Services.

“Output” means all content, results, predictions, recommendations, scores, decisions, classifications, analytics, reports, embeddings, code, text, images, audio, video, or other materials generated or returned by the AI System in response to Customer Data or Customer’s use of the Services.

“Personal Data” has the meaning given in applicable data protection law.

“Services” means the AI systems, models, APIs, software, support, professional services, updates, and related deliverables supplied under the Agreement.

“Subprocessor” means any third party engaged by Supplier to process Customer Data or otherwise provide material components of the Services, including model providers, infrastructure providers, annotation providers, and safety evaluators.

“Security Incident” means any actual or reasonably suspected unauthorized access to, acquisition of, disclosure of, loss of, destruction of, alteration of, or inability to access Customer Data, or any material compromise of the security, confidentiality, integrity, or availability of the Services.”

2. Scope of Supply and Order of Precedence

2.1 Scope of Services

Clause Title: Scope of AI Services

Sample wording:

“Supplier shall provide the Services, including all AI and non-AI components, strictly in accordance with the Agreement, the Specifications, the Service Levels, the Documentation, applicable AI Laws, and Customer’s written instructions. Supplier shall not materially change the architecture, core functionality, model family, hosting location, security posture, or risk profile of the Services without Customer’s prior written consent.”

2.2 Order of Precedence

Clause Title: Order of Precedence

Sample wording:

“In the event of conflict, the following order of precedence shall apply: (a) signed Order Form or Commercial Terms; (b) these core terms; (c) the Data Processing Agreement; (d) Security Schedule; (e) Service Level Agreement; (f) Statement of Work; (g) Supplier policies and click-through terms. No click-wrap, browse-wrap, online terms, or unilateral policy shall reduce Supplier’s obligations or Customer’s rights unless expressly agreed in writing by Customer.”

3. Regulatory Status, AI Classification, and Compliance

3.1 AI Act Status and Role Allocation

Clause Title: AI Regulatory Status and Role Allocation

Sample wording:

“Supplier represents and warrants that it has correctly assessed and documented the regulatory status of the AI System and its own role and Customer’s role under applicable AI Laws, including whether the AI System constitutes a prohibited AI practice, a high-risk AI system, a limited-risk AI system subject to transparency obligations, or a general-purpose AI model or system. Supplier shall provide Customer, before contract signature and on an ongoing basis, with accurate written information sufficient for Customer to understand and discharge its compliance obligations as a deployer or other regulated actor.”

3.2 Compliance with AI Laws

Clause Title: Compliance with AI Laws

Sample wording:

“Supplier shall, at all times during the Term, design, develop, train, test, validate, deploy, maintain, support, and provide the Services in full compliance with all applicable AI Laws. Supplier shall promptly implement any changes required by changes in law, regulatory guidance, harmonized standards, common specifications, or competent authority requirements, at no additional cost to Customer unless such change is demonstrably and exclusively caused by a Customer-specific non-standard use case.”

3.3 Prohibited AI Practices

Clause Title: No Prohibited AI Practices

Sample wording:

“Supplier represents and warrants that the Services do not include, enable, or require any prohibited AI practice under applicable AI Laws. Supplier shall not cause or permit Customer to use the Services in a manner that would constitute a prohibited AI practice and shall implement technical and contractual controls reasonably necessary to prevent such use.”

4. Documentation, Transparency, and Information Rights

4.1 Pre-Contractual Disclosure

Clause Title: AI Transparency and Disclosure

Sample wording:

“Before the Effective Date, and thereafter upon request, Supplier shall provide complete, accurate, and up-to-date documentation describing: (a) the intended purpose, limitations, and foreseeable misuse of the AI System; (b) model type, version, release history, and material changes; (c) training, validation, and testing methodologies; (d) known performance characteristics, confidence limitations, and failure modes; (e) human oversight requirements; (f) data sources categories and data governance controls; (g) safety, security, robustness, and bias mitigation measures; (h) applicable use restrictions; and (i) all information reasonably required for Customer’s legal, technical, procurement, governance, and risk assessments.”

4.2 Ongoing Transparency

Clause Title: Ongoing Notification of AI Changes

Sample wording:

“Supplier shall give Customer at least

\[30\]

days’ prior written notice of any material change to the Services, including any change to model version, model provider, fine-tuning approach, retrieval architecture, safety filters, hosting location, subprocessors, performance characteristics, interfaces, or security controls that could affect compliance, accuracy, explainability, interoperability, risk, cost, or Customer’s intended use. Customer may reject any such change that materially increases risk or reduces functionality.”

5. Performance, Accuracy, and Fitness for Purpose

5.1 Conformity to Specifications

Clause Title: AI Performance and Conformity Warranty

Sample wording:

“Supplier warrants that the Services shall perform materially in accordance with the Specifications, Documentation, agreed evaluation criteria, and service descriptions, and shall be fit for the purposes expressly disclosed by Customer and accepted by Supplier. Supplier shall not market or describe the Services in a misleading manner, including as to autonomy, accuracy, explainability, safety, compliance, or suitability for regulated use cases.”

5.2 Accuracy, Reliability, and Hallucination Controls

Clause Title: Reliability and Output Quality Controls

Sample wording:

“Supplier shall implement and maintain appropriate measures to reduce inaccurate, fabricated, misleading, biased, unsafe, or non-compliant Outputs, including testing, monitoring, guardrails, confidence signalling where appropriate, grounding controls, abuse detection, and escalation procedures. Supplier acknowledges that Output quality is a material contractual requirement where the Services are used in business-critical, regulated, or customer-facing workflows.”

5.3 Benchmarking and Acceptance Testing

Clause Title: Acceptance Testing and Performance Validation

Sample wording:

“Customer may conduct acceptance testing, pilot evaluations, red-team exercises, bias assessments, and technical validation against agreed criteria before production use and following any material change. If the Services fail to meet agreed acceptance criteria, Customer may reject the affected Services, require remediation at Supplier’s cost, suspend deployment, or terminate the relevant Order without penalty.”

6. Human Oversight and Use Restrictions

6.1 Human Oversight

Clause Title: Human Oversight and Review

Sample wording:

“Supplier shall design the Services to enable effective human oversight appropriate to the intended use and risk level, including the ability for authorized personnel to review, challenge, override, reverse, or disregard Outputs before or after reliance where reasonably required. Supplier shall provide clear instructions regarding when human review is mandatory and when Outputs must not be used without additional verification.”

6.2 Use Restrictions and Safe Deployment Conditions

Clause Title: Permitted Use and Deployment Conditions

Sample wording:

“Supplier shall identify in writing all prohibited, restricted, and high-risk uses of the Services and all deployment conditions necessary for lawful and safe operation. Supplier shall not impose use restrictions that prevent Customer from carrying out legally required testing, monitoring, security review, audit, incident investigation, or compliance verification.”

7. Data Governance and Data Rights

7.1 Customer Ownership of Data and Outputs

Clause Title: Customer Ownership of Data and Outputs

Sample wording:

“As between the parties, Customer retains all right, title, and interest in and to Customer Data. To the maximum extent permitted by law, Customer shall own all Outputs generated specifically for Customer through Customer’s use of the Services. If any Output or related right does not vest automatically in Customer, Supplier hereby assigns, and shall procure the assignment of, all such right, title, and interest to Customer upon creation. Supplier retains ownership only in the pre-existing Supplier Materials and underlying models, excluding Customer Data and Customer-specific Outputs.”

7.2 Limited License to Process Customer Data

Clause Title: Limited License for Service Delivery Only

Sample wording:

“Customer grants Supplier a non-exclusive, non-transferable, revocable, limited license to process Customer Data solely to provide, support, secure, and maintain the Services for Customer in accordance with the Agreement. No other rights are granted by implication, estoppel, or otherwise.”

7.3 No Training on Customer Data

Clause Title: Prohibition on Training and Model Improvement Using Customer Data

Sample wording:

“Supplier shall not, and shall ensure that its affiliates, subprocessors, and underlying model providers do not, use Customer Data or Outputs to train, retrain, fine-tune, evaluate, validate, calibrate, augment, improve, or otherwise modify any general model, foundation model, or other AI system, nor for benchmarking, product development, or benefit of any third party, except where Customer has given specific prior written consent in a signed amendment expressly describing the permitted use, data scope, retention period, security controls, and opt-out rights.”

7.4 Data Segregation

Clause Title: Segregation and Tenant Isolation

Sample wording:

“Supplier shall logically and, where appropriate, physically segregate Customer Data from data of other customers and from Supplier’s own development, testing, and training environments. Supplier shall maintain effective tenant isolation and shall not commingle Customer Data in a manner that creates unauthorized access, leakage, memorization, or inference risk.”

7.5 Data Quality and Governance

Clause Title: Data Governance Controls

Sample wording:

“Supplier shall maintain appropriate data governance measures in relation to data used to develop, train, validate, test, and operate the AI components of the Services, including documented controls relating to data provenance, relevance, representativeness, error detection, labeling quality, bias identification and mitigation, lawful sourcing, minimization, and retention.”

8. Privacy and Data Protection

8.1 Data Protection Compliance

Clause Title: Privacy Compliance

Sample wording:

“Supplier shall comply with all applicable data protection laws in connection with the Services. To the extent Supplier processes Personal Data on behalf of Customer, the parties shall enter into a compliant Data Processing Agreement, and Supplier shall process Personal Data only on Customer’s documented instructions.”

8.2 International Transfers

Clause Title: Data Location and International Transfers

Sample wording:

“Supplier shall not transfer, access, host, or process Customer Data outside the approved jurisdictions specified by Customer without Customer’s prior written consent. Any international transfer of Personal Data shall be supported by a valid transfer mechanism and supplementary measures where required by law.”

8.3 Data Subject and Regulatory Assistance

Clause Title: Assistance with Privacy and AI Rights Requests

Sample wording:

“Supplier shall promptly provide reasonable assistance, at no additional charge for standard assistance, to enable Customer to respond to data subject requests, regulatory inquiries, audits, impact assessments, and legal obligations relating to automated decision-making, profiling, explainability, contestability, and human review.”

9. Security, Robustness, and Resilience

9.1 Security Measures

Clause Title: Information Security and AI Security Controls

Sample wording:

“Supplier shall implement and maintain appropriate technical and organizational measures to protect the Services and Customer Data against unauthorized access, disclosure, alteration, loss, destruction, poisoning, prompt injection, model extraction, data exfiltration, privilege abuse, adversarial manipulation, and other AI-specific and information security risks. Such measures shall include encryption, access controls, logging, patching, vulnerability management, environment segregation, secrets management, secure development practices, and incident response capabilities.”

9.2 Security Standards and Testing

Clause Title: Security Standards and Independent Assurance

Sample wording:

“Supplier shall maintain an information security program aligned with recognized industry standards and, upon request, provide current independent assurance reports, certifications, penetration test summaries, vulnerability remediation status, and AI security testing results reasonably sufficient to demonstrate compliance with the Agreement.”

9.3 Business Continuity and Resilience

Clause Title: Business Continuity and Operational Resilience

Sample wording:

“Supplier shall maintain and test business continuity, disaster recovery, backup, and service resilience plans appropriate to the criticality of the Services. Supplier shall ensure continuity arrangements for any critical third-party model, cloud, or infrastructure dependency and shall notify Customer without undue delay of any material risk to service continuity.”

10. Bias, Fairness, Explainability, and Risk Management

10.1 Bias and Discrimination Controls

Clause Title: Bias Monitoring and Non-Discrimination

Sample wording:

“Supplier shall implement reasonable and proportionate measures to identify, test for, monitor, prevent, and mitigate unlawful bias and discriminatory effects in the Services and Outputs, including periodic assessments appropriate to the intended use and affected populations. Supplier shall promptly notify Customer of any material bias, fairness, or discrimination issue and provide a remediation plan.”

10.2 Explainability and Traceability

Clause Title: Explainability, Traceability, and Audit Logs

Sample wording:

“Supplier shall provide functionality and documentation sufficient to enable Customer to understand the basis, limits, and context of Outputs to a degree appropriate for the intended use. Supplier shall maintain traceability records, model/version logs, decision logs where applicable, and event records sufficient to support auditability, incident investigation, legal defense, and regulatory compliance.”

10.3 Risk Management System

Clause Title: AI Risk Management System

Sample wording:

“Supplier shall establish, document, implement, maintain, and update a risk management system for the AI components of the Services, including procedures for identifying, analyzing, evaluating, mitigating, and monitoring reasonably foreseeable risks to health, safety, fundamental rights, non-discrimination, privacy, security, and business continuity throughout the lifecycle of the Services.”

11. High-Risk AI-Specific Obligations

11.1 High-Risk AI Compliance Support

Clause Title: High-Risk AI System Obligations

Sample wording:

“If any part of the Services is or becomes a High-Risk AI System, Supplier shall ensure full compliance with all applicable high-risk requirements and shall provide Customer with all documentation, instructions for use, technical information, logs, conformity materials, post-market monitoring information, and assistance reasonably necessary for Customer to lawfully deploy and use the High-Risk AI System.”

11.2 Conformity Assessment and CE/Registration Support

Clause Title: Conformity and Registration

Sample wording:

“Where required by applicable AI Laws, Supplier shall complete and maintain any required conformity assessment, technical documentation, declarations of conformity, CE marking, registration, and related obligations before making the relevant AI System available to Customer. Supplier shall provide evidence of the same upon request.”

11.3 Post-Market Monitoring

Clause Title: Post-Market Monitoring and Corrective Action

Sample wording:

“Supplier shall maintain a post-market monitoring process proportionate to the nature of the AI System and shall promptly investigate, document, and remediate any serious incident, malfunction, degradation, non-conformity, or reasonably foreseeable misuse. Supplier shall notify Customer without undue delay and provide all information necessary for Customer’s own reporting and mitigation obligations.”

12. Third-Party Components, Open Source, and Supply Chain

12.1 Third-Party and Subprocessor Controls

Clause Title: Supplier Responsibility for Third Parties

Sample wording:

“Supplier remains fully responsible for all acts and omissions of its affiliates, subprocessors, subcontractors, underlying model providers, data providers, and infrastructure providers as if they were Supplier’s own. Supplier shall not engage or replace any material subprocessor or underlying model provider without prior written notice to Customer and, where the change is material, Customer’s prior written consent.”

12.2 Open Source and Third-Party Licensing

Clause Title: Third-Party Materials and Open Source Compliance

Sample wording:

“Supplier warrants that all third-party software, models, data, and other materials incorporated into or used to provide the Services are properly licensed and that Customer’s authorized use of the Services will not require Customer to disclose source code, license proprietary materials on unfavorable terms, or accept additional restrictions not expressly set out in the Agreement.”

13. Intellectual Property and Infringement Protection

13.1 Supplier IP Ownership

Clause Title: Supplier Retained IP

Sample wording:

“Supplier retains ownership of its pre-existing technology, models, software, methods, and Documentation, excluding Customer Data, Customer-specific configurations paid for by Customer where agreed, and Customer-owned Outputs.”

13.2 IP Infringement Indemnity

Clause Title: Intellectual Property Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer, its affiliates, and their respective personnel from and against any claim, action, damage, loss, liability, settlement, cost, or expense, including reasonable legal fees, arising from any allegation that the Services, Outputs as supplied by the Services, or Customer’s authorized use thereof infringe, misappropriate, or otherwise violate any intellectual property or proprietary right of any third party.”

13.3 Infringement Remedies

Clause Title: IP Claim Remedies

Sample wording:

“If the Services or any Output are, or are likely to be, subject to an infringement claim, Supplier shall, at its own expense and without limiting Customer’s rights: (a) procure for Customer the right to continue using the affected item; or (b) replace or modify it so that it becomes non-infringing while maintaining materially equivalent functionality, compliance, and performance. If neither option is commercially reasonable in Customer’s judgment, Customer may terminate the affected Services immediately and receive a pro rata refund of prepaid fees and reimbursement of reasonable replacement costs.”

14. Confidentiality

14.1 Confidentiality

Clause Title: Confidentiality of Customer Information

Sample wording:

“Supplier shall keep Customer Data, Outputs, Customer business information, security information, evaluation results, and all non-public information relating to Customer strictly confidential and shall not use or disclose such information except as necessary to perform the Agreement. Supplier shall apply at least the same degree of care it uses to protect its own most sensitive information, and in no event less than reasonable care.”

14.2 Confidentiality of Prompts and Outputs

Clause Title: Prompts and Outputs as Confidential Information

Sample wording:

“For the avoidance of doubt, all prompts, system instructions, retrieval context, Customer workflows, model settings selected by Customer, and all Outputs generated for Customer shall be deemed Customer Confidential Information.”

15. Audit, Inspection, and Assessment Rights

15.1 Audit Rights

Clause Title: Audit and Compliance Verification

Sample wording:

“Customer, its internal or external auditors, regulators, and professional advisers may, on reasonable notice, audit Supplier’s compliance with the Agreement, including AI governance, security, privacy, subprocessors, service levels, and regulatory obligations. Supplier shall provide access to relevant records, personnel, systems information, policies, logs, test results, and facilities, subject to reasonable security controls.”

15.2 Assessments and Questionnaires

Clause Title: Ongoing Risk and Compliance Assessments

Sample wording:

“Supplier shall complete Customer’s reasonable due diligence questionnaires and periodic reassessments relating to AI compliance, privacy, security, resilience, ethics, and procurement risk management, and shall promptly notify Customer of any material change affecting prior responses.”

16. Service Levels, Support, Maintenance, and Change Control

16.1 Service Levels

Clause Title: Service Levels and Availability

Sample wording:

“Supplier shall meet the service levels set out in the SLA, including uptime, latency, response time, support response, incident resolution, model availability, throughput, and recovery targets. Chronic failure to meet service levels shall constitute material breach.”

16.2 Support and Expertise

Clause Title: Support and AI Competence

Sample wording:

“Supplier shall provide adequately trained support personnel with appropriate technical, legal, and compliance knowledge relating to the Services and applicable AI Laws. Supplier shall provide timely assistance for incidents involving inaccurate, unsafe, biased, or non-compliant Outputs.”

16.3 Change Control

Clause Title: Change Management

Sample wording:

“No material change to the Services, including retraining, fine-tuning, tuning of thresholds, safety systems, prompt templates, retrieval sources, or model replacement, shall be implemented without documented change control, impact assessment, rollback capability, and prior notice to Customer. Customer may require re-testing or re-approval following material changes.”

17. Warranties and Representations

17.1 Core Warranties

Clause Title: Supplier Warranties

Sample wording:

“Supplier represents, warrants, and undertakes that throughout the Term:
(a) it has full right, power, and authority to enter into and perform the Agreement;
(b) the Services will comply with the Agreement, Documentation, Specifications, and applicable laws;
(c) the Services will be provided using personnel with appropriate skill, care, diligence, and expertise;
(d) the Services will not contain malicious code, hidden functionality, unlawful surveillance capability, or unauthorized access mechanisms;
(e) Supplier will not knowingly provide false, incomplete, or misleading compliance, performance, or risk information; and
(f) Supplier will maintain the policies, procedures, and records reasonably required to demonstrate compliance with this Agreement and applicable AI Laws.”

17.2 No Degradation of Protection

Clause Title: No Reduction in Safeguards

Sample wording:

“Supplier shall not materially reduce the security, privacy, compliance, auditability, explainability, interoperability, or data protection features of the Services during the Term without Customer’s prior written consent.”

18. Incident Management and Regulatory Cooperation

18.1 Incident Notification

Clause Title: Security, Safety, and AI Incident Notification

Sample wording:

“Supplier shall notify Customer without undue delay, and in any event within

\[24\]

hours, after becoming aware of any Security Incident or any material AI incident, including serious malfunction, material degradation, unauthorized model behavior, unsafe Output pattern, bias event, legal non-compliance, or suspected breach of applicable AI Laws affecting the Services or Customer’s use thereof.”

18.2 Cooperation and Remediation

Clause Title: Incident Cooperation and Corrective Action

Sample wording:

“Supplier shall immediately take all necessary containment, correction, and mitigation measures, keep Customer regularly informed, preserve relevant evidence and logs, perform root cause analysis, and implement corrective actions at Supplier’s expense. Supplier shall not notify regulators, affected individuals, or third parties regarding Customer-specific incidents without Customer’s prior written approval unless prohibited by law.”

18.3 Regulatory Cooperation

Clause Title: Cooperation with Regulators and Authorities

Sample wording:

“Supplier shall provide all reasonable assistance, records, and technical information necessary for Customer to respond to requests, inspections, investigations, audits, or enforcement actions by competent authorities relating to the Services.”

19. Indemnities

19.1 Compliance Indemnity

Clause Title: AI and Regulatory Compliance Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer and its affiliates from and against all losses, liabilities, fines, penalties, costs, and expenses arising out of or in connection with Supplier’s breach of applicable AI Laws, data protection laws, cybersecurity obligations, or sector-specific legal requirements, except to the extent directly caused by Customer’s use of the Services in material breach of Supplier’s written instructions.”

19.2 Data and Security Indemnity

Clause Title: Data Breach and Security Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer from and against all losses, damages, claims, costs, and expenses arising from any Security Incident or confidentiality breach caused by Supplier or its subprocessors.”

19.3 Output Harm Indemnity

Clause Title: Indemnity for Harm Caused by Defective or Non-Compliant AI Outputs

Sample wording:

“Supplier shall indemnify Customer against third-party claims and direct losses arising from materially defective, unlawful, infringing, biased, misleading, or unsafe Outputs to the extent caused by Supplier’s breach of the Agreement, negligence, failure to implement agreed safeguards, or non-compliance with applicable law.”

20. Limitation of Liability

20.1 Buyer-Protective Liability Structure

Clause Title: Liability Cap and Exclusions

Sample wording:

“Supplier’s total liability under or in connection with the Agreement shall be no less than

\[three to five times\]

the total fees paid or payable under the Agreement in the preceding

\[12\]

months, provided that the foregoing cap shall not apply, or shall apply to a separate higher cap, to liability arising from: (a) breach of confidentiality; (b) infringement or misappropriation of intellectual property rights; (c) breach of data protection obligations; (d) Security Incidents; (e) fraud, fraudulent misrepresentation, wilful misconduct, or gross negligence; (f) death or personal injury; (g) breach of AI Laws; or (h) indemnification obligations.”

Buyer note: For critical AI procurement, buyers often seek uncapped or super-capped liability for privacy, security, IP, and regulatory breaches.

21. Fees, Payment Protections, and Audit of Charges

21.1 Fee Transparency

Clause Title: Pricing Transparency and Consumption Controls

Sample wording:

“Supplier shall provide transparent pricing for licenses, usage, tokens, compute, storage, support, overages, professional services, model tiers, and third-party pass-through charges. Supplier shall implement usage controls, budget alerts, and hard caps at Customer’s request. Customer shall not be liable for charges caused by Supplier error, unauthorized access, defective metering, or unapproved usage.”

21.2 Audit of Charges

Clause Title: Billing Audit Rights

Sample wording:

“Customer may audit Supplier’s invoices, usage calculations, token counts, and other charges relevant to the Services. Supplier shall retain supporting records for at least

\[7\]

years and promptly refund any overcharges.”

22. Term, Suspension, and Termination

22.1 Suspension Rights

Clause Title: Customer Suspension Rights

Sample wording:

“Customer may immediately suspend use of any affected Services, without liability, where Customer reasonably believes that continued use may create legal, regulatory, security, safety, discrimination, confidentiality, or operational risk. During suspension, Supplier shall cooperate fully in investigation and remediation.”

22.2 Termination for Cause

Clause Title: Termination for Cause

Sample wording:

“Customer may terminate the Agreement or any affected Order immediately upon written notice if Supplier: (a) materially breaches the Agreement and fails to cure within

\[10/15/30\]

days; (b) suffers a repeated service level failure; (c) breaches confidentiality, data protection, security, or AI Laws; (d) makes a material adverse change to the Services without consent; or (e) exposes Customer to unacceptable legal, operational, or reputational risk.”

22.3 Termination for Convenience

Clause Title: Termination for Convenience by Customer

Sample wording:

“Customer may terminate the Agreement or any Order for convenience on

\[30/60/90\]

days’ written notice. Upon such termination, Customer shall pay only undisputed fees for Services properly provided up to the effective date of termination, and Supplier shall refund any prepaid unused fees.”

23. Exit, Transition, and Data Return

23.1 Exit Assistance

Clause Title: Exit Assistance and Transition Support

Sample wording:

“Upon expiration or termination, Supplier shall provide all reasonable transition assistance necessary to migrate Customer to Customer’s replacement supplier or internal solution, including continued access for a transitional period, data export, technical cooperation, documentation, knowledge transfer, and assistance with reconfiguration or migration, at rates no higher than those stated in the Agreement or, if termination is caused by Supplier breach, at no additional charge.”

23.2 Data Return and Deletion

Clause Title: Return, Portability, and Deletion of Data

Sample wording:

“Promptly upon termination or upon Customer’s request, Supplier shall return Customer Data and Outputs in a structured, commonly used, machine-readable format, together with relevant metadata, logs, and configuration information reasonably necessary for continuity. Supplier shall thereafter securely delete all Customer Data and certify deletion in writing, except to the extent retention is required by law.”

23.3 Model/Configuration Portability

Clause Title: Portability of Customer-Specific Configurations

Sample wording:

“Supplier shall provide Customer with a copy of Customer-specific prompts, workflows, retrieval configurations, policies, templates, model parameters to the extent customer-specific and exportable, evaluation datasets provided by Customer, and other artifacts reasonably necessary to reduce vendor lock-in.”

24. Publicity, Reference Use, and Disclosure

Clause Title: Publicity Restrictions

Sample wording:

“Supplier shall not name Customer, use Customer’s trademarks, or describe Customer’s use of the Services in any marketing, case study, benchmark publication, or public statement without Customer’s prior written consent.”

24.2 No Use of Customer for Benchmarking

Clause Title: Restriction on Benchmarking Using Customer Data

Sample wording:

“Supplier shall not use Customer Data, Customer use patterns, or Customer-specific results for public or private benchmarking, leaderboards, comparative marketing, or product claims without Customer’s explicit prior written consent.”

25. Governing Law, Dispute Resolution, and Interim Relief

25.1 Governing Law

Clause Title: Governing Law

Sample wording:

“This Agreement shall be governed by the laws of

\[Jurisdiction\]

, excluding conflict of laws principles.”

25.2 Dispute Resolution

Clause Title: Dispute Resolution

Sample wording:

“The parties shall first seek to resolve disputes through good faith escalation between senior representatives. If unresolved, either party may pursue litigation in the courts of

\[Jurisdiction\]

/ arbitration under the rules of

\[institution\]

. Nothing in this Agreement shall prevent Customer from seeking injunctive or other urgent relief in any court of competent jurisdiction.”

26. General Provisions Especially Important in AI Deals

26.1 Assignment

Clause Title: Assignment

Sample wording:

“Supplier may not assign, subcontract, transfer, novate, or otherwise dispose of the Agreement, in whole or in part, without Customer’s prior written consent, except to an affiliate that is demonstrably capable of performing the obligations and assumes them in writing. Any permitted assignment shall not relieve Supplier of liability.”

26.2 Subcontracting

Clause Title: Subcontracting Controls

Sample wording:

“Supplier shall remain fully liable for all subcontracted performance and shall ensure that all subcontractors are bound by obligations no less protective than those in this Agreement.”

26.3 Amendment

Clause Title: Amendments and No Unilateral Changes

Sample wording:

“No amendment, policy update, online term, or product notice shall modify the Agreement unless expressly agreed in writing by Customer. Continued use of the Services shall not constitute acceptance of any unilateral change.”

26.4 Survival

Clause Title: Survival

Sample wording:

“Provisions relating to confidentiality, data protection, security, audit, intellectual property, indemnities, liability, payment, dispute resolution, and exit assistance shall survive termination to the extent necessary to give them effect.”

Optional AI-Specific Clauses Often Added in Practice

These are not always in every contract, but are often highly valuable.

A. AI Governance Committee

Clause Title: Governance and Review Meetings

Sample wording:

“The parties shall establish a governance process, including periodic review meetings, to address performance, incidents, regulatory changes, model changes, fairness metrics, security risks, and roadmap impacts.”

B. Red Teaming and Adversarial Testing

Clause Title: Adversarial Testing Rights

Sample wording:

“Customer may perform, or appoint a third party to perform, reasonable adversarial testing, prompt injection testing, abuse case testing, and validation of safety controls in a non-production or approved environment.”

C. Kill Switch / Feature Disablement

Clause Title: Emergency Disablement

Sample wording:

“Supplier shall provide Customer with the ability, where technically feasible, to disable specified AI features, model endpoints, automated actions, or integrations immediately if Customer reasonably determines they create unacceptable risk.”

D. Recordkeeping

Clause Title: Recordkeeping and Retention

Sample wording:

“Supplier shall maintain complete and accurate records relating to model versions, training provenance categories, evaluations, incidents, changes, approvals, and compliance activities for at least

\[6–10\]

years or such longer period as required by law.”

Practical buyer comments on a few points from your reference text

Some of the wording in the reference you provided is not buyer-optimal and should usually be reversed or tightened:

Ownership of AI outputs
Your reference says the provider retains all rights in outputs.
Buyer-protective position: Customer should own, or at minimum have a broad perpetual right to use, modify, commercialize, and sublicense outputs generated from its use.
User input data license
Your reference grants the provider an irrevocable, perpetual, sublicensable right over user inputs.
Buyer-protective position: This is usually unacceptable. The supplier should get only a limited license strictly necessary to deliver the service.
Liability for AI outputs
Your reference largely disclaims provider liability.
Buyer-protective position: For enterprise procurement, especially under regulated or sensitive use cases, supplier should bear responsibility for non-compliant, infringing, unsafe, or defective outputs to the extent caused by its system or breach.
Prior consent for AI features
This is a very strong clause and often useful where AI is embedded in broader software.
Buyers should require no AI features without prior written consent, especially where the original procurement was for non-AI software.

A Practical AI Procurement Control Checklist

A useful AI procurement control checklist should help lawyers, procurement staff, compliance officers, and business owners assess vendors in a structured way.

At minimum, it should ask these questions.

Does the vendor understand the business problem and the industry context?

Can the vendor show relevant implementation experience and references?

Can the vendor demonstrate security, privacy, and regulatory readiness?

Can the vendor explain the system’s outputs, limitations, and bias controls?

Are support, update, audit, drift, and exit terms contractually defined?

Is there a clear process for performance review, escalation, and remediation?

This checklist should be used early and updated as the deal progresses. It should also be shared across procurement, legal, security, and business teams so the review stays integrated.

Implementation tip: Keep the checklist short enough to use in real vendor reviews and deep enough to expose meaningful risk. Long questionnaires that nobody reads carefully are false comfort.

PracticalTips in AI Procurement and Due Diligence

These tips apply across the full buying process.

Tip 1: Buy against the operating reality, not the demo

Demos are controlled. Operations are not.

Implementation tip: Evaluate the AI system using your workflow conditions, your user expectations, your governance rules, and your data sensitivity profile. That is the real buying environment.

Tip 2: Treat explainability and support as procurement issues

These are often pushed to later project stages. They belong in vendor selection and contracting.

Implementation tip: Ask vendors how operators, reviewers, and support staff are supposed to understand and troubleshoot the system in practice.

Tip 3: Plan for exit before the relationship gets comfortable

AI vendor dependence becomes harder to manage over time.

Implementation tip: Define data return, deletion, transition support, and model or configuration portability early. Exit planning is much easier before problems arise.

Tip 4: Keep procurement, legal, and technical reviews connected

AI risk often sits between functions.

Implementation tip: Hold at least one joint review session with procurement, legal, security, privacy, product, and the business owner before final vendor selection. That one meeting often surfaces the real blockers.

References for AI Procurement

If you want a stronger AI procurement process, anchor it in recognized governance, security, and contract frameworks.

Here are the references I would use.

ISO/IEC 42001, AI management systems
ISO/IEC 42005, information to include in an AI impact assessment
ISO/IEC 23894, AI risk management
NIST AI Risk Management Framework 1.0
ISO/IEC 27001 and 27002 for supplier security controls and information security management
Vendor risk management and procurement standards
Data protection, confidentiality, and sector-specific legal requirements relevant to the use case
Internal contract review, architecture review, and third-party risk workflows
AI-specific SLA and model documentation expectations for transparency and performance governance

If your organization already has strong procurement and vendor risk functions, adapt them for AI instead of creating a separate process from scratch. The key is adding the AI-specific controls that standard technology procurement often misses.

Why AI Procurement Fails When Treated as a Vendor Selection Exercise

When teams treat AI procurement as a vendor selection exercise, they compare features, pricing, and references, then move quickly to signature. The harder questions stay underexplored. How does the vendor handle drift. What rights do they have over customer data. How transparent is the system. Who supports the tool when outputs degrade quietly. What happens if the provider changes direction, gets acquired, or fails to meet compliance expectations.

When teams treat AI procurement as a control process, the purchase becomes stronger. The chosen vendor fits the business goal, the contract reflects the real risks, the support model is clearer, and the organization keeps more control over future performance and change.

A strong AI procurement process works because it buys operational fit and accountability, not just software access.

If you reviewed your current AI vendor pipeline today, which gap would worry you most first: weak business-fit evaluation, weak security and privacy review, thin explainability checks, weak contract protections, or poor post-signature performance governance?

About the Author

The frameworks, tools, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and globally.

Practical AI Service Level Agreements

Thu, 12 Mar 2026 00:00:00 +0000

How to Write SLA Terms for AI Systems That Hold Up in Real Operations

Most AI contracts spend too much time on commercial terms and too little time on service reality.

That is a problem. AI systems do not fail like ordinary software alone. They drift. They degrade quietly. They produce slower responses under load. They handle edge cases badly. They change behavior after updates. They depend on data quality, infrastructure stability, support responsiveness, and security coordination. If your AI service level agreement does not account for that, the contract may look complete while leaving the customer exposed and the supplier underdefined.

A strong AI service level agreement should do more than promise uptime. It should define how performance is measured, how drift is handled, what support is available, how vulnerabilities are disclosed, what happens when service levels are missed, and how AI-specific characteristics such as robustness, fairness, explainability, privacy, and resilience are reflected in the service model. This post shows you how to build that kind of SLA.

Understanding the Core Framework for an AI Service Level Agreement

An AI service level agreement is a negotiated contractual addendum that sets measurable service commitments between supplier and customer for an AI-based system. It should translate technical and operational expectations into enforceable terms.

The framework I use has four layers. Service definition, measurable commitments, operational support, and remedy and escalation. If one of these layers is weak, the SLA usually becomes hard to enforce or too vague to guide operations.

1. Service definition

This layer explains what service is being provided, what the key terms mean, what is in scope, and what exclusions apply.

This matters because AI vendors often describe a broad platform while the customer thinks they are buying a specific workflow outcome. The SLA should narrow that gap.

Implementation tip: Define the service in operational terms, not marketing terms. State what the system actually processes, returns, supports, and depends on.

2. Measurable commitments

This layer includes performance metrics, targets, calculation methods, and acceptable tolerances. This is the heart of the SLA.

A lot of AI SLAs stop at uptime and support response times. That is too thin for AI. You also need terms for quality, scalability, drift handling, update management, and where relevant, robustness, fairness, explainability, privacy, and resilience.

Implementation tip: Every SLA metric should answer three questions clearly. What is measured. How is it measured. What counts as success or failure.

3. Operational support

This layer covers support channels, support hours, response periods, update procedures, data management support, and vulnerability notifications. It is where the service becomes usable in practice.

AI systems need support that fits their operating pattern. If the AI supports regulated workflows or customer-facing services, support models and escalation paths become especially important.

Implementation tip: Match support commitments to the actual business criticality of the AI service, not just the vendor’s default package.

4. Remedy and escalation

This layer defines what happens when the service fails, metrics are missed, or disputes arise. It includes compensation, credits, limitations, and escalation procedures.

Without remedy and escalation language, the SLA may document expectations without giving either side a workable response path.

Implementation tip: Put escalation and remedy terms in plain language. If only lawyers can interpret the service failure process, recovery will be slower.

Why AI SLAs Often Fail in Practice

The most common problem is over-reliance on generic SaaS language.

That language covers availability, maintenance windows, and support tickets reasonably well. It often misses AI-specific failure patterns. A service can be “available” while model quality degrades. A tool can respond on time while producing unstable output. An update can improve one use case and hurt another. Without AI-specific terms, these issues remain operationally real and contractually blurry.

Another issue is weak definitions. Accuracy is promised with no measurement logic. Fairness is referenced without operational criteria. Drift is mentioned but not tied to thresholds or response obligations. Security notification is required but timelines are vague.

There is also a gap between legal drafting and operational readiness. If the SLA is not integrated with security event management, support processes, and change controls, the document may never shape how the service is actually run.

Implementation tip: Review AI SLAs with legal, procurement, security, product, and operations together. If only one function reviews them, important operational gaps will survive.

Stage 1: Define the AI Service and Core SLA Terms Clearly

The first step is defining the service and the language that will govern it.

The responsible parties are legal, procurement, vendor management, product owners, security, AI governance, and the business sponsor. Suppliers should contribute operational detail, not just standard terms.

The critical artifacts are the service description, SLA schedule, term definitions, architecture summary, support model, and integration dependencies. These should be consistent with the main contract and the actual deployed service.

What to implement: Include all core SLA components. Definitions, performance metrics and targets, monitoring process, and remedies for non-compliance. Define key terms such as availability, incident, maintenance window, drift, response time, processing time, support request, vulnerability, confirmed vulnerability, and major service failure.

Specify calculation methods directly in the definitions section. If monthly availability excludes planned maintenance, say that clearly. If response times apply only during support hours, define the support window. If “processing complete” means a document has been ingested, classified, enriched, and returned to the workflow, define that too.

This section should also explain how the AI service integrates with security event management and other operational processes. If alerts, logs, or security notifications must be coordinated across systems, that belongs in the SLA structure.

Implementation tip: Put calculation assumptions inside the defined term itself. That reduces later disputes about what the metric was supposed to mean.

Stage 2: Set AI-Specific Performance Metrics and Targets

This is where an AI service level agreement becomes more than a standard uptime attachment.

The responsible parties are product, engineering, supplier operations, customer operations, legal, procurement, and AI governance. Data science or model risk teams may need to review metric suitability where quality claims are important.

The critical artifacts are the KPI schedule, metric definitions, target thresholds, sample calculations, and reporting format. These should show not only what is promised, but how evidence will be generated.

What to implement: Link performance metrics to service objectives such as robustness, fairness, explainability, privacy, and resilience where relevant to the use case. Define uptime and reliability rates, such as 99.9 percent availability, backed by regular backups and disaster recovery support such as Infrastructure as Code. Add processing and scalability commitments, for example that 99 percent of recommendations or documents should be processed within a specified time window.

For predictive or classification services, define quality metrics carefully. Accuracy alone is often too weak. Where relevant, define sensitivity and specificity ratios, or other measures like precision, recall, false positive rates, and false negative rates. For AI outputs used in critical workflows, quality commitments should align with the real business risk.

Fairness and explainability are harder to promise contractually, but they should still be reflected where material. This may take the form of documented testing commitments, reporting obligations, or support for customer validation rather than a simplistic numeric warranty.

Implementation tip: Do not promise a metric you cannot monitor consistently. Contractual precision without operational evidence creates avoidable conflict.

Stage 3: Address Performance Drift, Updates, and Data Support

AI services change over time. A serious SLA has to account for that.

The responsible parties are supplier product and engineering teams, customer product and operations teams, vendor management, legal, and AI governance. Security and compliance may need a role where updates affect controls or regulated processes.

The critical artifacts are the drift management clause, update procedure, validation support terms, data support commitments, and acceptance process. These should connect directly to change management and service review workflows.

What to implement: Require the supplier to address performance drift when results move outside agreed margins. Define how drift is detected, who gets notified, what investigation window applies, and what remediation steps are expected. If the system depends heavily on customer data quality, define support responsibilities there too. AI service problems often sit at the boundary between model quality and input quality.

Also define update management procedures. Include notice periods, validation periods, rollback support where relevant, and any free customization or support window tied to material changes. Customers need enough time to test changes before accepting them in sensitive workflows.

Data management support should be explicit as well. Set expectations around data quality standards, acceptance periods, and support timeframes when ingestion or schema issues arise.

Implementation tip: Separate “platform update,” “model update,” and “customer configuration change” in the SLA. These changes have different risks and should not be treated as one category.

Stage 4: Define Support Services in Operational Detail

Support is where many SLA promises succeed or fail.

The responsible parties are supplier support teams, customer operations, product owners, vendor management, legal, and procurement. Security should review if incidents or vulnerabilities may be routed through the same channels.

The critical artifacts are the support matrix, ticket severity definitions, support center schedule, response and resolution targets, holiday coverage terms, and escalation paths.

What to implement: Define support methods clearly. Include support center hours, supported time zones, holiday coverage, and service windows such as 8x5x252 or 24x7x365. If the customer operates globally, specify whether local holidays are excluded or covered. Include guaranteed response periods for normal request volumes, such as 48 hours for routine issues, and shorter windows for higher severity events.

Severity categories should be tied to business impact. A full outage is different from delayed document processing. A wrong answer in a critical workflow may be more serious than a cosmetic issue. The SLA should reflect that.

This section should also explain how support is initiated, what information the customer must provide, and how unresolved issues escalate to engineering or leadership.

Implementation tip: Distinguish between response time and resolution time. Vendors often promise one and customers assume both.

Stage 5: Add Security, Privacy, and Vulnerability Notification Obligations

AI services introduce security and privacy dependencies that need direct contractual handling.

The responsible parties are security, privacy, legal, procurement, vendor risk, and supplier security teams. Product and operations should be informed because these issues often affect service continuity too.

The critical artifacts are the security schedule, incident notification clause, vulnerability notification terms, privacy commitments, and integration requirements with customer security event management processes.

What to implement: Require suppliers to notify customers of confirmed vulnerabilities within agreed timeframes. Define what “confirmed” means, what information must be shared, and which severity levels trigger customer notification. Include obligations for cooperation during investigation and remediation.

The SLA should also reflect resilience expectations such as backups, recovery processes, environment controls, and alignment with customer incident management where relevant. If the AI service processes personal or sensitive data, privacy controls and support expectations should align with the broader contract and data processing terms.

This section matters because service quality and security quality are often linked. A vulnerability can create both operational disruption and compliance exposure.

Implementation tip: Tie vulnerability notification to severity bands and response windows. General promises to notify “promptly” are too weak for meaningful incident handling.

Stage 6: Define Remedies, Compensations, and Dispute Handling Clearly

An SLA without consequences is mostly a statement of intent.

The responsible parties are legal, procurement, finance, vendor management, and the business sponsor. Operations and product should review to ensure remedies fit the actual service impact.

The critical artifacts are the remedy table, service credit structure, compensation clauses, limitation language, and dispute escalation workflow.

What to implement: Include compensation or service credit clauses for failure to meet warranted service uptime percentages and other key commitments where appropriate. Define how credits are calculated, claimed, and capped. Also outline the process for handling service failures or disputes, including escalation steps, review periods, and decision paths.

For AI services, remedies may need to cover more than outage. Repeated drift outside agreed margins, failure to provide required support, failure to disclose vulnerabilities, or unmanaged update impacts may also need contractual consequences or stronger governance triggers.

Still, remedies should stay practical. Overly aggressive penalties can make negotiation harder and may not improve actual service quality if they are never invoked or if the supplier prices the risk back into the contract.

Implementation tip: Match remedies to the service criticality. A low-value internal copilot and a mission-critical AI workflow should not use the same remedy structure.

AI Service Level Agreements Practices

These tips help make the SLA usable after signature.

Tip 1: Link the SLA to live operational processes

A strong SLA should fit into monitoring, support, security, and vendor review workflows.

Implementation tip: Make sure the teams running service reviews can actually access the data needed to measure SLA compliance. If not, the agreement is too abstract.

Tip 2: Keep AI quality commitments realistic and measurable

AI behavior is probabilistic in many use cases. That means quality terms need careful drafting.

Implementation tip: Use quality ranges, review obligations, and drift thresholds where hard guarantees are unrealistic. Precision helps more than overpromising.

Tip 3: Review SLAs after major service changes

AI services evolve quickly. The SLA should not stay frozen if the product, deployment context, or customer reliance changes materially.

Implementation tip: Trigger SLA review after major model changes, architecture changes, support model changes, or expansion into higher-risk workflows.

Tip 4: Use examples during negotiation

SLA language becomes clearer when both parties work through realistic scenarios.

Implementation tip: Test draft clauses against sample events such as a drift incident, a vulnerability disclosure, a document processing backlog, or a holiday support gap. Scenario review exposes weak wording fast.

References for AI Service Level Agreements

If you want a stronger AI SLA structure, anchor it in recognized security, governance, procurement, and service management standards.

Here are the references I would use.

ISO/IEC 42001, AI management systems
ISO/IEC 23894, AI risk management
ISO/IEC 42005, information to include in an AI impact assessment
NIST AI Risk Management Framework 1.0
ISO/IEC 27001 and 27002 for security controls, incident handling, and resilience
Service management practices for availability, incident response, and support operations
Vendor risk management and procurement standards
Data processing, privacy, and sector-specific legal obligations relevant to the service
Internal business continuity, disaster recovery, and security event management requirements

If your organization already uses SaaS SLA templates, vendor risk reviews, and operational governance forums, adapt them for AI rather than starting from zero. The important part is adding AI-specific service logic where the standard template is too generic.

Why AI SLAs Fail When Treated as Contract Boilerplate

When teams treat AI service level agreements as boilerplate, the SLA covers uptime, support hours, and little else. Drift goes unmanaged. quality terms stay vague. update effects are underdefined. vulnerability notifications are too soft. customers assume the supplier is accountable for outcomes the contract never actually defines. suppliers assume standard SaaS language is enough when the service is far more dynamic than standard software.

When teams treat the AI SLA as an operational contract, it becomes a real management tool. It clarifies what the service is, how it is measured, what support looks like, how issues escalate, and what happens when the service underperforms. That improves accountability on both sides.

A strong AI service level agreement works because it turns AI uncertainty into operational clarity where it matters most.

If you reviewed your current AI vendor contracts today, which gap would likely worry you most first: weak metric definitions, missing drift commitments, vague support coverage, weak vulnerability notification, or remedies that do not match the real business risk?