Skip to content

Chile Ley 19.628 Data Protection Mapping

Maps the ai-agent-eval-harness-healthtech reference implementation against Ley 19.628 (Chilean Law on Protection of Private Life / Protección de la Vida Privada), as amended through 2024. This document evaluates which data protection principles the reference implementation observes and what a Chilean deployment would require.

Read alongside the regulatory posture and the HIPAA readiness assessment.

Ley 19.628 regulates the treatment of personal data in Chile. Key amendments include the 2018 constitutional recognition of data protection as a fundamental right (Ley 21.096) and the 2024 GDPR-aligned modernisation (Ley 21.719), plus subsequent updates strengthening consent requirements, data subject rights, and cross-border transfer provisions. 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.

Principle (Ley 19.628)Current StateProduction Path
Lawfulness (Art. 2)No personal data collected. The system operates on 100% synthetic data. No real individuals’ data is processed at any point.Lawful basis for processing (consent, contractual necessity, legal obligation, or legitimate interest); documented legal basis for each processing activity
Purpose limitation (Art. 2)Not applicable — no personal dataClear, specific, and explicit purpose for each data processing activity; purpose limitation enforced in system design
Data minimisation (Art. 2)The system collects minimal runtime input: the user’s conversational turn. PII is redacted before processing. No data is persisted beyond process lifetime (in-memory checkpointer).Collect only data necessary for the stated purpose; periodic review of data collected; deletion of data no longer needed
Accuracy (Art. 2)Not applicable — no personal dataMechanisms for data subjects to update or correct their data; data quality review procedures
Storage limitation (Art. 2)No persistent storage of user data; conversations held in memory and lost on process restartDefined retention periods; deletion procedures; data subject access and deletion request handling
Security (Art. 2)PII redaction at input/output; OpenTelemetry audit trail; no secrets in the repository (automated secret scanning); HTTPS on the hosted demoTechnical and organisational security measures appropriate to the risk; encryption, access controls, breach notification procedures
Transparency (Art. 2)Demo disclaimer on every response; public model card; published regulatory posture documents scopePrivacy notice accessible before data collection; clear language about data processing purposes, retention, and rights
Right (Ley 19.628)Current StateProduction Path
Access (Art. 12)Not applicable — no personal data storedMechanism for data subjects to request and receive confirmation of whether their data is being processed
Rectification (Art. 12)Not applicableMechanism for data subjects to correct inaccurate data
Deletion (Art. 12)Not applicable — no persistent dataMechanism for data subjects to request deletion of their data; deletion verification
Opposition (Art. 12)Not applicableMechanism for data subjects to object to processing on legitimate grounds
Portability (implied by 2018 amendment)Not applicableMechanism for data subjects to receive their data in a structured, machine-readable format

Ley 19.628 provides enhanced protections for sensitive personal data (health data, biometric data, among others). Under the law, sensitive data may only be processed with explicit written consent or when necessary for medical prevention, diagnosis, or healthcare management.

AspectCurrent StateProduction Path
Health dataNo real health data. All clinical content is synthetic. The agent discusses medication adherence with synthetic personas only.Explicit consent for health data processing; purpose limitation to the healthcare context; enhanced security measures; access restricted to authorised healthcare personnel
Biometric dataNo biometric data collected or processedExplicit consent; purpose limitation; enhanced security; deletion when purpose is achieved
Consent managementNot applicable — no personal dataConsent management platform; granular consent options; consent withdrawal mechanism; consent audit trail
AspectCurrent StateProduction Path
LLM provider data transferUser input is sent to LLM providers (OpenAI, Anthropic, Groq) over HTTPS. No personal data is present in the input (synthetic-only reference implementation).Assessment of LLM provider jurisdictions; adequacy determination or appropriate safeguards for cross-border transfer; contractual provisions ensuring equivalent protection levels
Observability data transferTelemetry spans are sent to Langfuse Cloud and Phoenix. User message text is explicitly excluded from spans (privacy invariant).Assessment of observability provider data residency; data processing agreements; exclusion of personal data from telemetry

The reference implementation handles no personal data and is therefore not subject to Ley 19.628 obligations. However, the design incorporates several data-protection-aligned practices:

  • No personal data: The system operates on 100% synthetic data. No real individual’s data enters the reference implementation, demo, or eval pipeline.
  • PII redaction: The redaction layer detects and redacts identifiers relevant to Chilean users (RUT, Chilean phone number formats), alongside US and Brazilian identifiers, at both input and output stages.
  • No persistent storage: The demo uses an in-memory checkpointer; no user data persists beyond the process lifetime.
  • Privacy invariant: User message text never enters telemetry spans, logs, or trace attributes. This is a hard constraint enforced by a dedicated unit test.
  • es-419 locale support: The eval corpus includes a dedicated es-419 slice, and refusal templates support Latin-American Spanish, demonstrating awareness of LATAM users.

The PII redaction patterns for Chilean identifiers (RUT format, Chilean phone number prefixes) and the locale-aware refusal templates that support es-419 responses are part of the deterministic guardrail layer.

Deploying this architecture for Chilean users in a context that processes personal data would require:

  1. Data controller registration: Registration with the Chilean data protection authority (if required for the specific processing activity)
  2. Consent management: Explicit consent for personal data collection and processing; granular consent options; consent withdrawal mechanism; consent audit trail
  3. Privacy notice: Clear, accessible privacy notice in Spanish describing data processing purposes, retention periods, and data subject rights
  4. Data Protection Officer (DPO): Appointment of a DPO or equivalent role responsible for data protection compliance
  5. Cross-border transfer assessment: Evaluation of LLM provider data residency; contractual safeguards for data transferred outside Chile; adequacy determination or equivalent protection mechanisms
  6. Health data provisions: If the system processes real health data, compliance with the enhanced protections for sensitive data under Ley 19.628, including explicit written consent and purpose limitation to healthcare management
  7. Data subject rights infrastructure: Mechanisms for access, rectification, deletion, opposition, and portability requests; response within statutory timeframes
  8. Security measures: Technical and organisational measures appropriate to the sensitivity of the data processed; regular security assessments; breach notification procedures