Como trocar o modelo de IA usado pela empresa

Trocar o motor não deveria exigir reconstruir o veículo

Novos modelos de inteligência artificial chegam com frequência. Um oferece melhor qualidade em documentos. Outro reduz custo. Um terceiro responde mais rápido ou trabalha melhor com ferramentas. A liderança vê a novidade e pergunta se a empresa deveria migrar.

Essa decisão fica cara quando modelo, processo e dados foram construídos como uma peça única. Instruções dependem de comportamentos específicos. Formatos mudam. Integrações interpretam respostas de maneiras diferentes. Ninguém sabe quais casos foram usados para aprovar a versão atual.

Uma arquitetura saudável permite comparar modelos sem colocar a operação inteira em aposta. A troca ocorre sobre um contrato de trabalho conhecido: entradas, saídas, ferramentas, critérios, limites e métricas.

O objetivo não é mudar a cada lançamento. É preservar capacidade de escolha quando custo, qualidade, risco ou estratégia justificarem a mudança.

O modelo é uma camada do sistema

Um agente empresarial costuma depender de várias camadas:

• processo e responsabilidade operacional;
• fontes de contexto;
• memória e estado;
• instruções e procedimentos;
• ferramentas e permissões;
• modelo de IA;
• validações;
• revisão humana;
• logs, métricas e contingência.

Quando essas camadas estão separadas, o modelo pode evoluir sem levar junto toda a lógica da empresa. Quando estão misturadas, cada troca vira um projeto de reconstrução.

A distinção importa porque capacidade técnica e capacidade operacional são coisas diferentes. Um modelo pode melhorar em testes gerais e piorar no formato, idioma, latência ou uso de ferramentas que sustentam um processo específico.

O artigo sobre full stack de IA para empresas detalha por que o resultado depende do conjunto, e não de um componente isolado.

Motivos legítimos para considerar a migração

Qualidade insuficiente em casos importantes

O modelo atual falha com frequência em documentos longos, classificações específicas, extração de dados ou uso de ferramentas. A falha aparece em casos reais e aumenta revisão, atraso ou risco.

Custo total da execução

O preço por chamada conta pouco quando um modelo exige mais tentativas, produz retrabalho ou consome uma janela de contexto maior. Compare custo por unidade concluída com qualidade.

Latência e capacidade

Alguns fluxos exigem resposta rápida. Outros processam lotes durante a noite. Limites de uso, filas e disponibilidade regional podem alterar a viabilidade operacional.

Privacidade e requisitos contratuais

Políticas de retenção, localização de dados, subcontratados, controles administrativos e termos de uso podem não acompanhar as exigências da empresa ou do cliente.

Novas capacidades necessárias

O processo pode passar a exigir visão, áudio, execução de código, uso de ferramentas ou contexto maior. Essa mudança precisa nascer de uma necessidade da operação, não da vontade de experimentar um recurso.

Concentração de fornecedor

Uma empresa pode decidir reduzir dependência de um único provedor. Ter uma alternativa testada melhora continuidade e poder de negociação, mesmo quando a migração imediata não é necessária.

O que comparar antes de trocar

Resultado nos casos reais

Use um conjunto representativo da operação. Inclua situações comuns, exceções, dados incompletos e casos de alto risco. O modelo candidato precisa enfrentar os mesmos exemplos da versão atual.

O guia sobre como avaliar agentes de IA explica como definir referência, métricas de tarefa, fluxo e negócio.

Compatibilidade de entrada e saída

Verifique:

• tamanho e formato dos documentos;
• suporte ao idioma e vocabulário do setor;
• consistência de JSON ou outros formatos estruturados;
• limites de contexto;
• anexos e tipos de arquivo;
• citações ou referências à fonte;
• comportamento quando falta informação.

Uma resposta melhor escrita pode quebrar um sistema se deixar de respeitar o formato que alimenta a próxima etapa.

Uso de ferramentas

Agentes precisam escolher e preencher ferramentas corretamente. Compare taxa de seleção, argumentos, repetição de chamadas, tratamento de erro e capacidade de interromper a execução.

Teste também falhas reais: API indisponível, campo obrigatório ausente, permissão negada e retorno contraditório.

Segurança e limites

Observe se o candidato mantém instruções, recusa ações proibidas, protege dados e pede aprovação nos pontos definidos. Avaliações genéricas raramente cobrem a política específica da empresa.

Latência e disponibilidade

Meça distribuição, e não apenas média. Uma rotina pode tolerar cinco segundos na maior parte dos casos e falhar quando alguns levam um minuto. Registre também indisponibilidade, limite de requisições e comportamento sob volume.

Custo completo

Inclua consumo do modelo, infraestrutura, observabilidade, revisão humana, ajustes de instrução e manutenção. O artigo sobre quanto custa um agente de IA ajuda a montar essa conta.

Operação e suporte

Avalie documentação, gestão de acesso, ambientes separados, histórico de uso, suporte, comunicação de mudanças e possibilidade de fixar uma versão. O melhor resultado de laboratório pode vir acompanhado de uma operação difícil de governar.

Crie um contrato interno para o modelo

A empresa precisa declarar o que espera dessa camada. Um contrato simples pode conter:

