Mapeamento de proteção de dados da Ley 19.628 do Chile
Mapeia a demo hospedada
ai-agent-eval-harness-healthtechfrente à Ley 19.628 (Lei chilena sobre Proteção da Vida Privada / Protección de la Vida Privada), com suas alterações, e a modernização alinhada ao GDPR introduzida pela Ley 21.719. Descreve como os dois planos de dados da demo são tratados e o que um deployment de produção mais amplo acrescentaria.Leia em conjunto com o Aviso de Privacidade da Demo, a postura regulatória e a avaliação de prontidão para HIPAA.
Contexto legislativo
Seção intitulada “Contexto legislativo”A Ley 19.628 regula o tratamento de dados pessoais no Chile. Os marcos principais incluem o reconhecimento constitucional da proteção de dados em 2018 (Ley 21.096) e a modernização alinhada ao GDPR de 2024 (Ley 21.719, publicada em 13 de dezembro de 2024 e vigente a partir de 1º de dezembro de 2026), que reforça os requisitos de consentimento, os direitos dos titulares e as disposições sobre transferência transfronteiriça, e cria a Agência de Proteção de Dados Pessoais (APDP). A lei se aplica ao tratamento de dados pessoais quando o responsável (controlador de dados) tem domicílio no Chile ou quando o tratamento utiliza meios localizados em território chileno.
Esta demo está claramente dentro do escopo: o controlador está estabelecido no Chile.
Os dois planos de dados
Seção intitulada “Os dois planos de dados”A demo hospedada trata dados em dois planos distintos. A Ley 19.628 se aplica de forma diferente a cada um, por isso eles são avaliados separadamente ao longo desta página.
| Plano | O que contém | Dados pessoais? | Onde é tratado |
|---|---|---|---|
| (a) Plano conversacional (seu chat com o agente) | O texto do turno que você digita. Identificadores diretos (email, telefone, documentos governamentais, números de cartão) são redigidos antes que o turno seja usado para qualquer coisa que não seja produzir a resposta; os nomes são mantidos deliberadamente dentro do tópico para personalização. Nenhum registro da conversa é mantido; endereços IP e User-Agent brutos não são armazenados. A demo é projetada para entradas sintéticas e proíbe dados reais de pacientes / PHI. | Dados operacionais pseudonimizados. O corpus é sintético por design, mas os nomes mantidos no tópico fazem com que este plano seja mais bem tratado como dados pessoais pseudonimizados, não como dados plenamente anônimos. | Transmitido a subprocessadores de IA terceiros nomeados nos Estados Unidos a cada turno (transferência transfronteiriça). |
| (b) Plano de contato / funil (sua solicitação de chave) | O email, o nome e a organização que você envia, além de sua finalidade declarada e o registro de consentimento. | Sim — dados pessoais reais. | Armazenado no Supabase (PostgreSQL gerenciado, região US East — us-east-2, Ohio); a aplicação roda no Google Cloud Run (região dos EUA). Essa PII não é encaminhada aos subprocessadores de chat. |
O restante desta página avalia as obrigações da Ley 19.628 frente a estes dois planos tal como a demo opera hoje, não frente a um sistema hipotético somente sintético.
Controlador, lei aplicável e base legal
Seção intitulada “Controlador, lei aplicável e base legal”- Controlador: Waldemar Szemat, estabelecido no Chile. Contato de privacidade e de direitos do titular: waldemar@szemat.pro.
- Lei aplicável: a Ley 19.628 (Chile) é a lei regente principal, porque o controlador está estabelecido no Chile. O GDPR se aplica aos titulares na UE/EEE; a CCPA/CPRA se aplica aos residentes da Califórnia.
- Base legal: consentimento explícito e granular, registrado antes do tratamento. Para o plano de contato / funil, o gate da solicitação de chave se recusa a persistir qualquer PII a menos que o titular tenha aceitado os termos de privacidade (o gate de base legal GOVR-05; o indicador de consentimento, a versão do aviso e um carimbo de tempo de consentimento gerado no servidor são armazenados com a linha). O contato de marketing é um consentimento separado, não agrupado e opcional que nunca é obrigatório para usar a demo e pode ser retirado a qualquer momento. O controlador não se baseia no interesse legítimo para esses dados pessoais.
Avaliação dos princípios de dados pessoais
Seção intitulada “Avaliação dos princípios de dados pessoais”A Ley 19.628 em vigor contém definições em seu Art. 2 em vez de um catálogo de princípios no estilo do GDPR; o catálogo a seguir corresponde ao marco alinhado ao GDPR introduzido pela Ley 21.719 (vigente a partir de 1º de dezembro de 2026), lido em conjunto com as obrigações que a Ley 19.628 já impõe.
| Princípio (Ley 21.719) | Estado atual — tal como a demo opera hoje | Caminho até produção (deployment mais amplo) |
|---|---|---|
| Licitude | A PII do plano de contato é tratada com base em consentimento explícito e granular registrado antes da gravação (gate GOVR-05; sem consentimento, sem linha). O plano conversacional opera com entradas redigidas e pseudonimizadas. | Base legal documentada para cada atividade de tratamento; revisão periódica da base legal. |
| Limitação de finalidade | A PII de contato é usada apenas para processar a solicitação de chave e, com um consentimento separado, para conversar sobre um piloto pago. A dica de triagem de leads do lado do operador é meramente indicativa e nunca condiciona o acesso. | Vinculação explícita de finalidade por campo; limitação de finalidade aplicada no design do sistema. |
| Minimização de dados | Apenas email, nome, organização e finalidade são coletados no plano de contato. No plano conversacional, nenhum registro da conversa é mantido, os identificadores diretos são redigidos antes que o turno seja usado para qualquer coisa que não seja produzir a resposta e a telemetria exclui o texto do usuário. | Revisão periódica dos campos coletados; exclusão dos dados que não são mais necessários. |
| Exatidão | Os titulares podem corrigir seu registro entrando em contato com o controlador; os dados de contato são autodeclarados no momento da solicitação. | Mecanismo de correção autosserviço; procedimentos de revisão da qualidade dos dados. |
| Limitação de armazenamento | Aplica-se uma retenção definida (ver a seção Retenção mais abaixo): contatos com opt-in são retidos até que a exclusão seja solicitada; contatos sem opt-in têm um teto de 12 meses; registros de chat redigidos são excluíveis mediante solicitação. | Aplicação automatizada da retenção e exclusão segura no vencimento. |
| Segurança | Redação de identificadores diretos na entrada/saída; o email bruto nunca é duplicado para o vínculo (um SHA-256 com sal, subject_email_hash, vincula o titular entre tabelas); as rotas de direitos do titular são de escopo por chave e à prova de IDOR; os códigos de verificação são armazenados apenas como hashes com sal; os segredos são mantidos fora do repositório; HTTPS na demo hospedada. | Medidas técnicas e organizacionais apropriadas ao risco; criptografia em repouso, controles de acesso formais, procedimentos de notificação de violações; execução dos DPAs dos provedores. |
| Transparência | O Aviso de Privacidade da Demo é apresentado antes da coleta e é vinculado a partir do gate de consentimento; o gate registra qual versão do aviso o titular viu. | Avisos em camadas; linguagem clara sobre finalidades, retenção e direitos (já substancialmente cumprido). |
Direitos dos titulares dos dados
Seção intitulada “Direitos dos titulares dos dados”A demo implementa os direitos do titular dentro da sessão (de escopo por chave, à prova de IDOR) e por uma via de email do operador. Nunca se honra um identificador fornecido pelo cliente; o solicitante é resolvido a partir de sua chave de demonstração.
| Direito (Ley 19.628, Art. 12) | Estado atual — tal como a demo opera hoje | Notas |
|---|---|---|
| Acesso | O titular pode recuperar suas linhas armazenadas dentro da sessão (GET /data/export), ou solicitá-las ao controlador por email. | A exportação é completa-ou-recusada (nunca um parcial silencioso). |
| Retificação | Tratada entrando em contato com waldemar@szemat.pro; os dados de contato são autodeclarados e podem ser solicitados novamente. | Na escala atual da demo, a via por email é o canal de retificação aceito; um controle de retificação autosserviço dentro da sessão fica diferido para um deployment de produção mais amplo. |
| Cancelamento (exclusão) | O titular pode apagar todos os seus dados dentro da sessão (DELETE /data), o que cascateia sobre as tabelas de sua propriedade e a linha de captura de lead; um runbook do operador e um script cobrem a via fora de banda (por exemplo, uma chave expirada). | Uma chave revogada por abuso é recusada para a exclusão, de modo que não possa apagar sua própria trilha de abuso; o acesso, a exportação e o opt-out sobrevivem à revogação. |
| Bloqueio / opt-out | O titular pode interromper o registro futuro de interações dentro da sessão (POST /opt-out) sem encerrar a sessão; o consentimento de marketing pode ser retirado. | O Art. 12 da Ley 19.628 confere o “bloqueio” (suspensão temporária). |
| Portabilidade (Ley 21.719) | A exportação dentro da sessão retorna as linhas do titular em um payload JSON estruturado. | A portabilidade passa a ser um direito legal explícito com a Ley 21.719 (vigente a partir de 1º de dezembro de 2026). |
Ley 21.719 (vigente a partir de 1º de dezembro de 2026) acrescenta o direito de oposição ao tratamento por motivos legítimos e o direito à portabilidade dos dados, e cria a Agência de Proteção de Dados Pessoais (APDP) como autoridade de proteção de dados do Chile. Conforme a Ley 19.628 em vigor, o Art. 12 confere acesso, retificação, cancelamento (exclusão) e bloqueio; não estabelece uma autoridade de proteção de dados.
Disposições sobre dados sensíveis
Seção intitulada “Disposições sobre dados sensíveis”A Ley 19.628 prevê proteções reforçadas para dados pessoais sensíveis (dados de saúde, dados biométricos, entre outros). Conforme o Art. 10, dados sensíveis só podem ser tratados quando a lei autorizar, quando o titular consentir, ou quando forem necessários para a determinação ou concessão de benefícios de saúde (“otorgamiento de beneficios de salud”) que correspondam aos seus titulares.
| Aspecto | Estado atual — tal como a demo opera hoje | Caminho até produção |
|---|---|---|
| Dados de saúde | Nenhum dado real de saúde é coletado. Todo o conteúdo clínico é sintético; os termos de uso proíbem inserir dados reais de pacientes ou PHI, e os identificadores diretos no chat são redigidos. | Consentimento expresso para o tratamento de dados de saúde; limitação de finalidade ao contexto de cuidados de saúde; segurança reforçada; acesso restrito a profissionais autorizados. |
| Sensibilidade da PII de contato | Email, nome e organização são dados pessoais comuns, não dados sensíveis / de categoria especial, de modo que o regime de dados sensíveis do Art. 10 não é acionado pelo plano de contato. | Se campos futuros fossem sensíveis, aplicar-se-iam as condições do Art. 10. |
| Dados biométricos | Nenhum dado biométrico é coletado ou tratado (os recursos de voz, quando ativados, são divulgados separadamente e estão desativados por padrão). | Consentimento expresso; limitação de finalidade; segurança reforçada; exclusão quando a finalidade for cumprida. |
| Gestão de consentimento | Um consentimento granular e não agrupado é registrado antes do tratamento (GOVR-05); o canal de marketing é um opt-in separado e opcional; a versão e o carimbo de tempo do consentimento são armazenados. | Plataforma de gestão de consentimento; mecanismo de retirada; trilha de auditoria do consentimento (substancialmente cumprido hoje na escala da demo). |
Transferência transfronteiriça de dados
Seção intitulada “Transferência transfronteiriça de dados”| Aspecto | Estado atual — tal como a demo opera hoje | Caminho até produção |
|---|---|---|
| Plano conversacional -> subprocessadores de IA | A entrada de chat é enviada a subprocessadores de LLM, embeddings e reordenação nomeados nos Estados Unidos a cada turno. É uma transferência transfronteiriça de conteúdo de entrada redigido. A Voyage AI tem uma postura de treinamento por padrão; a exclusão no nível de administrador da organização não está ativada para esta demo. | Avaliação da transferência e salvaguardas apropriadas; ativar a exclusão da Voyage e executar os DPAs dos provedores (condição prévia para operar com dados reais). A transferência se baseia no consentimento explícito e informado do titular à transferência transfronteiriça para os Estados Unidos, divulgado no Aviso de Privacidade da Demo e registrado no gate de consentimento antes de qualquer tratamento; os DPAs dos provedores são executados como salvaguarda complementar. |
| Plano de contato / funil -> Supabase | A PII de contato é armazenada no Supabase (PostgreSQL gerenciado, região US East — us-east-2, Ohio); a aplicação roda no Google Cloud Run (região dos EUA). Essa PII não é encaminhada aos subprocessadores de chat. | A transferência transfronteiriça da PII de contato para os Estados Unidos se baseia no consentimento explícito do titular registrado no gate de solicitação de chave; a região do Supabase (us-east-2, Ohio) é refletida na divulgação de subprocessadores. |
| Telemetria | Apenas atributos de trace redigidos são exportados ao sink de telemetria ao vivo (Langfuse Cloud); o texto de chat anterior à redação nunca lhe é enviado. | Executar o DPA do provedor de telemetria; confirmar a janela de retenção e a região de hospedagem antes de operar com dados reais. |
Retenção
Seção intitulada “Retenção”- Os dados de contato enviados com uma solicitação de chave, quando o titular concedeu o opt-in de marketing separado, são retidos indefinidamente até que a exclusão seja solicitada (“indefinido-até-a-exclusão”). Contatos consentidos não são excluídos automaticamente; a exclusão mediante solicitação é sempre honrada.
- Os dados de contato enviados sem o opt-in de marketing são retidos apenas pelo tempo necessário para processar a solicitação, até um teto de 12 meses, após o qual são excluíveis.
- Os registros de chat redigidos são dados operacionais da demo e são excluíveis mediante solicitação por meio dos controles de direitos do titular.
O que a produção completa acrescentaria
Seção intitulada “O que a produção completa acrescentaria”A demo já cumpre as obrigações centrais da Ley 19.628 para os dados pessoais que trata (base legal, aviso, direitos do titular, retenção). Um deployment de produção mais amplo que tratasse dados pessoais ou de saúde reais em escala exigiria adicionalmente:
- Registro do controlador junto à Agência de Proteção de Dados Pessoais (APDP), a autoridade supervisora criada pela Ley 21.719 (operante a partir de 1º de dezembro de 2026), se exigido para a atividade de tratamento específica. Na escala atual da demo, este registro não é exigível; seria reavaliado para um deployment de produção mais amplo que tratasse dados pessoais ou de saúde reais em escala.
- Um Encarregado de Proteção de Dados ou representante, se exigido pela escala e pela natureza do tratamento. Não é exigido um Encarregado de Proteção de Dados nem representante para o controlador na escala e natureza atuais do tratamento; seria reavaliado para um deployment de produção mais amplo.
- DPAs de provedores executados (incluindo a exclusão da Voyage AI e um DPA do provedor de telemetria) antes de operar com dados reais.
- Procedimentos formais de notificação de violações e avaliações de segurança periódicas.
- Controles reforçados de dados sensíveis (Art. 10) se o sistema algum dia tratar dados de saúde reais, incluindo consentimento expresso por escrito e limitação de finalidade à gestão de cuidados de saúde.
- Aplicação automatizada da retenção (o cron de exclusão autoexecutável está diferido para depois do lançamento; a postura de lançamento é o runbook documentado mais o script de exclusão do operador).
Veja também
Seção intitulada “Veja também”- Aviso de Privacidade da Demo — controlador, base legal, subprocessadores, retenção e direitos
- Postura regulatória — fronteira regulatória
- Plano de registro de auditoria — o que é registrado e persistido
- Avaliação de prontidão para HIPAA — avaliação de prontidão para HIPAA
- Documentação de redação de PII — documentação de redação de PII
- Design de observabilidade — design de observabilidade
Parte do portfólio de Waldemar Szemat · szemat.pro
GitHub · LinkedIn