Mascaramento de Dados no AI Gateway: O Que Realmente Funciona

O que o mascaramento de dados realmente é

O mascaramento de dados substitui um valor sensível por um substituto seguro de expor, mantendo os dados ao redor utilizáveis. Ele vem do mundo dos bancos de dados: forneça à equipe de QA uma cópia da produção onde cada número de cartão seja 4111-****-****-1234 e eles poderão testar formatos realistas sem manipular PII real. Aponte isso para um LLM gateway e a dinâmica muda — você está mascarando texto livre, a caminho de terceiros, dentro de uma conversa que precisa continuar fazendo sentido.

Estes termos são constantemente usados como sinônimos. Eles não são sinônimos.

Reversível vs irreversível é a distinção que realmente importa. Tokenização, FPE e criptografia fazem o percurso de ida e volta — alguém possui um cofre ou uma chave, um novo ativo a ser protegido. Mascaramento, redação e anonimização são unidirecionais: mais simples, mais seguros e inúteis no momento em que algo abaixo na cadeia (downstream) precisa do valor real.

Pseudonimização não é anonimização. Sob o GDPR (e LGPD), dados pseudonimizados ainda são dados pessoais e continuam no escopo regulatório; apenas dados genuinamente anonimizados ficam fora da regulamentação. Substituir cada nome por um User-8812 estável é pseudonimização, e chamá-la de anonimização não passará em uma auditoria.

Um terceiro eixo é fácil de passar despercebido: consistência é diferente de reversibilidade. Um mascarador pode ser determinístico — a mesma entrada sempre gera o mesmo substituto — sem ser reversível, e o determinismo é o que permite a um modelo raciocinar sobre "a mesma pessoa" ao longo de uma conversa.

O que quebra quando você me mascara o tráfego de LLM

Esta é a parte que a maioria dos artigos pula, e é o que decide se o seu projeto sobreviverá.

A qualidade da saída do modelo degrada, de forma desigual. Transforme Ligue para nosso escritório em 312-555-1234 em Ligue para nosso escritório em ************ e o modelo não saberá mais que aquilo era um número de telefone — asteriscos não carregam informação de tipo. Substitutos rotulados como [PHONE_NUMBER] mantêm o tipo, ao custo de revelar a qualquer pessoa que veja o prompt o que estava ali. A sumarização mal percebe; a extração falha ruidosamente; a correlação entre duas entidades falha silenciosamente, o que é pior.

Chamadas de ferramentas precisam do valor real. A falha mais crítica. Um agente que me mascara cliente@acme.com na entrada não pode, em seguida, chamar buscar_conta(email=...). Mascarar o caminho do modelo e deixar o caminho da ferramenta aberto cria a brecha oposta: o modelo nunca viu o endereço, mas os argumentos da ferramenta o levam a um servidor MCP de terceiros. Decida, por ferramenta, qual é mais confiável.

Saída estruturada e esquemas JSON quebram. Se você está usando saídas estruturadas com JSON Schema, o mascaramento pode produzir um valor que não satisfaz mais seu próprio campo: um campo com format: email não pode conter [REDACTED EMAIL], e um campo de inteiro não pode conter asteriscos. O mascaramento que preserva o comprimento é mais amigável porque mantém o formato. Mascarar a etapa de saída é pior — o modelo produziu um JSON válido, o mascarador reescreveu um valor dentro dele, e o seu parser lança um erro em uma resposta que o modelo acertou.

Consistência entre múltiplas interações (multi-turn). Interação um: "Priya Raman é a proprietária da conta." Interação quatro: "ela ainda é a proprietária?" Se a interação um virou asteriscos, o modelo não tem fio condutor para seguir. A pseudonimização determinística resolve isso, mas apenas se o mascarador mantiver o estado entre as interações — o que uma guardrail sem estado (stateless) não faz.

Recuperação em RAG contra texto mascarado. Mascare documentos antes da indexação e o embedding não conterá mais a entidade, portanto uma busca por ela não recuperará o trecho. Indexe sem mascarar e mascare no momento da recuperação, e seu banco vetorial conterá o corpus não mascarado — exatamente o que você estava evitando.

