Privacy Policies for AI Products: Notice Granularity, Training-Data Clauses and Four Sharing Scenarios

The privacy policy is a mandatory document for every AI product and, equally, the one most often produced from a template. The usual result is a long document with complete clauses that nevertheless cannot answer a regulator’s first question: what training data was used, whether user input enters the model, whether calling an overseas API constitutes a cross-border transfer. The problem is not word count but the gap between the granularity of notice and what the product actually does.

Article 17 of the Personal Information Protection Law requires that, before processing personal information, a processor inform the individual in a prominent manner and in clear, plain language, truly, accurately and completely, of six matters: the name and contact details of the processor; the purpose and method of processing; the categories of information and the retention period; and the manner in which rights may be exercised. These six are the floor. The difficulty for AI products is that each must be tied to a specific processing activity.

1. The six elements as applied to AI products

Processor identity and contact details. The operating entity and the technology provider must be distinguished. Where product A is operated by company A and the model is supplied by company B, the policy should state who is the processor and who processes on instruction. Naming only a brand leaves the user unable to find the responsible party when exercising rights, which is itself incomplete notice.

Purpose. It is not enough to say that information is used to provide and improve the service. An AI product should separate at least four purposes: delivering the generative service; securing the service through content moderation and risk control; improving the model; and complying with legal obligations. The lawful basis differs between them, and a single rolled-up sentence cannot later be substantiated.

Method. Collection, storage, use, processing, transmission, provision and deletion. For AI products two further matters must be stated: whether input enters any stage beyond the inference path, and whether output is retained for training or evaluation.

Categories. Beyond accounts, devices and logs, an AI product must list user input as its own category. Contracts, customer lists, medical records and employee data that users paste become personal or sensitive personal information on the platform side, yet most policies say nothing about them.

Retention. State a period, or the method for determining one, for each category. The Interim Measures for Generative AI Services require retention of network logs; the relationship between that period and the data-minimisation principle should be explained rather than reduced to a reference to periods required by law.

Exercise of rights. Access, copy, correction, deletion, withdrawal of consent, portability and explanation — each of the seven should have an entry point, rather than a single line directing users to a customer service mailbox.

2. The four hardest scenarios

First, third-party information within user input. Whether the platform processes information about others that a user pastes into a dialogue box, to what extent, and whether this amounts to provision to the platform, must be addressed. A workable approach is to state clearly that users must not submit personal information about others without authorisation, and to explain that the platform processes input only as necessary to deliver the service and deletes it after a reasonable period.

Second, training-data use. This is the clause that regulators and users both look for. The policy must answer three questions: whether user input is used for training; if so, what de-identification or aggregation is applied; and whether the user can opt out. A clause that answers only one of the three cannot be implemented. Where input is used for training, separate notice and consent are generally required; a sentence in the body of the policy saying that information may be used to improve the service is not sufficient.

Third, model and API providers. Whether a third-party model service is engaged as a processor or as an independent controller depends on who determines the purpose and method. In most cases the platform remains the processor and the model provider processes on instruction, which calls for a data processing agreement. Where the model provider uses the data to improve its own model, however, that may constitute independent processing requiring separate notice. The policy should list the categories of principal processors rather than refer vaguely to partners.

Fourth, automated decision-making. Content moderation, recommendation ranking, risk scoring and credit limits all involve automated decision-making. Article 24 requires transparency and fairness, and where a decision has a material impact on an individual, an explanation and a means of refusal must be offered. Moderation errors leading to account suspension are a frequent instance, and the policy needs an appeal and human review channel.

3. Four forms of consent

All four share a requirement of withdrawability, and withdrawal does not affect processing already carried out. The common defect is bundling consent into a single sentence that registration constitutes acceptance of all terms; such blanket consent does not hold for sensitive information, third-party provision or cross-border transfer.

4. Four sharing scenarios

The second row is the most frequently overlooked. Many AI products integrate analytics, push notification and crash-reporting SDKs which collect device information independently; that is the SDK provider’s own processing, and the platform is obliged to disclose it.

5. Retention, deletion and evidence

Retention should be set by category: account information for the life of the account, logs for the statutory period, user input for the shortest period necessary to deliver the service, training samples managed as de-identified datasets. The deletion mechanism must actually operate, covering user-initiated deletion, clean-up after account closure and synchronous deletion at processors.

Evidence is the other half of the work. Regulatory inspections typically request the version and effective date of the policy, records of user consent, screenshots of the separate-consent implementation, processor agreements and logs of deletion operations. Without these, a complete policy is still difficult to prove as performed.

6. Six common drafting defects

1. Purpose expressed as improving the service experience, corresponding to no specific activity;
2. User input omitted from the categories, leaving the core processing activity undisclosed;
3. Training use reduced to a sentence about improving the service, with no opt-out;
4. Third-party sharing described only as partners, with no categories or purposes;
5. Automated decision-making with no appeal or human review;
6. Rights exercised through a single mailbox that nobody monitors.

7. Checklist

The real threshold for a privacy policy is not drafting but consistency with the data flow. When the product changes its model, its provider or its SDKs, the policy must follow; otherwise the more complete the document, the further it drifts from reality.

Related reading: user agreements for AI products, five data-compliance risks for AI companies, GDPR and cross-border data transfers, new duties for large personal information processors, and the data compliance service page.

Last updated: 25 June 2026.