Chile Ley 19.628 Data Protection Mapping

Maps the hosted ai-agent-eval-harness-healthtech demo against Ley 19.628 (Chilean Law on Protection of Private Life / Protección de la Vida Privada), as amended, and the GDPR-aligned modernisation introduced by Ley 21.719. It describes how the demo’s two data planes are treated and what a broader production deployment would add.

Read alongside the Demo Privacy Notice, the regulatory posture, and the HIPAA readiness assessment.

Legislative Context

Ley 19.628 regulates the treatment of personal data in Chile. Key milestones include the 2018 constitutional recognition of data protection as a fundamental right (Ley 21.096) and the 2024 GDPR-aligned modernisation (Ley 21.719, published 13 December 2024 and effective 1 December 2026), which strengthens consent requirements, data subject rights, and cross-border transfer provisions and creates the Personal Data Protection Agency (APDP). The law applies to the treatment of personal data when the responsible party (data controller) is domiciled in Chile or when the processing uses means located in Chilean territory.

This demo is squarely within scope: the controller is established in Chile.

The Two Data Planes

The hosted demo processes data in two distinct planes. Ley 19.628 applies differently to each, so they are assessed separately throughout this page.

Plane	What it holds	Personal data?	Where it is processed
(a) Conversational plane (your chat with the agent)	The turn text you type. Direct identifiers (email, phone, government IDs, card numbers) are redacted before the turn is used for anything other than producing the reply; names are deliberately retained in-thread for personalization. No conversation record is kept; raw IP and User-Agent are not stored. The demo is designed for synthetic input and forbids real patient data / PHI.	Pseudonymized operational data. The corpus is synthetic by design, but retained in-thread names mean this plane is best treated as pseudonymized personal data, not fully anonymous.	Transmitted to named third-party AI sub-processors in the United States on every turn (cross-border transfer).
(b) Contact / funnel plane (your demo-key request)	The email, name, and organization you submit, plus your stated purpose and consent record.	Yes — real personal data.	Stored in Supabase (managed PostgreSQL, US East region — us-east-2, Ohio); the app runs on Google Cloud Run (US region). This PII is not forwarded to the chat sub-processors.

The remainder of this page assesses Ley 19.628 obligations against these two planes as the demo operates today, not against a hypothetical synthetic-only system.

Controller, Applicable Law, and Lawful Basis

Controller: Waldemar Szemat, established in Chile. Privacy and data-subject contact: waldemar@szemat.pro.
Applicable law: Ley 19.628 (Chile) is the primary governing law, because the controller is established in Chile. GDPR applies for data subjects in the EU/EEA; CCPA/CPRA applies for California residents.
Lawful basis: explicit, granular consent, recorded before processing. For the contact / funnel plane, the demo-key request gate refuses to persist any PII unless the subject has accepted the privacy terms (the GOVR-05 lawful-basis gate; the consent flag, the notice version, and a server-stamped consent timestamp are stored with the row). Marketing contact is a separate, un-bundled, optional consent that is never required to use the demo and may be withdrawn at any time. The controller does not rely on legitimate interest for this personal data.

Personal Data Principles Assessment

Ley 19.628 as currently in force sets out definitions in Art. 2 rather than a GDPR-style catalogue of principles; the catalogue below follows the GDPR-aligned framework introduced by Ley 21.719 (effective 1 December 2026), read together with the obligations already in force under Ley 19.628.

Principle (Ley 21.719)	Current state — as the demo operates today	Production path (broader deployment)
Lawfulness	Contact-plane PII is processed on explicit granular consent recorded before the write (GOVR-05 gate; no consent, no row). The conversational plane operates on redacted, pseudonymized input.	Documented lawful basis for every processing activity; periodic legal-basis review.
Purpose limitation	Contact PII is used only to process the demo-key request and, on a separate opt-in, to discuss a paid pilot. The operator-side lead-triage hint is advisory only and never gates access.	Explicit purpose binding per field; purpose-limitation enforced in system design.
Data minimisation	Only email, name, organization, and purpose are collected on the contact plane. On the conversational plane, no conversation record is kept at all, direct identifiers are redacted before the turn is used for anything other than producing the reply, and telemetry excludes user text.	Periodic review of collected fields; deletion of data no longer needed.
Accuracy	Subjects can correct their record by contacting the controller; contact data is self-submitted at request time.	Self-service correction mechanism; data-quality review procedures.
Storage limitation	Defined retention applies (see the Retention section below): opted-in contacts are retained until deletion is requested; non-opted-in contacts are capped at 12 months; redacted chat records are deletable on request.	Automated retention enforcement and secure deletion at expiry.
Security	Direct-identifier redaction at input/output; the raw email is never duplicated for linkage (a salted SHA-256 `subject_email_hash` links a subject across tables); DSR routes are key-scoped and IDOR-safe; verification codes are stored only as salted hashes; secrets are kept out of the repository; HTTPS on the hosted demo.	Technical and organisational measures appropriate to the risk; encryption at rest, formal access controls, breach-notification procedures; execution of vendor DPAs.
Transparency	The Demo Privacy Notice is presented before collection and is linked from the consent gate; the consent gate records which notice version the subject saw.	Layered notices; clear language on purposes, retention, and rights (already substantially met).

Data Subject Rights

The demo implements data-subject rights in-session (key-scoped, IDOR-safe) and via an operator email path. A client-supplied identifier is never honoured; the caller is resolved from their demo key.

