Pre-training data compliance has been widely discussed; fine-tuning has not. The reason is probably volume: a few thousand to a few hundred thousand records looks immaterial. The reality is the opposite. Fine-tuning data is often taken straight from business systems — customer conversations, support tickets, contract text, internal knowledge bases — with concentrated sources and high personal information density, so a problem spreads further than with scraped public data.
Article 7 of the Interim Measures for the Administration of Generative Artificial Intelligence Services sets four requirements for training data processing: use data and base models with lawful provenance; where intellectual property is involved, do not infringe rights held by others; where personal information is involved, obtain consent or satisfy another statutory basis; and take effective measures to improve data quality. These apply to fine-tuning regardless of volume.
Four sources and their authorisation chains
| Source | Key points in the chain | Common defect |
|---|---|---|
| Public scraping | Comply with robots and site terms, circumvent no technical measures, exclude personal information and protected works | Scraping beyond public pages, or no archived copy of the terms at the time of capture |
| Purchased data | Contract expressly permits model training, with warranties on title and traceability | Contract only says “data services”, with no training purpose |
| User data | Notice and consent cover the training purpose, or another lawful basis; separate consent for sensitive data | Covered only by “service improvement”, with no mention of training |
| Open-source datasets | Check licence type, purpose limits and attribution, retain the version | Research or non-commercial licence used for commercial training |
Among the four, user data is the hardest to repair. Most privacy notices were drafted before training was contemplated, and obtaining consent after the fact is costly with low coverage. A workable approach is to split the scenarios: new collection states the training purpose in the notice; historical data is assessed for use after removing personal information, or restricted to non-identifying statistics.
Three tests for personal information
First, whether personal information exists. Names, phone numbers, identity numbers, addresses, account identifiers and combinations that allow indirect identification are all personal information. Customer service transcripts are especially dense.
Second, whether a lawful basis exists. Training is a new purpose and generally requires notice and consent or another statutory basis. Relying on necessity for contract performance rarely works, because training is not required to deliver the service to that user.
Third, whether separate consent is needed. Sensitive personal information requires separate consent; biometric, health, financial account and location data in the corpus must be assessed item by item.
De-identification deserves emphasis. Text with names and numbers removed remains personal information with reduced identifiability; only anonymisation falls outside the Personal Information Protection Law, and it must reach a standard where identification and re-identification are impossible. Treating de-identification as anonymisation is the most common error.
Two layers of copyright
Reproduction and adaptation. Including a work in the corpus involves reproduction; rewriting, continuation and style transfer during fine-tuning may involve adaptation. Both need a rights basis unless a permitted use applies.
The limits of permitted use. The enumerated exceptions in the Copyright Law are narrow and generally do not cover commercial model training. A workable approach is to screen the corpus by rights status: public domain, licensed, and unknown provenance to be removed.
Open-source licences are a second thread. Code corpora require checking copyleft and commercial restrictions; text datasets require checking whether commercial use and redistribution are permitted. Where attribution is required, it should be reflected in model documentation.
Cross-border transfer is often missed
Two scenarios arise: training on overseas compute, and annotation by overseas teams. The first transfers domestic personal information to overseas servers, which is an outbound transfer; the second provides data to an overseas annotator, which is also external provision.
Both require choosing a route first: security assessment, standard contract or certification, according to volume and data type. Annotation also involves entrusted processing, so the contract should set purpose, duration, safeguards and deletion.
An auditable record list
A compliance review is in substance a test of whether each data batch can be traced. Six record types are worth keeping:
- Provenance register: batch number, source type, acquisition date, volume, person responsible
- Authorisation documents: purchase contract clauses, user consent texts, open-source licence copies
- Capture records: archived robots and site terms at the time of capture
- Cleaning logs: deduplication, de-identification and removal of sensitive items
- Version records: correspondence between corpus and model versions
- Assessment records: personal information impact assessment and rights screening conclusions
The six need not be elaborate; they need to be sustainable. Rebuilding documentation for every fine-tuning run quickly becomes a formality.
How to review efficiently
Sample first, then scale. Draw a sample from the corpus, classify by source, and test whether each chain is complete. Sampling locates the main gaps within a week.
High risk first, long tail after. Customer conversations, contract text, and health or financial corpora come first; public news and general encyclopaedic material is comparatively lower risk.
Repair the chain before the text. Where authorisation is missing, fix it through contract clauses or notices first; where it cannot be fixed, assess removal, which is usually cheaper than explaining later.
Related reading: AI data compliance risk checklist, Privacy policy for AI products, Personal information protection impact assessment, Data compliance service
Frequently Asked Questions↑ Back to article
Fine-tuning uses little data. Does it still need a compliance review?
Yes. Fine-tuning usually draws on business data with concentrated sources and high personal information density, so problems spread further. The review focuses on provenance and authorisation rather than volume.
Can scraped public data be used for training?
Not automatically. Check whether robots protocols and site terms were respected, whether technical protections were circumvented, and whether personal information or protected works are included. Publicly accessible does not mean licensed for use.
What authorisation is needed to fine-tune on customer data?
At minimum a contractual basis expressly permitting model training, and for personal information a lawful basis built on notice and consent. Necessity for service provision generally does not support training as a new purpose.
Can de-identified data be used freely?
No. De-identified information remains personal information with reduced identifiability. Only anonymisation falls outside the regime, and anonymisation must reach a standard where re-identification is impossible, which is hard to evidence.
What should we check in open-source datasets?
The licence type and purpose restrictions, and retain the dataset version and acquisition record. Research-only or non-commercial licences cannot support commercial training.
What materials should the review produce?
A provenance register, authorisation documents or contract clauses, cleaning and deduplication logs, privacy notices, and version records. The aim is to trace every data batch back to its source.