Radar IA 18 de outubro de 2026
✨ IA MÁGICA Agentes · Modelos · Automação
ÚLTIMAS
Tutoriais e Guias

DLP com Presidio: mascaramento de dados em APIs

Implemente mascaramento de dados com Presidio antes das chamadas de API. Veja detecção em português, regras de bloqueio e testes para evitar exposição de dados.

DLP com Presidio: mascaramento de dados em APIs
Imagem: capa editorial — Tutoriais e Guias

Mascaramento dinâmico de dados em APIs é uma etapa que transforma informações sensíveis antes de enviá-las a outro sistema. Em um fluxo com IA, essa etapa pode retirar nomes, documentos e contatos que não são necessários para a tarefa. O Presidio oferece componentes para detectar entidades em texto e aplicar transformações, mas a política de bloqueio, os testes e a autorização continuam sendo responsabilidade da aplicação.

Um caminho seguro para começar é selecionar uma única operação, definir quais campos podem sair e testar o filtro com dados sintéticos. Depois, coloque a inspeção antes da chamada externa e antes dos registros de conteúdo. Não dependa de uma instrução ao modelo para esconder o que o próprio aplicativo já transmitiu.

Resumo rápido

  • DLP significa prevenção contra perda de dados; o mascaramento é uma das medidas possíveis.
  • O Analyzer detecta entidades e o Anonymizer transforma os trechos identificados.
  • Campos estruturados devem seguir regras explícitas, além da análise de texto livre.
  • Português exige configuração e avaliação próprias, incluindo formatos brasileiros.
  • Mascarar um identificador não garante que todo o contexto ficou anônimo.

Defina o que realmente precisa chegar à API

Comece pelo objetivo da operação. Para classificar o assunto de um chamado, o serviço provavelmente precisa da descrição do problema, mas não do CPF do solicitante. Para redigir uma resposta genérica sobre prazo de entrega, pode bastar a situação logística e um identificador temporário. A pergunta de projeto é concreta: qual informação altera a resposta que queremos obter?

Faça um inventário do corpo da requisição, dos cabeçalhos de negócio, das URLs e dos anexos. Separe campos obrigatórios, opcionais e proibidos para cada destino. Um campo chamado “observação” pode conter praticamente qualquer coisa; um campo chamado “cliente” pode esconder um objeto completo vindo do CRM. O contrato precisa descrever ambos.

Em vez de encaminhar o objeto original e apagar algumas chaves conhecidas, construa um novo objeto com os campos autorizados. Essa abordagem torna visível a seleção. Quando uma integração acrescentar um campo, ele não será automaticamente incluído na chamada externa. O filtro de texto livre entra depois dessa seleção inicial.

Esse trabalho complementa a auditoria de bases usadas com IA. Uma base organizada ajuda a localizar a origem dos dados e a justificar por que determinada informação entra na operação. Sem isso, a equipe acaba mantendo exceções sem saber quem as solicitou nem quando devem expirar.

Como Presidio separa detecção e transformação

O Presidio Analyzer identifica entidades em texto usando reconhecedores, que podem combinar padrões e processamento de linguagem. O resultado inclui tipo de entidade, posição inicial, posição final e pontuação. Esse resultado descreve uma detecção; ainda não significa que o texto foi removido da requisição.

O Presidio Anonymizer recebe as posições detectadas e aplica operadores. A documentação inclui substituição, remoção, máscara, hash e criptografia. A escolha depende do que a tarefa exige. Para classificar um chamado, trocar um contato por um marcador costuma ser mais simples de inspecionar do que preservar partes do contato.

Tratamento Uso possível Cuidado de projeto
Remover campo Informação desnecessária Verificar se o contrato aceita a ausência
Substituir por marcador Manter o papel de uma entidade no texto Distinguir pessoas quando a relação importar
Mascarar parte Exibir referência reduzida a um operador O fragmento restante ainda pode identificar
Usar identificador temporário Relacionar resposta ao registro interno Guardar a correspondência em área restrita

Se houver uma tabela que permita recuperar o original, trate o processo como reversível. A palavra “anonymizer” no nome de uma biblioteca não prova que o conjunto final deixou de permitir identificação. Um cargo raro, uma cidade pequena e uma ocorrência específica podem revelar uma pessoa mesmo sem seu nome. Avalie o texto que efetivamente sai.

