Catálogo de modelos de IA aprovados: guia prático

A empresa descobre seus modelos quando algum deles muda

Uma equipe usa um modelo para atendimento. Outra conecta um provedor diferente à análise de documentos. Um workflow antigo mantém o nome de uma versão que já saiu da recomendação do fornecedor. A área financeira enxerga a fatura, mas não sabe quais processos dependem de cada item.

A dispersão costuma permanecer invisível até ocorrer uma mudança de preço, limite, política de dados, comportamento ou disponibilidade. Nesse momento, a empresa precisa localizar aplicações, donos, testes, alternativas e impactos sob pressão.

Um catálogo de modelos de IA aprovados organiza essas decisões antes da ocorrência. Ele registra quais modelos, versões e perfis podem atender cada classe de tarefa, com quais dados, parâmetros, limites, evidências e responsáveis.

O catálogo não serve como vitrine de lançamentos. Ele funciona como uma superfície de decisão para operação, tecnologia, segurança, compras e áreas de negócio.

O que é um catálogo de modelos aprovados

É um registro governado dos recursos de IA autorizados para uso em processos empresariais. Cada entrada liga um modelo ou perfil a uma responsabilidade operacional e ao conjunto de evidências que sustenta sua aprovação.

Uma entrada útil responde:

qual tarefa o recurso pode executar;
qual fornecedor e modalidade de acesso são usados;
quais capacidades foram testadas;
quais dados podem ser processados;
quais parâmetros e ferramentas estão liberados;
qual nível de qualidade, custo e latência foi observado;
quais restrições permanecem;
quem aprovou e quem opera;
qual alternativa existe;
quando a aprovação precisa ser revista;
como retirar o recurso sem deixar dependências órfãs.

O catálogo pode viver em uma base simples, repositório versionado ou plataforma de governança. A forma importa menos que a capacidade de localizar dependências e aplicar a decisão na infraestrutura.

Catálogo, configuração, roteamento e gateway cumprem funções diferentes

Esses componentes se conectam, mas terminam em decisões distintas.

Catálogo de modelos

Registra quais recursos estão aprovados, para quais tarefas, sob quais condições e com qual evidência. Ele governa entrada, revisão e retirada do portfólio.

Perfil de configuração

Define como um modelo opera em uma responsabilidade específica: instruções, parâmetros, formato de saída, ferramentas, limites e testes. O guia sobre configuração de modelos em produção detalha essa camada.

Roteamento

Escolhe qual perfil aprovado atenderá uma unidade de trabalho com base em classe, risco, custo, latência e disponibilidade. A política de roteamento de modelos transforma essa escolha em regra observável.

Gateway

Aplica identidade, acesso, orçamento, registros e rotas comuns na fronteira com provedores. O gateway de IA para empresas pode executar as restrições definidas pelo catálogo.

O catálogo responde o que pode ser usado. O perfil descreve como. O roteador escolhe quando. O gateway controla a passagem.

Catalogue perfis de uso, não apenas nomes comerciais

O mesmo modelo pode ter desempenhos, custos e riscos diferentes conforme contexto, ferramentas, parâmetros e tarefa. Uma linha com fornecedor e nome do produto oferece pouca utilidade operacional.

Prefira entradas orientadas por responsabilidade, como:

triagem_atendimento_ptbr_v3;
extracao_nota_fiscal_v2;
analise_contrato_com_fontes_v1;
resumo_reuniao_interno_v4;
planejamento_agente_sem_escrita_v2.

Cada perfil aponta para o modelo, a versão conhecida, o provedor, a configuração e o conjunto de avaliação. A aplicação solicita uma responsabilidade aprovada em vez de espalhar nomes de modelos pelo código.

Essa abstração reduz dependência, mas não deve esconder diferenças relevantes. Se uma capacidade exclusiva sustenta a qualidade, registre essa dependência e seu plano de substituição.

Campos essenciais de cada entrada

Identidade

Registre:

identificador do perfil;
fornecedor;
modelo e versão conhecida;
modalidade de acesso;
região ou infraestrutura;
status;
data de entrada;
próxima revisão.