Aplicado de forma cirúrgica, o mascaramento vale a pena. Aplicado globalmente, ele degrada silenciosamente o produto sem que ninguém conecte as duas coisas.

Onde as equipes erram

Assumir que o mascaramento faz o percurso de ida e volta. Uma equipe mascara PII a caminho do modelo, assume que algo desmascarará no retorno e constrói a aplicação com base nisso. A menos que você tenha escolhido um esquema reversível e algo armazene as chaves, quem chama a API também verá o valor mascarado.

Mascarar o prompt e esquecer o caminho da ferramenta. Os dados trafegam em quatro lugares: para dentro do modelo, para fora do modelo, para dentro de uma ferramenta, para fora de uma ferramenta. Cobrir apenas um é comum. O vazamento então acontece por meio do resultado de uma ferramenta que ninguém estava inspecionando.

Tratar a redação de logs como controle de fluxo de dados. Redigir logs armazenados limita quem dentro da sua empresa lê os prompts. O provedor ainda assim recebeu o texto original.

Escolher mascaramento irreversível para um problema reversível. Se algo abaixo na cadeia precisa do valor de volta, o mascaramento é a técnica errada. Você precisa de tokenização ou FPE, o que significa um cofre ou uma chave.

Como o mascaramento funciona no TrueFoundry

O mascaramento não é um produto separado aqui. Cada guardrail possui duas configurações — Operation Mode (Modo de Operação) e Enforcement Strategy (Estratégia de Aplicação) — sendo o mascaramento um valor da primeira.

Mutate vs Validate

A prioridade é todo o modelo de ordenação para o mascaramento. Três guardrails de mutação em um mesmo hook executam em ordem, cada uma vendo a saída da anterior: um mascarador de segredos com prioridade 1 e um mascarador por regex com prioridade 2 significa que a guardrail de regex fará o match em um texto que já diz ***REDACTED***.

A mutação de entrada é bloqueante e executa primeiro — a requisição para o modelo não pode iniciar até que o prompt esteja finalizado. A validação de entrada é então executada em segundo plano paralelamente a ela, e se a validação falhar no meio do caminho, o gateway cancela a requisição do modelo para que você não pague por ela. A mutação e a validação de saída executam sincronamente após a resposta chegar, ponto em que o custo do modelo já foi incorrido.

As chamadas de ferramentas MCP adicionam dois hooks síncronos: pre-invoke (pré-invocação), onde uma falha significa que a ferramenta nunca é executada, e post-invoke (pós-invocação), onde uma falha retém o resultado. As guardrails executam em cada chamada de ferramenta separadamente — cinco ferramentas, cinco conjuntos de verificações.

Enforce vs Enforce But Ignore On Error

A segunda configuração separa duas falhas: a guardrail encontrou algo, versus a guardrail quebrou.

Estratégia

Em caso de violação

Em caso de erro da guardrail

Enforce

Bloqueia

Bloqueia (fail-closed)

Enforce But Ignore On Error

Bloqueia

Deixa passar (degradação graciosa)

Audit

Deixa passar, apenas registra em log

Deixa passar

A documentação chama Enforce But Ignore On Error de "o padrão mais seguro" e recomenda a evolução gradual Audit → Enforce But Ignore On Error → Enforce.

Quais recursos nativos podem realmente mascarar

"Temos uma guardrail de PII" não lhe diz nada sobre se ela pode mascarar.

A PII / PHI Detection é a exceção: ela não pode bloquear, apenas mascarar. Se o requisito for "rejeitar qualquer requisição contendo um CPF/SSN", esta não é a guardrail adequada.

Suas opções documentadas de estratégia de aplicação são apenas enforce e enforce_but_ignore_on_error — audit não está listado, ao contrário de Secrets, Regex e SQL Sanitizer. A implantação iniciando por Audit não é uniforme entre os recursos nativos. [VERIFICAR] se isso é uma restrição real ou uma lacuna na documentação.

O Regex Pattern Matching fornece substitutos rotulados em vez de asteriscos. Ele inclui 46 predefinições — CPF/SSN, cartões de crédito, passaportes de dez países, chaves de nuvem, tokens do GitHub e Slack, IPs — além de padrões customizados, como EMP-\d{6} → [REDACTED EMPLOYEE ID].

