O que é DLP? Prevenção de vazamento de dados na prática

Uma analista de atendimento recebe um cliente irritado, com uma planilha de cobranças que não bate. Para responder mais rápido, ela copia as 300 linhas, com nome, CPF e valor, e cola num assistente de IA gratuito pedindo "acha a diferença". A resposta sai em dez segundos e o cliente fica satisfeito.

Ninguém viu. O firewall registrou uma conexão HTTPS comum e o log mostra uma funcionária autorizada abrindo um arquivo permitido. Trezentos CPFs saíram por um caminho que nenhum controle olhava, e é para esse caso que existe o DLP.

DLP é a capacidade de saber qual dado é sensível e o que acontece com ele quando alguém, com acesso legítimo, tenta levá-lo para fora. Sem classificação e sem dono do dado, nenhuma ferramenta desse tipo funciona, e é por isso que tantos projetos são desligados no terceiro mês.

O que é DLP, sem jargão

DLP é a sigla de Data Loss Prevention, prevenção de perda (ou de vazamento) de dados. O glossário do NIST define como a capacidade de um sistema de identificar, monitorar e proteger dados em uso, em trânsito e em repouso, por meio de inspeção de conteúdo e análise do contexto da transação: quem originou, qual é o dado, por qual meio, em que momento e para qual destino.

Controle de acesso responde se o usuário pode abrir o arquivo. O DLP responde se ele pode mandar esse conteúdo para esse destino por esse canal. A analista do exemplo podia abrir a planilha; não podia colar os CPFs num serviço externo sem contrato.

Os três estados do dado

Dado em uso é o que está sendo copiado, colado, impresso ou salvo em pen drive. Quem enxerga é o agente instalado na máquina.

Dado em trânsito é o que passa pela rede: anexo de e-mail, upload, mensagem de aplicativo. Quem enxerga é o gateway de e-mail ou o proxy no caminho.

Dado em repouso é o que está guardado em pasta, bucket ou banco. Aqui a ferramenta faz varredura e responde onde estão os arquivos com CPF que ninguém abre há três anos.

Tipos de prevenção de vazamento e onde cada um atua

Produtos como o Microsoft Purview juntam várias linhas numa política só. Na compra, pergunte qual linha continua descoberta. A linha de nuvem está detalhada em CASB: o que é e como protege os apps na nuvem, e a soma dessas linhas num serviço entregue pela nuvem é o SASE.

Prevenção de vazamento na IA generativa

A última linha da tabela tem duas pontas. Na entrada, o controle inspeciona o que o usuário cola no prompt e deixa passar, mascara (troca o CPF por ***.***.***-**) ou bloqueia. Na saída, inspeciona a resposta, porque um modelo conectado a dados internos pode devolver o que o usuário não deveria ver.

O tema se cruza com dados da empresa no ChatGPT e com a política de uso de IA na empresa. A política diz o que pode, e o DLP verifica se a regra foi seguida.

Como a ferramenta decide o que é sensível

Há quatro jeitos de reconhecer o dado, e um projeto maduro usa todos.

Classificação e rótulos. O documento carrega uma etiqueta (público, interno, confidencial, restrito) e a política vale para o rótulo: confidencial não sai para domínio externo. É o método mais confiável e o mais trabalhoso, porque depende de gente rotulando.

Padrões. Expressões que reconhecem CPF com dígito verificador válido (o cálculo está em validar CPF), CNPJ, cartão que passa no algoritmo de Luhn, chave PIX. Os bons motores exigem também palavras próximas ("CPF", "titular"), porque onze dígitos aparecem em muita coisa que não é CPF.

Fingerprint. A ferramenta gera uma impressão digital de um documento ou base específica (a tabela de preços, o contrato-modelo, o cadastro de clientes) e reconhece trechos dele mesmo copiados para outro arquivo. Serve para proteger o que não tem formato padrão.

Contexto. Usuário, destino, horário e volume. Planilha para o contador cadastrado é normal; o mesmo arquivo indo para e-mail pessoal às 23h, na semana do aviso prévio, não é.

O que a política faz quando encontra

As ações vão da mais leve à mais dura, e quem escolhe entre elas é o negócio:

1. Monitorar: registra o evento, ninguém é interrompido.
2. Alertar: avisa o usuário e pede justificativa, sem parar o trabalho.
3. Bloquear: impede a ação.
4. Criptografar ou mascarar: deixa o dado sair protegido, ou tira a parte sensível e deixa o resto passar.

Por que tantos projetos de DLP fracassam

Em geral, a empresa compra a ferramenta depois de um susto e ativa as regras prontas em modo bloqueio. Na segunda semana o diretor comercial não consegue mandar proposta, alguém cria uma exceção ampla, e no terceiro mês a ferramenta está em modo monitorar para sempre, sem ninguém ler os relatórios.

Bloquear antes de conhecer o normal. O financeiro manda CPF para a contabilidade todo mês e o RH manda para o plano de saúde. Bloquear isso no primeiro dia quebra o negócio.

