Esta é uma tradução automática do documento original em inglês. Em caso de conflito entre esta tradução e a versão original em inglês, a versão em inglês prevalecerá. Ler a versão original em inglês
Pseudonimizador no dispositivo: construído e avaliado
2026-05-22 · Caiioo Team
Queríamos resolver o problema de privacidade de sistemas de AI que treinam e retêm informações reais de identificação pessoal. As políticas e acordos de "Retenção Zero de Dados" reduzem o risco, mas estão repletos de exceções. Elas essencialmente dizem: "Não armazenaremos nenhum de seus prompts ou saídas, exceto para: (insira uma longa lista de exceções aqui: fins de segurança, vigilância governamental, retenções judiciais, desenvolvimento de produtos, logs de erros, melhoria dos serviços...)"
Para resolver isso, construímos um filtro de dados pessoais que roda na própria máquina do usuário, vê a mensagem antes de ela sair do dispositivo e retorna a mesma resposta que o usuário teria recebido se tivesse digitado sem filtro algum.
Então, construímos um. A próxima versão do Caiioo incluirá o Pseudonimizador. Acessível através do ícone de escudo no chat do agente, bem como nas configurações.
Este white paper descreve a lógica, a arquitetura, o processo de avaliação e os princípios de design por trás do nosso sistema de filtragem de privacidade.
O que nos propusemos a fazer
Proteção geral de privacidade por minimização de dados. Quando um usuário conversa com um modelo remoto, o modelo não precisa de um nome real, um endereço residencial, um e-mail real ou o número de telefone de um cliente para responder à pergunta do usuário. Ele precisa da forma da pergunta, e precisa que ela pareça uma pergunta real para que o LLM não descarte a consulta como um teste. O filtro, portanto, remove identificadores reais dos dados enviados à AI e costura os valores reais de volta no retorno. O modelo vê nomes e identificadores sintéticos; o usuário vê a conversa real.
Assistência de conformidade com a HIPAA. Um segundo modo visa os 18 identificadores na regra Safe Harbor da HIPAA (§164.514) e a variante mais flexível Limited Data Set. Um clínico, um administrador de saúde ou qualquer pessoa que trabalhe em um fluxo de trabalho coberto pode conversar com um modelo de uso geral sobre casos reais sem enviar informações de saúde protegidas (PHI) para a AI. Nós não somos o oficial de conformidade da entidade coberta — mas podemos ser a camada que impede que as PHI saiam do laptop em primeiro lugar. Nossas avaliações fornecem benchmarks mensuráveis que as organizações podem usar para avaliar a adequação do filtro aos seus padrões de conformidade e privacidade. Todas as medidas de privacidade e segurança são decisões de julgamento que são de responsabilidade do usuário ou da entidade usuária.
Escolhemos ambos porque a engenharia é a mesma, e o caso de uso de PHI é, na verdade, tecnicamente mais fácil devido ao uso de entidades nomeadas distintas, que são mais fáceis de redigir do que os dados mais gerais na categoria de Dados Pessoais. A filtragem HIPAA também é auxiliada pelo fato de estar geralmente em inglês ou espanhol. Detectamos identificadores, substituímos por pseudônimos estáveis e identificadores substituídos no mesmo formato, restauramos no retorno e nunca registramos os valores reais. O mapeamento entre a informação sintética e a informação real permanece apenas no dispositivo do usuário, para que o usuário possa ler informações reais nas respostas do agente. A lista de categorias e a porta de política são o que mudam entre os modos.
Por que regex mais machine learning, e não apenas um deles
Existem duas tecnologias de filtro principais em nosso pseudonimizador: uma linguagem de reconhecimento de padrões determinística chamada regex e modelos de machine learning treinados.
O regex é imbatível em formatos de superfície. Um endereço de e-mail tem um formato ([email protected]). O mesmo vale para um IP, um cartão de crédito, um IBAN, um VIN, um SSN (XXX-XX-XXXX), uma chave de API. Se o formato for confiável, o regex o captura de forma determinística, todas as vezes, sem carga de modelo e sem custo de inferência.
O regex é, no entanto, inútil em relação ao contexto. "O prontuário de Sarah da última terça-feira" contém uma pessoa e uma data, mas nenhuma delas pode ser distinguida apenas pelo seu formato. "O paciente na 14 Elm" contém um endereço que se sobrepõe a mil não-endereços. "O MRN deles é 7741032" precisa das palavras ao redor do número para significar algo.
Um pequeno modelo de linguagem ajustado lida com o contexto — o nosso é um codificador de 110 milhões de parâmetros especialmente treinado, destilado de um modelo de linguagem minúsculo e multilíngue —. Ele lê a frase, não a substring, e é pequeno o suficiente para rodar de forma extremamente rápida em um dispositivo, até mesmo em um celular.
Os benchmarks ilustram as forças complementares das duas camadas. Testamos as duas camadas isoladamente para garantir que cada uma esteja realmente cumprindo seu papel. No conjunto de 150 perguntas do PrivacyBench-PD, onde as perguntas e respostas explicitamente NÃO foram usadas para treinar o modelo:
| Camada | PII capturadas | Taxa de captura |
|---|---|---|
| Apenas Regex | 205 / 670 | 30.6 % |
| Apenas ML | 516 / 670 | 77.0 % |
| Ambas (produção) | 625 / 670 | 93.3 % |
O regex sozinho perde três quartos dos identificadores porque a maioria dos identificadores em prosa real não é estruturada. O ML sozinho perde 16 pontos percentuais que a camada de regex teria capturado — as coisas que são puramente seu formato (um cartão de crédito se parece com um cartão de crédito; o modelo não tem sinal extra para adicionar). Juntos, eles cobrem o que nenhum deles cobre sozinho.
Analisando mais profundamente onde cada camada é decisiva: em todo esse mesmo conjunto, 16 valores de teste foram capturados apenas por regex (e-mails, IPs, contas financeiras, IDs estruturados) e 327 foram capturados apenas por ML (nomes, identificadores contextuais, frases multilíngues).
Pequeno, inteligente, rápido — e roda em qualquer lugar
Tivemos que fazer o filtro rodar no dispositivo, o que foi um desafio de engenharia.
Ele tem que ser pequeno porque nosso aplicativo roda no dispositivo em muitos sistemas: dentro de uma extensão do Chrome, um app macOS, um app iOS, um app Android, ou Windows e Linux. O pacote tem cerca de 113 MB por modelo. Existem dois modelos — um para dados pessoais gerais, um para informações de saúde protegidas — e o modo Safe Harbor executa ambos em paralelo. Entre estes, um dispositivo Android de baixo custo é o de menor desempenho, mas nosso sistema funciona perfeitamente.
Ele tem que ser inteligente porque falsos negativos vazam dados reais para um LLM remoto e falsos positivos estragam a conversa. Nomes devem ser redigidos; pronomes não. O e-mail do médico em uma conversa encaminhada deve ser redigido; o rodapé [email protected] provavelmente não.
Ele tem que ser rápido porque ele se posiciona diretamente no caminho de cada mensagem que o usuário envia ou recebe. Medimos a sobrecarga de ida e volta em menos de 200 ms em uma única thread de CPU, principalmente tokenização. No WebGPU e no Apple Neural Engine, isso é minúsculo comparado à latência de rede da própria chamada do LLM.
Ele tem que rodar em múltiplos ambientes porque o Caiioo é multiplataforma. O mesmo sistema roda em extensões do Chrome, macOS e iOS, Android, e no Windows e Linux. Um modelo de detecção, uma biblioteca de regex, um integrador, uma política — comportamento idêntico em todas as superfícies onde o Caiioo opera.
As pontuações
Após rodadas de testes e treinamento, definimos a 16ª versão dos nossos modelos. Abaixo estão três benchmarks, cada um medindo algo diferente.
Nosso próprio conjunto de testes, 150 perguntas que o modelo nunca viu
Antes de testar contra benchmarks públicos, executamos nosso filtro de Personal Data contra um conjunto de testes interno que mantivemos deliberadamente fora dos dados de treinamento — portanto, o detector nunca viu nenhuma dessas perguntas antes. 150 perguntas divididas em quatro grupos (trechos de código, prosa de documentos, frases intencionalmente desconhecidas e 10 idiomas não ingleses), além de um grupo "negativo" que não contém nenhum dado privado (uma verificação de sanidade para garantir que não fazemos redação excessiva). Pipeline combinado de regex + ML:
| Sub-bench | Capturado | Taxa |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Todos os 4 benches positivos | 625 / 670 | 93.3 % |
(O grupo negativo não tinha dados privados para encontrar. O filtro mascarou uma coisa que não deveria — consistente com os números de precisão mais abaixo.)
O avaliador é rigoroso: cada parte esperada de dados privados deve desaparecer totalmente da saída mascarada para que a pergunta pontue. Sem crédito parcial, sem "perto o suficiente". Isso é mais severo do que benchmarks que pedem a outro LLM para ser o juiz (juízes LLM tendem a ser generosos). Para números diretamente comparáveis contra outros sistemas, veja a seção de confronto direto mais abaixo.
PrivacyBenchHIPAA — 40 perguntas de saúde
Cada pergunta lista informações de saúde protegidas que devem ser redigidas (nomes, números de prontuário médico, etc.) E sinais que devem ser mantidos (datas, geografia, idade se for inferior a 90 — a regra HIPAA Limited Data Set). O avaliador verifica ambas as direções: removemos o que deveríamos ter removido e deixamos intacto o que deveríamos ter deixado intacto?
| Modo | PHI redigido | Retidos mantidos |
|---|---|---|
| Limited Data Set (preservar datas / geografia / idade ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (redigir tudo, incluindo datas) | 99 / 104 (95.2 %) | — |
O submodo Limited Data Set é perfeito neste benchmark. O Safe Harbor — que tem mais a redigir, portanto mais oportunidades de erro — cobre 95.2%.
Resultados categoria por categoria em nossos próprios dados, 200 amostras por modo
Benchmarks públicos agrupam tudo. Nossos dados de teste internos detalham os resultados por categoria (nomes, e-mails, endereços e assim por diante) e executam cada uma de três maneiras: apenas regex, apenas ML e ambos juntos. Isso nos diz exatamente qual tecnologia está capturando qual tipo de identificador — e onde cada uma precisa da outra. Execução mais recente, 2026-05-20:
Resumo em todos os três modos de filtro
| Modo | Recall combinado | Precisão | F2 | Amostras |
|---|---|---|---|---|
| Filtro Personal Data | 97.3 % | 97.8 % | 97.4 | 200 |
| Filtro HIPAA — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| Filtro HIPAA — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Esses números excluem URLs, que deixamos intactas deliberadamente — remover uma URL quebraria ações posteriores como "abrir este link" ou "buscar aquela página". Mais sobre isso na seção de fluxo de trabalho abaixo.
O panorama geral antes das tabelas por categoria: em todos os modos, os identificadores que realmente identificam uma pessoa são capturados em ou perto de 100% das vezes. Nomes, e-mails, números de telefone, endereços postais, IDs governamentais, IDs biométricos, geolocalização precisa, números de prontuário médico, datas de nascimento, números de seguro social — capturados em cada amostra, em cada teste. As categorias onde caímos abaixo de 100% são previsíveis: IDs de dispositivos (enorme variedade de formatos em texto real), IDs institucionais diversos (números de fidelidade, IDs de funcionários — mesmo problema) e fotos (um filtro apenas de texto não consegue ver o que está dentro de uma imagem). Nenhum desses é o identificador "nome em um prontuário" ou "e-mail em um rascunho" que realmente importa para vazamentos. As categorias de alto risco são as confiáveis.
Filtro Personal Data
Ordenado por recall combinado (melhor primeiro), depois por nível de risco (T1 = mais sensível).
| Categoria | Nível | Recall Regex | Recall ML (bruto) | Recall Combinado | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
Analisando os dados, o design de duas camadas está valendo a pena. Endereços postais, datas de nascimento e nomes de pessoas pontuam 0–13% apenas com regex — não há um padrão fixo para corresponder, então apenas o modelo de ML pode capturá-los. E-mails, números de telefone, IPs, IDs governamentais, IDs biométricos e geolocalização precisa pontuam 100% apenas com regex — formatos de superfície que o modelo de ML obtém "de graça". Handles online, IDs de veículos e segredos de autenticação são mistos: regex captura as formas padrão, ML captura o restante. O recall combinado atinge ou excede qualquer que seja a camada individual mais forte, em todas as categorias.
IDs de dispositivos e IDs institucionais diversos são as categorias abaixo de 100%, e sabemos o porquê: esses têm a maior variedade de formatos em texto real. Preferimos ser honestos sobre as categorias onde o recall cai do que fingir que o filtro é perfeito em todos os lugares.
Filtro HIPAA — submodo Limited Data Set
O submodo Limited Data Set preserva datas, geografia e idades de 89 anos ou menos por design — esses são os sinais que o HIPAA permite que uma organização mantenha para pesquisa clínica e operações legítimas.
| Categoria | Nível | Recall Regex | Recall ML (bruto) | Recall Combinado | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
Fotos são uma falha conhecida — um filtro apenas de texto não consegue ver o que está dentro de uma imagem. PHI em imagem é um problema separado que ainda não lançamos. Todas as outras categorias neste modo estão em 100%.
Filtro HIPAA — submodo Safe Harbor
O Safe Harbor remove tudo o que o submodo Limited Data Set teria mantido — datas, idades acima de 89 anos, geografia. Para obter a cobertura mais rigorosa, ele executa ambos os modelos de filtro em paralelo: o específico para HIPAA e o geral para dados pessoais.
| Categoria | Nível | Recall Regex | Recall ML (bruto) | Recall Combinado | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
As duas linhas interessantes são datas gerais (regex 100%, ML 30%) e idades acima de 89 (regex 100%, ML 0%). Nós deliberadamente deixamos o regex lidar com ambos no Safe Harbor: datas têm um formato que o regex captura sempre, e não queremos um modelo probabilístico questionando um limite numérico como ">89". Uma regra determinística é mais confiável do que pedir ao modelo de ML para aprender a mesma regra.
Números gerais em todas as categorias
Somando tudo: como o pipeline completo (regex + ML juntos) se compara a qualquer uma das camadas isoladamente?
| Modo | Camadas | Recall | Precisão | F2 |
|---|---|---|---|---|
| Personal Data | apenas regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | apenas ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | ambos (full) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | apenas regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | apenas ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | ambos (full) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | apenas regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | apenas ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | ambos (full) | 92.4 % | 88.9 % | 91.7 % |
A linha "full" do filtro Personal Data supera ambas as versões de camada única em todas as métricas — combinar regex (para formatos de superfície) com o modelo de ML (para contexto) genuinamente fornece algo que nenhuma camada sozinha consegue. O destaque de 97.3% no início deste post é o número que reflete o que um usuário real obtém. O número na tabela acima é um pouco menor apenas porque inclui a categoria URL, que preservamos deliberadamente para não quebrar links e chamadas de ferramentas.
Confronto direto contra outros filtros de privacidade dedicados
A comparação justa para um filtro de privacidade no dispositivo e quase instantâneo como o nosso é contra outros filtros de privacidade no dispositivo e quase instantâneos — não contra LLMs gigantes hospedados na nuvem que levam segundos por mensagem e precisam de uma viagem de ida e volta na rede. Executamos todos os sistemas desta classe contra os mesmos conjuntos de testes, usando as mesmas regras de correspondência. O mesmo padrão para todos.
A classe de pares:
- openai/privacy-filter — filtro de privacidade dedicado de código aberto da OpenAI. Cerca de 50 milhões de parâmetros, pequeno o suficiente para rodar em qualquer navegador moderno.
- piiranha-v1 — um detector de 278M de parâmetros da iiiorg. Sua licença o restringe apenas a pesquisa e avaliação (podemos medi-lo, mas ele não pode ser enviado comercialmente).
- Microsoft Presidio — o redator de código aberto mais amplamente implantado, combinando correspondência de padrões tradicional com um pequeno modelo de linguagem para contexto.
- Família GLiNER PII — uma família de classificadores de entidades de propósito geral e pequenos. Knowledgator envia variantes small (~44M), base (~86M) e large (~304M); a NVIDIA lançou uma variante de 570M em outubro de 2025.
- Caiioo em todos os três modos (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall em todos os cinco conjuntos de testes, ordenados com Caiioo primeiro:
| Sistema | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 locais) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo lidera a classe de filtros dedicados nos dois maiores testes (PD-200 e PHI-200), empata ou lidera nos benchmarks públicos e fica em segundo lugar no multilíngue. No menor teste (PrivacyBench PD-25, apenas 25 perguntas), Caiioo e openai/privacy-filter empatam em 96.2%. No multilíngue, o openai/privacy-filter ainda lidera com 94.9%, com o Caiioo em 92.6% — o idioma onde ficamos mais atrás é o chinês; em todos os outros lugares estamos no topo ou perto dele. Se a cobertura multilíngue for de missão crítica, o openai/privacy-filter é uma alternativa razoável. Para a maioria das outras cargas de trabalho nesta classe, o Caiioo é a escolha.
O resultado HIPAA é o destaque. Ambos os modos Caiioo HIPAA atingiram 100% de recall em todos os testes HIPAA — cada nome de paciente, cada número de prontuário médico, cada data de nascimento, cada número de conta é capturado. O segundo melhor sistema é o openai/privacy-filter com 93.7% no PrivacyBenchHIPAA — uma lacuna de 6.3 pontos, em um benchmark onde cada falha é uma exposição no mundo real.
Um segundo número que vale a pena ler: redação excessiva — mascarar coisas que não eram realmente dados privados. A redação excessiva não é um dano à privacidade, é um custo de usabilidade. Mascare coisas demais e o raciocínio do LLM piora, e a resposta retornada é degradada. Caiioo mascara desnecessariamente 1–24 vezes nos conjuntos de testes. Presidio: 10–51. GLiNER da NVIDIA: 31–64 apenas nos testes HIPAA. A precisão importa tanto quanto o recall quando o objetivo é a melhor resposta possível com a menor exposição possível.
E quanto a usar apenas um LLM de fronteira como filtro?
Eles podem — e no recall bruto, eles vencem. Grandes LLMs de propósito geral (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B e similares), rodando na nuvem ou localmente, podem pontuar 95–100% em todos os testes, incluindo multilíngue. Essa é uma opção real para usuários que precisam de recall máximo e estão dispostos a pagar por isso.
No entanto, as desvantagens são reais:
- É lento. Segundos por mensagem em vez de milissegundos. O filtro fica na frente de cada mensagem que o usuário envia.
- Ou a mensagem sai da máquina do usuário, ou o modelo sai. Para filtrar na nuvem, a mensagem tem que ir para lá — derrotando o propósito. Para filtrar no dispositivo, é necessário baixar um modelo de 1–17 GB.
- Pode ser enganado. Um modelo generativo pode ser convencido, no meio da mensagem, a não redigir (um ataque de "prompt injection"). Um pequeno classificador como o nosso não pode.
- Mesma entrada, saída diferente. Modelos generativos nem sempre dão a mesma resposta duas vezes. Isso quebra a viagem de ida e volta — mascarar na saída e desmascarar na volta depende do mesmo valor real sempre mapeando para o mesmo fake.
Caiioo foi construído para o outro lado dessa troca: um filtro minúsculo, previsível e de sub-segundo que roda no editor antes de o usuário pressionar enviar, e que sempre produz o mesmo fake para o mesmo valor real dentro de uma conversa, para que a viagem de ida e volta permaneça coerente. A tabela de classe de pares acima é a comparação direta para esse tipo de caso de uso.
A prova está nos detalhes
Os benchmarks são um ponto de partida, não a linha de chegada. O filtro está integrado ao novo recurso do Caiioo: o pseudonymizer — o componente que realmente se posiciona entre o compositor e o modelo.
Aqui está o que acontece quando o usuário pressiona enviar.
- Detectar. A camada regex é executada primeiro — é determinística e rápida na escala de microssegundos. O modelo de ML é executado em seguida no que restar. Se as duas camadas se sobrepuserem no mesmo trecho de texto, usamos uma regra simples: regex vence em formatos de superfície, ML vence no contexto.
- Etiquetar próprio vs. outros. O Caiioo separa identificadores que se referem ao usuário de identificadores que se referem a outras pessoas. O usuário pode optar por redigir apenas um, ou ambos. Nomes que o usuário adicionou a um dicionário pessoal sempre contam como "próprio".
- Substituir. Cada valor real recebe um pseudônimo estável e compatível com o estilo. "Sarah Goldberg" torna-se "Maya Hartwell" — e permanece "Maya Hartwell" durante toda a conversa, para que o raciocínio do modelo sobre essa pessoa não se fragmente entre os turnos. Uma tabela de consulta de real-para-falso é mantida no dispositivo do usuário, criptografada com uma chave do keychain da plataforma.
- Enviar. O modelo recebe uma mensagem totalmente falsa. Nenhum identificador real jamais cruza a rede, e nosso log de auditoria registra apenas contagens — nunca os valores em si.
- Restaurar. A resposta em streaming é mapeada de volta conforme chega. "Maya Hartwell" na resposta do modelo torna-se "Sarah Goldberg" antes de chegar à tela, renderizada com um pequeno brilho (glow pill) para que o usuário possa ver rapidamente o que foi protegido.
- Restaurar argumentos de ferramentas também. Se o modelo chamar uma ferramenta — enviar um e-mail, abrir um ticket, escrever em um documento — e os argumentos contiverem dados falsos, substituímos pelos valores reais de volta antes da execução da ferramenta. O modelo raciocina sobre os dados falsos; a ação utiliza o valor real.
O filtro não se importa com qual serviço de AI está em uso. Ele é executado antes que a mensagem chegue ao modelo, portanto, OpenRouter, Anthropic, Google, OpenAI e um Ollama local recebem todos a mesma carga mascarada. Adicionar um novo provedor não reabre a brecha de privacidade.
Quem ele protege
O usuário. O nome, e-mail, endereço, telefone, IP e identificadores biométricos de um usuário — as coisas que, tomadas em conjunto, identificam uma pessoa para um agregador — nunca saem do dispositivo quando o filtro está ativado.
As pessoas de quem o usuário fala. A maioria das ferramentas de privacidade foca na pessoa que digita, mas o que ignoram é o 'contrato social' — o fato de que todos temos uma responsabilidade para com os outros, assim como para conosco. Enviar "Por favor, analise a conduta do Sr. Saunders por incompetência" para um LLM, onde pode ser registrado em logs do sistema indefinidamente, é irresponsável (e potencialmente difamatório). Pedir ajuda a um LLM com uma planilha do Google que contém 1.000 contatos comerciais deposita todos eles na armadilha de retenção de dados (em graus variados, dependendo da 'retenção zero de dados' real em vigor). O filtro do Caiioo também cobre terceiros: o cliente para quem um contrato está sendo redigido, o paciente cujo registro está sendo analisado, o colega cujo e-mail foi colado no contexto. Eles não consentiram que um LLM remoto visse seus identificadores. O filtro respeita isso por padrão; o usuário pode mudar para "apenas eu" ou "apenas outros" se um fluxo de trabalho exigir.
Entidades — empresas, hospitais, firmas. Números de conta, números de licença, números de prontuário médico, detalhes de roteamento financeiro, IDs internos, chaves de API, listas de clientes. Uma empresa tem o mesmo interesse de minimização de dados que uma pessoa. Um clínico usando o Caiioo para redigir uma nota de alta não está enviando o número do prontuário médico do paciente para a OpenAI. Um advogado não está enviando o número da conta do cliente para a Anthropic. Um engenheiro de suporte não está enviando a chave de API do log do cliente para o Google. O filtro não pergunta se o identificador pertence a uma pessoa ou a uma entidade — ele apenas o mantém no dispositivo.
Máxima utilidade, mínima exposição
O objetivo principal é que o usuário não deva sentir o filtro.
A maioria das ferramentas de privacidade força uma escolha: redigir agressivamente e ver a resposta do modelo piorar, ou manter o prompt utilizável e ver a promessa de privacidade erodir. Rejeitamos essa troca. O modelo ainda recebe um prompt totalmente formado — ele vê um nome, um lugar, uma data, um número de prontuário médico, todos nas posições gramaticais corretas. Ele apenas vê dados falsos. Seu raciocínio é idêntico; apenas as strings são limpas.
A substituição estável é o que faz isso funcionar. Como o mesmo valor real sempre mapeia para o mesmo valor falso dentro de uma conversa — na mensagem do usuário, no resultado da ferramenta que volta referenciando esse nome, na resposta anterior do modelo que o mencionou — o modelo tem uma pessoa, lugar ou coisa coerente sobre a qual raciocinar. Conversas de múltiplos turnos não se perdem. Chamadas de ferramentas não quebram. Subagentes herdam o mapa da conversa pai e permanecem consistentes em toda a tarefa.
A saída que o usuário vê é a conversa real. Os dados que o provedor vê são uma ficção coerente. O trabalho acontece na lacuna entre essas duas visões, e o objetivo — o único objetivo — é tornar essa lacuna invisível.
Um filtro de privacidade que atrapalha será desativado. Um filtro de privacidade que desaparece no fluxo de trabalho é o único tipo que vale a pena lançar.
Esse é o padrão que construímos.