A practical approach to the right to erasure: more than just hitting delete
Under Art. 7 of Law 21.719 (which amends Law 19.628), everyone has the right to request the erasure of their personal data. Say it's December 1, 2026, the law takes effect and one of your users exercises the right to erasure. How would you handle it?
In large organizations, deleting one user's personal data is not trivial. There are almost certainly distributed systems, microservices and multiple data sources in play.
Nishant Bhajaria, author of Data Privacy, uses the image below in one of his courses to show how data travels once it has been collected
It shows how the reactive way organizations roll out privacy tooling costs them effectiveness, because by then the collected data has already been passed to other systems: analytics services, third parties, data lakes and so on.
So deleting that one piece of data, which today could be stored in several different sources, is a “cacho”, as we would say in Chile: a real problem.
You could try to handle it manually, asking each team or Data Owner (whoever is accountable for the data) to delete the user in their systems and send you the corresponding evidence.
The teams in charge will be terrified of doing it. Nothing is harder than running a DELETE.
You'll agree that this option doesn't scale over time; it would put an open-ended operational load on every team involved (though it does help the organization learn how to proceed).
You could then build a (micro) service with the connectivity and the permissioned users it needs to reach every database and run the DELETE operation directly.
From a software architecture standpoint, that creates improper coupling: the rest of the microservices would lose control over the business rules that govern their own data. It also makes maintenance more expensive and raises the risk of errors.
So what do we do? In this article we'll go over a few more definitions to understand the deletion problem better, and look at a solution proposed by Nishant B.
What deleting data really means
In my experience, there are two valid mechanisms for meeting what the Law requires, each with different technical implications:
1. Physical or logical deletion
Physical deletion means destroying the data for good. It's the most direct route, but it isn't always viable in complex systems.
Logical deletion, on the other hand, means marking the data as deleted (with flags like is_deleted, for example). This approach is common in systems that need traceability or recovery. The problem is that, legally, this on its own may not be enough. That's why you also have to apply an anonymization technique to stay compliant.
2. Anonymization
Under the law, anonymized data is data that cannot be linked to a natural person and where the process is irreversible.
That means:
No key can exist that would let anyone re-identify the user
No combinations of data can be left that would let anyone infer the identity
No auxiliary information can exist that would let anyone rebuild the link
For example:
Removing the RUT but leaving date of birth, municipality and gender can still allow re-identification
Simple hashing can be reversible in practice. Even if you turn a value (a RUT, say) into something that looks unrecognizable, someone could reconstruct the original by trying known combinations.
Keeping lookup tables — lists that link the original value to its transformed version — breaks anonymization completely, because they lead straight back to the person's identity.
There are different anonymization techniques; what matters is reducing the risks of identification.
The image below sums up how the various anonymization techniques are not foolproof against every risk
What the risk levels mean:
Yes: the technique does not effectively mitigate the risk and has to be combined with others to improve protection.
Sometimes: the technique can mitigate the risk in certain circumstances or up to a point. The specific context where the technique will be applied matters.
No: the technique effectively mitigates the associated risk, offering robust protection against that specific type of risk.
Anonymization techniques aren't foolproof, but there may be cases where they do meet what the law requires. We'll have more clarity once the Agency weighs in.
In many cases, techniques such as anonymization or logical deletion are used to meet this goal, as long as the data no longer makes it possible to identify a person.
Where the data has to be deleted
Personal data is usually spread across many places:
Relational and non-relational databases
File systems (documents, images, exports)
Messaging systems and logs
Email
Chats
Third-party systems
Others
It's the organization's job to identify them and delete the data in all of them.
How much to delete
The right to erasure doesn't always mean wiping all the information. In practice, there are at least two scenarios:
Partial deletion: the user asks to delete certain specific attributes.
Full deletion: all the information associated with the data subject is deleted.
What can actually be deleted, though, doesn't depend only on the user's request. It also depends on the organization's legal and regulatory obligations. Certain data — debt records or accounting information, for example — may have to be kept by law.
That means your systems have to be able to delete while taking into account both the data subject's request and the legal restrictions that apply.
Deletion order
Data can reappear through replication or syncing, so the recommended order is:
Source systems
Replicated or derived systems
This order minimizes inconsistencies and keeps deleted data from being regenerated. Keep in mind that source systems or replicated systems are often third parties (vendors)
With those definitions in place, let's get to the core design of the proposed deletion system. The idea is inspired by the book Data Privacy: A runbook for engineers by Nishant Bhajaria, chapter 7.
Destroyer
The Destroyer, in its most basic form, is a central service that handles deleting personal data from different information sources when a user files an erasure request. It does this by orchestrating the deletion services of the different systems.
The Destroyer is the service in charge of:
Orchestrating deletion across multiple systems
Keeping the process traceable
Running upfront validations
Guaranteeing consistency
It doesn't delete data itself. It coordinates the systems that do.
Before deleting any data, you have to check whether there is a legal reason to keep it. That includes:
Legal retention (active products)
Regulatory obligations (reporting information to institutions)
Court proceedings (Ley papito corazón)
For this we bring in a dedicated service (Holden, in the image) that centralizes these checks.
The flow is simple:
If there's a legal reason to keep it → it isn't deleted
If there isn't → you can proceed
This step is critical to avoid breaking the law by deleting something you shouldn't.
Once you've confirmed the user isn't subject to legal retention, the deletion mechanism has to be started.
To make that work, the service owners for each system, who are responsible for administering the databases that hold the personal data, have to register their deletion services in the Destroyer, along with the personal data to be deleted.
Deletion services
Each system has to build 3 services that the Destroyer will need in order to run the deletion:
GET_TEST_USER: Returns a user_id for testing deletion. The user it returns must have enough data to exercise the whole deletion flow.
Note: after testing, consider running an “un-delete” on the data generated by that user.
DELETE: The main service that carries out the deletion. It ranges from complete deletion to applying some anonymization technique.
IS_DELETED: Determines whether a user's data was deleted or not.
The test flow should be:
Generate a test user with GET_TEST_USER
Check that it isn't deleted with IS_DELETED -> false
Run the deletion with DELETE
Confirm that it was deleted with IS_DELETED -> true
This has to be repeated for every system registered in the Destroyer, so let's look at how to organize the deletion
Deletion plan
When the Destroyer receives a deletion request, it has to generate a plan based on what the user asked for. A full deletion is not the same as a partial one (deleting just the email address, for example).
That's why it matters to have a solid registration contract for the systems in the Destroyer (here, “contract” means a technical definition of how a system works: what data it handles and how other systems can interact with it)
At a minimum, this contract has to include:
What personal data each system stores
The URLs of the three services defined above
The authentication method
Which systems are sources and which replicate data (several systems can replicate from the same source)
Whether deletion is synchronous or asynchronous (some systems won't be able to delete in real time and will answer later)
Whether it requires manual approval
With this information, the deletion plan is built.
The plan runs the data deletion in order, level by level, from level 0 up to level N:
Level 0 holds the source systems (where the data originates)
Level 1 holds the systems that replicate data from level 0 and, in turn, feed others
And so on up to level N
This order matters to keep the information consistent and to prevent deleted data from reappearing through replication processes. On top of that, all the systems on the same level can run their deletion in parallel, which makes the process more efficient.
Before wrapping up this post, here's how I imagine you could display the execution of a deletion for a user's erasure request
All of the above doesn't just let you carry out data deletion correctly. It also leaves traceable evidence of what was done, when and in which systems.
That's key, because in the event of an enforcement action your organization has to be able to show how it puts the right to erasure into practice.
In that situation, the Agencia de Protección de Datos Personales would probably be surprised to get an audit trail of that quality from your organization.
Final thoughts
The right to erasure is, at its core, an architecture problem. It forces you to answer hard questions: where the data actually lives, how it spreads and how to guarantee it is effectively deleted.
Implementing it properly means thinking about orchestration, distributed consistency and contracts between systems.
In other words, it isn't an isolated legal requirement. It's a chance to design systems that are more aware, more controlled and more responsible with the data they manage.
The proposed solution won't always be viable right away, but it sets a clear target to move toward. Adopting it, even partially or step by step, is already a big leap in how an organization understands and manages its data and the right to erasure.
