Pular para o conteúdo

Privacidade · 4 min de leitura

Os dados pessoais que os padrões não detectam

A correspondência de padrões é rápida, barata e determinística. Usada sozinha, ela deixa passar justamente os dados pessoais que viram um incidente.

Antes que qualquer coisa chegue a um modelo, você precisa responder com segurança a uma pergunta: isto contém dados pessoais que não temos permissão para enviar? O instinto é procurá-los com correspondência de padrões, que é rápida, barata, determinística e é o padrão há décadas. Mas, usada sozinha, ela também é incompleta de formas difíceis de perceber, e as falhas são justamente os casos que viram um incidente.

O que a correspondência de padrões faz muito bem

Expressões regulares são excelentes para encontrar dados pessoais com um formato previsível. Um número de seguro social ou de identificação nacional tem um agrupamento fixo de dígitos. Um cartão de pagamento tem um comprimento fixo e passa em uma soma de verificação. Endereços de e-mail, números de telefone, endereços IP, referências de conta e códigos postais seguem formatos rígidos que uma expressão regular reconhece em microssegundos.

Para esses casos, a correspondência de padrões é rápida, determinística, auditável e praticamente gratuita, e o determinismo importa tanto quanto a velocidade. Não há motivo para gastar uma chamada ao modelo para confirmar que uma string com formato de número de seguro social é um número de seguro social, e há todos os motivos para preferir um controle cujo comportamento você consegue prever com exatidão.

Onde ela falha sem aviso

A maioria dos dados pessoais reais não chega com um formato fixo. Um nome é só um conjunto de palavras. Um lugar é só um lugar. Pense em duas frases que identificam uma pessoa específica com total certeza e não contêm nenhum padrão reconhecível: “Maria, no quarto 4B” e “a diretora financeira que veio do escritório de Reno no ano passado”.

Uma expressão regular não consegue raciocinar sobre o significado, então deixa passar tudo o que depende do contexto: nomes que ninguém informou a ela, cargos ligados a uma pessoa, identificadores indiretos, referências de conta parafraseadas e identificadores montados ao longo de uma frase em vez de estarem em um único token. Ela também produz falsos positivos na direção contrária, marcando qualquer número de nove dígitos como identificador, e deixa de funcionar assim que os dados chegam em um formato que ninguém previu.

A falha não dá nenhum sinal, e essa é a pior característica que um controle de privacidade pode ter. Nada é sinalizado, nada é registrado e o pipeline informa que tudo deu certo.

O que uma análise baseada no contexto acrescenta

Um detector baseado em modelo lê o texto como uma pessoa leria. Ele consegue reconhecer que “a paciente”, “quarto 4B” e um primeiro nome, juntos, formam uma informação de saúde identificável, mesmo que nenhum token isolado corresponda a nada. Ele detecta nomes que nunca viu, percebe quando uma frase descreve uma pessoa específica e não uma categoria, e se adapta a formulações que nenhuma regra previu.

O custo é que ele é mais lento e probabilístico. Ele raciocina em vez de buscar correspondências, então não convém executá-lo sobre cada byte de cada solicitação se uma regra determinística e barata já resolveu a questão. Isso também significa que o resultado dele é um julgamento, e precisa ser tratado como tal.

A resposta são as duas, em ordem

As duas abordagens falham em lugares opostos, e é exatamente por isso que elas vêm uma depois da outra em vez de competirem. Primeiro, uma verificação determinística e rápida remove os identificadores estruturados de forma barata e previsível. Depois, uma análise baseada no contexto percorre o que sobrou e detecta os nomes, lugares e referências parafraseadas que os padrões não conseguiam ver.

A correspondência de padrões traz volume e precisão; a análise baseada no contexto traz nuance e abrangência. Em camadas, as duas cobrem uma lacuna que nenhuma cobre sozinha, e ambas são executadas enquanto cada token sensível ainda está dentro dos seus sistemas. É a única ordem que ajuda, porque um mascaramento aplicado depois da chamada ao modelo já chegou tarde.

Detectar é metade do controle; a outra metade é o que acontece depois

Um detector que encontra algo e não faz nada consistente a respeito não é um controle. A segunda decisão é de política: diante de uma correspondência, o valor é mascarado, substituído por um token estável para que a frase continue fazendo sentido, removido por completo, ou a solicitação inteira é recusada? Cada tema tem a sua resposta certa, e por isso vale a pena configurar isso por fluxo de trabalho e não de forma global.

Dois controles próximos importam mais do que parece. Primeiro, poder definir o que conta como sensível no seu setor, porque um termo inofensivo em uma área é um identificador em outra. Segundo, manter credenciais e segredos de conexão totalmente fora do tráfego para o modelo, porque se uma chave pode chegar a um prompt, pode chegar a um log, e o log é o que você entrega a um auditor.

E como cada detecção e cada ação ficam registradas, a afirmação muda de forma. “Acreditamos que nossos dados estão seguros” passa a ser um registro que mostra o que foi detectado, o que foi feito a respeito e quando.

Continue lendo

Mais guias sobre IA com governança

Leituras práticas para criar, governar e executar agentes de IA.

Para configurações e parâmetros, consulte a documentação do produto (em inglês).

Comece hoje a criar com o NeuralSeek.

Cadastre-se online e comece com um teste de duas semanas, ou fale com nossa equipe sobre como usar o NeuralSeek na sua própria nuvem.