Thoughts on the new GDPR right-to-erasure rules? Does it make migrating data harder?

The GDPR's right to erasure (Article 17) introduces a significant operational constraint for data pipelines, and this becomes acutely visible during CRM migrations. While the rule itself is clear, its implementation transforms a one-time data transfer into managing an ongoing, stateful obligation. The primary difficulty shifts from simple data mapping to maintaining a verifiable chain of data provenance and deletion across systems.

From an MLOps perspective, this complicates migrations in two key ways:

* **Data Lineage Becomes Critical:** You can no longer treat a migrated customer record as a simple row in a new table. You must preserve, and be able to query, the link between the record in the old system (now decommissioned) and its counterpart in the new one. If a deletion request arrives post-migration for data originating in the old CRM, your new system must know how to fulfill it.
* **Soft Deletes and Audit Trails Are Not Optional:** Hard deletions are risky. A practical implementation requires immutable audit logs. For example, your migration script and subsequent application logic must handle erasure requests as flagged deletions, not physical `DROP` commands.

Consider a simplified example of a user table post-migration. You need additional metadata to manage erasure requests.

```sql
-- Example schema addition for managing erasure in a post-migration CRM
CREATE TABLE customers (
id UUID PRIMARY KEY,
email VARCHAR(255),
-- ... other fields
migrated_from_source_id VARCHAR(255), -- Original ID from legacy CRM
source_system VARCHAR(50), -- e.g., 'legacy_crm_v2'
is_erased BOOLEAN DEFAULT FALSE,
erasure_request_id UUID, -- Links to audit log
erased_at TIMESTAMP
);

-- An erasure operation becomes an update, not a delete
UPDATE customers
SET is_erased = TRUE,
erasure_request_id = 'request_uuid_here',
erased_at = NOW()
WHERE email = 'requested_user@example.com';
```

The real challenge is ensuring all downstream services—like recommendation models, vector databases for customer support embeddings, or analytics dashboards—respect this `is_erased` flag. Your data contracts and model inference pipelines must filter out erased persons. This adds complexity to validation steps during the cutover and requires thorough testing of the erasure workflow before going live.

Does anyone have experience architecting this? Specifically, how did you validate that erasure requests properly cascaded to associated systems like marketing automation platforms or ML feature stores?