Também evite usar o resultado completo da detecção como log de diagnóstico. Uma rotina criada para reduzir exposição pode voltar a expor dados ao registrar entradas e exceções. Prefira contagens, tipos detectados, versão da política e resultado da decisão. Amostras de conteúdo precisam de um fluxo controlado separado.

Português, CPF e conteúdo livre exigem testes próprios

O tutorial oficial de modelos e idiomas adicionais explica que tanto o motor de linguagem quanto os reconhecedores devem ser adaptados ao idioma. Alterar apenas um parâmetro para português não comprova cobertura. Configure os componentes, registre suas versões e examine quais reconhecedores estão realmente ativos.

A lista de entidades suportadas serve como ponto de partida para conferir identificadores disponíveis. Não presuma que todo documento brasileiro será detectado em qualquer configuração. Para CPF, telefone, matrícula de funcionário e código interno, estabeleça casos específicos e reconhecedores adequados quando necessário.

Uma expressão regular que localiza onze dígitos pode ajudar a encontrar candidatos a CPF, mas também pode atingir números de pedidos. Combine o padrão com regras de domínio e contexto quando fizer sentido. Teste valores com e sem pontuação, espaços inesperados, quebras de linha e erros de digitação. Não coloque documentos reais em um repositório de testes.

Separe os dois tipos de falha. Um falso negativo deixa passar algo que deveria ser tratado. Um falso positivo transforma conteúdo legítimo, como o código de uma peça, e pode impedir que o modelo entenda o chamado. Aumentar o rigor sem medir o efeito pode tornar o sistema inutilizável e incentivar a equipe a contornar o filtro.

Use um conjunto pequeno, revisado manualmente, como primeira referência. Para cada exemplo, registre o trecho sensível esperado e o comportamento desejado: transformar, bloquear ou revisar. Acrescente novos casos a partir das falhas observadas, mantendo uma parte dos exemplos fora do ajuste para verificar se a melhoria generaliza.

Monte o fluxo antes da chamada externa

Uma arquitetura enxuta pode seguir esta ordem: autenticar o solicitante, autorizar a operação, selecionar campos, analisar texto livre, aplicar a política, transformar o conteúdo e validar a saída. Somente o objeto aprovado segue para a API. O código que faz o envio deve receber esse objeto, sem manter uma opção silenciosa para usar a entrada original.

entrada autorizada
  -> seleção dos campos permitidos
  -> detecção com configuração validada
  -> decisão: transformar, bloquear ou revisar
  -> validação do objeto resultante
  -> chamada à API de destino

Esse esquema é uma proposta de arquitetura, não um programa pronto. Sua implementação deve preservar os tipos do contrato, tratar listas e objetos aninhados e limitar o tamanho das entradas. Evite converter todo o JSON em uma string para depois reconstruí-lo com substituições improvisadas; isso pode corromper números, identificadores e estruturas necessárias ao sistema de destino.

Defina o comportamento quando a inspeção falhar. Para um fluxo que proíbe dados pessoais no destino, a alternativa coerente é bloquear a transmissão e encaminhar o caso para tratamento interno. Um timeout não deve autorizar o envio do conteúdo original. Mostre ao usuário uma mensagem clara, sem reproduzir o material sensível no erro.

Decida também como tratar a resposta da API. Ela pode repetir dados recebidos ou produzir novos trechos inadequados. A validação de saída precisa ocorrer antes de mostrar conteúdo a outra pessoa ou gravá-lo em sistemas compartilhados. Se houver restituição de identificadores temporários, faça-a apenas para um destinatário autorizado e dentro do contexto correto.

O monitoramento pode registrar volume de bloqueios, taxa de revisão, latência do filtro e falhas de integração. Mantenha o conteúdo bruto fora do tracing comum. O guia de observabilidade de chamadas a modelos ajuda a pensar no rastreamento; aqui, a seleção do que registrar precisa ser parte do desenho desde o início.

Exemplo: administradora de condomínios em Recife

Considere uma administradora de condomínios em Recife que quer classificar solicitações de manutenção e produzir sugestões de resposta. O caso é ilustrativo. Moradores escrevem mensagens livres com nomes, telefones, números de apartamento e relatos particulares. O objetivo do piloto é preservar o assunto operacional e reduzir o conteúdo pessoal enviado ao serviço de IA.

