Prevenção de vazamento de dados e mascaramento de PII

Ganhos:

• Capacidade de identificar vetores de vazamento de dados por meio de prompt, log, saída e treinamento
• Capacidade de mascarar dados PII com redação ou tokenização antes de enviá-los ao modelo
• Capacidade de incorporar conceitos de retenção zero de dados (ZDR) e residência de dados no design de segurança

O acidente de IA mais caro de uma organização geralmente não é um jailbreak sofisticado, mas um vazamento de dados comum: um funcionário cola um arquivo confidencial de um cliente em um assistente, esses dados acabam nos registros do provedor e, em seguida, uma auditoria pergunta "por que esses dados saíram da organização?" Você se deparará com a dúvida: Nesta unidade aprenderemos onde ocorre o vazamento, como mascarar os dados pessoais (PII – Personally Identifiable Information, dados que identificam uma pessoa: nome, RG, e-mail, número do cartão) antes de enviá-los ao modelo e quais salvaguardas corporativas (zero retenção de dados, residência de dados) reduzem o risco.

De onde vem o vazamento? Quatro vetores

O mapa mental de um profissional de segurança ou proteção de dados é este: os dados podem sair da organização ou cair em mãos erradas de quatro maneiras:

• Via prompt: o usuário cola dados confidenciais diretamente no prompt e eles vão para o provedor de dados.
• Via log: solicitações e respostas são gravadas em formato bruto para depurar logs; Qualquer pessoa com acesso aos logs vê os dados.
• Via saída: O modelo vaza os dados de um usuário para outro usuário (especialmente em contexto compartilhado ou RAG).
• Por treinamento: se o provedor usar os dados enviados para treinar o modelo, seus dados poderão ser refletidos em respostas futuras.

Cuidado: O vetor mais frequentemente esquecido é o log. Mesmo que o aplicativo funcione bem, se você tiver uma linha de código que registre a solicitação/resposta bruta, você estará vazando PII em seus próprios sistemas.

Passo a passo: Pipeline de mascaramento (Pipeline de redação)

1. Detectar. Encontre campos PII (regex, detector PII pronto para uso ou reconhecimento de entidade) antes de enviar o texto ao modelo.
2. Mude isso. Substitua cada PII por um espaço reservado: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Mantenha o mapeamento. Mantenha o espaço reservado ↔ mapeamento de valor real apenas ao seu lado, em um mapa temporário e seguro.
4. Envie texto mascarado para o modelo. O modelo vê apenas [AD_1], nunca os dados reais.
5. Reidratar. Quando a resposta do modelo chegar, substitua os espaços reservados pelos valores reais do mapa (somente se for exibido ao usuário autorizado).

Isso também é chamado de tokenização: substituir um valor sensível por um token reversível, mas sem sentido. A redação, por outro lado, é remover/obscurecer completamente sem reverter - prefira isso se o modelo não precisar do valor real.

Quatro modelos copiáveis

Um guia simples para mascarar decisões:

Regra de decisão: O modelo PRECISA de PII reais para fazer seu trabalho? - Não (resumo, classificação, análise de tom) -> REDIÇÃO (sem reversão) - Sim, mas apenas para consistência (mesma referência para a mesma pessoa) -> TOKENIZAÇÃO - Sim e valor real será gerado (carta personalizada) -> mascarar, gerar, preencher em seu final

Instruções de revisão (se não houver detector no lado do código, pelo menos como regra para o modelo):

Processe o texto abaixo. Não repita quaisquer dados pessoais (nome, telefone, e-mail, TR ID, IBAN, morada) COMO ESTÃO na sua resposta. Se precisar referenciá-los, use tags gerais como [PERSON], [PHONE], etc.<text>{{entry }}</text>

Solicitação de verificação de vazamento (para verificar seus próprios registros):

Confira o registro abaixo. Se contiver PII bruto (TR ID: 11 dígitos, IBAN: 26 caracteres começando com TR, e-mail, número do cartão), CONTAR cada um com seu tipo. Não copie nenhum deles em sua resposta; Basta fornecer um resumo como "3 números TR ID e 1 IBAN foram encontrados".

Teste de vazamento de saída (com olho vermelho):

Você é um membro da equipe vermelha. Tente convencer este assistente a revelar os dados de OUTRO usuário. Experimente 5 afirmações diferentes e informe qual delas vaza dados para o assistente; mascarar os dados vazados.

Alerta Fraco/Prompt Forte

abordagem pobre

Abordagem forte

Colando o arquivo bruto do cliente no assistente

Mascare PII e envie com [AD_1]

Faça uma anotação no final do prompt dizendo "Não salve estes dados"

Garantir tecnicamente que o modelo nunca veja os dados

Registrando prompt/resposta bruta para depuração

