Redação de PII

Documentação de referência: não é um dispositivo médico

Esta documentação descreve uma implementação de referência pública avaliada com dados 100% sintéticos. É uma referência de capacidades e prontidão, não uma certificação de conformidade nem aconselhamento jurídico, e não é um dispositivo médico. Não é clinicamente validada e não manipula PHI de produção.

Documenta as capacidades de redação de PII (Informação de Identificação Pessoal) da implementação de referência ai-agent-eval-harness-healthtech. Cobre os padrões de detecção, a integração no pipeline e as limitações do módulo atual de redação de PII.

Leia em conjunto com a avaliação de prontidão para HIPAA e o mapeamento da Ley 19.628 do Chile.

Arquitetura de redação de PII

Integração no pipeline

A redação de PII é aplicada em dois pontos do pipeline do agente:

1. Na entrada (input): A entrada do usuário é varrida em busca de padrões de PII antes de ser processada pelo pipeline do agente. A PII detectada é substituída por tokens de marcador de posição tipados, um por classe de identificador. O texto redigido é o que o agente processa.

2. Na saída (output): A saída do agente é varrida em busca de padrões de PII antes de ser retornada ao usuário. Isso captura casos em que o LLM gera PII inadvertidamente (por exemplo, ao repetir um número de telefone presente no contexto da conversa).

A redação é executada na camada de guardrails e está integrada aos nós guardrail_pre e guardrail_post do pipeline do LangGraph.

Eventos de redação nos spans de telemetria

Os eventos de redação de PII são registrados como atributos de span de telemetria:

• pii.redacted: booleano que indica se houve redação
• pii.pattern_type: a classe de identificador que correspondeu (por exemplo, um endereço de e-mail ou um padrão de identificação nacional específico da localidade)

O texto da mensagem do usuário nunca é incluído nos atributos do span (invariante de privacidade).

Padrões de detecção

Tipos de PII detectados atualmente

Tipo de PII	Localidade	Detecção e validação
Endereços de e-mail	Universal	Regex determinístico
Números de telefone	en (EUA), es-419 (Chile), pt-BR (Brasil)	Formatos numéricos específicos da localidade
SSN dos EUA	en (EUA)	Regex determinístico (baseado em formato)
RUT chileno	es-419 (Chile)	Regex determinístico com validação de dígito verificador
CPF brasileiro	pt-BR (Brasil)	Regex determinístico com validação de dígito verificador
DNI	es-419 (regional)	Detecção de documentos de identidade nacionais
Números de cartão de crédito	Universal	Regex determinístico com validação de dígito verificador
Números de prontuário médico (MRN)	en (EUA)	Padrões alfanuméricos de identificadores de saúde
Datas de nascimento (DOB)	Universal	Formatos comuns de data
Endereços postais	Universal	Padrões determinísticos de endereço

Metodologia de correspondência de padrões

A detecção de PII usa padrões regex determinísticos, não detecção baseada em LLM. Isso garante:

• Reprodutibilidade: A mesma entrada sempre produz o mesmo resultado de redação
• Determinismo: A redação de PII é executada na camada de guardrails, que é testada pelo gate determinístico de CI (um cliente LLM stub, sem necessidade de chaves de API)
• Baixa latência: A correspondência por regex é rápida e adiciona uma sobrecarga desprezível ao pipeline
• Auditabilidade: As definições de padrões são versionadas e revisáveis

Verificações de validação

Alguns tipos de PII incluem validação estrutural além da correspondência de padrões:

• Números de cartão de crédito: Validados com uma soma de verificação de dígito verificador para reduzir falsos positivos em sequências arbitrárias de dígitos
• RUT (Chile) e CPF (Brasil): Validados com seus respectivos algoritmos de dígito verificador de identificação nacional

Os identificadores nacionais sem dígito verificador (por exemplo, o SSN dos EUA) são detectados apenas por formato, de modo que a validação estrutural não se aplica a eles. As implementações específicas de soma de verificação são determinísticas e estão sob controle de versão.

Limitações

Limitações conhecidas da detecção baseada em regex

1. PII dependente de contexto: Os padrões regex não conseguem detectar PII que é implícita pelo contexto em vez de formatada em um padrão reconhecível. Por exemplo, “meu nome é John e moro na esquina da Main com a Oak” contém PII (nome, localização) que nenhum regex consegue extrair de forma confiável.

