Controles empresariais e confiança27 de outubro de 2026Flatkey Team

Guia de APIs de remoção de PII (2026): comparação entre AWS, Google Cloud, Azure e Presidio para aplicações com LLMs

Uma API de remoção de PII identifica e mascara dados pessoais em texto. Compare Amazon Comprehend, Google Sensitive Data Protection, Azure Language PII e Presidio, com código, unidades de cobrança, resultados reais de detecção e um pipeline de remoção de PII para LLMs.

Guia de APIs de remoção de PII (2026): comparação entre AWS, Google Cloud, Azure e Presidio para aplicações com LLMs

Guia de APIs de remoção de PII (2026): comparação entre AWS, Google Cloud, Azure e Presidio para aplicações com LLMs

Uma API de remoção de PII recebe um texto, identifica dados pessoais, como nomes, e-mails, números de telefone, números de cartão e documentos de identificação, e retorna a localização desses dados ou uma cópia do texto com eles mascarados, substituídos ou tokenizados. Para equipes de produtos de IA, o principal objetivo é remover ou pseudonimizar dados pessoais antes que prompts, documentos e logs cheguem a um LLM de terceiros. As quatro opções que a maioria das equipes avalia são Amazon Comprehend DetectPiiEntities, Google Cloud Sensitive Data Protection (antigo Cloud DLP), detecção de PII do Azure Language e Microsoft Presidio, de código aberto.

Este guia compara endpoints, autenticação, idiomas compatíveis, unidades de cobrança e formato de saída, com exemplos executáveis que usam dados sintéticos. Também apresenta resultados reais de detecção de um teste local com o Presidio, incluindo dados não detectados e falsos positivos para os quais você deve se preparar. Todos os detalhes dos provedores foram conferidos na documentação oficial em 27 de outubro de 2026.

A Flatkey não oferece uma API integrada de remoção de PII. Os padrões abaixo são executados no seu próprio serviço antes de uma solicitação ser enviada por qualquer gateway de modelos, incluindo a Flatkey. Para entender as políticas relacionadas ao mesmo problema, leia nosso guia de políticas de remoção de dados em APIs de IA.

Remoção, mascaramento, detecção de entidades e tokenização: qual é a diferença?

Técnica O que retorna Reversível? Uso típico
Detecção de entidades Tipo da entidade, pontuação de confiança e posições dos caracteres Não se aplica (o texto não é alterado) Decidir o que fazer com cada entidade; auditar os dados em circulação
Remoção Texto com PII removidas ou substituídas por um rótulo como [PERSON_1] Não Prompts para LLMs externos, logs, análises
Mascaramento Texto com caracteres ocultos, como ***********1111 Não Telas de atendimento que precisam exibir valores parciais
Tokenização / pseudonimização Texto com PII substituídas por um token consistente ou valor criptografado Sim, com a chave ou tabela de consulta Fluxos com LLMs que precisam reinserir os valores reais na resposta
Remoção por campo Campos conhecidos (como email em JSON) removidos ou substituídos conforme o esquema Depende Payloads estruturados nos quais você sabe quais campos contêm PII

Para dados estruturados, regras por campo são mais rápidas e confiáveis do que qualquer modelo. Use APIs de detecção de PII para texto livre: mensagens de chat, chamados de suporte, transcrições e documentos.

Comparação de APIs de remoção de PII (outubro de 2026)

Amazon Comprehend Google Sensitive Data Protection Azure Language PII Microsoft Presidio
Tipo API gerenciada API gerenciada API gerenciada (também em contêineres) Código aberto, hospedagem própria
Chamada principal DetectPiiEntities projects.content.deidentify analyze-text com PiiEntityRecognition AnalyzerEngine + AnonymizerEngine
Retorna diretamente o texto com PII removidas Não, retorna posições (use-as para remover os dados) Sim Sim (redactedText) Sim
Tokenização reversível Não Sim (transformações baseadas em criptografia) Não Sim (operadores encrypt / decrypt)
Idiomas compatíveis com detecção de PII Inglês e espanhol Muitos infoTypes, alguns específicos de cada país Vários idiomas, conforme a documentação Depende do modelo de NLP carregado
Limite de entrada / unidade 100 KB por solicitação; cobrança a cada 100 caracteres, mínimo de 3 unidades Cobrança por GiB; mínimo de 1 KB por solicitação Cobrança por registro de texto Sua infraestrutura computacional
Franquia gratuita 50K unidades (5M caracteres) por API por mês durante 12 meses Primeiro 1 GiB por mês para inspeção 5,000 registros de texto por mês (plano gratuito) Software gratuito
Os dados saem da sua rede Sim (AWS) Sim (Google Cloud) Sim, a menos que você execute o contêiner Não

