Allowlist de modelos
Lista de modelos aprovados para uso, por organização e centro de custo. Default-OFF: o que não foi aprovado explicitamente é recusado com 403, antes de gastar tokens.
Por que importa
Allowlist de modelos é a lista do que é permitido usar — por organização e por centro de custo — em vez de uma lista do que é proibido. A distinção é tudo. Uma lista de proibições (denylist) parte do princípio de que tudo é liberado até alguém vetar; uma allowlist parte do oposto: nada é permitido até ser explicitamente aprovado. Para governança, só a segunda abordagem é segura, porque o catálogo de modelos cresce o tempo todo, e uma denylist está sempre atrasada em relação ao que apareceu ontem.
Importa porque escolher modelo não é detalhe técnico inócuo: modelos diferem em custo, em qualidade, em onde o dado é processado e em que termos o provedor oferece. Deixar qualquer modelo livre é deixar essas decisões na mão de quem chama, caso a caso, sem critério comum. A allowlist devolve a decisão para a organização e a aplica antes do gasto.
Como funciona
A allowlist é default-OFF: nenhum modelo está disponível até que a organização o aprove explicitamente. Quando uma chamada pede um modelo que não está na lista aprovada daquela organização e centro de custo, a camada recusa com 403 — antes de qualquer token ser gasto. A recusa é barata e imediata, e não há cobrança por uma chamada que nem chegou ao provedor. Aprovar um modelo é uma ação consciente, registrada, que liga aquele modelo para aquele escopo.
No roteamento, a camada usa wildcard por provedor: ela sabe falar com qualquer modelo de um provedor configurado, mas o que cada organização pode de fato usar é o recorte que a allowlist autoriza. Separar as duas coisas — a capacidade técnica de chamar e a permissão de governança — é o que permite ligar e desligar modelos por política sem mexer em integração.
Como a Horse Labs trata
Na Horse Labs, a allowlist é global default-OFF, guardada na base de governança e aplicada por organização e centro de custo. O catálogo de modelos vem ao vivo das APIs dos próprios provedores, e a aprovação é um toggle consciente; o que não foi aprovado é recusado com 403 antes de gastar token. O roteamento usa wildcard por provedor, de modo que ligar um modelo aprovado não exige reescrever a integração — basta aprová-lo no escopo certo.
Erros comuns
O erro clássico é inverter a postura: começar com tudo liberado e tentar proibir o que for surgindo. Essa denylist nunca alcança o catálogo, que muda mais rápido que a revisão. O segundo erro é tratar a allowlist como configuração global única, sem escopo — quando o certo é por organização e centro de custo, porque o modelo apropriado para um time pode ser caro ou inadequado para outro. O terceiro é deixar a recusa cara: bloquear depois do gasto, e não antes. Uma allowlist bem-feita recusa com 403 antes do token, não depois da conta.