Não ter classificação. Sem rótulos, a ferramenta depende só de padrões, que sozinhos geram alerta demais ou, afrouxados, não pegam nada. O roteiro para criar os rótulos está em classificação de dados.

Não ter dono do dado. Quando chega o alerta de 5 mil CPFs indo para fora, quem sabe dizer se aquilo é processo ou vazamento é a área de negócio, não a TI. Sem dono nomeado, o alerta morre na fila.

Excesso de falso positivo. Um time que recebe 800 alertas por dia, dos quais 790 são inofensivos, para de ler alertas. O mesmo acontece em qualquer SOC com alerta demais.

Minha opinião, de quem trabalha com segurança: o DLP é a ferramenta de segurança em que a parte técnica é mais fácil e a parte organizacional é mais difícil. Proposta que fala só de agentes, conectores e regras, sem dizer quem decide sobre cada classe de dado, vende a metade que costuma dar certo.

Prevenção de vazamento no atendimento com IA

No atendimento, o cliente entrega dado sensível por vontade própria: digita o CPF, manda foto do cartão. Com um agente de IA no meio, surgem três pontos de controle.

Mascarar no chat. CPF, cartão e dados bancários digitados pelo cliente são detectados e mascarados antes de chegar ao modelo e ao histórico do atendente. O dado completo fica no cofre de pagamento ou no CRM com controle de acesso. O modelo não precisa do número do cartão para entender que o cliente quer contestar uma cobrança.

Impedir que o dado escape pelo atendente ou pelo agente. O atendente que cola a conversa numa ferramenta externa é pego pelo controle de endpoint e de navegador. O agente só deve chamar ferramentas e APIs aprovadas, com o conteúdo inspecionado na saída. Um agente que pode enviar texto livre para qualquer URL é um canal de exfiltração esperando uma injeção de prompt.

Proteger as transcrições. Transcrição vira base de análise de qualidade e de treinamento, com muito CPF dentro. Varredura periódica, retenção definida e mascaramento antes de exportar resolvem a maior parte.

Detalhei os outros riscos desse cenário em segurança de IA no atendimento.

DLP, LGPD e Shadow AI

O artigo 46 da LGPD obriga os agentes de tratamento a adotar "medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito". O parágrafo 2º diz que essas medidas valem desde a concepção do produto ou serviço.

A lei não cita DLP pelo nome, mas fala em comunicação indevida, que é o que a ferramenta vigia. Num incidente comunicado à ANPD pelo artigo 48, alguém vai perguntar qual medida existia para impedir aquela saída. Para empresas menores, o caminho regulatório está em LGPD para PMEs.

A Shadow AI trouxe o tema de volta à pauta. O relatório Cost of a Data Breach 2025 da IBM mostrou que uma em cada cinco organizações teve violação envolvendo Shadow AI, que níveis altos de uso não autorizado de IA somaram em média US$ 670 mil ao custo da violação e que, nesses incidentes, dados pessoais foram comprometidos em 65% dos casos, contra 53% na média geral. No Brasil, segundo a edição brasileira do mesmo relatório, o custo médio de uma violação chegou a R$ 7,19 milhões, a Shadow AI acrescentou em média R$ 591,4 mil e 87% das organizações disseram não ter política de governança de IA.

Contra dado pessoal saindo por IA não autorizada, inspeção de prompt e política de uso precisam andar juntas.

Por onde começar

1. Escolha dois ou três tipos de dado, como CPF, cartão e a base de clientes. Não tente classificar tudo no primeiro mês.
2. Nomeie um dono para cada tipo, alguém da área de negócio.
3. Ligue em modo monitorar no e-mail, no upload web e nas ferramentas de IA mais usadas, por quatro a seis semanas.
4. Leia os eventos com o dono do dado e separe fluxo legítimo (cria exceção específica, com destino nomeado) de fluxo arriscado.
5. Passe para alertar nos casos arriscados.
6. Bloqueie só o que é claramente proibido, como cartão completo saindo para fora ou base de clientes indo para e-mail pessoal.
7. Amplie canal por canal, repetindo o ciclo.

Se o dado já saiu, o roteiro está em dados vazados: o que fazer. A prevenção de vazamento entra como mais uma camada da lógica de Zero Trust: ter acesso a um dado não autoriza levá-lo para qualquer lugar.

O teste que eu faria amanhã

Pegue uma planilha fictícia com vinte CPFs válidos de teste e peça para alguém do time tentar tirá-la da empresa por cinco caminhos: e-mail pessoal, pen drive, upload num site de compartilhamento, cópia para um assistente de IA gratuito e mensagem no WhatsApp Web. Anote quantos caminhos alguém percebeu e quanto tempo levou.

Se ninguém percebeu nada, você mediu o problema sem gastar nada. Se todos foram percebidos, falta saber quem leu o alerta. Meu palpite é que o resultado fique no meio, e que o caminho despercebido seja o da IA.