- within Transport topic(s)
A Pragmatic Guide for Customers and Suppliers
In Part 1, we looked at why AI-embedded software calls for a different contracting approach than the templates most companies may still be using. We covered how to identify what kind of AI is actually in scope, and walked through the three issues that matter most on the customer side: training data use, output ownership, and accuracy risk.
Here, we turn to those same issues from the supplier’s perspective, and close with a few suggested drafting principles that apply regardless of which side of the table you sit on.
Top Issues for Suppliers
1. Rights to Improve the Service
Pre-AI service agreements treated usage data (logs, diagnostics, support tickets) as an operational detail. In an AI-enabled service, that same data is often what makes the product better over time.
As a result, the supplier’s objective is to preserve the ability to improve its products and models without compromising customer confidentiality or contractual commitments.
That raises a few key questions:
- How much customer data, and in what form (raw, aggregated, de-identified), does the supplier actually need to keep the service running and secure?
- Does that use case require touching foundation model training at all, or does it stop at service-specific improvement?
- What transparency does the customer need about how its data is used, even where use is permitted?
Suppliers generally land in the same place. They retain rights to use aggregated or de-identified usage data for service improvement and operational purposes. Customer confidential information and personal data are excluded from broader foundation model training absent consent. Retention and improvement practices are disclosed.
The same contractual line drawn in Part 1 — service improvement vs. generalized model training — does the work on both sides of the negotiation.
2. Limiting Output Liability
Just as customers are negotiating for output ownership and accuracy protections, suppliers are negotiating which risks are actually theirs to own. An unlimited warranty that outputs will be accurate, complete, or non-infringing “in all circumstances” made more sense for deterministic software than it does for a probabilistic model shaped in part by the customer’s own prompts.
The supplier’s objective is to avoid responsibility for risks outside its own visibility or control. That raises a few key questions:
- Which failures originate in the platform or model architecture itself, versus in how the customer prompted, configured, or deployed it?
- What level of validation should the customer be expected to perform before relying on outputs in a business-critical decision?
- Should indemnity obligations extend to every downstream use of an output, or stop at platform-level infringement?
Three positions are becoming standard. Performance commitments are tied to documented specifications rather than absolute warranties. Disclaimers address customer prompts and implementation choices, with human review required for business-critical use cases. Indemnities are scoped to platform-level infringement rather than every downstream use of an output.
Courts and insurers are, for good reason, unlikely to underwrite unlimited output liability, which makes this less a negotiating tactic than a reflection of where the risk actually sits.
3. Model Updates and Versioning
Traditional software was released in discrete, numbered versions that customers could choose to adopt or decline. AI models often evolve continuously, through retraining, tuning, and infrastructure changes, in ways that don’t map cleanly onto a versioning clause built for annual releases.
The supplier’s objective is to maintain flexibility to improve models and deploy updates as the technology
- How much version stability does the customer actually need for its use case?
- What counts as a “material” change worth flagging, versus routine tuning that shouldn’t require a conversation every time?
- What notice period is realistic given how quickly models are updated?
Contracts that hold up over time tend to share a similar structure. Suppliers are given the right to deploy updates and improvements without customer consent for each change. Notice is required for changes that materially affect functionality, security, or outputs, along with a commitment not to materially degrade any of them. Legacy model versions receive limited, rather than indefinite, support.
The question is not whether models will change — they will, continuously. It is whether the contract tells the customer which changes it will hear about.
Practical Drafting Principles (For Both Sides)
As AI technologies continue to evolve, contract provisions grounded in how the technology actually functions and how the parties intend to use it generally work best. Five principles hold up regardless of which side you represent:
Define AI precisely. Not every AI-enabled feature carries the same legal or commercial risk. A definition that distinguishes traditional machine learning, generative AI, embedded functionality, and customer-facing applications can sometimes be more useful than a broad reference to “artificial intelligence” or “automated decision-making.”
Distinguish model training from service improvement. Contracts that separate generalized model training from the telemetry and diagnostics needed to maintain, secure, and improve the service can often reduce a large share of the friction in these negotiations.
Distinguish inputs, outputs, derivatives, and underlying technology. Ownership, licensing, and data rights can often become easier to allocate when agreements separately address customer inputs, AI-generated outputs, supplier technology, derivative developments (e.g., fine-tunings), and pre-existing intellectual property.
Match protections to actual risk. Contractual protections that track with what’s actually at stake (e.g., the sensitivity of the data and the intended use case) — rather than being triggered automatically because the word “AI” appears in the product description — are more likely to hold up in practice, and less likely to burden low-risk use cases with protections they don’t need.
Allocate risk in proportion to control. The most durable agreements tend to assign responsibility to whichever party is actually positioned to manage a given risk, rather than attempting to make one side responsible for outcomes it can’t see or influence — a customer’s downstream use of an output, or a supplier’s dependence on a third-party foundation model it didn’t build.
The Bottom Line
As AI becomes a standard component of commercial software and services, the most effective contracts will be those that allocate risk in a way that reflects how the technology actually functions, while preserving the flexibility both sides need to keep improving it.
Effective AI contracting is less about predicting every future risk than about allocating responsibility based on architecture, data flows, operational realities, and business objectives. When those are clearly understood, negotiations become more focused and more likely to produce a commercially durable agreement.
GC provides outside general counsel services to companies of all sizes, offering project-based support, subject-matter expertise, and day-to-day GC services through a team of partner-level business attorneys. For more information visit: Outside General Counsel Corporate Legal Services.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
[View Source]