• tipos de entrada aceitos;
• formato obrigatório de saída;
• ferramentas disponíveis;
• informações que nunca podem ser inventadas;
• decisões que exigem fonte;
• ações que pedem aprovação;
• tempo máximo desejado;
• orçamento por execução;
• critérios de interrupção;
• métricas mínimas de qualidade.

Esse contrato não depende do fornecedor. Ele descreve a responsabilidade operacional que qualquer modelo deverá cumprir.

Instruções específicas podem variar entre modelos, mas o critério permanece. Essa separação evita que o conhecimento da empresa fique preso em uma sequência de prompts impossível de transportar.

Um processo seguro de migração

1. Congele a linha de base

Registre versão atual, instruções, configurações, ferramentas, métricas e conjunto de testes. Sem linha de base, a equipe compara impressões.

2. Rode o candidato em modo sombra

O novo modelo recebe cópias das entradas reais, com proteção adequada de dados, e produz saídas sem agir na operação. A equipe compara resultados com a versão vigente.

Modo sombra reduz risco, mas ainda exige cuidado com privacidade e custo. Os dados enviados ao candidato precisam respeitar as mesmas regras do ambiente oficial.

3. Classifique as diferenças

Separe melhoria, equivalência e regressão. Registre também o tipo de falha:

• contexto perdido;
• formato inválido;
• ferramenta errada;
• fato sem fonte;
• escalonamento ausente;
• custo excessivo;
• latência inadequada.

Uma média pode esconder erro impeditivo. O candidato não deve avançar se falhar em um limite crítico, mesmo com resultado geral melhor.

4. Ajuste a camada de adaptação

Modelos diferentes podem exigir instruções, parâmetros e formatos próprios. Mantenha essa adaptação perto do conector do modelo, sem espalhá-la pelo processo inteiro.

Se cada workflow possui uma cópia diferente das mesmas instruções, a migração ficará lenta e sujeita a inconsistências.

5. Libere uma parcela controlada

Comece por usuários, unidades ou tipos de caso de menor risco. Preserve revisão humana e compare indicadores com o grupo que continua na versão anterior.

6. Aumente o tráfego por evidência

Amplie apenas quando qualidade, custo, latência e falhas permanecem dentro dos limites. A decisão deve considerar vários dias ou ciclos relevantes, não uma demonstração.

7. Preserve reversão

Mantenha configuração, acesso e dados necessários para voltar à versão anterior. Defina quem pode acionar a reversão e em quais condições.

O plano de reversão precisa existir antes da mudança

Migrações falham de formas pouco dramáticas. O agente começa a gerar mais casos para revisão, omite um campo, demora além do SLA ou usa uma ferramenta de maneira menos consistente. A operação degrada aos poucos.

Defina gatilhos objetivos, como:

• erro crítico acima da tolerância;
• formato inválido em sequência;
• aumento relevante de retrabalho;
• latência acima do limite;
• custo por caso fora do teto;
• falha de permissão;
• indisponibilidade sem contingência;
• queda em uma métrica operacional principal.

A reversão pode ocorrer por tipo de tarefa. A empresa mantém o novo modelo para resumo interno e volta ao anterior nas rotinas que usam ferramentas, por exemplo.

Esse desenho por responsabilidade é mais seguro do que uma troca total em data única.

Como reduzir dependência desde o início

Preserve dados e memória fora do modelo

Histórico, estado, documentos e decisões devem permanecer em fontes controladas pela empresa. O artigo sobre memória de agentes de IA mostra como separar contexto persistente de instruções temporárias.

Versione instruções e configurações

Registre mudanças, motivo, responsável e resultado nos testes. Isso permite reproduzir a versão aprovada e entender regressões.

Use formatos estruturados

Contratos de saída bem definidos reduzem adaptações espalhadas. Valide o formato antes de passar a informação para a próxima etapa.

Mantenha avaliações portáveis

O conjunto de casos e critérios pertence à empresa. Ele deve servir para comparar versões, fornecedores e arquiteturas.

Evite recursos exclusivos sem justificativa

Uma capacidade proprietária pode gerar valor real. Registre o benefício, a dependência criada e o caminho de contingência. Dependência consciente é uma decisão; dependência invisível é dívida.

Checklist para a decisão

• Existe um motivo operacional claro para migrar?
• A versão atual tem linha de base registrada?
• O candidato foi testado nos mesmos casos?
• Erros críticos receberam peso próprio?
• Formatos e ferramentas foram validados?
• Privacidade, contrato e retenção foram revisados?
• Custo inclui revisão e adaptação?
• Houve execução em modo sombra?
• A liberação será gradual?
• Existe gatilho e responsável pela reversão?
• Dados, memória e avaliações permanecem sob controle da empresa?

Arquitetura preserva liberdade de escolha

A empresa não precisa perseguir cada lançamento. Precisa conseguir testar uma mudança sem perder o controle do processo.

Quando contexto, procedimentos, avaliações e métricas pertencem à arquitetura operacional, o modelo pode ser escolhido pelo resultado que entrega naquela responsabilidade. A migração deixa de ser uma aposta de plataforma e vira uma mudança controlada de componente.

Essa liberdade tem valor financeiro e estratégico. Ela permite aproveitar avanços, negociar fornecedores e manter continuidade sem reconstruir o conhecimento operacional a cada nova geração de tecnologia.