Right (Ley 19.628, Art. 12)	Current state — as the demo operates today	Notes
Access	The subject can retrieve their stored rows in-session (`GET /data/export`), or request them from the controller by email.	Export is complete-or-refused (never a silent partial).
Rectification	Handled by contacting waldemar@szemat.pro; contact data is self-submitted and can be re-requested.	At the current demo scale the email path is the accepted rectification channel; a self-service in-session rectification control is deferred to a broader production deployment.
Cancellation (deletion)	The subject can erase all of their data in-session (`DELETE /data`), which cascades across the owned tables and the lead-capture row; an operator runbook and script cover the out-of-band path (for example, an expired key).	A revoked-for-abuse key is refused deletion so it cannot wipe its own abuse trail; access, export, and opt-out survive revocation.
Blocking / opt-out	The subject can stop future interaction-logging in-session (`POST /opt-out`) without ending the session; marketing consent can be withdrawn.	Ley 19.628 Art. 12 confers “blocking” (temporary suspension).
Portability (Ley 21.719)	The in-session export returns the subject’s rows in a structured JSON payload.	Portability becomes an explicit statutory right under Ley 21.719 (effective 1 December 2026).

Ley 21.719 (effective 1 December 2026) adds a right to object (opposition) to processing on legitimate grounds and a right to data portability, and it creates the Personal Data Protection Agency (APDP) as Chile’s data protection authority. Under Ley 19.628 as currently in force, Art. 12 confers access, rectification, cancellation (deletion), and blocking; it establishes no data protection authority.

Sensitive Data Provisions

Ley 19.628 provides enhanced protections for sensitive personal data (health data, biometric data, among others). Under Art. 10, sensitive data may only be processed where the law authorises it, where the data subject consents, or where the data is necessary for the determination or granting of health benefits (“otorgamiento de beneficios de salud”) owed to the data subjects.

Aspect	Current state — as the demo operates today	Production path
Health data	No real health data is collected. All clinical content is synthetic; the terms of use forbid entering real patient data or PHI, and direct identifiers in chat are redacted.	Explicit consent for health-data processing; purpose limitation to the healthcare context; enhanced security; access restricted to authorised personnel.
Contact PII sensitivity	Email, name, and organization are ordinary personal data, not special-category / sensitive data, so the Art. 10 sensitive-data regime is not triggered by the contact plane.	If future fields were sensitive, Art. 10 conditions would apply.
Biometric data	No biometric data is collected or processed (voice features, when enabled, are disclosed separately and are off by default).	Explicit consent; purpose limitation; enhanced security; deletion when purpose is achieved.
Consent management	Granular, un-bundled consent is recorded before processing (GOVR-05); the marketing channel is a separate optional opt-in; consent version and timestamp are stored.	Consent-management platform; withdrawal mechanism; consent audit trail (substantially met today at demo scale).

Cross-Border Data Transfer

Aspect	Current state — as the demo operates today	Production path
Conversational plane -> AI sub-processors	Chat input is sent to named LLM, embedding, and reranking sub-processors in the United States on every turn. This is a cross-border transfer of redacted input content. Voyage AI carries a train-by-default posture; the org-admin opt-out is not enabled for this demo.	Transfer assessment and appropriate safeguards; enable the Voyage opt-out and execute vendor DPAs (a precondition for operating on real data). The transfer relies on the data subject’s explicit, informed consent to the cross-border transfer to the United States, disclosed in the Demo Privacy Notice and recorded at the consent gate before any processing; the vendor DPAs are executed as a supplementary safeguard.
Contact / funnel plane -> Supabase	Contact PII is stored in Supabase (managed PostgreSQL, US East region — us-east-2, Ohio); the app runs on Google Cloud Run (US region). This PII is not forwarded to the chat sub-processors.	The cross-border transfer of contact PII to the United States relies on the data subject’s explicit consent recorded at the demo-key request gate; the Supabase region (us-east-2, Ohio) is reflected in the sub-processor disclosure.
Telemetry	Only redacted span attributes are exported to the live telemetry sink (Langfuse Cloud); pre-redaction chat text is never sent to it.	Execute the telemetry-provider DPA; confirm retention window and hosting region before operating on real data.

Retention

Contact details submitted with a demo-key request, where the subject gave the separate marketing opt-in, are retained indefinitely until deletion is requested (“indefinite-until-deletion”). Consented contacts are not auto-deleted; deletion on request is always honored.
Contact details submitted without the marketing opt-in are retained only as long as needed to process the request, up to a ceiling of 12 months, after which they are deletable.
Redacted chat records are operational demo data and are deletable on request via the data-subject-rights controls.

What Full Production Would Add

The demo already meets the core Ley 19.628 obligations for the personal data it processes (lawful basis, notice, DSR, retention). A broader production deployment that processed real personal or health data at scale would additionally require:

Data controller registration with the Personal Data Protection Agency (APDP), the supervisory authority created by Ley 21.719 (operative from 1 December 2026), if required for the specific processing activity. At the current demo scale this registration is not required; it would be reassessed for a broader production deployment processing real personal or health data at scale.
A Data Protection Officer or representative, if required for the scale and nature of processing. A DPO or representative is not required for the controller at the current demo scale and nature of processing; it would be reassessed for a broader production deployment.
Executed vendor DPAs (including the Voyage AI opt-out and a telemetry-provider DPA) before operating on real data.
Formal breach-notification procedures and periodic security assessments.
Enhanced sensitive-data controls (Art. 10) if the system ever processes real health data, including explicit written consent and purpose limitation to healthcare management.
Automated retention enforcement (the self-enforcing deletion cron is deferred post-launch; the launch posture is the documented runbook plus the operator deletion script).