Commercial Contract System
AI contracts are not a template exercise. Every clause touches data flows, liability allocation and regulatory duties — the agreement set defines where your commercial boundary actually sits.
AI contracts fail on three questions a generic template cannot answer
Who bears the cost when the model gets it wrong? Who owns what the model emits? What authorises you to train on what the user typed? A contract downloaded from a template library was drafted for software that behaves deterministically and does not ingest user content. It answers none of the three.
The gap is structural. Traditional software promises a defined function; an AI product promises a capability with a distribution of outcomes. Once output is probabilistic, liability, ownership and consent all have to be written down explicitly — otherwise the default rules apply, and the default rules were not designed for this.
What we do
- SaaS subscription agreement: scope of service, SLA, disclaimer of reliance on model output, security commitments, suspension and termination
- API access agreement: permitted calls, rate limits, ownership of inputs and outputs, use of call data, metering and billing
- Data processing agreement (DPA): controller/processor allocation, security measures, breach notification timeline, cross-border transfer clauses
- End-user terms: registration terms, privacy policy, cookie policy, minors and age-gating provisions
- Procurement templates: technology services, data labelling, compute and model licensing agreements
What is different for an AI company
- Draw the liability boundary around model output. Accuracy, availability commitments and exclusions must correspond one-to-one; for high-risk use, specify human review and who makes the final decision, or a single bad output becomes a breach claim.
- Whether user input can train the model. This is the first question a customer’s legal team asks. Default to no training use, or state an explicit opt-out, in the main agreement rather than only in the privacy policy.
- Guard against API resale and abuse. Call limits, a resale prohibition, abnormal-traffic handling and a duty to cooperate with investigations — miss one and the upstream provider’s claim lands on you.
- Upstream discontinuation is a real risk. A model provider suspending service, raising prices or changing licence terms flows straight into your SLA. Contracts need a fallback and a liability cap.
- Open-source and third-party model obligations travel with delivery. Where deliverables embed open-source components or licensed models, licence obligations and notices must be delivered with the contract.
Typical situations
Situation 1: Model output caused customer loss, and nothing limits the exposure
A customer uses the product to support a commercial decision, the output is wrong, and the loss is material. The SaaS agreement defines the service in broad terms, with no statement about the reliability of model output and no liability cap. The claim is effectively uncapped.
Our approach: state plainly that output is assistive and does not constitute professional advice, cap aggregate liability at fees paid in the preceding twelve months, exclude indirect and consequential loss, and align the product interface with the contractual position so the two do not contradict each other in a dispute.
Situation 2: The API was abused at scale and the terms gave no right to act
An API key is used to generate prohibited content in volume. The terms contain no prohibited-use clause, no rate limits, and no suspension right. After the account is blocked, the customer claims breach of contract — and on the paper, they have an argument.
Our approach: build a prohibited-use schedule, an audit and suspension right that operates on notice, a content-moderation reservation, and key management obligations — then mirror them in the technical controls so the contractual right is exercisable in practice.
Situation 3: Training on user inputs, with a privacy policy that stays silent
Conversation data is used to improve the model, but the privacy policy states only that data is used “to provide the service”. A user complains, a regulator inquires, and remediation is ordered — over a disclosure gap, not a technical failure.
Our approach: disclose the training use explicitly, provide an opt-out path, define the scope of training data and de-identification standards in the DPA, and check that the consent chain actually supports the disclosed purpose.
Process and deliverables
| Stage | Work | Deliverables |
|---|---|---|
| 1 | Business model mapping, contract needs assessment, risk identification | Contract architecture map + risk register |
| 2 | Drafting the core set (SaaS / API / DPA / end-user terms) | Full document set (4-6 core agreements) |
| 3 | Internal review, customer testing, clause refinement | Final agreements + usage notes |
| 4 | Template deployment, signing workflow | Contract repository + signing SOP |
| Ongoing | Regulatory tracking, clause updates | Change alerts + revised agreements |
AI-specific deliverables
- AI clause set: model-output liability, training-data authorisation, permitted use of user input and ownership of output, each with alternative wording and risk notes.
- Training-data authorisation chain: sources, licences and scope of use compiled as a diligence-ready file.
Frequently asked
Can we start from a SaaS template downloaded online? The defect is not quality but coverage. Generic templates carry no clause on model-output reliance, no training-use authorisation, and no allocation of rights in generated content. Those three are where AI products actually lose money, and they are precisely what a generic template omits.
When do we need a DPA? Whenever the product processes personal data on a customer’s behalf. If you act as processor, the DPA sits as a schedule to the main agreement. If any data crosses the border, it must also carry transfer terms and a documented transfer mechanism.
Can the API agreement and the SaaS agreement be merged? Not advisable. The rights and obligations differ: API use turns on call limits, output ownership and technical integration; SaaS use turns on availability, support and account management. Merging them produces clauses that fit neither.
How often should end-user terms be revised? On any change in the underlying regulation, on any product change that affects user rights, and at minimum on an annual full review. Terms that lag the product are worse than no terms, because they document a promise you are not keeping.
Can we train models on customer data? Not by default. Authorisation must be taken separately, with purpose, scope and exit terms stated; a general “as necessary to provide the service” clause is hard to rely on later.
Legal basis
- Civil Code, Book III (Contracts): formation, validity, breach, standard terms (Arts. 496-498)
- Personal Information Protection Law: processing rules, entrustment agreements (Art. 21), separate consent for third-party provision, privacy impact assessment
- Data Security Law: security management obligations for data processing activities
- E-Commerce Law: platform operator obligations
- Interim Measures for the Management of Generative AI Services: disclosure of intended users, occasions and purposes, and the duty to conclude service agreements with users (Art. 9); content labelling (Art. 12)
- Provisions on the Administration of Deep Synthesis of Internet Information Services: obligations on user agreements and prominent risk warnings