Governança de IA corporativa: o guia dos 4 eixos
Governança de IA é o conjunto de controles que mantém o uso de modelos de linguagem previsível, auditável e sob o seu domínio. Na prática, ela se decompõe em quatro eixos: dados, custo, acesso e modelos. Este guia define cada um e mostra como resolvê-los na camada de infraestrutura — um LLM gateway self-hosted — em vez de confiar no provedor.
Governança de dados
Governança de dados em IA é garantir que informação sensível (PII, segredos, dados de cliente) não vaze para o provedor do modelo nem para logs sem controle.
Sem governança, qualquer prompt sai da sua operação direto pro provedor — e leva junto o que não deveria. CPF, chave de API, segredo de cliente coladas no texto viram tokens enviados pra fora e, muitas vezes, registradas em logs de quem você nem controla. O vazamento não é um ataque: é o uso normal, sem nenhuma barreira entre o dado sensível e o modelo.
Resolver isso na camada de infraestrutura significa inspecionar cada chamada antes que ela chegue ao provedor. No gateway, um guardrail de DLP roda pré-call e analisa o conteúdo em duas frentes: detecção determinística por padrão (segredos, chaves, formatos conhecidos) e uma camada de NLP que reconhece PII como nome de pessoa. Ao identificar um achado, dá pra mascarar o trecho ou bloquear a chamada inteira — antes do dado sair.
O efeito é que informação sensível não chega silenciosamente ao provedor nem aos logs. A política é definida por organização, com modos de observar ou bloquear, e o ponto de controle é um só — em vez de depender de cada desenvolvedor lembrar de limpar o prompt na mão.
Na Horse Labs, um guardrail SecOps roda pré-call no gateway com detecção determinística (regex sob RE2, imune a ReDoS) mais uma camada NLP com Presidio para PII, mascarando ou bloqueando conforme a política por organização — e é fail-closed: se a camada de PII está em Block e o Presidio fica indisponível, a chamada é bloqueada, não liberada.
Governança de custo
Governança de custo de LLM é tornar o gasto com modelos previsível e atribuível: teto por orçamento, bloqueio antes do estouro e custo rastreado por cliente, time ou projeto.
Sem governança, o custo de IA aparece só na fatura — e já estourado. O provedor cobra por token consumido, mas não responde "quem gastou, em quê e por qual contrato". Em operação multi-cliente isso é inviável: você não consegue cobrar o custo certo nem prever o mês seguinte.
A governança de custo resolve isso na camada que fica entre a sua operação e os provedores. Cada chamada passa por um ponto único onde dá pra aplicar teto de orçamento, alertar em limiares (50%, 80%, 100%) e bloquear automaticamente quando a verba acaba — antes do estouro, não depois. O gasto é atribuído por centro de custo, então cada cliente, time ou projeto carrega o próprio número.
O efeito é duplo: previsibilidade financeira (sem surpresa na fatura) e atribuição correta (você cobra o custo real de cada contrato e enxerga onde o gasto não otimizado está — por exemplo, um modelo caro rodando uma tarefa que um modelo leve resolveria).
Na Horse Labs, o gateway aplica orçamento por centro de custo com alertas em limiar e bloqueio automático no estouro; o gasto por cliente fica visível em tempo real no Console e pode ser entregue por relatório.
Governança de acesso
Governança de acesso é controlar quem (pessoa ou agente) pode usar quais modelos e dados, com credenciais que nunca ficam expostas e trilha de auditoria de cada uso.
Sem governança de acesso, todo mundo — e todo agente — alcança qualquer modelo com a mesma credencial, normalmente uma chave de API solta no código ou numa variável de ambiente. Quando ela vaza, vaza tudo; e quando algo dá errado, não há como reconstruir quem usou o quê. Em operação com vários clientes, o pior é a falta de fronteira: o dado de um acaba acessível pelo contexto do outro.
Tratado na infraestrutura, o acesso vira papel, não chave. Cada pessoa ou agente opera sob um perfil com permissões escopadas, e tudo é filtrado por organização — o dado de um cliente fica isolado do de outro. As credenciais dos provedores ficam num cofre de segredos, entregues aos serviços sob demanda e nunca embutidas nos próprios agentes ou modelos; alterar um segredo exige um segundo fator. Cada ação sensível fica registrada.
O resultado é que você controla quem chega a quais modelos e dados, mantém as credenciais isoladas do código que as consome e tem trilha de auditoria de cada uso — a base para responder "quem fez o quê" sem reconstruir nada.
Na Horse Labs, o controle de acesso é RBAC com três papéis (operator de plataforma, admin de uma organização, member/viewer self-service) tudo escopado por organização e validado por testes de integração; os segredos vivem no HashiCorp Vault, entregues via AppRole e nunca embutidos nos agentes, com escrita protegida por 2FA (TOTP) e cada ação sensível na trilha de auditoria.
Governança de modelos
Governança de modelos é decidir e impor quais modelos a organização pode usar — uma allowlist aprovada — e rotear cada tarefa pro modelo certo, sem lock-in de provedor.
Sem governança de modelos, qualquer modelo que o provedor expõe está disponível por padrão — inclusive os caros, os experimentais e os que sua organização nunca aprovou. Some a isso o código amarrado à API de um único fornecedor e você tem dois problemas: falta de controle sobre o que pode rodar e lock-in, em que trocar de provedor vira reescrita.
Na camada de infraestrutura, isso se inverte com uma allowlist que começa desligada: nada é utilizável até ser explicitamente aprovado. O catálogo de modelos disponíveis vem ao vivo da API de cada provedor, não de uma lista fixa que envelhece, e a aprovação é imposta no gateway — um modelo não aprovado simplesmente recebe 403. O roteamento é por curinga por provedor, então adicionar ou trocar um modelo é configuração, não reescrita.
O efeito é que a organização decide quais modelos podem ser usados e direciona cada tarefa pro modelo certo, sem ficar presa a um único fornecedor — controle e portabilidade na mesma camada.
Na Horse Labs, a governança de modelos é uma allowlist global default-OFF na governance-db, alimentada pelo catálogo ao vivo das APIs dos provedores, imposta no gateway (modelo não aprovado retorna 403) com roteamento por curinga por provedor — adicionar ou trocar provedor é configuração, não reescrita.
FAQ
O que é governança de IA corporativa?
É o conjunto de controles sobre dados, custo, acesso e modelos que mantém o uso de LLMs na empresa previsível, auditável e sob o seu domínio — aplicado na camada de infraestrutura, não no provedor.
Governança de IA é o mesmo que conformidade/LGPD?
Não. Conformidade é uma consequência: quando dados, acesso e auditoria estão sob controle técnico, atender a LGPD fica viável. Governança é a camada operacional que torna isso possível.