Status úteis incluem proposta, avaliação, piloto, produção limitada, produção, suspenso, em retirada e retirado.

Responsabilidade operacional

Descreva a unidade de trabalho, entrada, saída e exclusões.

“Analisar documentos” é amplo. “Extrair fornecedor, valor, vencimento e número de uma nota fiscal brasileira, devolver campos estruturados e sinalizar ausência, sem preparar pagamento” oferece uma fronteira testável.

Capacidades exigidas

Liste somente o que a tarefa precisa:

idioma;
tamanho de contexto;
visão ou áudio;
saída estruturada;
chamada de ferramentas;
recuperação de fontes;
raciocínio em várias etapas;
baixa latência;
execução assíncrona;
controle de aleatoriedade;
suporte a uma modalidade específica.

Capacidade anunciada pelo fornecedor abre uma hipótese. Aprovação exige teste no caso real.

Dados permitidos

Relacione classes de dados, finalidade, ambiente e restrições.

Inclua:

conteúdo público, interno, confidencial ou restrito;
dados pessoais permitidos;
campos que exigem máscara;
dados proibidos;
uso de entradas e saídas pelo fornecedor;
retenção configurada;
região exigida;
clientes ou contratos com isolamento próprio.

O artigo sobre classificação de dados para agentes de IA mostra como transformar sensibilidade e finalidade em regras de rota, contexto e registro.

Configuração aprovada

Aponte para a versão de:

instrução de sistema;
parâmetros;
schema de saída;
ferramentas disponíveis;
política de tentativas;
limite de contexto;
orçamento por unidade;
validadores;
bloqueios;
handoff humano.

Não duplique toda a configuração dentro do catálogo. Preserve referências estáveis para que uma mudança possa localizar consumidores e testes afetados.

Evidência de avaliação

Registre o conjunto de casos, data, versão e resultados relevantes:

taxa de unidade aceita;
erros críticos;
aderência ao schema;
uso correto de fontes;
escolha de ferramentas;
escalonamento;
latência;
custo por unidade válida;
revisão humana;
testes de segurança;
comparação com a linha de base.

Média geral não basta. O modelo pode funcionar em casos comuns e falhar justamente na exceção de maior impacto.

Operação e suporte

Inclua:

dono do processo;
responsável técnico;
área que aprovou dados e risco;
canal de incidente;
limite de volume;
disponibilidade esperada;
fallback aprovado;
procedimento de suspensão;
condição de retorno;
plano de retirada.

A aprovação ganha vida quando existe alguém capaz de responder por mudança, falha e revisão.

Um modelo de ficha operacional

| Campo | Exemplo | |---|---| | perfil | triagem_atendimento_ptbr_v3 | | tarefa | classificar assunto e urgência de chamados recebidos | | saída | categoria, urgência, justificativa curta e rota sugerida | | exclusões | não responder cliente, encerrar chamado ou alterar cadastro | | modelo | referência técnica aprovada | | dados | interno e confidencial limitado à finalidade | | ferramentas | nenhuma | | qualidade | critérios por categoria e erro crítico | | custo | teto por chamado e por lote | | latência | janela compatível com a fila | | fallback | perfil secundário testado ou fila humana | | dono | operação de atendimento | | revisão | por data, drift ou mudança do fornecedor | | status | produção limitada |

A ficha deve apontar para avaliação, configuração, política de dados e consumidores. Ela permite entender a decisão sem abrir cinco sistemas.

Defina critérios de entrada no catálogo

Um modelo novo só deveria chegar à produção depois de cumprir um caminho conhecido.

1. Triagem inicial

Verifique compatibilidade técnica, termos, segurança, dados, custo, disponibilidade e capacidades necessárias. Elimine opções que não atendem a um requisito impeditivo.

2. Teste offline

Use casos representativos, incluindo exemplos comuns, ambíguos, incompletos e sensíveis. Compare com respostas validadas e com a linha de base atual.

3. Teste adversarial

Avalie instruções conflitantes, conteúdo não confiável, tentativa de acesso indevido, uso errado de ferramentas, vazamento entre contextos e respostas fora do contrato.

4. Modo sombra