Fontes: documentação de PII do Amazon Comprehend, preços do Comprehend, documentação de desidentificação do Google, preços do Sensitive Data Protection, visão geral de PII do Azure, preços do Azure Language, e documentação do Presidio, todas consultadas em 27 de outubro de 2026.

Quanto custa?

  • Amazon Comprehend: no exemplo da própria AWS para Detect PII, 10,000 comentários de clientes com 550 caracteres cada correspondem a 6 unidades por solicitação; portanto, 60,000 unidades a $0.0001 por unidade custam $6 (preços do Comprehend, exemplo 7). Solicitações curtas são cobradas pelo mínimo de 3 unidades (300 caracteres), então agrupar mensagens pequenas em lotes reduz o custo.
  • Google Sensitive Data Protection: a inspeção de conteúdo é gratuita para o primeiro 1 GiB por mês; depois, custa $3.00 por GiB, caindo para $2.00 por GiB em volumes maiores; o preço listado para transformação é de $2.00 por GiB e, depois, $1.00. Há uma cobrança mínima de 1 KB por solicitação.
  • Azure Language: a detecção de PII é cobrada por registro de texto, com 5,000 registros de texto gratuitos por mês no plano gratuito. Os planos pagos estão listados na página de preços do Azure para sua região.
  • Presidio: não há taxa de licença; você paga pelos recursos computacionais que executam o analisador e o modelo de NLP.

Amazon Comprehend: DetectPiiEntities

O Comprehend detecta PII em textos em inglês ou espanhol. DetectPiiEntities retorna Type, Score, BeginOffset e EndOffset de cada entidade; o limite de entrada é de 100 KB de texto em UTF-8 (referência da API). Ele não retorna o texto com PII removidas, então você precisa substituir os trechos por conta própria.

import boto3

comprehend = boto3.client("comprehend", region_name="us-east-1")
text = "Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187."

resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en")

# Replace from the end so earlier offsets stay valid
redacted = text
for e in sorted(resp["Entities"], key=lambda e: e["BeginOffset"], reverse=True):
    if e["Score"] >= 0.5:
        redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
print(redacted)

A autenticação usa credenciais padrão da AWS (função do IAM, SSO ou chaves de acesso) com permissão para comprehend:DetectPiiEntities.

Google Cloud Sensitive Data Protection: content.deidentify

A API do Google inspeciona e transforma em uma única chamada. Você escolhe os infoTypes (como EMAIL_ADDRESS e PHONE_NUMBER) e uma transformação: replaceWithInfoTypeConfig, redactConfig, characterMaskConfig ou pseudonimização baseada em criptografia (documentação de desidentificação).

curl -X POST \
  "https://dlp.googleapis.com/v2/projects/$PROJECT_ID/content:deidentify" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{
    "item": {"value": "Email dana.whitfield@example.com or call 212-555-0187."},
    "inspectConfig": {
      "infoTypes": [{"name": "EMAIL_ADDRESS"}, {"name": "PHONE_NUMBER"}, {"name": "PERSON_NAME"}]
    },
    "deidentifyConfig": {
      "infoTypeTransformations": {
        "transformations": [{"primitiveTransformation": {"replaceWithInfoTypeConfig": {}}}]
      }
    }
  }'

O campo item.value da resposta contém um texto como Email [EMAIL_ADDRESS] or call [PHONE_NUMBER]. O Google recomenda listar apenas os infoTypes necessários, pois a busca pelo conjunto padrão aumenta a latência.

Azure Language: reconhecimento de entidades de PII

