Data Compliance and Privacy
AI data problems are not a privacy-policy edit. Training-data provenance, multi-party flows through aggregated APIs, memorised personal data resurfacing in outputs — each needs a mechanism, not a sentence.
The difference is not the volume of data — it is that the data does something
Traditional internet compliance asks what you collected and whether you said so. An AI product asks harder questions: where the training data came from and whether you may use it; what happens to personal data when a request passes through an aggregator, a model provider and an inference service; whether the model will reproduce personal information it saw in training.
None of these is resolved by rewriting a privacy policy. They are resolved by mapping the data path, assigning a lawful basis at each hop, and building records that survive a technical review. Regulators have moved from principle-based guidance to mechanism-based examination: the question is no longer whether you have a policy, but whether your described processing matches what the system does.
What we do
- Data inventory and mapping: collection channels, categories, storage locations, flow paths, third-party sources and API call chains
- Lawful basis architecture: consent, contract necessity and other bases assigned per purpose, with separate consent where the law requires it
- Policy and notice set: privacy policy, service terms, cookie notice, all reconciled against the actual data flow
- Personal information impact assessment (PIA): mandatory for sensitive data, automated decision-making, entrustment, third-party provision and cross-border transfer
- Processing agreements: DPAs with every processor, security assessment of API counterparts
- Cross-border mechanisms: security assessment, certification or standard contract, chosen against current thresholds
What is different for an AI company
- Training data has three provenance types, each with a different legal basis. Self-collected, purchased and publicly scraped carry different authorisation and notice requirements; scraping also turns on platform terms, anti-scraping measures and robots protocols. Without a provenance schedule, no later assessment has a starting point.
- De-identification is not anonymisation. Personal information used for training may remain identifiable in combination even after direct identifiers are removed; the position taken for provision and transfer must be the same.
- Models can memorise training data. Output-side filtering and memorisation testing — particularly for face, medical and financial data — are design questions, not post-launch operations.
- Calling an overseas API can itself be a cross-border transfer. Sending user input to a model service abroad is providing personal information overseas, requiring the corresponding path; many teams assume “nothing deployed abroad” means no transfer.
- Classification and grading set the downstream obligations. Identifying important data, personal-information impact assessment and transfer assessment all build on the classification result — classify first, then sequence the compliance actions.
Typical situations
Situation 1: The policy says no sharing, the architecture shares
The privacy policy states that personal data is not provided to third parties. In practice each request is forwarded to an upstream model API. That is a provision to a third party, and it requires its own basis and disclosure. The gap between the document and the system is the finding.
Our approach: rewrite the notice from the data map rather than from the previous template, and then change whichever of the two is wrong. In most cases both need work: the disclosure is inaccurate, and the consent architecture does not support the flow it now describes.
Situation 2: The consent chain breaks at the second hop
Users consent to the privacy policy at registration. Sensitive personal information, however, needs separate consent; automated decision-making needs a transparency notice and an opt-out; and withdrawal must actually stop processing. A single checkbox covers none of these.
Our approach: build consent as a set of purpose-specific records with a verifiable trail — what was shown, when, for which purpose, and what happened on withdrawal — so that the answer to a regulator’s question is a log entry, not an assurance.
Situation 3: Aggregated APIs, and nobody owns the middle of the chain
The platform calls provider A, which routes to provider B. The user’s data crosses three entities. Who is controller, who is processor, what basis applies at each hop, and where are the records? This is the least examined area in AI SaaS, and the one most likely to be examined.
Our approach: document the chain end to end, allocate roles contractually rather than by assumption, and require each counterpart to evidence its own security measures. Where a hop cannot be documented, the architecture is the problem, and it is cheaper to change the architecture than to defend the gap.
Process and deliverables
| Stage | Work | Deliverables |
|---|---|---|
| 1 | Data asset mapping and risk identification | Data map + risk register |
| 2 | Policy and consent architecture | Revised policy set + consent flow design |
| 3 | Agreements and third-party management | DPA pack + counterpart assessment |
| 4 | PIA and cross-border mechanism where triggered | PIA report + transfer filing package |
| Ongoing | Release-by-release compliance review | Change impact notes + updated records |
AI-specific deliverables
- Training-data legitimacy file: the three source categories with the legal basis, authorisation evidence and cleaning record for each.
- Model-output and user-input note: whether output counts as processing, and whether input may be reused for training.
Frequently asked
Do we need a PIA for a product that only uses an upstream model API? Usually yes. Entrustment processing, third-party provision and automated decision-making each trigger an assessment, and calling an upstream API typically involves at least one of the three. The assessment is short if the architecture is clean; it is where the architecture gets fixed if it is not.
Is training on user content permitted? Only with a basis that covers it. Consent obtained for “providing the service” does not extend to model training. Training use must be disclosed, separately grounded, and — where personal information is involved — supported by de-identification and purpose limitation. An opt-out path is the practical minimum.
Can the model reproduce personal data it was trained on? It can, which is why memorisation is a compliance issue and not only a technical one. Mitigation combines data minimisation at ingestion, de-identification, output filtering, and a documented response process for individual rights requests that reach generated content.
When does cross-border transfer require a filing? Depends on volume and sensitivity under the current thresholds. Three mechanisms exist — security assessment, certification, and standard contract filing — and the threshold rules determine which applies. The mistake to avoid is designing the transfer first and choosing the mechanism afterwards.
Legal basis
- Personal Information Protection Law: lawful bases (Art. 13), separate consent (Arts. 14, 23, 29), notification (Art. 17), entrusted processing (Art. 21), automated decision-making (Art. 24), sensitive personal information (Art. 28), security measures (Art. 51), impact assessment (Arts. 55-56), individual rights (Arts. 44-50), cross-border provision (Art. 38)
- Data Security Law: data classification and security management systems
- Regulations on the Administration of Network Data Security (effective 2025): processing obligations across the data lifecycle
- Provisions on Promoting and Regulating Cross-Border Data Flows (2024): thresholds for assessment, certification and standard contract
- Measures for the Standard Contract for Export of Personal Information: filing procedure
- Interim Measures for the Management of Generative AI Services: training data and personal information handling