Processe unidades reais sem produzir consequência. Compare resultado, tempo, custo e divergências com a operação vigente.

5. Produção limitada

Libere poucos casos, volume controlado, ações reversíveis e revisão próxima. O escopo precisa estar codificado, não apenas comunicado à equipe.

6. Aprovação operacional

Registre evidências, restrições, donos, data e gatilhos de revisão. Aprovação condicional deve aparecer como condição técnica ou fila de exceção.

O guia sobre critérios de aceite para agentes de IA ajuda a transformar demonstrações em evidência de conclusão, qualidade, limites e recuperação.

Aprovação deve ser por tarefa e consequência

Um modelo aprovado para resumir documentos internos não recebe autorização automática para analisar contratos, responder clientes ou acionar ferramentas.

Separe a aprovação por:

processo;
classe de tarefa;
tipo de entrada;
classe de dados;
ambiente;
ferramentas;
autonomia;
consequência;
cliente ou obrigação específica.

Essa granularidade evita dois extremos. Aprovação ampla demais cria uma licença invisível. Aprovação estreita demais transforma cada pequena variação em comitê. Agrupe tarefas quando compartilham contrato, risco e avaliação de forma demonstrável.

Compare modelos pelo trabalho válido entregue

Preço por token, posição em benchmark e tamanho de contexto não respondem sozinhos se o perfil melhora a operação.

Meça por unidade de trabalho:

conclusão correta;
erro impeditivo;
correção humana;
tentativas;
tempo total;
consumo técnico;
custo de revisão;
falha de integração;
escalonamento adequado;
resultado confirmado no processo.

Um modelo mais barato pode aumentar retrabalho. Um modelo mais capaz pode ser desperdício em classificação simples. Um benchmark público pode medir uma capacidade distante do seu documento, idioma, ferramenta ou regra.

O custo útil é o da unidade aceita dentro do prazo e do risco. O guia de controle de custos de agentes de IA liga consumo, tentativas e revisão ao trabalho concluído.

Trate versão como parte da identidade

Nomes comerciais podem permanecer iguais enquanto o comportamento muda. APIs podem apontar aliases para versões mais recentes. Parâmetros padrão, filtros, limites e formatos também evoluem.

Registre sempre que estiver disponível:

identificador exato;
versão ou data do snapshot;
endpoint e modalidade;
parâmetros explícitos;
versão do SDK ou adaptador;
data da avaliação;
versão do conjunto de testes;
comportamento conhecido do alias;
política para atualização automática.

Quando o fornecedor não oferece versão fixa, trate qualquer mudança relevante como gatilho de avaliação. Monitore qualidade por classe para detectar drift em agentes de IA antes que a média mensal esconda a alteração.

Use gatilhos objetivos de revisão

Esperar a data anual pode deixar um perfil inadequado em produção por meses. Combine revisão periódica com eventos.

Gatilhos comuns:

mudança de versão ou alias;
alteração de preço;
mudança em retenção ou uso de dados;
novo subfornecedor;
regressão de qualidade;
aumento de erro crítico;
latência fora da janela;
mudança de ferramenta ou schema;
nova classe de dados;
novo processo consumidor;
incidente;
capacidade substituta disponível;
encerramento anunciado pelo fornecedor.

A revisão pode manter, limitar, suspender, substituir ou retirar a entrada. Registre motivo e evidência.

Catálogo sem aplicação técnica vira documentação atrasada

A decisão precisa chegar aos sistemas que fazem chamadas.

Algumas formas de aplicação:

gateway aceita somente perfis ativos;
orquestrador valida tarefa e classe de dados;
CI impede referência a modelos fora do catálogo;
secrets são liberados apenas a consumidores autorizados;
roteador considera somente alternativas aprovadas;
painéis atribuem uso ao perfil e processo;
alerta dispara quando alias ou preço muda;
kill switch suspende perfil, fornecedor ou consumidor;
inventário localiza aplicações antes de uma retirada.

Comece com os controles de maior impacto: identidade, allowlist, dados permitidos, volume, registro e suspensão. Automação excessiva antes de um catálogo legível cria política difícil de corrigir.

Governança proporcional ao risco

