Data Minimization in the AI Era: Do Not Collect, Do Not Retain, Do Not Overlap

Article 5 of the GDPR sets data minimization in paragraph 1(c), storage limitation in paragraph 1(e), and accountability in paragraph 2.[1] Minimization is not about arbitrarily removing columns, but about being able to explain the necessity of holding data for each purpose, subject, granularity, and period.

For AI cases, we must not use 'for future retraining' as an indefinite justification; instead, we compare assumed tasks, required performance, alternative aggregated/pseudonymized/on-device processing, and re-acquisition costs. We use aggregation for evaluations where individual-level data is unnecessary, and do not collect free-text fields if they are not needed. When the purpose changes, we do not automatically extend based on initial consent or legal basis, but conduct a re-review.

Necessity is recorded by comparing whether the same purpose can be met with coarser granularity, shorter retention, or aggregated values, before debating the presence or absence of columns. We do not justify retention solely on the explanation that performance improves slightly; the business owner must demonstrate whether that improvement changes the usage decision. If the purpose changes, we do not reuse the previous necessity evaluation, but reconfirm the legal basis and alternatives.[1]

Carlini et al. queried GPT-2 XL via black-box access and confirmed at least 604 unique memorized examples from 600,000 generated samples. The classification table also reported examples containing real names of non-news individuals and contact information.[2] Even if derived from public web sources, if specific contacts or contexts are reproduced from model outputs, the public nature at the time of collection does not explain the risk of reuse.

This count is not the leakage rate for all large language models, but a demonstration for a specific model and attack. Nevertheless, it provides grounds for requiring pre-learning PII detection, access restrictions, exclusion of secret information, extraction testing per model, output filters, and model stoppage and retraining during incidents. Model weights are managed as assets that can retain information, not as artifacts unrelated to the original data.

Kandpal et al. reported that sequences appearing 10 times in training data are generated on average about 1,000 times more likely than those appearing only once, demonstrating that deduplication weakens privacy attacks such as membership inference.[3] In large-scale crawling, reposts, templates, and backups may cause the same secrets to be learned repeatedly.

Deduplication is not for volume savings, but for risk reduction control. We detect not only exact matches but also approximate duplicates at the document, paragraph, and sequence levels, and track reposts across sources. However, unique personal information, rare expressions, and leaks in logs or prompts remain. We do not substitute deduplication for anonymization or formal privacy guarantees, but layer it with collection minimization and access control.

The cause of high extraction rates may be not only model memory, but also the overlap of the same document from multiple paths. By comparing the difference in generation of secret-like sequences or membership inference between the version with approximate duplicates removed and the original version, we can delineate the scope where deduplication measures are effective.[3] Even if the difference shrinks, we cannot shift the risk to PII or operational logs that exist independently, so we retain collection stoppage and access control.

The following are recommendations for implementing data minimization. Instead of merely guessing in meetings whether an item is useful, create conditions for removing the item, lowering granularity, shortening the period, or placing it in aggregation, and pre-compare whether the same decision-making procedure meets the required standard. This serves not as a substitute for legal judgment, but as a technical document for explaining necessity.

As a hypothetical example, if replacing an exact birth date with a decade does not change the target selection, the explanation for retaining date precision for that purpose becomes weak. On the other hand, if only a few cases change the decision, rather than retaining all data and deciding immediately, we try a two-step procedure to see if the same purpose can be met by requesting additional confirmation for those cases. We also count the confirmation load after replacement.

We do not decide comparisons based on average performance alone. We list the types of errors, affected subjects, frequency of imposing additional burden on individuals, and possibility of re-acquisition for each purpose. Even if the reduction plan does not meet the lower limit, we do not treat necessity as proven for all purposes, but record the reason limited to that decision, granularity, and retention period in the ledger. We also decide the lower-limit judge in advance.

We propose operations that mandate end conditions at the time of creation, rather than finding and deleting derivatives afterward. For development copies, evaluation samples, search indexes, and log extractions, we issue loan records specifying purpose, responsible party, source data version, storage location, deadline, and renewability, making them unusable until re-approval after the deadline. We also assign loan IDs.

Extension of the loan period is not a procedure that simply copies the original purpose. We individually reconfirm usage records, remaining judgment, fewer alternatives, and the possibility of reflecting deletion requests. Copies with unknown owners or deadlines are moved to isolation candidates without assuming future utility benefits, and are closed after confirming processing in use. The number of extensions is also recorded.

In closure confirmation, we test not only file deletion notifications, but also index references, derivative outputs, recreation jobs, and re-appearance after backup restoration using samples. If residuals are found, they are returned to the loan record as a deletion failure path. Whether model response is needed is judged by a different responsible party, and closure is not considered complete with just copy closure.

• ABLATION RECORD: Retain removed items, lowered granularity, shortened periods, and judgment differences by purpose
• DATA LEASE: Fix purpose, responsible party, source version, storage location, deadline, and renewability of derivatives at issuance
• RESIDUAL TEST: Test whether samples reappear in indexes, derivative outputs, recreation jobs, and after restoration
• CLOSEOUT: Close the loan in states of deleted, isolated, pending extension review, and pending model judgment

The data ledger records the source of acquisition, purpose, legal basis, necessary columns and granularity, deduplication processing, use in learning/evaluation/search, prompt and log storage, access subjects, retention period, and deletion method. Including development copies, feature stores, vector indexes, and backups, we find paths where derivatives remain even if the original is deleted.

Metrics track not only total volume, but also data with unknown purposes, expired periods, duplication rates, overly broad permissions, un-deletable derivatives, and extraction test results. Minimization is not a one-time inventory, but is repeated for each new data source, model update, and purpose addition. Since legal compliance varies by region and context, we link the technical ledger to expert judgment and explanations to individuals.

Deletion is audited not by the number of applications received, but by whether derivatives were also deleted. We select target records from the ledger and conduct an end-to-end test of confirming the location of originals, development copies, search indexes, logs, backups, and retraining-waiting data, and obtaining deletion evidence. If extraction from the model is suspected, we do not complete the process with output blocking alone, but escalate judgments including stopping affected versions or retraining to the model owner.[2]

• COLLECT: Review purpose, columns, granularity, and alternatives before collection
• TRAIN: Record PII exclusion, exact/approximate deduplication, and data versions
• SERVE: Separate permissions and retention for prompts, outputs, logs, and search indexes
• DELETE: Track originals, derivatives, backups, and model responses
• Data Owner: Explain necessity and retention period by purpose
• Infrastructure Responsible Party: Leave execution evidence of deduplication and derivative deletion
• Model Owner: Judge stoppage and retraining for extraction signs