The impact assessment isn't written by a lawyer: it's run by your development team
Article 15 ter asks four questions, and three of them can only be answered honestly by someone who can open the database schema. What the law requires, what artifacts the team should produce, and why the burden of proof changes the calculation.
The data protection impact assessment is being sold in Chile as a legal deliverable. A document, with its cover page, its methodology and its signature.
Read Article 15 ter carefully and you'll find something else. The law asks four questions, and three of them can only be answered honestly by someone who can open the database schema and check who queries what.
This is not an argument against lawyers. It's an argument about who holds the data needed to answer.
What Article 15 ter actually requires
The obligation appears when processing may produce "a high risk to the rights of data subjects", considering its nature, scope, context, the technology used, or its purposes. In that case you have to assess before operations begin — not during, and not after.
And an assessment is always required in four cases, which the law lists explicitly:
a) Systematic and exhaustive evaluation of personal aspects based on automated processing or decisions, such as profiling, producing significant legal effects.
b) Mass or large-scale data processing.
c) Processing involving systematic observation or monitoring of a publicly accessible area.
d) Processing of sensitive and specially protected data, under the exceptions to consent.
On content, the same article tasks the Agencia de Protección de Datos Personales with publishing an indicative list of processing operations that require an assessment, along with the minimum guidance for carrying one out, covering at least the description of the operations, their purpose, the necessity and proportionality assessment, the risk assessment, and the mitigation measures.
Those criteria don't exist yet
Several articles in circulation present that list as though it were a requirement already in force. It isn't. The law delegates the criteria to the Agency, and the Agency hasn't published them. What is settled is the floor: those five elements are the minimum the guidance will have to cover.
A note on what to call it, because you'll find this exercise written three different ways depending on who's publishing: AIPD, EIPD and DPIA, the last one inherited from the European GDPR. The law uses none of the three. Article 15 ter calls it, simply, a personal data protection impact assessment. That's how I write it here, or just "the assessment" — an acronym each consultancy defines its own way helps nobody understand what we're talking about.
One last point that gets misread often: consulting the Agency is optional. The article says controllers "may consult" when the result shows high risk. There is no prior authorisation to wait for.
The four questions, translated
Take the five elements from the third paragraph and turn them into operational questions. The change of language is revealing.
"Description of the processing operations" is not answered with the diagram from the sales proposal. It's answered with the real flow: which endpoint receives the data, which tables it lands in, which jobs move it, which external services it travels to, which logs it gets written into along the way, and how many backups it lives in. That inventory almost never matches what the business side believes the system does. The gap between the two is usually the most valuable finding of the whole exercise.
"Necessity and proportionality" is, in engineering terms, a question about columns. Why does that field exist? Who reads it? When was the last time anyone queried it? Article 14 quáter reinforces the point from the other side: by default, only data that is "specific and strictly necessary" may be processed, considering the number of data points collected, the extent of the processing, the retention period and their accessibility. Four variables, all four measurable in a real system.
"Risk assessment" is threat modelling under another name. What happens if this table leaks, who is exposed and to what. It isn't risk to the company: the article speaks of risk to the rights of the data subject, which is a different thing and usually a worse one.
"Mitigation measures" is the only one of the four people answer easily, and also where the trap is. We'll come back to that in a moment.
The four cases, read as an engineer
Case (a) doesn't require artificial intelligence. A delinquency score calculated with three rules in a SQL CASE is a systematic evaluation based on automated processing. If someone's service gets cut off or a benefit denied on the basis of that number, there is a significant legal effect. The complexity of the algorithm is not the criterion; the consequence for the person is.
Case (b), "mass or large-scale data processing", is the most ambiguous of the four and the one most people dismiss too quickly. The law sets no number, and the Agency's indicative list doesn't exist yet. In the meantime, the sensible criterion isn't how many records you hold but what proportion of a population you cover and at what granularity. A school with 900 students has few records in absolute terms and practically every data point of the school life of 900 minors. That looks a lot more like "large scale" than a list of 50,000 newsletter addresses.
Case (c) appears wherever there are cameras. If your system integrates CCTV, biometric access control, or any record of presence in a space the public enters, it lands here without much argument.
Case (d) is the one that activates most vertical systems. Health data, biometrics, origin, affiliations. A school nursing module, an injury record at a gym, an allergy log at a dining hall: all of that is sensitive data, even when the system as a whole doesn't feel like a "health" system.
The part almost nobody mentions: the burden of proof
Here, for me, is the most relevant point in the whole law for a technical team — and it's in a different article.
Article 14 quinquies, after listing the required security measures, closes with this: in the event of an incident, and in any judicial or administrative dispute, it falls to the controller to demonstrate "the existence and the operation" of the security measures adopted.
Existence and operation are two different things
Existence is demonstrated with a document: here is the encryption policy, here is the access control. Operation is not. It's demonstrated with evidence that the control actually worked over the period in question — logs with sufficient retention, access records, dated restore tests, and the results of the regular verifications the same article requires.
A team that documents its controls but cannot show they worked has done half the work, and it's the cheap half.
Article 14 quinquies is fairly explicit about what's expected, and its list reads like a backlog: pseudonymisation and encryption of personal data; the ability to guarantee ongoing confidentiality, integrity, availability and resilience; the ability to restore access to data quickly after an incident; and a process for regularly verifying and evaluating the effectiveness of those measures.
None of those four is solved by writing a document.
The artifacts the team should produce
If engineering runs the assessment, its deliverables look very little like a report. In practice they are these, and nearly all of them are code or configuration:
A data inventory generated from the schema, not transcribed by hand. A script that walks the tables and classifies columns by data category is more reliable than a spreadsheet, and it can be re-run when the schema changes. A spreadsheet goes stale in the first sprint.
A real access matrix, derived from the roles and permissions that exist in the system, set against who should be able to see what. The difference between those two columns is the finding.
Retention implemented as a job, not as a sentence in a policy. If the policy says data is deleted after five years and nothing deletes it, the policy is a signed statement of non-compliance.
Restore evidence, dated. A backup that has never been restored isn't a backup, it's an intention. The article asks for the ability to restore quickly; that gets tested, not declared.
Access logs for sensitive data, with a defined retention period. It's what lets you answer "who saw this and when" when the question arrives, and it arrives at the worst possible moment.
The breach register required by Article 14 sexies. Worth reading closely if you work with minors: beyond reporting to the Agency without undue delay, you must notify data subjects when the breach affects sensitive data, data of children under fourteen, or economic, financial, banking or commercial data. A school system falls into two of those three categories at once.
Where it fits in the development cycle
The temptation is to treat it as a preliminary phase: do it once, file it, move on to building.
It doesn't work that way, and the reason is in the text. Article 14 quáter speaks of applying appropriate measures by design "prior to and during the processing". During. The assessment describes a system that will keep changing, and every meaningful change makes it stale.
Treating it as a recurring control is more honest and considerably cheaper. A handful of events should trigger a review: a new data category in the model, a new integration that pulls data out of the system, a change in who can access what, and any feature that makes automated decisions about people. If those four cases are written into the team's definition of done, the assessment stays alive on its own.
The mistake you'll see most often
Running the assessment against the documented system instead of the one in production.
Every company with a few years of operation has differences between the two. The integration that was thrown together for one client and stayed. The report someone scheduled to arrive by email every Monday with more columns than necessary. The copy of the database in the test environment with real data, which was temporary three years ago. The endpoint left open for a migration that finished long ago.
None of those things is in the diagram. All of them are in the real data flow, and they are exactly the kind of finding the assessment exists to surface.
That's why the exercise is worth doing even for those not obliged to do it. The assessment is the institutional excuse to review, on paid time, something nobody ever reviews.
What to do this week
If you're starting out, three concrete things, in this order.
First, work out whether you fall under any of the four cases in Article 15 ter. That's a one-hour conversation with someone who knows the system, not a project.
Second, run the inventory from the schema before writing a single line of the document. It's cheap and it will change what you write: in most cases, data nobody remembered storing turns up.
Third, make the list of what you couldn't demonstrate today. Not what's left to implement — what is implemented but you couldn't prove worked last month. That list tends to be the shortest to write and the most uncomfortable to read, and it's the one that will serve you best the day someone asks.
The entry into force is still December 1, 2026. There's a postponement bill that reached the Senate on September 1 and, as of this writing, has not been voted on. Planning around it is a bad idea — we go into that in what to do before December and why the postponement won't save you.
At id3a we build vertical software for markets where regulation is part of the product, not an annex. If you're assessing a system and want a second technical opinion on its exposure, let's talk.
This article describes technical requirements arising from Ley 21.719 from an engineering perspective. It is not legal advice; for the legal characterisation of a specific processing operation, consult a specialised lawyer.
Sources: Ley 21.719, Articles 14 ter, 14 quáter, 14 quinquies, 14 sexies, 15 ter, 49 and 50, per the text in force published by the Biblioteca del Congreso Nacional (bcn.cl).
Enjoyed this article?
Find out how we can help you bring these solutions into your business.