O endpoint analyze-text do Azure retorna tanto as entidades quanto um campo redactedText. O parâmetro redactionPolicies controla a saída, por exemplo, entityMask para rótulos ou characterMask para asteriscos (referência REST).

curl -X POST "$AZURE_LANGUAGE_ENDPOINT/language/:analyze-text?api-version=2026-05-01" \
  -H "Ocp-Apim-Subscription-Key: $AZURE_LANGUAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "PiiEntityRecognition",
    "parameters": {"redactionPolicies": [{"policyKind": "entityMask"}]},
    "analysisInput": {"documents": [
      {"id": "1", "language": "en", "text": "My name is John Doe My phone number is 424 878 9192"}
    ]}
  }'

A resposta de exemplo documentada pela Microsoft retorna "redactedText": "My name is [PERSON_1] My phone number is [PHONENUMBER_1]", além da categoria, posição, comprimento e pontuação de confiança de cada entidade. O Azure também oferece detecção de PII em conversas e documentos, além de contêineres para executar o modelo no seu próprio ambiente.

Versão em Node.js

const res = await fetch(
  `${process.env.AZURE_LANGUAGE_ENDPOINT}/language/:analyze-text?api-version=2026-05-01`,
  {
    method: "POST",
    headers: {
      "Ocp-Apim-Subscription-Key": process.env.AZURE_LANGUAGE_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      kind: "PiiEntityRecognition",
      parameters: { redactionPolicies: [{ policyKind: "entityMask" }] },
      analysisInput: {
        documents: [{ id: "1", language: "en", text: "Call Dana at 212-555-0187." }],
      },
    }),
  }
);
const data = await res.json();
console.log(data.results.documents[0].redactedText);

Microsoft Presidio: remoção de PII com código aberto

O Presidio é executado inteiramente na sua própria infraestrutura. O analisador combina reconhecimento de entidades nomeadas com NLP, expressões regulares, somas de verificação e palavras de contexto; o anonimizador aplica operadores como replace, mask, redact, hash e encrypt. A documentação deixa claro que a detecção automatizada não garante a identificação de todos os dados sensíveis, então planeje medidas de proteção adicionais.

Instalamos o Presidio (analisador 2.2.365 com o modelo en_core_web_lg do spaCy) e o executamos com esta frase sintética:

Olá, sou Dana Whitfield. Envie um e-mail para dana.whitfield@example.com ou ligue para 212-555-0187. Cartão 4111 1111 1111 1111, SSN 078-05-1120. O pedido #A-77231 será enviado para 42 Elm Street.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

text = ("Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187. "
        "Card 4111 1111 1111 1111, SSN 078-05-1120. Order #A-77231 ships to 42 Elm Street.")

results = AnalyzerEngine().analyze(text=text, language="en")
for r in sorted(results, key=lambda r: r.start):
    print(r.entity_type, repr(text[r.start:r.end]), round(r.score, 2))

out = AnonymizerEngine().anonymize(
    text=text,
    analyzer_results=results,
    operators={
        "DEFAULT": OperatorConfig("replace", {"new_value": "<REDACTED>"}),
        "PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
        "EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
        "CREDIT_CARD": OperatorConfig("mask", {"masking_char": "*", "chars_to_mask": 15, "from_end": False}),
    },
)
print(out.text)

O que foi detectado e o que passou despercebido

Texto Detectado como Pontuação Avaliação
Dana Whitfield PERSON 0.85 Correto
dana.whitfield@example.com EMAIL_ADDRESS 1.0 Correto
example.com (dentro do e-mail) URL 0.5 Falso positivo, sobrepõe-se ao e-mail
212-555-0187 PHONE_NUMBER 0.4 Correto, mas com baixa confiança
4111 1111 1111 1111 CREDIT_CARD 1.0 Correto (soma de verificação validada)
078-05-1120 PHONE_NUMBER 0.4 Tipo incorreto: este é um exemplo conhecido de SSN inválido, por isso o reconhecedor de SSN o rejeitou
Elm Street LOCATION 0.85 Parcialmente correto; o número do imóvel "42" permaneceu no texto
A-77231 (ID do pedido) Não detectado Não se aplica Não detectado: identificadores de negócio precisam de regras personalizadas

