If you process personal data in Chile, there are two questions your organization will need to answer with documents starting December 2026: where is your record of processing activities? and how do you manage the risk of each processing activity? That month, Law 21.719 — Chile's new personal data protection law, aligned with Europe's GDPR — reaches full effect and creates the Personal Data Protection Agency. The fine print of the sanctions regime and its deadlines is worth validating with Chilean legal counsel; what leaves no room for doubt is the date, and the fact that the law asks for evidence, not promises.
We already published the regional overview: why Chile and Brazil are turning data governance into a requirement, and what the cost of non-compliance looks like. This article goes one level deeper: which concrete artifacts the Chilean law demands, and how a data governance program produces them and — more importantly — keeps them alive.
The law doesn't ask for intentions: it asks for artifacts
The heart of Law 21.719 is the principle of proactive responsibility (accountability): treating data well is not enough — you must be able to demonstrate it documentally. In practice, that demonstration concentrates on three artifacts.
1. The RAT — Record of Processing Activities (Chile's equivalent of GDPR's RoPA). A living inventory of every personal-data processing activity in the organization. The official guide from Chile's Digital Government Secretariat (RAT v1.0, published November 2025) defines its structure in concrete fields: activity · controller or processor · data category · universe of data subjects · purpose · legal basis · intended recipients · retention period · data source. The guide is written for public bodies, but its structure is today the practical reference for any controller that must demonstrate proactive responsibility.
2. Risk analysis and management. For each processing activity, assess probability × impact on the rights of data subjects and assign a risk level (very high, high, medium, low) from a catalog of factors: data types, processing scope, categories of data subjects, technical factors. The typical output is a risk matrix or heat map. An honest nuance: Chile has not yet published an official risk-management guide equivalent to the RAT one; in practice, the methodology of Spain's data protection agency (AEPD), aligned with GDPR, is used as the reference — a reasonable approach that should nonetheless be validated with local legal counsel.
3. The DPIA — data protection impact assessment. When a processing activity is high-risk, the law requires a documented assessment justifying the measures adopted and the residual risk accepted. Exactly which processing activities trigger it is a detail we recommend validating with Chilean legal counsel — but the logic is clear: the DPIA stands on the two previous artifacts.
There are further obligations (data subject rights, security measures, breach management), but these three artifacts concentrate the biggest gap between what organizations have today and what they will need to show.
Why a static document isn't enough
The obvious temptation is to treat this as a documentation project: commission the RAT, fill in the matrix during a workshop, file the three PDFs, and declare yourself compliant.
The problem is one of physics, not willpower. All three artifacts describe systems that change every week: a new SaaS gets contracted, a team adds a field to the CRM, marketing launches a campaign with a different data source, someone copies a table with national IDs into an analytics environment. March's RAT is fiction by September. And a record that contradicts the reality of your systems doesn't demonstrate management — it demonstrates the opposite.
That's why organizations that have already been through reviews under GDPR-style regimes discover that the problem was never writing the document: it was keeping it true. And that isn't solved with more documentation consulting; it's solved from within the data operation itself.
How a governance program produces each artifact
A data governance program — structured with frameworks like DAMA-DMBOK and DCAM — builds exactly the capabilities these artifacts are views of. (If the concept is new to you, we explain it from scratch here.) The mapping is direct.
The RAT is a view of your data catalog. Walk through the fields: the data category comes from inventory and classification (PII tagging across all systems, not just the CRM); the controller comes from ownership (every data asset with an owner who has a name and a role); purpose, legal basis, recipients, retention, and source come from the business metadata — glossary, properties, lifecycle policies — that the program documents asset by asset. When that foundation exists and is fed automatically — with your cloud's native catalog or an open-source one like OpenMetadata; the tool matters less than the program — the RAT stops being a project and becomes a report: a view assembled from living metadata.
The risk matrix consumes classification, quality, and lineage. Assessing probability × impact requires knowing what data types exist (classification), how many data subjects the processing reaches (inventory), who accesses it and under which policies (ownership and controls), and where the data flows (lineage). Without those inputs, risk scoring is an opinion in a workshop. With them, it's a repeatable method: when a system changes, the input changes, and the matrix gets recalculated instead of going stale.
The DPIA stands on the previous two. An impact assessment justifies measures against identified risks: the RAT says what the processing is, the matrix says why it's high-risk, lineage shows the real data flows, and data quality evidences the controls that actually operate. The program doesn't write the DPIA for you — that's an exercise of process and legal judgment — but it turns weeks of data archaeology into days of analysis, with the evidence ready for the annex.
The key word in all three cases is sustainable: the program includes the processes — periodic review, onboarding of new processing activities, data owners accountable for keeping their part current — that keep the artifacts true between one audit and the next. That's what a framework like DAMA-DMBOK contributes: not a tool, but the discipline of culture, organization, processes, and technology operating together.
What technology doesn't solve on its own
We wouldn't be serious if we claimed this comes pre-installed. Three things no software solves by itself:
- Ownership is an organizational decision. Appointing data owners, giving them mandate and time, and sustaining a committee that arbitrates — that's culture and organization, not configuration.
- The legal basis is legal judgment. Which lawful basis applies to each processing activity, what triggers a mandatory DPIA, how to interpret deadlines and penalties in detail — your legal counsel defines that, not a platform. Our job is making sure that when the lawyer asks, the evidence exists and can be trusted.
- Process outweighs software. A catalog without a program produces empty evidence: dashboards nobody updates and a RAT as fictional as the spreadsheet it replaced.
A well-designed program integrates these three layers from day one — which is why we speak of a program, not an implementation.
December 2026 is closer than it looks
Building inventory, ownership, classification, and lineage takes months, not weeks — and the date won't move. The right question today isn't "which tool do I buy?" but "what do I already have governed, and what is orphaned?"
Our data maturity assessment answers exactly that: an honest diagnosis of where your organization stands against what Law 21.719 will demand — which artifacts you can produce today, which you can't, and the roadmap to close the gap with time to spare.
Sources: Record of Processing Activities — Wikiguías, Digital Government Secretariat