By · Last updated 2026-06-05

Voltar ao BlogTécnico

Por que a Detecção Binária de PII Está Falhando com...

Detectado/não detectado é insuficiente para contextos de conformidade que exigem julgamento humano.

June 5, 20268 min de leitura
confidence scoringPII detectionlegal discoverycomplianceGDPR audit

title: "Por que a detecção binária de DCP falha em conformidade" description: "Indicadores detectado/não-detectado não são suficientes para decisões de redação defensáveis. O scoring de confiança transforma a anonimização de DCP de uma suposição binária em um controle de conformidade auditável." category: technical publishedAt: 2026-06-21 tags:

  • scoring de confiança
  • detecção de DCP
  • discovery jurídico
  • conformidade
  • auditoria RGPD readingTime: 8

Por que a detecção binária de DCP falha em conformidade

Atualizado para 2026

Toda ferramenta de detecção de dados pessoais enfrenta um problema central. A mesma cadeia de texto pode ser um dado pessoal em um contexto e não em outro.

"João" em um arquivo de cliente é um titular de dados. "João" em um texto histórico sobre João Paulo II não é. Um número de nove dígitos em um prontuário médico é um identificador HIPAA. Os mesmos nove dígitos em um código de produto não são.

Um indicador sim/não não consegue lidar com isso. Ele impõe duas escolhas ruins: redigir todas as cadeias que podem ser dados pessoais, ou redigir apenas as correspondências certas. Ambas falham no direito, onde cada decisão deve ser clara e documentada.

Uma pontuação de 0 a 100 por entidade oferece um terceiro caminho. Ele orienta regras em camadas, filas de revisão humana e registros de auditoria completos.

O limite dos indicadores sim/não

O contexto muda o significado dos dados. Dois arquivos podem conter a mesma cadeia. Em um, são dados pessoais. No outro, não. Um indicador não pode mostrar isso. Um número pode.

Com apenas um indicador, suas duas opções são ruins. A sobre-redação destrói o valor do documento. A sub-redação cria risco legal. Nenhuma das duas resiste em um tribunal.

Discovery jurídico: por que as pontuações são necessárias

O discovery jurídico tem regras que tornam obrigatória a detecção com pontuação.

O problema da sobre-redação. Redigir nomes de advogados ou citações judiciais prejudica as provas. Tribunais já sancionaram advogados por sobre-redação. A mesma jurisprudência que cobre a sub-redação se aplica aqui também.

O problema da sub-redação. Não detectar dados pessoais reais cria riscos. Isso inclui violações de privacidade do cliente, reclamações à OAB e, em alguns lugares, acusações criminais.

A necessidade de explicar cada decisão. Quando um tribunal pergunta por que um item foi redigido, os advogados devem explicar. "A ferramenta sinalizou" não é suficiente. "A ferramenta pontuou isso em 94% como número de previdência social. Nossa regra redige automaticamente acima de 85%." Isso é suficiente.

Um indicador sim/não não pode dar essa resposta. Uma ferramenta com pontuação e regras definidas pode. Veja também: Defendendo redações: pontuações de IA nos tribunais.

Um sistema de revisão em três camadas

A configuração mais eficaz usa três camadas baseadas na pontuação da entidade.

Camada 1 — Automático (acima de 85%):

  • Itens que correspondem a formatos de alta certeza (SSN, IBAN, MRN)
  • Redigidos automaticamente sem etapa humana
  • O registro captura tipo de entidade, pontuação, método e hora
  • Exemplo: "571-44-9283" a 97% como SSN — redigido automaticamente

Camada 2 — Revisão humana (50–85%):

  • Itens que podem ser dados pessoais mas requerem julgamento
  • Enviados a um revisor para aceitar, rejeitar ou reclassificar
  • O registro captura tipo de entidade, pontuação, ID do revisor, decisão e hora
  • Exemplo: "João Silva" em um doc técnico a 67% — revisor confirma que é um nome — redigido

Camada 3 — Apenas sugestão (abaixo de 50%):

  • Itens de baixa certeza mostrados como sugestões
  • Não redigidos automaticamente; revisor pode agir ou ignorar
  • O registro captura tipo de entidade, pontuação e decisão do revisor
  • Exemplo: "Silva" em um documento de produto a 42% — revisor determina que é um nome de empresa — não redigido

Apenas a Camada 2 requer trabalho humano. Todas as três camadas produzem registros de auditoria.

Como as pontuações são construídas

Ferramentas de DCP combinam sinais para produzir um número por entidade.

Padrões regex. Uma correspondência exata com o formato SSN obtém uma pontuação base alta. Uma correspondência parcial obtém uma mais baixa.

Saída do modelo. Modelos de reconhecimento de entidades nomeadas atribuem uma probabilidade por classe. Uma pontuação de 0,93 para PESSOA produz uma detecção de alta certeza.

Sinais de contexto. O texto ao redor da entidade ajusta a pontuação. "Meu SSN é 571-44-9283" a aumenta. "Código de produto 571-44-9283" a diminui.

Regras de conjunto. Os sistemas combinam sinais de regex, modelo e contexto com pesos definidos. O número final reflete todas as evidências disponíveis.

Esse número orienta cada decisão de limiar em seu fluxo de trabalho. Para mais sobre falsos positivos em ferramentas sim/não: O imposto de falsos positivos em ferramentas de DCP.

Sinistros de seguros: um exemplo real

Arquivos de seguros misturam DCP claras — nome do segurado, endereço, número de previdência social — com dados dependentes de contexto: nomes de testemunhas, nomes de empresas, assinaturas de peritos.

Uma ferramenta sim/não redige todos os nomes (incorreto para empresas) ou perde nomes de testemunhas (um risco). Uma ferramenta com pontuação trata cada item individualmente:

  • SSN com rótulo "policyholder SSN" a 96% — redigido automaticamente
  • Nome do segurado, marcado PESSOA, a 91% — redigido automaticamente
  • Empresa contratada, marcada ORG, a 78% — revisada — revisor rejeita a redação
  • Nome da testemunha, marcado PESSOA, a 82% — revisado — revisor aceita
  • Nome do perito, marcado PESSOA, a 71% — revisado — revisor aceita (dados de terceiros)

Cada decisão tem uma base numérica. O registro de auditoria está completo.

Construindo registros de conformidade

Para o RGPD Artigo 5(1)(f) e a HIPAA Security Rule, ferramentas com pontuação geram registros automaticamente.

Registros de auditoria por entidade capturam tipo de entidade, pontuação, tipo de decisão (automática ou manual), ID do revisor e hora. Estes se exportam como CSV para investigações de autoridades de proteção de dados.

Registros de limiar documentam as configurações atuais e cada alteração. Cada alteração inclui quem a fez, quando e por quê. Isso demonstra uma política gerenciada e deliberada.

Relatórios de estatísticas cobrem taxas de detecção por tipo de entidade, taxas de revisão da Camada 2 e taxas de substituição. Eles respondem a uma autoridade de dados que pergunta: "Mostre-nos seus controles."

Para orientação sobre trilhas de auditoria HIPAA: Redação explicável: auditorias HIPAA.

Um indicador sim/não é uma suposição. Uma pontuação é evidência.

Fontes

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.