Três lições deste pequeno teste:

  1. Os limiares de confiança equilibram omissões e ruído. Quando executamos novamente com score_threshold=0.5, o número de telefone (pontuação 0.4) foi descartado e permaneceu no texto sem remoção. Ajuste os limiares por tipo de entidade, não de forma global.
  2. Seus próprios identificadores precisam de reconhecedores personalizados. A adição de um PatternRecognizer para \bA-\d{5}\b com pontuação 0.6 detectou o ID do pedido. Um valor com formato realista de SSN (536-90-4399) foi detectado como US_SSN com pontuação 0.85.
  3. A tokenização reversível funciona. O uso do operador encrypt com uma chave de 128 bits e do DeanonymizeEngine com decrypt restaurou o texto original exatamente.

Um pipeline de remoção de PII para aplicações com LLMs

O padrão comum em produtos de IA é remover os dados, chamar o modelo e restaurar o que o usuário precisa ver:

  1. Regras por campo primeiro. Remova ou substitua campos conhecidos de PII em payloads estruturados conforme o esquema.
  2. Detecte em texto livre. Execute uma API de PII ou o Presidio em mensagens, chamados e documentos.
  3. Pseudonimize de forma consistente. Substitua cada entidade por um marcador estável (<PERSON_1>) e mantenha o mapeamento no seu serviço, nunca no prompt.
  4. Chame o LLM com o texto com PII removidas.
  5. Restaure os marcadores na saída do modelo apenas onde o usuário tem permissão para ver os valores reais.
  6. Registre em log a versão com PII removidas e as contagens de entidades, não o original.
import os, re
from openai import OpenAI
from presidio_analyzer import AnalyzerEngine

analyzer = AnalyzerEngine()
client = OpenAI(api_key=os.environ["FLATKEY_API_KEY"], base_url="https://router.flatkey.ai/v1")

def non_overlapping(results, min_score=0.35):
    kept = []
    # prefer higher scores, then longer spans; drop anything overlapping a kept span
    for r in sorted(results, key=lambda r: (-r.score, -(r.end - r.start))):
        if r.score >= min_score and all(r.end <= k.start or r.start >= k.end for k in kept):
            kept.append(r)
    return sorted(kept, key=lambda r: r.start, reverse=True)

def pseudonymize(text):
    mapping, counters = {}, {}
    for r in non_overlapping(analyzer.analyze(text=text, language="en")):
        counters[r.entity_type] = counters.get(r.entity_type, 0) + 1
        token = f"<{r.entity_type}_{counters[r.entity_type]}>"
        mapping[token] = text[r.start:r.end]
        text = text[:r.start] + token + text[r.end:]
    return text, mapping

ticket = "Customer Dana Whitfield (dana.whitfield@example.com) says order A-77231 never arrived."
safe, mapping = pseudonymize(ticket)
reply = client.chat.completions.create(
    model="claude-haiku-5-5",
    messages=[{"role": "user", "content": f"Draft a short apology email for this ticket:\n{safe}"}],
).choices[0].message.content
for token, value in mapping.items():  # restore only on your side
    reply = reply.replace(token, value)
print(reply)

A etapa non_overlapping é importante: sem ela, a URL detectada dentro do endereço de e-mail corrompe a substituição. Com ela, nosso chamado de teste ficou assim: Customer <PERSON_1> (<EMAIL_ADDRESS_1>) says order A-77231 never arrived. O ID do pedido ainda passa sem alteração, por isso o reconhecedor personalizado da seção anterior deve fazer parte da implementação em produção. O próprio anonimizador do Presidio resolve as sobreposições para você.

Tratamento de falhas e testes

Risco Mitigação
Timeout ou erro 5xx da API de PII Bloqueie o envio em caso de falha: não envie ao LLM o texto sem remoção de PII; coloque na fila e tente novamente
Detecções com baixa confiança Limiares por entidade; revisão semanal de amostras
Idioma não compatível Detecte o idioma primeiro; a detecção de PII do AWS Comprehend abrange apenas inglês e espanhol
Identificadores de negócio (IDs de pedidos, números de conta) Reconhecedores personalizados com expressões regulares ou regras por campo
Falsos positivos que prejudicam o sentido Listas de permissões para nomes de produtos e endereços públicos
PII na saída do modelo Execute a detecção nas respostas antes de registrá-las em log ou exibi-las a outros usuários
Logs que contêm os originais Registre apenas o texto com PII removidas e as contagens de entidades