Entre as integrações de guardrails de terceiros, as capazes de mutação incluem Google Model Armor, CrowdStrike AIDR, F5 AI Security, TrojAI, Enkrypt AI, Pillar Security, Lasso (classifix), HiddenLayer (/redact-*), DeepKeep e Noma — as duas últimas exigem Mutate. Apenas Validate: Cisco AI Defense, Gray Swan Cygnal, Patronus, NVIDIA NeMo, Guardrails AI, Arthur AI. Pedir a um provedor apenas Validate para mascarar é um caminho sem saída.

O Google Model Armor tem uma armadilha de configuração: o Mutate precisa de ambos os modelos no Google Cloud: um modelo de inspeção SDP e um modelo de de-identificação, vinculados ao modelo do Model Armor, com a transformação configurada como "Replace with infoType name". Sem ambos, o mutate falha.

A questão do desmascaramento, respondida claramente

As guardrails de mascaramento próprias do TrueFoundry são unidirecionais. O modelo vê o valor mascarado e quem faz a chamada também. PII / PHI Detection, Secrets Detection e Regex Pattern Matching não documentam nenhuma forma de restaurar o original, e não há cofre de tokens no nível do gateway ou etapa de reidratação na documentação até setembro de 2026.

Existe exatamente um percurso de ida e volta documentado, e ele pertence a um terceiro. O CrowdStrike AIDR suporta criptografia com preservação de formato: quando o Operation é Mutate e a etapa de entrada criptografou os valores com FPE, o gateway passa o fpe_context resultante de volta para o AIDR na etapa de saída como input_fpe_context e chama POST {baseUrl}/v1/unredact, para que as mesmas chaves sejam usadas de ponta a ponta. Um caminho reversível real — mas exige CrowdStrike, modo Mutate e um fpe_context da etapa de entrada.

Portanto, se a sua aplicação precisa do valor real de volta, não planeje obtê-lo do gateway. Mantenha-o na sua aplicação, envie a versão mascarada e faça a junção (re-join) usando um identificador controlado por você. Um comportamento relacionado do AIDR surpreende as pessoas: assim que ele dispara uma violação, o Mutate não a suaviza em uma redação — a requisição ainda assim retorna erro 400.

Um exemplo prático: um copilot de suporte interno

Um copilot de suporte lê o texto dos chamados e busca registros de contas por meio de um servidor MCP. Os chamados rotineiramente contêm e-mails de clientes, números de telefone e IDs internos de funcionários.

Decida o que nunca deve chegar ao provedor. E-mails e números de telefone: mascarar. IDs de funcionários: mascarar com um rótulo, para que o modelo ainda consiga diferenciar dois funcionários em um mesmo chamado. Credenciais coladas por engano: mascarar também na saída.

Escolha modos e prioridades. PII / PHI Detection na LLM Input, Mutate (seu único modo), prioridade 1. Regex Pattern Matching na LLM Input, Mutate, prioridade 2, padrão customizado EMP-\d{6} → [REDACTED EMPLOYEE ID]. Secrets Detection na LLM Output, Mutate. Inicie cada uma na estratégia mais permissiva que ela suportar.

Decida o caminho da ferramenta deliberadamente. A busca de contas precisa do e-mail real, portanto a regra de mascaramento se destina ao modelo, não ao servidor MCP; em vez disso, a Secrets Detection executa no MCP Post-Invoke, capturando credenciais que retornem em um resultado de ferramenta. Documente o motivo: o servidor MCP está dentro da sua VPC e o provedor do modelo não está. Essa justificativa é o verdadeiro controle.

Vincule com uma política. Registrar uma guardrail não a aplica ao tráfego. Vá em AI Gateway → Policies → Guardrails → Add Rule e defina o escopo por alvos (modelos, servidores MCP, opcionalmente por ferramenta), sujeitos (usuários, equipes, contas virtuais com IN / NOT IN), metadados e hooks. Regras correspondentes são mescladas por hook.