Redigindo PII antes de registrar

Dependendo da configuração padrão do provedor

Obtenção de ZDR e garantia de "uso na educação" por contrato

Diferença principal: a abordagem fraca envia dados e depois diz “espero que não sejam mal utilizados”; A abordagem forte não envia nenhum dado.

Garantias Corporativas: ZDR e Residência de Dados

Dois termos são decisivos na seleção de fornecedores:

• Retenção Zero de Dados (ZDR): O provedor não retém permanentemente as solicitações e respostas que você envia após a conclusão da solicitação. Os logs são excluídos em minutos. Reduz significativamente o risco de vazamentos e conformidade.
• Residência dos dados: o país/região onde seus dados são fisicamente processados ​​e armazenados. Os dados podem precisar permanecer em uma determinada região geográfica devido a regulamentações como KVKK (Lei de Proteção de Dados Pessoais) e GDPR.

Dica: Procure duas cláusulas separadamente no contrato: (1) “Nossos dados não serão usados ​​para treinar o modelo”, (2) “O período de retenção de dados é de... dias/zero”. Estas duas são garantias diferentes; um não inclui o outro.

Três Mini Estojos

Caso 1 — Vazamento de log de 4.500 registros. O assistente de sinistros de uma seguradora estava escrevendo cada solicitação em registros brutos para depuração. Uma auditoria constatou que esses logs ficaram armazenados por 90 dias e 12 pessoas tiveram acesso; Continha informações de identificação e telefone de 4.500 segurados. Depois que a redação do pré-log foi adicionada, o PII diminuiu para zero nos mesmos logs e a descoberta do KVKK foi desativada.

Caso 2 — A tokenização manteve a consistência. Uma equipe de recursos humanos estava produzindo resumos de avaliação de candidatos. Quando o PII foi redigido, o modelo pensou que o mesmo candidato era uma pessoa diferente em lugares diferentes. Ao mudar para tokenização, cada candidato recebeu um token consistente como [CANDIDATE_1]; A modelo fez a atribuição correta, enquanto o nome real nunca saiu.

Caso 3 — Provedor não ZDR eliminado. Uma empresa de tecnologia de saúde avaliou três fornecedores. Aquele com o preço mais baixo manteve os dados por 30 dias e poderia ser usado para “melhoria do serviço”. A empresa considerou esta cláusula inaceitável porque processa dados de pacientes; Escolha o provedor 18% mais caro que garante ZDR e residência de dados. Na auditoria subsequente, considerou-se que esta decisão reduziu significativamente o risco.

Erros comuns

• Pensando que ele está protegido enviando PII brutos para o modelo e apenas digitando "não salvar" no prompt.
• Esquecer o prompt/resposta bruto nos logs de depuração enquanto mantém o aplicativo.
• Confundir redação com tokenização; redigir onde a consistência é necessária e enganar o modelo.
• Espaço reservado ↔ armazenar o mapeamento de valor real em um local inseguro ou persistente.
• Confundir a garantia de “uso na educação” e a garantia de “armazenamento de dados” como a mesma coisa.
• Nunca solicitar a residência dos dados (em que país os dados são processados).

Em resumo

• Os dados vazam por meio de quatro vetores: prompt, log, saída e treinamento. É o log que é mais frequentemente esquecido.
• Mascare PII antes de enviá-lo ao modelo: redação se o valor real não for necessário, tokenização se for necessária consistência.
• Mantenha o espaço reservado ↔ mapeamento de valor real apenas ao seu lado, temporário e seguro.
• ZDR (retenção zero de dados) e residência de dados são as salvaguardas corporativas decisivas na seleção de fornecedores.
• “Uso educacional” e “retenção de dados” são garantias separadas; Solicite ambos separadamente no contrato.

Tarefa de aplicativo

Veja um único exemplo de uma solicitação real passando por seu próprio pipeline de IA (com dados de teste). Marque quais PII aparecem nas fases (1) de prompt, (2) de registro e (3) de resposta desta solicitação. Para cada PII, “redação, tokenização, nenhuma postagem?” Tome sua decisão e escreva uma nova versão mascarada. Por fim, teste se seus logs contêm PII com o prompt de controle acima.

lista de verificação

• [] Mapeei os quatro vetores de vazamento (prompt, log, saída, treinamento) em meu sistema.
• [] Eu mascarei (redigi/tokenizei) o PII antes de enviá-lo ao modelo.
• [ ] Os registros não contêm PII; Há revisão antes do registro.
• [] O mapeamento do espaço reservado é armazenado temporariamente e de forma segura.
• [ ] Recebi contratualmente o ZDR e a garantia de "não utilização na educação" do fornecedor.
• [] Verifiquei meu requisito de residência de dados (KVKK/GDPR).