DLP para agentes de IA: como evitar vazamento de dados
Veja como aplicar DLP a agentes de IA para identificar dados sensíveis, controlar destinos, bloquear saídas e investigar tentativas de vazamento.
O dado pode sair por uma ação perfeitamente válida
Um agente comercial consulta o CRM, abre uma proposta e prepara um resumo para a próxima reunião. A tarefa foi autorizada. O problema aparece quando o resumo inclui margem, condição especial de outro cliente ou uma chave copiada por engano para uma observação. O arquivo segue para um canal externo e a execução termina com sucesso.
A integração funcionou. A política de acesso permitiu a leitura. A resposta parecia útil. Mesmo assim, informação sensível atravessou uma fronteira indevida.
DLP para agentes de IA organiza controles para prevenir perda ou exposição de dados durante o trabalho automatizado. A sigla vem de Data Loss Prevention. Em uma arquitetura de agentes, ela precisa cobrir contexto, modelos, memória, ferramentas, logs, artefatos e destinos. Verificar somente o prompt deixa boa parte do caminho sem proteção.
Este guia mostra como transformar classificação de dados e regras de finalidade em decisões executáveis antes que uma saída chegue ao lugar errado.
O que DLP precisa controlar em agentes de IA
Soluções tradicionais de DLP observam e-mail, arquivos, dispositivos, nuvem e tráfego de rede. Agentes acrescentam uma camada capaz de reunir conteúdo de várias fontes, interpretar linguagem e criar novos artefatos.
A política precisa responder cinco perguntas em cada unidade de trabalho:
- qual dado está sendo usado?
- para qual finalidade ele foi recuperado?
- quem ou qual processo solicitou a tarefa?
- qual destino receberá o conteúdo ou a ação?
- que transformação reduz a exposição sem impedir o trabalho?
O dado pode aparecer de forma direta, como CPF, e-mail, contrato ou chave de API. Também pode surgir por combinação. Nome da empresa, valor, data e descrição de uma negociação talvez revelem uma condição confidencial mesmo sem um campo marcado como sensível.
A classificação de dados para agentes de IA define o tratamento esperado por classe, finalidade e impacto. DLP aplica esse tratamento nas fronteiras de saída.
Onde ocorre perda de dados em um fluxo com agentes
Contexto enviado ao modelo
O agente recupera um documento inteiro quando precisava de dois campos. A chamada inclui dados pessoais, cláusulas restritas ou conteúdo de outros clientes. A exposição acontece antes de qualquer resposta.
Retorno do modelo
A saída pode reproduzir trechos do contexto, reconstruir informações ou combinar dados permitidos de um modo que cria sensibilidade nova. Um relatório agregado pode acabar citando uma pessoa ou contrato específico.
Argumentos de ferramentas
O agente preenche destinatário, corpo de mensagem, caminho de arquivo, consulta ou payload de API. Um argumento pode transportar conteúdo confidencial para um sistema sem autorização para recebê-lo.
Artefatos produzidos
Planilha, apresentação, PDF, resumo, transcrição e código podem persistir dados que existiam apenas de forma temporária no contexto. O arquivo passa a ter dono, acesso, retenção e destino próprios.
Logs, traces e avaliação
Plataformas de observabilidade podem registrar prompts, respostas e parâmetros de ferramentas. Um controle aplicado ao e-mail final não corrige a cópia que já ficou no trace.
Memória e cache
Informações usadas em uma tarefa podem reaparecer em outra execução. Sem escopo por cliente, finalidade e validade, a memória vira uma rota silenciosa de mistura de contexto.
Canais externos
E-mail, WhatsApp, navegador, webhooks, armazenamento compartilhado e sistemas de terceiros ampliam o alcance. A identidade pode estar autorizada a usar o canal e continuar proibida de enviar aquela classe de dado para aquele destinatário.
DLP difere de classificação, permissão e prompt injection
Esses controles se conectam, mas terminam em decisões diferentes.
- classificação de dados declara sensibilidade, finalidade e tratamento;
- controle de acesso decide quem pode consultar ou alterar um recurso;
- proteção contra prompt injection reduz a chance de conteúdo não confiável desviar a execução;
- DLP decide se determinada informação pode atravessar uma fronteira e chegar ao destino pretendido.
Um vendedor pode ter acesso legítimo à margem de uma proposta. Isso não autoriza o envio da margem ao cliente. Um agente pode ler dados financeiros para preparar uma aprovação interna. Isso não libera o conteúdo para um modelo, log ou arquivo externo incompatível.
Permissão de leitura e permissão de divulgação são contratos diferentes.
Comece por unidades de trabalho e destinos reais
Criar uma regra global para “bloquear dados sensíveis” costuma gerar excesso de bloqueios ou lacunas. O desenho começa pela tarefa.
Considere um agente que prepara respostas de atendimento. Registre:
- evento de entrada;
- pessoa ou sistema solicitante;
- fontes consultadas;
- campos necessários;
- classificação herdada;
- transformações permitidas;
- modelos e ferramentas envolvidos;
- artefato produzido;
- destinatário interno ou externo;
- prazo de retenção;
- dono humano;
- estados de bloqueio e escalonamento.
A mesma informação pode ter rotas diferentes. O número de um pedido pode aparecer para o cliente correto, mas não em um painel público. Um contrato pode ser resumido para a equipe jurídica, enquanto uma comunicação ao fornecedor recebe somente a cláusula necessária e aprovada.
Construa uma política de saída
Uma política operacional de DLP combina dado, identidade, finalidade, canal e destino.
Uma matriz inicial pode usar esta estrutura:
| Classe | Destino interno autorizado | Destino externo | Transformação | Decisão padrão | |---|---|---|---|---| | pública | canais aprovados | permitido após verificar versão | nenhuma ou adequação editorial | permitir | | interna | pessoas e sistemas do processo | bloqueado por padrão | resumo ou remoção de detalhes | permitir internamente | | confidencial | grupo e sistema autorizados | somente por fluxo específico | minimização, máscara ou aprovação | escalar ou bloquear | | restrita | rota dedicada e poucas identidades | proibido por padrão | tokenização ou referência protegida | bloquear | | segredo técnico | cofre e runtime | proibido | injeção direta na ferramenta | bloquear conteúdo |
A matriz precisa considerar combinação e artefato final. Três campos internos podem formar uma saída confidencial. Um documento com dados restritos continua restrito depois de convertido para PDF.
Coloque controles em sete fronteiras
1. Antes da recuperação
Confirme finalidade, identidade, cliente, objeto e campos necessários. Uma consulta estreita reduz o volume que precisa ser inspecionado depois.
A política pode impedir:
- busca sem filtro por cliente;
- recuperação de campos fora da tarefa;
- acesso a ambiente de produção durante teste;
- uso de fonte incompatível com o canal de saída;
- combinação de carteiras ou unidades.
2. Antes da chamada ao modelo
Classifique o pacote e aplique redução antes de enviá-lo ao provedor:
- suprimir campos desnecessários;
- mascarar identificadores;
- substituir valores por tokens;
- recortar somente os trechos relevantes;
- bloquear segredos;
- escolher rota de modelo compatível;
- registrar política sem copiar o conteúdo integral.
Usar o modelo externo para descobrir se ele poderia receber o dado chega tarde. A decisão precisa ocorrer na fronteira anterior.
O comparativo entre anonimização e pseudonimização para IA ajuda a escolher a transformação conforme a utilidade exigida.
3. Na composição do contexto
Separe conteúdo por fonte, autoridade, cliente e finalidade. O agente deveria receber referências identificáveis, não um bloco indistinto de documentos.
A composição também precisa impedir herança acidental. Um trecho usado para analisar um caso não deve entrar automaticamente em memória de longo prazo ou em exemplos para outra área.
4. Antes de chamar ferramentas
Inspecione argumentos estruturados e conteúdo livre. Verifique:
- destinatário e domínio;
- canal e ambiente;
- caminho e visibilidade do arquivo;
- campos enviados;
- classificação da saída;
- volume de registros;
- vínculo do destinatário com o caso;
- autorização excepcional vigente;
- necessidade de aprovação.
Uma ferramenta genérica de envio torna o controle mais difícil. Funções estreitas, como enviar_resposta_ao_contato_do_chamado, permitem validar destinatário contra o registro oficial.
5. Antes de persistir artefatos
Aplique classificação, proprietário, localização, acesso e prazo ao arquivo produzido. Remova metadados e conteúdo auxiliar que não fazem parte da entrega.
Um resumo temporário não deveria cair em uma pasta pública. Uma planilha de teste não deveria herdar compartilhamento amplo. Um PDF confidencial precisa carregar a política mesmo depois de sair do runtime.
6. Antes da resposta ao usuário
Valide texto, anexos, links, referências e identidade do solicitante. A saída pode exigir:
- remoção de trechos;
- máscara;
- resumo em vez de conteúdo literal;
- bloqueio de download;
- aprovação humana;
- redirecionamento para sistema seguro;
- recusa com próxima ação legível.
7. Na observabilidade
Configure redução antes de armazenar prompts, respostas e argumentos. Logs deveriam preservar evidência suficiente para investigação sem reconstruir o vazamento.
Registre identificador, classe, política, destino, decisão, regra acionada e pessoa responsável. Conteúdo integral fica restrito a casos com justificativa, acesso e prazo definidos.
Regras determinísticas e classificadores cumprem papéis diferentes
Campos conhecidos pedem regras conhecidas. CPF, cartão, token, senha, conta bancária, e-mail e identificadores possuem padrões ou metadados que podem ser detectados sem depender de julgamento do modelo.
Texto livre e combinações exigem classificadores adicionais. Eles podem reconhecer entidades, temas, segredos prováveis e conteúdo contratual. Ainda assim, são probabilísticos e produzem falsos positivos e falsos negativos.
Uma arquitetura robusta combina:
- metadados herdados da fonte;
- regras determinísticas para campos e padrões;
- dicionários específicos da empresa;
- classificadores para texto livre;
- política de destino;
- revisão humana para casos incertos de alto impacto;
- testes contínuos com exemplos reais protegidos.
A regra mais confiável deve prevalecer. Um classificador não libera um campo marcado como restrito pela fonte oficial.
Trate o destino como parte do risco
O conteúdo não possui o mesmo risco em todos os destinos.
Avalie:
- interno ou externo;
- pessoa autenticada ou endereço livre;
- sistema oficial ou ferramenta pessoal;
- ambiente corporativo ou conta pública;
- armazenamento temporário ou persistente;
- região e fornecedor envolvidos;
- compartilhamento individual ou link aberto;
- destinatário único ou envio em lote;
- possibilidade de revogação;
- confirmação de entrega.
A residência de dados em IA ajuda a mapear onde provedores, índices, caches e subfornecedores processam ou armazenam informação. DLP acrescenta a decisão sobre qual conteúdo pode entrar em cada rota.
Desenhe respostas melhores que um erro genérico
Bloquear sem orientar transfere a tarefa para mensagens paralelas. A decisão de DLP deveria produzir um estado operacional.
Permitir
O conteúdo e o destino estão dentro da política. A ação segue com registro.
Transformar
O sistema remove campos, aplica máscara, gera resumo ou troca o anexo por um link protegido.
Reduzir o destino
A resposta deixa de ser enviada externamente e vira rascunho interno ou tarefa de revisão.
Escalar
Uma pessoa recebe o conteúdo mínimo, a regra acionada, o destino proposto e a consequência para decidir.
Bloquear
A ação proibida não alcança a ferramenta. O caso registra motivo, responsável e alternativa segura.
Conter
Quando existe tentativa anormal ou possível incidente, o sistema interrompe a classe afetada, preserva evidência e aciona o plano de resposta a incidentes de IA.
Como testar DLP antes de liberar um agente
Monte casos que exercitem canais e combinações reais.
Dados explícitos
Inclua documento pessoal, credencial, dado bancário, informação contratual e dado de outro cliente em entradas autorizadas e indevidas.
Dados dentro de texto e imagem
Teste assinatura de e-mail, rodapé, anexo, captura de tela, comentário em CRM, metadado e conteúdo extraído por OCR.
Combinações
Reúna campos que isoladamente parecem comuns, mas identificam cliente, negociação ou pessoa quando aparecem juntos.
Destinos
Varie endereço corporativo, domínio externo, destinatário divergente, link público, pasta compartilhada e webhook não aprovado.
Transformações
Confirme se máscara, pseudônimo e resumo removem o conteúdo proibido sem inutilizar a tarefa.
Contorno
Teste arquivo compactado, formato alternativo, codificação, instrução indireta, ferramenta intermediária e agente subordinado. O objetivo é verificar o sistema inteiro, não ensinar o prompt a reconhecer uma lista curta de frases.
Observabilidade
Procure o dado nos logs, traces, erros, arquivos temporários, memória e conjunto de avaliação. A ação final pode ser bloqueada enquanto uma cópia permanece em outra camada.
Cada falha deve virar caso de regressão. O red team para agentes de IA amplia o exercício para identidade, rede, ferramentas, filas e persistência.
Métricas para operar DLP
Acompanhe medidas ligadas à decisão e à correção:
- saídas inspecionadas por canal;
- bloqueios por classe e regra;
- transformações aplicadas;
- falsos positivos que atrasaram trabalho válido;
- falsos negativos encontrados em revisão;
- destinos não autorizados solicitados;
- dados sensíveis encontrados em logs;
- artefatos sem classificação;
- exceções abertas e vencidas;
- repetição de uma mesma causa;
- tempo entre detecção e contenção;
- processos que recuperam campos acima da necessidade;
- incidentes por origem, ferramenta e destino.
Uma taxa alta de bloqueio pode provar que a barreira funciona ou revelar que o processo consulta dados demais. A métrica precisa levar a uma mudança na fonte, na tarefa, na ferramenta ou na política.
Checklist de DLP para agentes de IA
- [ ] A unidade de trabalho e sua finalidade estão definidas?
- [ ] Fontes entregam classificação e proprietário quando possível?
- [ ] A recuperação busca somente campos necessários?
- [ ] Combinações de dados recebem avaliação própria?
- [ ] A política considera identidade, canal e destino?
- [ ] Dados são reduzidos antes da chamada ao modelo?
- [ ] Segredos ficam fora de prompts, memória e logs?
- [ ] Argumentos de ferramentas passam por inspeção?
- [ ] Destinatários são confirmados no sistema oficial?
- [ ] Artefatos recebem classe, dono, acesso e retenção?
- [ ] Logs aplicam redução antes do armazenamento?
- [ ] Bloqueios geram motivo e próxima ação?
- [ ] Exceções possuem aprovador, alcance e validade?
- [ ] Testes cobrem texto livre, anexos, combinações e contorno?
- [ ] Falhas alimentam regressão e resposta a incidentes?
- [ ] Existe um dono capaz de ajustar a política e o processo?
Prevenir perda exige controlar o caminho completo
Agentes tornam o trabalho mais rápido porque reúnem informação, interpretam contexto e acionam sistemas. A mesma capacidade amplia o número de lugares onde um dado pode atravessar uma fronteira.
DLP eficaz começa antes do modelo e termina depois da consequência. Ele limita recuperação, reduz contexto, verifica ferramentas, classifica artefatos, protege observabilidade e trata destino como parte da decisão.
A empresa ganha capacidade quando o agente consegue concluir o trabalho usando somente a informação necessária e entregando cada saída ao lugar autorizado. Esse contrato precisa existir em política e código. Deixar a responsabilidade apenas na instrução do agente produz uma recomendação educada diante de uma porta aberta.