Governança de dados em IA
Governança de dados em IA é impedir que informação sensível — PII, segredos, dados de cliente — saia da sua operação para o provedor do modelo ou para logs sem controle. Este guia detalha o que vaza num prompt, como mascarar ou bloquear antes do envio, por que o controle precisa ser fail-closed e como manter o dado sensível fora dos logs — tudo na camada do gateway.
PII e segredos
PII e segredos vazam quando informação sensível colada num prompt sai direto pro provedor — não é um ataque, é o uso normal sem barreira.
O dado sensível raramente vaza por má-fé: vaza porque o caminho mais curto é colar tudo no prompt. Um CPF para o modelo conferir, uma chave de API dentro de um trecho de código que se quer explicar, o segredo de um cliente embutido num contexto que parecia inofensivo — cada um desses vira token enviado para fora da sua operação. E não para no provedor: o mesmo conteúdo costuma ser registrado em logs de requisição, de monitoramento ou de depuração, muitos deles fora do seu controle. O problema não é alguém burlando uma proteção; é não haver proteção nenhuma entre o que o usuário digita e o modelo que recebe.
Por ser uso normal, não dá para resolver com treinamento ou política escrita: ninguém lembra de limpar o prompt na pressa, e um único esquecimento já expõe o dado. A diferença entre uma operação que controla isso e uma que não controla está em onde a inspeção acontece. Se cada chamada atravessa um ponto único antes de chegar ao provedor, esse ponto pode olhar o conteúdo e agir sobre o que é sensível. Sem esse ponto, o dado já saiu quando alguém percebe — e o que saiu não volta.
Na Horse Labs, cada chamada passa por um guardrail SecOps no gateway antes de chegar ao provedor — o ponto único onde PII e segredos podem ser detectados antes do envio.
Mascarar ou bloquear
Ao detectar dado sensível, o gateway pode mascarar o trecho ou bloquear a chamada inteira — conforme a política, em modo Off, Monitor ou Block.
A detecção do dado sensível tem duas frentes complementares. A primeira é determinística: padrões conhecidos — chaves de API, segredos, formatos de documento — reconhecidos por regex executada sob o Google RE2, que é imune a ReDoS e por isso roda com segurança em cada chamada. A segunda é de NLP, com o Microsoft Presidio, que reconhece o que não tem formato fixo, como nome de pessoa. Juntas, cobrem tanto o segredo que casa com um padrão rígido quanto a PII que só se identifica pelo contexto. Ao registrar um achado, há duas respostas possíveis: mascarar o trecho, deixando a chamada seguir sem o dado sensível, ou bloquear a requisição por inteiro.
Qual resposta usar é decisão de política, definida por organização e com três modos. Em Off, a verificação não roda; em Monitor, o achado é registrado mas a chamada segue, o que serve para medir a exposição antes de endurecer; em Block, o dado sensível impede o envio. Assim cada organização calibra o rigor ao próprio risco — começar observando, entender o que aparece nos prompts e só então passar a bloquear — sem trocar de ferramenta nem reescrever integração a cada ajuste.
Na Horse Labs, o guardrail combina detecção determinística (regex sob RE2, imune a ReDoS) com uma camada NLP (Presidio) para PII, mascarando ou bloqueando conforme a política por organização nos modos Off, Monitor ou Block.
Fail-closed
Um DLP que falha aberto não é um DLP: se a camada de PII está em Block e o Presidio fica indisponível, a chamada é bloqueada, não liberada.
Todo controle de segurança encara a mesma pergunta no momento da falha: o que acontece quando a verificação não consegue rodar? Há duas respostas, e elas são opostas. Falhar aberto significa deixar a chamada passar quando o detector está fora do ar — conveniente, mas é exatamente nesse instante que o dado sensível escapa sem ninguém ver. Falhar fechado significa bloquear a chamada quando não dá para verificar. Um DLP que falha aberto oferece proteção só enquanto tudo funciona, ou seja, deixa de proteger justamente quando seria preciso; na prática, não é proteção, é uma falsa sensação dela.
Por isso o comportamento na falha tem que acompanhar a intenção da política. Se a organização colocou a detecção de PII em Block, ela declarou que aquele dado não pode sair sem checagem — e essa regra precisa valer inclusive quando a camada de NLP está indisponível. Nesse caso a chamada é bloqueada, não liberada: o pior resultado passa a ser uma requisição recusada que pode ser repetida, em vez de um vazamento silencioso e irreversível. A escolha de falhar fechado é o que separa um controle de verdade de um enfeite que cede na primeira pressão.
Na Horse Labs, o guardrail é fail-closed: com a camada de PII em Block e o Presidio inalcançável, a chamada é bloqueada, então o dado sensível não sai sem checagem mesmo durante uma falha.
Dados nos logs
Dado sensível não pode parar em log sem controle — um ponto único pré-call resolve isso de uma vez, em vez de cada desenvolvedor limpar na mão.
O vazamento por log é o mais traiçoeiro porque é silencioso. Mesmo que o provedor descarte o conteúdo, o prompt costuma passar por camadas que registram tudo — proxies, ferramentas de observabilidade, arquivos de depuração — e qualquer uma delas pode guardar o dado sensível por tempo indefinido, em lugares que ninguém revisa. Diferente de uma resposta errada, que alguém nota, o dado parado num log fica invisível até o dia em que aquele log é exposto. A informação saiu da fronteira de controle sem que houvesse uma decisão a respeito.
A alternativa de deixar cada desenvolvedor limpar o prompt na mão não escala e não é confiável: depende de todo mundo lembrar, sempre, em todo código. O controle eficaz é estrutural — interceptar o conteúdo num ponto único, antes da chamada sair, e ali mascarar ou bloquear o que é sensível. Resolvido pré-call, o dado já não está presente quando o restante da cadeia registra a requisição: o que não foi enviado não pode ser logado. Um ponto de controle substitui dezenas de limpezas manuais espalhadas, e a garantia deixa de depender de disciplina individual.
Na Horse Labs, o guardrail roda pré-call no gateway, então o dado sensível é mascarado ou bloqueado antes de a chamada seguir — e não chega aos logs da cadeia adiante.
FAQ
O que é governança de dados em IA?
É o conjunto de controles que impede que informação sensível — PII, segredos, dados de cliente — saia para o provedor do modelo ou para logs sem controle, inspecionando cada chamada na camada do gateway antes do envio.
DLP no gateway substitui revisão de prompt manual?
Sim — em vez de cada desenvolvedor lembrar de limpar o prompt na mão, um ponto único pré-call mascara ou bloqueia o dado sensível, de forma consistente e auditável, sem depender de disciplina individual.