A equipe começa por chamados de manutenção simples. O número do apartamento fica no sistema interno; o modelo recebe apenas a descrição do equipamento, o problema relatado e a prioridade já definida por regra operacional. O texto livre passa pela inspeção. Mensagens sobre conflitos pessoais ou situações fora do escopo seguem para atendimento humano.

Em um teste sintético, a mensagem “o interfone do meu apartamento parou; fale com o contato informado no cadastro” pode virar uma descrição operacional sem contato. Se o morador colar telefone e nome no próprio relato, o detector deve tratar esses trechos. Se o sistema não conseguir processar o conteúdo, não há chamada externa.

Os testes incluem dois moradores mencionados na mesma mensagem. Substituir ambos por um marcador único pode confundir quem relatou e quem presenciou o problema. Quando essa relação não for necessária, a aplicação remove a referência inteira. Quando for necessária, usa marcadores distintos, com correspondência restrita àquela operação.

A avaliação pede a um funcionário que confira se a classificação continua correta após a transformação. Também verifica se o payload de rede, os logs e as mensagens de erro estão limpos. A aprovação depende desse conjunto de evidências, sem atribuir ao piloto um percentual de proteção que não foi medido.

Erros comuns

Usar uma lista de nomes como única proteção. Ela não cobre grafias novas, abreviações e referências indiretas. Combine seleção de campos, detecção e regras de negócio. Para material que não pode sair em hipótese alguma, mantenha a operação dentro de um ambiente apropriado ao requisito.

Confundir mascaramento com defesa contra instruções maliciosas. DLP trata exposição de dados. Um texto pode estar sem nomes e ainda tentar induzir uma ferramenta a executar uma ação indevida. Esse risco exige controles próprios, abordados nos testes de injeção de prompt.

Esquecer anexos e OCR. Um filtro de texto não inspeciona automaticamente o conteúdo visual de um documento. Defina se anexos são aceitos, como são extraídos e qual tratamento recebem. Não permita que o arquivo original siga por um caminho alternativo depois que seu texto foi filtrado.

Manter exceções permanentes. Uma liberação emergencial precisa de responsável, justificativa e revisão. Caso contrário, a política se torna uma coleção de permissões antigas que ninguém consegue explicar. O histórico deve mostrar o que mudou e quais testes foram refeitos.

Enviar dados reais para depurar o detector. Reproduza o formato com exemplos sintéticos. Quando uma análise interna de conteúdo real for indispensável, use o processo restrito da organização, com acesso e retenção definidos. O canal de suporte da biblioteca não é um destino automático para material corporativo.

Perguntas frequentes

Presidio garante encontrar todos os dados pessoais?

Não trate a ferramenta como garantia universal. A documentação de perguntas frequentes discute falsos positivos e falsos negativos. A cobertura depende da configuração e dos dados. Testes próprios e restrição dos campos enviados continuam necessários.

Posso deixar somente os últimos dígitos de um documento?

Isso depende da necessidade da operação e do restante do contexto. Um fragmento pode ajudar a identificar alguém quando combinado com outros dados. Se o destino não precisa do documento, prefira removê-lo em vez de preservar parte dele por conveniência.

Preciso devolver os nomes à resposta?

Somente quando o fluxo exigir e o destinatário estiver autorizado. Muitas classificações e sugestões de texto funcionam sem restituição. Se houver correspondência reversível, proteja o armazenamento, limite sua duração e impeça misturas entre clientes e sessões.

O filtro deve rodar no navegador?

Uma interface pode antecipar avisos ao usuário, mas a política efetiva deve ser aplicada no backend que controla o envio. Caso contrário, outro cliente ou uma chamada direta pode contornar a proteção. Teste o endpoint independentemente da interface.

Como saber se já posso colocar em produção?

Defina critérios antes do piloto: cobertura dos casos obrigatórios, ausência de conteúdo bruto nos registros, comportamento correto em falhas e manutenção da utilidade. Comece com escopo limitado e um responsável capaz de suspender o fluxo quando aparecer um problema.

Fontes e leitura recomendada

Sobre

A Redação IA Mágica é formada por especialistas e pesquisadores em inteligência artificial aplicada, agentes autônomos, automações no-code/pro-code e grandes modelos de linguagem (LLMs). Nossos conteúdos cobrem implementações reais, análises e tutoriais aprofundados para profissionais e empresas.