The problem: Why this matters now
Your AI training pipeline just received its first GDPR erasure request. An individual wants their data removed from your model's training set. Your engineering team asks: do you have to rebuild the model?
The answer depends on the legal basis you documented when processing that data. If you relied on consent and can't point to another valid ground, you're required to honor the request under Article 17. If you claimed legitimate interest, you need to demonstrate that your interest is "overriding" or comply with the deletion. The Italian DPA (Garante Per La Protezione Dei Dati Personali) has clarified that for publicly sourced AI training data, consent or legitimate interest are typically the only plausible lawful grounds.
Most organizations discover this exposure only after receiving their first request. By then, you're operating under time pressure with incomplete documentation. This guide helps you build a defensible erasure protocol before that happens.
What you need before starting
Required documentation:
- Your Article 30 Record of Processing Activities for AI training, including the specific legal basis (Article 6(1)(a) for consent, Article 6(1)(f) for legitimate interest)
- Data source inventory: where each training dataset originated, when it was collected, and under what terms
- Legitimate Interest Assessment (LIA) if processing under Article 6(1)(f), documenting why your interest outweighs individual rights
- Consent records if processing under Article 6(1)(a), showing specific, informed, freely given consent for AI training
Technical prerequisites:
- Data lineage tracking that maps individual records to specific training runs
- Version control for training datasets with timestamps
- Access to model training logs showing which data versions were used in which model iterations
- A test environment to validate data removal without affecting production
Team access:
- Legal or DPO sign-off authority for erasure decisions
- Engineering access to training data storage and model artifacts
- Documentation access to privacy notices and consent flows active when data was collected
If you're missing the LIA or can't trace which legal basis you used, stop here and complete that documentation first. You can't evaluate an erasure request without knowing which Article 17 exception might apply.
Step-by-step implementation
Step 1: Classify the request within 72 hours
When an erasure request arrives, determine which Article 17(1) ground applies:
- (a) Data no longer necessary: Rare for AI training; you'd need to prove the model is retired
- (b) Consent withdrawn: If Article 6(1)(a) was your sole basis, you must comply unless another exception in Article 17(3) applies
- (c) Objection to legitimate interest: If processed under Article 6(1)(f), the requester can object and you must comply unless you demonstrate overriding grounds
- (d) Unlawful processing: If you never had a valid legal basis, you must delete immediately
- (e) Legal obligation: If another EU or Member State law requires deletion, you must comply
- (f) Child's data from information society services: If the data came from a child under 16, you must delete
Document your classification in your DSAR tracking system.
Step 2: Check Article 17(3) exceptions
Before proceeding with deletion, verify whether an exception applies:
- Article 17(3)(b): Do you have a legal obligation to retain this data that supersedes the erasure right?
- Article 17(3)(e): Do you need this data to establish, exercise, or defend a legal claim?
If yes, document the specific obligation or claim and prepare your response declining the request. If no exception applies, proceed to Step 3.
Step 3: Scope the technical deletion
Identify every location where the individual's data exists:
SELECT training_run_id, dataset_version, model_artifact
FROM ai_training_lineage
WHERE source_record_id IN (
SELECT record_id FROM source_data
WHERE individual_id = '[requester_id]'
);
You need to remove data from:
- Raw source datasets (S3 buckets, data lakes, etc.)
- Preprocessed/cleaned training sets
- Cached or staged data used for model serving
- Any backup or archival copies unless covered by Article 17(3)(b)
You do not need to retrain models already in production unless the processing was unlawful from the start. The GDPR requires deletion of personal information, not reversal of every algorithmic consequence.
Step 4: Execute deletion with audit trail
For each identified location:
aws s3 rm s3://training-data-bucket/dataset-v2/records/[record_id] \
--profile ai-training-admin
echo "$(date -Iseconds),erasure_request_[ticket_id],[record_id],deleted" \
>> /var/log/gdpr-erasure-audit.log
Create deletion certificates showing:
- What was deleted (record IDs, not the personal data itself)
- When it was deleted (timestamps)
- Who authorized and executed the deletion
- Which systems were affected
Step 5: Respond to the requester within one month
Your response must include:
- Confirmation that deletion is complete, or
- Explanation of which Article 17(3) exception applies and why you're declining, or
- Request for extension (up to two additional months if the request is complex)
If you're declining based on overriding legitimate interest under Article 17(1)(c), your response must reference your LIA and explain specifically why your interest outweighs the individual's rights in this case.
Validation: How to verify it works
Immediate checks:
Run your data lineage query again to confirm zero results:
SELECT COUNT(*) FROM source_data
WHERE individual_id = '[requester_id]';
-- Expected result: 0
Verify backup systems don't restore deleted records:
- Check backup retention policies
- Confirm deleted records are flagged as "do not restore" if backups are retained under Article 17(3)(b)
Audit trail review:
Your deletion log should contain:
- One entry per deleted record
- Matching timestamps across all systems
- Sign-off from both technical and legal teams
Response quality check:
Before sending your response, verify it:
- Cites the specific Article 17 paragraph that applies
- References your legal basis documentation
- Includes no personal data in the response itself
- Explains appeal rights if you're declining
Maintenance: Ongoing tasks
Monthly:
- Review erasure request volume and patterns
- Update your LIA if processing purposes change
- Audit whether new data sources have clear legal basis documentation
Quarterly:
- Test your data lineage queries against a sample record
- Verify deletion scripts still target all relevant storage locations
- Review Article 17(3) exception documentation for continued validity
Annually:
- Reassess your legitimate interest grounds for AI training
- Update privacy notices if processing purposes have evolved
- Train engineering teams on erasure protocol changes
Before each new training run:
Document the legal basis for any new data sources. If relying on legitimate interest, update your LIA to cover the new processing. If relying on consent, verify the consent was specific to AI training and not just general data collection.
The Italian DPA's guidance makes clear that "publicly available" isn't itself a legal basis. You need consent or demonstrable legitimate interest. Build that documentation into your data acquisition workflow, not your incident response process.