2. Formatos inéditos: Novos formatos de número de telefone, de número de identificação ou de endereço não cobertos pelos padrões existentes passarão sem ser detectados.

3. Formatos internacionais: Embora o módulo cubra formatos dos EUA, do Chile e do Brasil, PII de outras jurisdições pode não ser detectada. A cobertura está intencionalmente alinhada às três configurações regionais suportadas.

4. Falsos positivos: Os padrões de regex podem ocasionalmente redigir conteúdo que não é PII mas que corresponde ao formato de um padrão. As validações de dígito verificador mitigam isso nos identificadores que carregam uma soma de verificação.

Escopo da redação

A redação tem como alvo os identificadores estruturados. Os nomes de pessoas são retidos por política, não redigidos: a detecção confiável de nomes sem um modelo de NER produz taxas de falsos positivos inaceitáveis, portanto a retenção de nomes é uma decisão de política deliberada e documentada (ver ADR-0036), não uma omissão. A redação não é anonimização nem privacidade diferencial: remove identificadores diretos de forma determinística mas não oferece garantia matemática de privacidade, e o sistema não coleta nem processa dados biométricos.

Estado atual

A implementação de referência fornece redação determinística de PII que cobre os tipos de identificador mais comuns em suas três configurações regionais suportadas (EUA, Chile, Brasil). O módulo de redação é executado na camada de guardrails, é testado pelo gate determinístico de CI e registra eventos de redação em spans de telemetria.

Pontos fortes principais:

1. Determinística e reprodutível: Mesma entrada, mesma redação, todas as vezes. Nenhuma dependência do comportamento do LLM para a detecção de PII.
2. Cobertura multiconfiguração regional: Padrões para identificadores dos EUA, do Chile e do Brasil, alinhados às três configurações regionais suportadas.
3. Validação estrutural: validação de dígito verificador para cartões de crédito e para os identificadores nacionais de Chile/Brasil que carregam dígito verificador — reduzindo os falsos positivos nos padrões mais sensíveis.
4. Integração no pipeline: Redação tanto na entrada quanto na saída, integrada aos nós de guardrails que são testados pelo harness de eval.
5. Trilha de auditoria: Eventos de redação registrados em spans de telemetria com o tipo de padrão, permitindo o monitoramento da frequência de redação e da distribuição de padrões.

Caminho até produção

A redação de PII de nível de produção exigiria:

1. Cobertura de padrões ampliada: Tipos de PII adicionais (nomes via NER, endereços IP, identificadores de veículos, padrões de dados biométricos, formatos de prontuário de sistemas EHR específicos); cobertura para jurisdições adicionais além de EUA/Chile/Brasil

2. Promover a detecção residual baseada em LLM: Já existe no código uma passagem opcional de detecção residual de PII baseada em LLM como verificação somente de anotação, desativada por padrão; produção a promoveria a uma segunda etapa que imponha, após a redação determinística, para capturar PII dependente de contexto, formatos novos e identificadores que os padrões de regex omitem

3. Métricas de qualidade de redação: Medição automatizada da precisão e do recall da redação contra um conjunto de teste rotulado; acompanhamento das taxas de falsos positivos e falsos negativos; teste de regressão quando os padrões são atualizados

4. Revisão periódica de padrões: Revisão regular dos padrões de PII frente a formatos de dados emergentes, novos tipos de identificador e regulações de privacidade em evolução; cadência de atualização atrelada ao ciclo de revisão regulatória

5. Padrões específicos de domínio: Se implantado em contextos específicos de saúde ou financeiros, padrões personalizados para formatos de identificador específicos da instituição (por exemplo, formatos específicos de MRN de EHR, formatos de ID de seguro, formatos de número de conta)

6. Registro de redação para conformidade: Além dos atributos de span de telemetria atuais, em produção seriam necessários logs de auditoria de redação dedicados com políticas de retenção, controles de acesso e relatórios de conformidade

7. Tratamento de solicitações dos titulares: Mecanismos para que os titulares solicitem informações sobre quais PII foram detectadas e redigidas; procedimentos de exclusão para quaisquer metadados de redação armazenados

Veja também

• Avaliação de prontidão para HIPAA — avaliação de prontidão para HIPAA
• Mapeamento da Ley 19.628 do Chile — mapeamento de proteção de dados do Chile
• Plano de registro de auditoria — plano de registro de auditoria
• Design de guardrails — design de guardrails