Observe antes de confiar. Cada guardrail é seu próprio span em Monitor → Request Traces, com tempo de execução, resultado, escopo, entrada, saída e mutações. Uma taxa de mutação próxima de zero em um hook movimentado significa que seus padrões estão errados; próxima de 100% significa que você está prestes a aprender o que o mascaramento faz com a qualidade da resposta.

Pronto para testar em uma rota?

Registre uma guardrail de PII, vincule uma política a um modelo e leia os spans de mutação.

Comece gratuitamente

Pegadinhas que vale a pena conhecer

O mascaramento não executa em saídas via streaming. As guardrails de saída são ignoradas completamente quando "stream": true, porque a avaliação de uma resposta exige o texto completo. As guardrails de entrada não são afetadas. A maioria das interfaces de chat usa streaming por padrão, portanto o mascaramento do lado da saída fica inativo na superfície que os usuários realmente veem.

System prompts nunca são mascarados. O gateway os remove antes de enviar o conteúdo para qualquer guardrail, portanto eles nunca são inspecionados, bloqueados ou redigidos. A única exceção é o CrowdStrike AIDR, que vê o system prompt, mas nunca o modifica. Coloque uma chave em um system prompt e nenhuma guardrail de mascaramento salvará você.

A redação de logs é um controle diferente do Mutate. A Logging Configuration baseada em regras do TrueFoundry redige padrões de corpos armazenados com semântica onde a negação prevalece — uma regra correspondente com Log desativado suprime o corpo inteiramente. Mas a documentação é explícita: "A redação é aplicada apenas à cópia registrada em log… A requisição ativa enviada ao provedor do modelo nunca é modificada." Ela governa quem dentro da sua empresa lê os prompts, não o que sai dela. Nosso artigo complementar sobre prevenção de perda de dados para tráfego de LLM cobre a saída de dados (egress).

A ordenação pode transformar um bloqueio em uma permissão. O DeepKeep documenta isso concretamente: ele aplica a precedência da primeira lista entre as regras que dispararam, não a ação mais severa. "Se PII estiver listada antes de Adversarial, um jailbreak que também disparar PII será redigido e permitido em vez de bloqueado." Isso se generaliza para qualquer cadeia de mutação — coloque as regras que devem bloquear antes das regras que mascaram.

PII / PHI Detection é hospedada apenas pelo TrueFoundry. Ela executa no Azure AI Language e não está disponível em implantações self-hosted ou híbridas ("Gateway Plane only"). Use o Azure PII com sua própria chave ou use o CrowdStrike.

Leitura relacionada

• Prevenção de Perda de Dados para Tráfego de LLM — o lado de detecção e saída de dados
• Redação de PII: Gateway vs Aplicação — onde o controle deve residir
• Explicação das Guardrails do TrueFoundry AI Gateway — o modelo completo de guardrails
• Saídas Estruturadas em LLM e JSON Schema — por que o mascaramento e os esquemas colidem
• Construindo uma Estrutura de Governança de IA — a camada de política superior

Conclusão

O mascaramento de dados é um bom controle aplicado incorretamente com mais frequência do que é bem aplicado. A falha raramente é do mascarador — são as premissas ao redor dele: de que o mascaramento faz o percurso de ida e volta, de que o caminho da ferramenta está coberto, de que a redação de logs é a mesma coisa, de que o modelo raciocina tão bem com asteriscos quanto com o texto original.

Vale a pena documentar quatro decisões primeiro. Quais tipos de entidades genuinamente não podem sair. Em qual dos quatro hooks cada regra executa. Se algo abaixo na cadeia precisa do valor de volta, porque essa resposta sozinha decide entre mascaramento versus tokenização. E o que você aceitará em termos de qualidade de saída, medido em vez de presumido.

Depois, construa de forma delimitada: comece em Audit onde a guardrail permitir, analise uma semana de traces, promova para Enforce But Ignore On Error e mantenha o Enforce completo para rotas onde o bloqueio em caso de falha (fail-closed) for o correto. Um gateway é o lugar certo para esse trabalho — o ponto único por onde cada modelo, equipe e agente passa. Mas uma regra de mascaramento que você não observou é uma regra que você não entende.

Aplique o mascaramento em uma rota e analise os traces

Comece gratuitamente