Design de Observabilidade para a Era da IA — Reconciliação da Proteção de PII com a Buscabilidade da IA

Divulgação de assistência de IA: Este artigo foi redigido com a ajuda de Claude. Todo o conteúdo técnico, decisões de design, referências de código e capturas de tela refletem sistemas de produção que eu projetei e opero na airCloset; a prosa foi revisada por mim antes da publicação.

Oi, eu sou Ryan, CTO da airCloset.

No Parte 1, eu passei pelos quatro eixos de monitoramento (aplicação / infraestrutura / CI / LLM) e a forma deliberadamente diferente que cada um acaba tendo. Esse é o lado de escrita da pilha de observabilidade, mais ou menos finalizado.

Mas moldar o lado de escrita não é o fim da história. No momento em que os dados de produção fluem pela pilha, você precisa bloquear o caminho que os PII podem tomar para entrar — e isso é verdade com ou sem IA. É o tipo de problema clássico de observabilidade onde, se você cortar caminhos, você caminha diretamente para um incidente de vazamento.

Historicamente, o conjunto de pessoas que podiam ler logs sobrepunha-se em grande parte ao conjunto que podia ler o banco de dados. Para engenheiros com acesso ao banco de dados, os logs não eram um caminho adicional para dados pessoais — o que colocava as defesas do lado dos logs em uma posição onde reforçá-las não movia significativamente a linha de defesa geral para a maioria das organizações.

A IA quebra essa premissa. Não-engenheiros puxando logs através do MCP não têm acesso ao banco de dados. Os logs se tornaram, pela primeira vez, um caminho onde alguém sem acesso ao banco de dados pode alcançar dados pessoais. Além disso, o conteúdo dos logs agora flui para a entrada da IA, o que introduz novas superfícies de exposição: transmissão para o modelo e reaparecimento na saída do modelo. A proteção de PII nos logs mudou de "higiene que vale a pena fazer" para "requerido como uma redesign de limite de confiança." Essa é a premissa da qual este post parte.

E além disso, se a pilha de observabilidade não for consultável pela IA, todo o objetivo de "observabilidade consumível por IA" da Parte 1 desmorona.

A Parte 2 é sobre como eu reconciliava esses dois — proteger PII enquanto mantenho a pesquisabilidade para IA — e como essa combinação acaba impulsionando Auto-Cura de falhas de CI a propostas de PR.

A Pilha de Observabilidade É um Caminho Natural para PII

O aplicativo emite um log → ele aterrissa no Loki → a IA o consulta através do MCP. Levante esse fluxo ingênuo e você obtém:

• Endereços de e-mail e números de telefone de clientes em logs de erro
• Payloads de resposta de pedidos dentro de rastros
• Logs de consulta ao banco de dados que emitem linhas completas de tabelas

O acúmulo de PII em texto simples na pilha de observabilidade significa que a IA pode pesquisá-lo diretamente. Isso não é realmente um problema de IA, é um problema de observabilidade: a pilha em si se torna um conduto de PII. Ao mesmo tempo, se você limpar completamente os PII, você perde "quero investigar o ticket de suporte do Cliente A" como uma consulta, que é um fluxo de trabalho normal de suporte.

O cortex (a plataforma interna de IA) teve que reconciliar ambos. O princípio chave foi: não tornar "bloquear o caminho do PII" e "pesquisar por PII" mutuamente exclusivos.

Nota: "cortex" aqui se refere ao codinome da plataforma interna de IA da airCloset. Não relacionado ao Snowflake Cortex, Palo Alto Networks Cortex, etc.

Design de PII em Múltiplas Camadas — Seis Camadas

O manuseio de PII do cortex é composto por seis camadas, cada uma com um papel diferente:

A quarta linha — pesquisar com a mesma função em ambos os lados — é onde a troca de segurança / usabilidade fica realmente apertada.

Usarei e-mail como exemplo contínuo, mas as seis camadas protegem mais do que e-mail. PII abrange nomes (incluindo leituras fonéticas), números de telefone, endereços, códigos postais, datas de nascimento, detalhes de cartões e bancos, IDs de serviços externos, e mais. A técnica de anonimização varia de acordo com a natureza do campo — hashing de mesma função para preservar a correlação (e-mail, telefone), mascaramento parcial (nomes, endereços), redação completa (números de cartões, tokens) — e essa decisão é feita por campo. O que permanece constante é a estrutura: qual das seis camadas a protege, e como. Essa é a parte reutilizável do design.

E essa anonimização não se limita a logs de observabilidade (Loki) também. Uma ferramenta MCP que consulta um banco de dados de serviços, por exemplo, puxa nomes de clientes, endereços e números de telefone para seu conjunto de resultados, então as mesmas regras de anonimização de PII são aplicadas antes que qualquer coisa seja devolvida à IA. A regra consistente é "anonimizar PII em cada caminho de dados que chega à IA," aplicada em todos os tipos de fontes de dados, não apenas em uma.

Hash em Ambos os Lados de Escrita e Pesquisa

Remover PII dos logs de forma ingênua e você não pode mais responder "deixe-me ver os logs do Cliente A." Mas se você hash na hora da escrita e armazena esse hash no log, o lado de pesquisa pode executar a mesma função de hash sobre a entrada e encontrar o registro correspondente. O e-mail em texto simples nunca toca em nenhuma das extremidades.

Concretamente:

Lado de escrita:

// Código do aplicativo
logger.info("Assinatura atualizada");