User Agreements for AI Products: Twelve Clauses, Six Failures and a Pre-Launch Checklist

In most AI companies the user agreement occupies an awkward position: drafted by legal from a template a week before launch, posted at the foot of the registration page, and consulted thereafter only when a regulator asks a question or a user complains. In a generative AI product, however, the document performs three functions at once. It defines the boundary of the service, allocates the liability that unpredictable output creates, and implements the contractual duties that regulation imposes on service providers. Article 9 of the Interim Measures for Generative AI Services requires providers to conclude a service agreement with users and to specify the rights and obligations of both sides. That provision converts the user agreement from an optional extra into a regulatory element.

Completeness is not the same as validity. In practice, clauses fail not because they are missing but because the notice and explanation duty for standard-form terms has not been discharged, because the consent mechanism has not been built, or because the text does not match the product as it actually operates.

1. Character first: three functions

The first function is service governance. What the service provides, what it does not, when it may change, and which conduct leads to suspension — without these in the agreement, operational decisions have no contractual basis. The point at which companies most often lose suspension disputes is precisely the clause that says only that the company may terminate the service, with no trigger conditions and no procedure.

The second function is risk allocation. Generative output cannot be fixed at the point of contracting; it may be inaccurate, may infringe third-party rights, and may be used for unlawful purposes. How those risks are divided between platform and user can only be settled by contract. The law does not allocate them for the parties; it reviews whether the allocation is manifestly unfair.

The third function is the implementation of regulatory duties. Beyond Article 9, Article 10 of the Interim Measures addresses training-data processing and Article 12 requires labelling of generated content. Since the Measures for Labelling AI-Generated Synthetic Content took effect on 1 September 2025, the labelling duty has become more specific. Some of these duties can only be transmitted to users through contract terms — for example, requiring users to preserve labels when they disseminate generated content and prohibiting removal or tampering.

These three functions mean the agreement cannot be produced by legal alone. Product, operations, engineering and customer service need to be involved while the clauses are being formed; otherwise the rules written down and the rules the product follows are two different systems.

2. Four differences from conventional SaaS

The differences determine the drafting. Templates built for conventional SaaS tend to miss in four places.

First, output is not predetermined. SaaS promises that a function will work; an AI product promises that a capability will be available, without any guarantee that the output will be correct. The agreement cannot promise accurate, complete and reliable output, but neither can it say only that no warranty of any kind is given — the latter is readily treated as excluding the user’s principal rights.

Second, the model changes. Version iteration, model substitution and capability withdrawal are routine. The agreement needs a variation right, but a variation right must carry a notice method and an effective date; otherwise the user has no expectation that what was bought today may be different tomorrow.

Third, input may contain another person’s personal information or trade secrets. When a user pastes a customer list, a contract or employee data into a dialogue box, the platform becomes a processor of that information. The agreement must require the user to warrant that its input has a lawful basis, and must state how the platform handles that input.

Fourth, output may infringe third-party rights. Training-data provenance is complex and similarity between output and existing works cannot be excluded entirely. The agreement should require the user to check output before use, and should establish a notification and cooperation mechanism if a third party asserts a claim.

3. Twelve clauses that must be drafted precisely

1. Service description and the right to vary. State the basic form of the service, the scope of its capabilities and the scenarios in which it should not be used, then grant a variation right. The variation clause should distinguish two categories: optimisations that do not affect core functionality may take effect immediately; changes that materially reduce capability or alter pricing should be notified in advance and should give the user a right to terminate. Merging both into a single right to adjust the service at any time amounts to an unsigned authorisation.

2. Accounts, real-name registration and age. Distinguish individual users from enterprise users and specify registration information, account ownership and administrator permissions separately. For enterprise editions, state that accounts are allocated by the enterprise administrator and how they are recovered when an employee leaves. An age clause cannot stop at a sentence saying that minors require guardian consent; it must correspond to whether the product offers a minor mode and whether it performs age identification. A consent clause unaccompanied by any identification capability does not produce a defence.

3. Ownership and licensing of generated content. This clause most affects whether deals close. For consumer products, provide that rights in output belong to the user, that the platform receives a limited licence for service delivery and model improvement, and state the scope, duration and sublicensing position of that licence. For enterprise customers, the usual position is that output belongs to the enterprise and that the platform may not use enterprise input for training. Drafting ownership as belonging to the platform in all cases will eliminate commercial customers at the procurement review stage.