Nem toda entrada precisa do mesmo rito.

Baixo risco

Resumo interno sem dado sensível e sem ação pode usar avaliação menor, limite de volume e revisão amostral.

Risco moderado

Classificação de atendimento ou preparação comercial com dado de cliente pede testes por categoria, isolamento, logs reduzidos e modo sombra.

Alto risco

Decisão financeira, comunicação externa sensível, contrato, saúde, credencial ou ferramenta com escrita pede aprovação multidisciplinar, barreiras técnicas, evidência detalhada e autoridade humana.

A governança deve acompanhar consequência e reversibilidade. Um processo simples em grande volume também merece controle, pois um erro pequeno pode se repetir milhares de vezes.

Planeje fallback sem liberar uma substituição fraca

Uma alternativa precisa passar pelos casos da tarefa e respeitar dados, ferramentas, formato, custo e prazo. Estar disponível não comprova adequação.

Para cada perfil, defina:

falhas que autorizam fallback;
alternativa aprovada;
modo degradado permitido;
dados compatíveis com a rota;
limite de tentativas;
mudança de qualidade aceita;
comunicação para operação;
condição de retorno;
tratamento de unidades em estado incerto.

Quando nenhuma alternativa cumpre o contrato, interrompa ou encaminhe. O fallback para agentes de IA detalha a retomada sem misturar indisponibilidade com permissão.

Retire modelos sem deixar chamadas escondidas

A retirada começa antes de desligar o endpoint.

marque a entrada como em retirada;
bloqueie novos consumidores;
localize aplicações, agentes, testes e credenciais;
meça volume e última utilização;
aprove o perfil substituto;
rode comparação em sombra;
migre por classe e risco;
acompanhe erro, custo e latência;
remova fallback para a versão antiga;
revogue chaves ou permissões exclusivas;
encerre dados e acessos conforme contrato;
confirme ausência de chamadas;
registre o aceite final.

O plano de saída para fornecedor de IA amplia esse fluxo para ativos, dados, contratos, conhecimento e continuidade.

Métricas do catálogo

Acompanhe saúde do portfólio e efeito operacional:

perfis em produção sem dono;
entradas sem teste vigente;
consumidores fora do catálogo;
aliases sem política de atualização;
modelos com dado incompatível;
perfis sem fallback ou modo degradado;
revisões vencidas;
versões antigas ainda chamadas;
custo por unidade válida;
erro crítico por perfil e tarefa;
tempo para localizar consumidores;
tempo para suspender uma rota;
incidentes por mudança de modelo;
entradas sem uso recente;
retiradas com dependências pendentes.

Um catálogo com muitas entradas pode indicar flexibilidade ou dispersão. A métrica precisa mostrar se cada opção resolve uma necessidade comprovada.

Checklist do catálogo de modelos aprovados

[ ] Cada entrada está ligada a uma tarefa concreta?
[ ] Fornecedor, modelo, versão e modalidade estão registrados?
[ ] Dados permitidos e proibidos estão claros?
[ ] Configuração e ferramentas possuem versões referenciadas?
[ ] Avaliação inclui casos comuns, exceções e falhas?
[ ] Qualidade, custo e latência são medidos por unidade válida?
[ ] Aprovação delimita ambiente, consequência e autonomia?
[ ] Donos operacional e técnico estão identificados?
[ ] Gatilhos de revisão incluem mudanças do fornecedor?
[ ] O gateway ou orquestrador aplica a allowlist?
[ ] Fallback passou pelos testes da mesma tarefa?
[ ] Existe suspensão rápida e segmentada?
[ ] Consumidores podem ser localizados antes da retirada?
[ ] Credenciais e dados são encerrados ao final?

O catálogo transforma variedade em escolha governável

Empresas podem usar vários modelos sem transformar cada lançamento em uma nova decisão improvisada. O catálogo preserva a relação entre recurso, tarefa, dado, evidência, custo e responsável.

Essa clareza reduz dependência de nomes comerciais e facilita trocar, limitar ou retirar uma rota. Modelos continuam evoluindo. A operação permanece legível porque sabe quais capacidades usa, por que usa e o que precisa acontecer quando a evidência muda.