Considerações SOC2 e GDPR para PII em Prompts e Logs
Todo prompt enviado para o Claude e toda resposta registrada para depuração são locais onde PII pode acabar sujeita a obrigações SOC2 e GDPR. Esta lista de verificação aborda as práticas de mascaramento, retenção e trilha de auditoria necessárias para manter o tráfego da API Claude em conformidade.
Como Usar Esta Lista de Verificação
- Aplique esta lista de verificação a todos os caminhos de código onde os dados do usuário chegam a uma chamada de API Claude, não apenas ao seu fluxo de chat principal, incluindo pipelines de recuperação, trabalhos em segundo plano e scripts de avaliação/teste.
- Trate os itens de Minimização de Dados e Mascaramento como a base, pois são os controles mais baratos e evitam a maioria dos problemas de conformidade subsequentes antes que comecem.
- Revise esta lista de verificação sempre que adicionar uma nova ferramenta, um novo destino de log ou uma nova integração de terceiros que toque no tráfego da API Claude.
- Mantenha um registro escrito da resposta para cada item; este registro é o que um auditor SOC2 ou uma revisão de proteção de dados GDPR pedirá para ver.
A - Minimização de Dados
- Envie apenas os campos que um prompt realmente precisa. Não passe um registro completo do usuário em um prompt quando a tarefa requer apenas um nome e um número de pedido; cada campo adicional é uma exposição adicional sem benefício.
- Remova PII do contexto recuperado antes que ele entre em um prompt. Se um pipeline RAG recuperar um documento contendo o registro completo de um cliente, filtre-o para os campos relevantes para a pergunta atual antes de montar o prompt.
- Evite passar PII bruta em exemplos de poucas tentativas (few-shot) ou prompts de sistema em cache. O conteúdo em cache persiste por mais tempo e é reutilizado em várias solicitações; use exemplos sintéticos ou anonimizados em vez de dados reais do cliente.
B - Mascaramento
- Mascare PII antes de escrever qualquer solicitação ou resposta em um log. Direcione todos os logs através de uma única função de mascaramento para que nenhum caminho de código possa acidentalmente gravar conteúdo não mascarado.
- Mascare PII em mensagens de erro e rastros de pilha (stack traces), não apenas em logs normais. Uma exceção gerada no meio de uma solicitação pode levar o payload completo do prompt para um rastreador de erros se não for sanitizado primeiro.
- Use uma abordagem de mascaramento em camadas, não uma única regex. Combine a detecção baseada em padrões (e-mail, telefone, formatos de ID nacional) com uma biblioteca dedicada de detecção de PII para nomes e endereços, que a regex sozinha não consegue capturar de forma confiável.
- Mascare antes que os dados saiam da sua infraestrutura, não depois. Se os logs forem enviados para uma plataforma de observabilidade de terceiros, o mascaramento deve ocorrer antes da etapa de envio, não como uma tarefa de limpeza subsequente.
C - Retenção
- Defina um período de retenção explícito para logs de conversas e defina-o em código, não apenas em um documento de política. Uma política de retenção escrita que não é aplicada por um trabalho de exclusão automatizado não é um controle que um auditor aceitará.
- Defina uma janela de retenção mais curta para dados brutos e não mascarados do que para dados mascarados. Se você precisar reter temporariamente conteúdo não mascarado para depuração, exclua-o bem antes que o período geral de retenção de logs expire.
- Aplique limites de retenção a caches e índices de armazenamento vetorial, não apenas a logs de conversas. Um banco de dados vetorial de um pipeline RAG pode reter blocos contendo PII indefinidamente se nenhuma política de expiração for anexada aos documentos indexados.
- Documente exceções de retenção e sua justificativa. Se uma retenção legal ou uma investigação ativa exigir a retenção de dados além da janela normal, registre o motivo e por quanto tempo; é exatamente isso que uma resposta a uma solicitação de titular de dados GDPR precisará referenciar.
D - Controle de Acesso e Trilhas de Auditoria
- Registre quem ou o que acessou prompts e logs contendo PII, não apenas que o acesso ocorreu. Auditorias SOC2 procuram especificamente por acesso atribuível; "alguém" não é suficiente, precisa ser um usuário específico, conta de serviço ou sistema.
- Restrinja o acesso a logs não mascarados ao menor grupo que precisa dele. A maior parte da depuração e monitoramento pode ser feita em logs mascarados; reserve o acesso não mascarado para um conjunto restrito e justificado de funções.
- Registre chamadas de ferramentas que tocam em PII com o mesmo rigor que os próprios prompts. Uma ferramenta que lê um registro de cliente é um evento de acesso a PII, quer esses dados cheguem ou não à resposta do modelo.
- Revise os logs de acesso em uma cadência definida, não apenas durante um incidente. Uma revisão periódica (mensal ou trimestral) detecta o aumento do escopo de quem tem acesso antes que se torne uma constatação de auditoria.
E - Obrigações Específicas do GDPR
- Suporte solicitações de acesso de titulares de dados contra o histórico de conversas. Seja capaz de localizar e exportar todas as interações da API Claude vinculadas ao identificador de um usuário específico dentro da sua janela de resposta exigida.
- Suporte o direito de exclusão em todos os locais onde PII pode persistir. Isso inclui logs de conversas, prompts em cache, índices de armazenamento vetorial e quaisquer eventos de análise derivados de uma conversa, não apenas o banco de dados principal.
- Estabeleça e documente uma base legal para o processamento de PII através da API Claude. Para a maioria dos recursos do produto, isso é necessidade contratual ou interesse legítimo; documente qual se aplica e por quê, por recurso.
- Determine se PII cruza alguma fronteira de transferência de dados regulamentada. Confirme onde o tráfego da API é processado e armazenado, e se isso atende aos requisitos de transferência de dados transfronteiriços da sua organização.
- Prepare um caminho de notificação de violação específico para exposição de prompt ou log. Se um log da API Claude inadvertidamente reter PII não mascarada além da política, saiba com antecedência quem é notificado, dentro de qual janela e quais são as etapas de remediação.
Aplicando a Lista de Verificação em Ordem
- Minimização de Dados e Mascaramento (itens 1-7) são controles arquitetônicos; aplique-os primeiro, pois reduzem ou eliminam a exposição antes que qualquer questão de retenção ou controle de acesso importe.
- Retenção (itens 8-11) limita por quanto tempo qualquer exposição que ocorra pode persistir; este nível é onde a maioria das constatações SOC2 se origina quando a política e a aplicação divergem.
- Controle de Acesso e Trilhas de Auditoria (itens 12-15) determinam quem pode ver o que resta após a minimização e o mascaramento, e produzem as evidências que um auditor revisa.
- Obrigações Específicas do GDPR (itens 16-20) adicionam direitos legais definidos sobre a postura geral de conformidade, e exigem que os níveis anteriores já estejam em vigor para realmente cumprir sob demanda.
Armadilhas Comuns
- Mascarar logs, mas não os payloads brutos enviados para uma ferramenta de observabilidade ou análise de terceiros. Uma função de mascaramento aplicada apenas em sua própria chamada de log perde o que é encaminhado para uma ferramenta APM ou rastreador de erros com seu próprio caminho de captura separado. Correção: audite todos os destinos para os quais um payload de solicitação ou resposta flui, não apenas seu coletor de logs principal.
- Tratar "temos um documento de política de retenção" como equivalente a "a retenção é aplicada". Uma política que não é suportada por um trabalho de exclusão automatizado é um controle de papel, e controles de papel não se sustentam sob uma auditoria SOC2 Tipo II, que testa a eficácia operacional ao longo do tempo. Correção: implemente a retenção como um trabalho agendado ou TTL de banco de dados, não um processo manual.
- Esquecer que os índices de armazenamento vetorial também são uma superfície de retenção. As equipes rotineiramente aplicam limites de retenção a logs de conversas, enquanto deixam blocos contendo PII em um banco de dados vetorial indefinidamente, pois não parece um "log" no sentido tradicional. Correção: aplique a mesma lógica de retenção e exclusão ao conteúdo RAG indexado que ao histórico de conversas.
FAQs
Cada chamada de API Claude precisa se preocupar com SOC2 e GDPR, ou apenas aquelas que lidam explicitamente com dados do cliente?
Qualquer chamada que possa carregar PII, direta ou através de contexto recuperado, está no escopo. Isso inclui chamadas que parecem não relacionadas a dados do cliente na superfície, como uma ferramenta de suporte interna que recupera o histórico de tickets contendo nomes e e-mails de clientes.
Qual é a diferença entre o que o SOC2 se preocupa e o que o GDPR se preocupa aqui?
- O SOC2 está primariamente preocupado com a eficácia operacional de seus controles de segurança e acesso: eles são definidos, aplicados e evidenciados ao longo do tempo.
- O GDPR adiciona direitos legais específicos para indivíduos (acesso, exclusão, uma base legal para processamento) que seus controles precisam ser capazes de cumprir, não apenas demonstrar.
O mascaramento baseado em regex é suficiente para fins de conformidade?
Regex captura de forma confiável PII estruturada (e-mails, números de telefone, formatos de ID nacional), mas perde PII não estruturada como nomes e endereços embutidos em texto livre. Uma abordagem em camadas combinando regex com uma biblioteca dedicada de detecção de PII é a base mais defensável.
Por quanto tempo os logs de conversas devem ser retidos?
Não há um número único correto; depende das necessidades de depuração do seu produto, requisitos legais e tolerância a riscos, mas o número deve ser explícito, aplicado em código e mais curto para dados não mascarados do que para dados mascarados.
O banco de dados vetorial de um pipeline RAG precisa de sua própria política de retenção separada dos logs de conversas?
Sim. Blocos de documentos indexados podem conter PII e geralmente persistem independentemente do histórico de conversas, sem expiração natural, a menos que uma seja explicitamente configurada. Trate-o como sua própria superfície de retenção, item 10 desta lista de verificação.
O que conta como "acesso atribuível" para fins de auditoria SOC2?
Acesso registrado contra um usuário específico, conta de serviço ou identidade de sistema, não uma entrada de log genérica no nível do aplicativo que não distingue quem ou o que realizou o acesso. "A ferramenta de suporte acessou este registro" é uma evidência mais fraca do que "o usuário jane.doe@empresa.com, através da ferramenta de suporte, acessou este registro às 14:02 UTC."
Como cumpro uma solicitação de direito de exclusão do GDPR que afeta o histórico da API Claude?
Você precisa ser capaz de localizar todos os locais onde os dados de um usuário podem persistir (logs de conversas, caches, índices vetoriais, eventos de análise derivados) usando seu identificador, e ter um caminho de exclusão para cada um. É por isso que o item 17 destaca a exclusão em todas as superfícies de persistência, não apenas no banco de dados principal.
Dados sintéticos devem ser usados em exemplos de poucas tentativas em vez de dados reais do cliente?
Sim, de acordo com o item 3. Exemplos de poucas tentativas geralmente residem em prompts em cache ou reutilizados, o que estende sua retenção e exposição efetivas bem além de uma única solicitação; dados reais do cliente não pertencem lá, mesmo que pareçam um exemplo conveniente.
Qual é o risco de encaminhar prompts não mascarados para uma ferramenta APM ou de rastreamento de erros de terceiros?
Cria um fluxo de dados fora do seu pipeline de log principal, um que é fácil de negligenciar durante uma revisão de conformidade, pois não parece "nossos logs" no sentido tradicional, mas ainda é um local onde PII persistiu com seus próprios controles de acesso e comportamento de retenção (ou falta dele) que você não controla diretamente.
As revisões de logs de acesso precisam acontecer mesmo que não tenha havido nenhum incidente conhecido?
Sim, de acordo com o item 15. Uma revisão periódica em uma cadência definida é o que detecta o aumento do escopo, alguém retendo acesso a logs não mascarados após sua função ter mudado, antes que se torne uma constatação de auditoria ou um incidente real.
O que é uma base legal para processamento de PII e por que o item 18 exige que seja documentado por recurso?
Uma base legal é a justificativa legal (sob o GDPR, tipicamente necessidade contratual, interesse legítimo ou consentimento) para processar os dados pessoais de alguém. Documentá-la por recurso, em vez de uma declaração geral, importa porque diferentes recursos (chat de suporte vs. personalização de marketing, por exemplo) geralmente dependem de justificativas diferentes.
Relacionados
- Gerenciamento de Segredos e Prevenção de Exfiltração de Dados Através do Uso de Ferramentas - as técnicas de mascaramento e registro de auditoria que esta lista de verificação assume que estão em vigor.
- Compreendendo o Modelo de Ameaças de Segurança e RAG do Claude - por que a exposição de PII e a exfiltração de dados são riscos relacionados.
- Lista de Verificação de Escopo de Ferramentas de Privilégio Mínimo para Agentes Claude em Produção - restringindo quais ferramentas podem acessar dados contendo PII em primeiro lugar.
- Melhores Práticas de Segurança, Conformidade e RAG - o resumo de toda a seção para o qual esta lista de verificação contribui.
Versões da Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e o SDK oficial
anthropicpara Python (última versão 0.x). Nomes de modelos, preços e versões de SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.