4. Warranties on user input. Require the user to warrant that its input infringes no intellectual property, contains no unauthorised personal information and breaches no confidentiality obligation. The purpose of this clause is not to exempt the platform but to give it a basis for defence and for recovery when a third-party claim arrives.

5. Acceptable use policy. Prohibited conduct — generation of unlawful content, jailbreak prompts, bulk scraping, resale of API access, use of output to commit fraud — does not belong in the body of the agreement and should stand as a separate annex. The advantage of an annex is that it can be updated independently and that it evidences, in a suspension dispute, that the rules were clearly stated.

6. Pricing, metering and refunds. For token-based products, state the metering basis, the validity period of allowances, treatment of overage and the method of price adjustment. Refund clauses should distinguish unused allowances from consumed services; a bare statement that all fees are non-refundable is readily treated as excluding the consumer’s principal rights.

7. Availability and service levels. Consumer products may adopt a commercially reasonable efforts standard, but should address scheduled maintenance and force majeure. Enterprise editions need availability metrics, incident response times and remedies for shortfall. An enterprise SLA drafted as best efforts is generally not accepted in procurement review.

8. Liability limits and caps. Indirect losses may be excluded and a cap may be set, but liability for personal injury and for loss caused by intent or gross negligence may not be excluded. A limitation clause must be brought to the user’s attention by reasonable means; where the notice and explanation duty has not been discharged, the clause may not form part of the contract.

9. Intellectual property and third-party rights. Confirm the platform’s rights in the product, interface and documentation, and prohibit reverse engineering and removal of rights notices. Establish a process for third-party claims concerning output: user notification, platform verification, suspension of use and subsequent arrangements.

10. Interface with the privacy policy. The user agreement should not repeat the privacy policy in full, but must do three things: identify the privacy policy as part of the agreement, state which document prevails in case of conflict, and warn that where input contains another person’s personal information the user must obtain authorisation. A training-data clause should not be buried in the privacy policy alone; where user input is used for model improvement, separate notice and consent are required.

11. Termination, suspension and data export. Specify the trigger events, the notice method, the appeal channel and the export window. Suspension materially affects user rights, so temporary restriction and permanent termination should be distinguished and a human review step retained. A termination clause without procedure is difficult to characterise as performance of the contract in litigation.

12. Dispute resolution, governing law and notices. Specify PRC law, the court or arbitral institution, and the permitted methods of notice — registered email, in-app message, announcement. A standard-form jurisdiction clause aimed at consumers that excludes their right to choose another forum risks being held invalid.

4. Six failures that survive on paper

What these six share is that the clause exists in the text but not in law. The test is not whether it was written but whether the accompanying procedure was performed — notice, disclosure, separate consent and withdrawal. If any one of the four is missing, the clause is weakened.

5. Document structure: body, annexes and change log

A mature user agreement is not one file but a set of files.

The body sets out the basic rights and obligations of the parties; annexes carry rules that can be updated independently, including the acceptable use policy, the service level statement and the data processing agreement; the change log preserves each version, its effective date and the substance of the change. The value of the three parts lies in evidence: in a dispute, they show what the rules were at a given time, what version the user saw, and whether notice was given.

The change log is the most commonly neglected part. “Which version did the user accept at registration” is a standard question in regulatory enquiries and litigation. Without version retention, the company can usually answer only with the current version — the least favourable answer available.

6. Pre-launch checklist

Items 7 and 8 are the ones most often skipped. The first requires changes to the registration flow to discharge the notice duty; the second requires a separate tick box on the product side. Both are typical points at which legal asks and product does not deliver — and both determine whether the clause can take effect.

7. Conclusion

The quality of a user agreement is not finally a matter of drafting detail but of three things: whether the clauses match the product, whether the notice and explanation procedure for standard-form terms has been performed, and whether consent and withdrawal actually work. Do these three and the agreement becomes an executable set of rules rather than a document of disclaimer; fail them and additional length merely adds a further exhibit to be explained when a dispute arrives.

Related reading: the core contract set for AI companies, five data-compliance risks for AI companies, the two requirements for AI services in the draft minors regulation, new duties for large personal information processors, and the data compliance and commercial contracts service pages.

Last updated: 11 June 2026.