Governança de modelos de IA
Governança de modelos de IA é decidir e impor quais modelos a organização pode usar e direcionar cada tarefa ao modelo certo, sem ficar presa a um único provedor. Este guia detalha os quatro mecanismos: uma allowlist que começa desligada, um catálogo que vem ao vivo da API de cada provedor, roteamento por curinga que evita lock-in e a aprovação imposta no próprio gateway.
Allowlist default-OFF
Allowlist default-OFF é uma lista de modelos aprovados que começa vazia: nada é utilizável até a organização aprovar explicitamente cada modelo.
Quando o acesso aos modelos segue o padrão do provedor, tudo que ele expõe está disponível por padrão — os modelos caros, os experimentais, os recém-lançados e os que a sua organização nunca avaliou. O default é "liberado", e cabe a alguém lembrar de desligar o que não deveria rodar, um a um, sempre atrás do que o provedor publica. A allowlist default-OFF inverte essa lógica: a lista começa vazia e nada fica utilizável até ser explicitamente aprovado. O padrão deixa de ser permissivo e passa a ser negado por omissão — quem decide o que pode rodar é a organização, não o catálogo do fornecedor.
Na prática, isso significa que adotar um modelo novo é uma decisão consciente, não um efeito colateral de o provedor tê-lo lançado. A aprovação fica guardada como estado de governança — não embutida no código de quem chama o gateway —, de modo que a lista do que é permitido é uma fonte única, revisável e auditável. Aprovar ou revogar um modelo é alterar essa lista, sem mexer em aplicação nenhuma. O resultado é controle real sobre a superfície de modelos: a organização sabe exatamente o que está habilitado e por decisão de quem.
Na Horse Labs, a allowlist é global e default-OFF, guardada na governance-db: nada é utilizável até ser aprovado, e a aprovação é alternada por lote (admin + segundo fator) — quem decide o que pode rodar é a organização.
Catálogo ao vivo
Catálogo ao vivo é descobrir os modelos disponíveis consultando a API de cada provedor em tempo real, em vez de manter uma lista fixa que envelhece.
Uma lista de modelos escrita à mão no código tem prazo de validade curto. Os provedores lançam modelos novos, depreciam os antigos e renomeiam versões num ritmo que nenhuma lista estática acompanha: em pouco tempo ela aponta para modelos que já não existem e ignora os que acabaram de surgir. Manter essa lista atualizada vira um trabalho recorrente e propenso a erro, e cada defasagem é ou um modelo indisponível por engano ou uma decisão tomada sobre informação velha. O catálogo ao vivo elimina essa manutenção: os modelos disponíveis vêm da própria API de cada provedor, consultada quando se precisa da lista.
Com isso, o que a organização vê para aprovar é sempre o estado atual do que cada provedor realmente oferece — incluindo nome e data de cada modelo, extraídos da resposta da própria API. Modelos novos aparecem para avaliação assim que o provedor os publica; os depreciados deixam de figurar. A governança continua sendo a allowlist, que decide o que é aprovado; o catálogo apenas garante que essa decisão seja tomada sobre a realidade do momento, não sobre uma fotografia desatualizada que alguém esqueceu de revisar.
Na Horse Labs, o catálogo de modelos vem ao vivo das APIs /models dos provedores (com nome e data por modelo), em vez de uma lista estática no código — modelos novos aparecem para aprovação e os depreciados somem sozinhos.
Roteamento sem lock-in
Roteamento sem lock-in é encaminhar cada chamada por curinga por provedor, de modo que adicionar ou trocar um modelo ou provedor seja configuração, não reescrita de código.
O lock-in nasce quando a aplicação fala diretamente com a API de um único fornecedor: o cliente daquele provedor, os formatos dele e as suas peculiaridades ficam espalhados pelo código. Trocar de provedor, nesse cenário, é um projeto de reescrita, e essa fricção é exatamente o que prende a operação a um fornecedor mesmo quando outro seria melhor ou mais barato. O roteamento por curinga por provedor quebra esse acoplamento: o gateway entende uma rota por curinga para cada provedor, então habilitar um novo provedor ou um novo modelo é ajustar configuração, não tocar na aplicação.
Para que isso funcione, quem chama o gateway usa um identificador de modelo prefixado pelo provedor, e não um apelido solto — o prefixo torna explícito a qual provedor a chamada se destina e permite que o roteamento por curinga resolva o destino sem uma entrada manual por modelo. A aplicação passa a falar com uma única interface estável, no padrão compatível com OpenAI, enquanto a escolha de provedor vira uma decisão de configuração reversível. Controle sobre quais modelos rodam e portabilidade entre fornecedores deixam de ser objetivos em conflito: ambos vivem na mesma camada.
Na Horse Labs, o model_list do gateway é curinga por provedor (anthropic/* openai/* gemini/* xai/*) e o chamador usa o id prefixado (ex.: anthropic/claude-opus-4-8) — adicionar ou trocar provedor é configuração, não reescrita.
Imposição no gateway
Imposição no gateway é checar a allowlist no ponto único por onde toda chamada passa: um modelo não aprovado recebe 403, antes de chegar ao provedor.
Uma allowlist só vale se for impossível contorná-la. Se a aprovação fosse uma convenção — uma lista num documento que se espera que cada equipe respeite — bastaria uma chamada direta, um trecho de código esquecido ou um agente mal configurado para rodar um modelo nunca aprovado, e ninguém perceberia até o gasto ou o incidente aparecer. A imposição no gateway fecha essa brecha colocando a verificação no único ponto por onde toda chamada obrigatoriamente passa: antes de encaminhar ao provedor, o gateway confere se aquele modelo está na allowlist daquele perfil de acesso. Não está, a chamada não segue — recebe 403.
O detalhe importante é que a decisão de governança (o que está aprovado) e o ponto de imposição (o gateway) ficam separados, mas conectados: a allowlist é a fonte da verdade, e o que o gateway permite é o resultado já reconciliado dessa decisão. Assim, aprovar ou revogar um modelo na allowlist passa a valer no enforcement sem reescrever regra nenhuma. O efeito final é que "quais modelos podem rodar" deixa de ser uma intenção e vira uma garantia técnica: o que não foi aprovado simplesmente não executa.
Na Horse Labs, a aprovação é imposta no gateway via o team.models do LiteLLM (resultado já reconciliado da allowlist): um modelo não aprovado retorna 403, antes de chegar ao provedor.
FAQ
O que é governança de modelos de IA?
É o conjunto de controles que decide e impõe quais modelos a organização pode usar — uma allowlist default-OFF alimentada pelo catálogo ao vivo dos provedores — e roteia cada tarefa ao modelo certo por curinga por provedor, com a aprovação imposta no gateway, sem lock-in.
Como trocar de provedor de modelo sem reescrever o código?
Roteando por curinga por provedor: a aplicação fala com uma única interface compatível com OpenAI usando um id de modelo prefixado, e habilitar ou trocar um provedor vira ajuste de configuração — não uma reescrita.