Crie um conjunto de testes rotulado com mensagens sintéticas semelhantes ao seu tráfego real, incluindo nomes de várias culturas, formatos internacionais de telefone e seus próprios formatos de ID. Meça a revocação por tipo de entidade antes do lançamento e após cada alteração nas regras.

Como escolher uma API de remoção de PII

  • Sua infraestrutura já está na AWS e o texto está em inglês ou espanhol: o Amazon Comprehend é simples e barato para volumes pequenos.
  • Você precisa de tokenização reversível como serviço gerenciado ou de muitos identificadores específicos de cada país: Google Sensitive Data Protection.
  • Você precisa receber diretamente o texto com PII removidas, detectar PII em conversas ou documentos, ou usar contêineres na sua infraestrutura local: Azure Language PII.
  • Os dados não podem sair da sua rede ou você precisa de controle total sobre as regras: Presidio, com reconhecedores personalizados e sua própria avaliação.

Muitas equipes combinam essas opções: Presidio ou regras por campo no fluxo crítico de processamento e uma API gerenciada para varreduras de documentos em lote.

Como isso se integra à Flatkey

A Flatkey é um gateway de modelos: uma única chave e um endpoint compatível com a OpenAI para vários LLMs. Ela não detecta nem remove PII por você, então execute a remoção na sua aplicação antes que as solicitações saiam do seu serviço, como no pipeline acima. A documentação empresarial da Flatkey descreve a retenção zero do conteúdo das solicitações, o que reduz a exposição, mas não substitui a remoção de PII. Leituras relacionadas: política de remoção de dados em APIs de IA, gerenciamento seguro de chaves de API, acompanhamento de custos de LLMs e o catálogo de modelos da Flatkey.

Perguntas frequentes

O que é uma API de remoção de PII?

É uma API que detecta dados pessoais em texto, como nomes, e-mails, números de telefone e documentos de identificação, e retorna a localização desses dados ou uma versão do texto com eles removidos, mascarados ou substituídos.

Qual é a melhor API de remoção de PII?

Depende da sua stack e dos seus dados. O Amazon Comprehend é adequado para textos em inglês e espanhol na AWS, o Google Sensitive Data Protection se destaca pela tokenização reversível e pela variedade de infoTypes, o Azure retorna diretamente o texto com PII removidas e pode ser executado em contêineres, e o Presidio é a melhor opção quando os dados precisam permanecer na sua rede.

Existe uma API gratuita de remoção de PII?

O Presidio é um software gratuito e de código aberto. Os serviços gerenciados têm franquias gratuitas: o AWS Comprehend cobre 50K unidades (5M caracteres) por API por mês durante 12 meses, o primeiro 1 GiB de inspeção do Google por mês é gratuito e o plano gratuito do Azure inclui 5,000 registros de texto por mês.

Devo remover PII antes de enviar prompts ao ChatGPT, Claude ou a outras APIs de LLMs?

Sim, quando o modelo não precisa dos valores reais. Pseudonimize nomes, dados de contato e identificadores, envie marcadores ao modelo e restaure os valores no seu próprio serviço se o usuário precisar deles.

A remoção de PII pode ser revertida?

A remoção simples e o mascaramento não podem. A tokenização ou a pseudonimização baseada em criptografia podem ser revertidas com a chave ou tabela de mapeamento, que você deve armazenar de forma segura e separada dos dados com PII removidas.

Qual é a precisão das APIs de detecção de PII?

Nenhuma é perfeita. No nosso teste com o Presidio, um número de telefone recebeu uma pontuação de apenas 0.4 e um ID de pedido não foi detectado até adicionarmos uma regra personalizada. Meça a revocação nos seus próprios dados sintéticos e bloqueie o envio quando o detector apresentar erros.

A Flatkey remove PII?

Não. A Flatkey encaminha solicitações aos modelos; a remoção deve acontecer na sua aplicação antes do envio da solicitação.