Law 21.719 comes fully into effect on December 1, 2026, requiring all organizations processing personal data in Chile to be able to demonstrate how they protect it. There is a mechanism that many data teams have yet to incorporate into their compliance strategy: when data is anonymized irreversibly, it ceases to be personal data and is no longer within the scope of the law.
This distinction matters because information like RUT, name, address, or customer history doesn't reside only in the production database. It is also replicated in test environments, backups, spreadsheets exported for analysis, and datasets used to train models. Each of these copies falls under Law 21.719.
What is Law 21.719 and since when is it applicable in Chile?
Law 21.719 was published in the Official Gazette on December 13, 2024, modernizing the old Law 19.628, which had been in force since the late 1990s and had long been overtaken by technological reality. Its full application will begin on December 1, 2026, so organizations have a limited period to adapt.
The main change is institutional. For the first time, Chile will have a Personal Data Protection Agency, an autonomous public entity with powers to conduct inspections, initiate proceedings, order the suspension of processing, and apply sanctions. The Agency will also maintain a National Register of Sanctions, so any non-compliance will be visible to customers, partners, and competitors.
The numbers show the extent of the risk. The most serious offenses can lead to fines up to 20,000 UTM—about 1.4 billion pesos—and, in case of repeat offenses, the penalty can scale up to 4% of the company's annual income. The law provides a transition period for smaller businesses during the first twelve months, with warnings instead of fines, but this gradual approach does not apply to all organizations nor does it remain in effect over time.
What Law 21.719 requires from personal data handlers
Law 21.719 organizes data processing around principles aligned with the international standard of the European GDPR: lawfulness, purpose, proportionality, data quality, and accountability. The last of these, the principle of proactive accountability, is the most demanding operationally, because it's no longer enough to comply: the organization must be able to prove it.
In practice, these principles translate into specific obligations. Data subjects can exercise their rights of access, rectification, cancellation, and objection, as well as the portability of their data. In the event of a security breach, the organization has a short window—72 hours in the cases defined by the law—to notify the Agency. Sensitive data, which includes health, socioeconomic status, biometric data, and ethnic origin, receive heightened protection and require explicit consent, except for specific circumstances.
For a CISO or engineering manager, the main challenge does not lie in the production database, which usually has mature controls, but in all the environments surrounding it.
Personal data in test environments: the blind spot of Law 21.719
It's important to identify where a copy of the customer table with real RUT exists today. Usually, there are several: in the QA environment where releases are validated, in staging, in the dataset the analytics team uses to train a model, and in backups stored in the cloud. Each of these copies constitutes data processing under Law 21.719 and increases the organization's exposure.
The root of the problem is well known: for teams to test software thoroughly, they need data that behaves like real data, with representative volumes, intact relationships between tables, and edge cases that only appear in production. Copying the production database to test environments is precisely what the new law penalizes. The issue isn’t intent, but the fact that real data outside of production rarely receives the same level of oversight as the production environment.
At this point, anonymization stops being just a legal technicality and becomes an architectural decision.
Anonymization vs. pseudonymization under Law 21.719
This distinction determines whether an organization is inside or outside the scope of the law, so it's important to clarify.
Anonymizing means irreversibly breaking the link between the data and the person. When done properly, the process is not reversible: no actor can reidentify the subject. When data reaches this state, it is no longer considered personal data and therefore falls outside the scope of Law 21.719.
Pseudonymization works differently. It separates identifying information and stores it elsewhere with safeguards, so the data loses identity at first glance, but reidentification is still possible for those who have the key. For this reason, pseudonymized data remains personal data under the law, with all associated obligations. It's a good security measure, not a way out of the regime.
The practical consequence is clear. If data is anonymized before it reaches a test environment, that environment stops handling personal data: the risk of sanctions is reduced, regulatory exposure is limited, and the compliance burden is simplified. Pseudonymization, on the other hand, lowers the risk but keeps the organization within the regulatory perimeter.
There is a nuance that many teams overlook: poor anonymization is worse than no anonymization, as it gives a false sense of security. Replacing the RUT with a value that can be calculated, leaving the birthdate unchanged, or keeping links that allow identity to be inferred are mistakes a forensic expert can easily reverse. Effective anonymization needs to be designed, validated, and tested for reidentification.
How to comply with Law 21.719 with data anonymization, step by step
There is no single automatic solution; there is a process—and that process can be automated. The following steps provide compliance that the organization can later demonstrate to the Agency.
1. Discover and classify where sensitive data resides
You can’t protect what you don’t know. The first step is to connect to databases and identify which fields hold personal information: RUT, names, emails, addresses, health data, and socioeconomic information. In the Chilean context, RUT is the critical identifier, as it links most records and shows up in tables where it might not be expected. Automatic data classification by risk level lets you prioritize what to protect first and how.
2. Define anonymization policies by data type
Not all fields require the same treatment. A name is replaced by a coherent synthetic one; a RUT by a valid but fictitious one; a date is shifted within a range that keeps business logic intact. The best practice is to define these rules once as reusable policies and apply them consistently to every environment. Improvised, field-by-field configuration is the leading cause of residual leakage.
3. Anonymize while preserving referential integrity
This is where most projects fail. If you anonymize the RUT in the customer table but do not update the orders, payments, and tickets tables that reference it, the relationships break and the dataset becomes useless for testing. Anonymization must keep table and system relationships intact, so the data still makes sense to the development team, even if it no longer pertains to any real person. Without referential integrity, anonymizing is as good as rendering the test environment useless.
4. Automate delivery in the pipelines
Manual anonymization by each team is not a reliable control. It has to be integrated into the data provisioning flow: whenever a QA environment is refreshed or a new one is spun up, the data should already be transformed. Integrating this into CI/CD pipelines makes protection the default behavior, not the exception.
5. Generate auditable evidence
The proactive accountability principle requires organizations to prove what actions were taken, when, and on which data. Each anonymization process should generate a log: what fields were transformed, with which rules, in which environment, and under which authorization. This traceability is what lets you face a compliance inspection with documentary proof.
Common anonymization mistakes (and how to avoid them)
Anonymizing without a method is a risk in itself. Three scenarios are common in audits. The first is reidentification by correlation: one field is anonymized, but others remain that, when combined, point back to the person. The second is the forgotten data: the production environment is protected, but old backups and datasets used for models are not reviewed. The third is confusing pseudonymization with anonymization and mistakenly assuming the organization is out of scope.
None of these errors can be fixed on the fly; all require a process that discovers, transforms, and validates systematically.
What will determine your exposure to Law 21.719 in December 2026?
Law 21.719 doesn’t evaluate the quality of written policies, but rather the organization’s ability to show that real data doesn’t circulate in uncontrolled environments. Irreversible anonymization, applied before data leaves production and backed by referential integrity and traceability, makes the difference between an inspection resolved with documentary evidence and one that ends up in the National Register of Sanctions.
Comply with Law 21.719 with Gigantics, without slowing down your teams
Gigantics is the data security platform that automates the entire cycle: it uses AI to discover and classify sensitive information in databases, applies irreversible anonymization while preserving referential integrity between tables and systems, and delivers secure, representative datasets to non-production environments directly from CI/CD pipelines. Every transformation is logged with auditable evidence—precisely the support the Agency will require.
QA and development teams continue to work with data that behaves like the real thing, while the organization eliminates personal data from uncontrolled environments.