O modelo é infraestrutura: por que LLM deveria ser adapter, não o centro da sua arquitetura

Existe uma pergunta simples que ajuda a separar uma estratégia madura de IA de uma integração frágil com um fornecedor: se amanhã sua empresa trocasse o modelo principal, o que seria perdido? A resposta pode revelar muito mais do que parece. Se a perda for limitada a alguns ajustes de prompt, pequenas calibrações de comportamento, mudanças de custo e adaptações de API, provavelmente a organização está em um caminho razoável. Mas se a troca fizer a empresa perder o comportamento dos seus agentes, a qualidade das respostas, a memória dos fluxos, os critérios de avaliação, os exemplos bons e ruins, os aprendizados operacionais e boa parte do conhecimento acumulado, então o problema é maior. A empresa não construiu apenas uma solução de IA; ela colocou conhecimento organizacional dentro da infraestrutura de outra empresa.

Essa discussão ficou mais clara depois de uma publicação recente de Satya Nadella no X, em que ele escreveu: “A company should be able to switch out a ‘generalist’ model without losing the ‘company veteran’ expertise built into their learning system.” Em tradução livre, uma empresa deveria conseguir trocar um modelo generalista sem perder a expertise de “veterano corporativo” construída dentro do seu sistema de aprendizado. A frase importa porque desloca o foco da arquitetura. O objetivo não deveria ser apenas escolher o melhor LLM do trimestre, já que modelos, custos, rankings, janelas de contexto e fornecedores vão continuar mudando. O objetivo deveria ser construir uma arquitetura em que o conhecimento da empresa não evapore quando o modelo muda. É nesse sentido que a ideia central deste artigo se torna simples: o modelo é infraestrutura. Publicação do Satya Nadella no X

Mas existe uma forma ainda mais concreta de explicar essa ideia: em uma arquitetura corporativa saudável, o modelo deveria se comportar como um adapter, não como o centro do sistema. A aplicação não deveria “pensar em GPT”, “pensar em Claude” ou “pensar em Gemini”. Ela deveria pensar em capacidades internas, como classificar intenção, resumir atendimento, revisar um pull request, investigar um incidente, extrair dados de contrato ou responder uma dúvida com base em uma política. O LLM entra como uma implementação possível dessas capacidades, assim como um banco, uma fila, uma API externa ou um gateway de pagamento entram como detalhes externos atrás de uma porta bem definida.

A analogia com arquitetura hexagonal

A arquitetura hexagonal, também conhecida como Ports and Adapters, foi proposta por Alistair Cockburn como uma forma de proteger o núcleo da aplicação dos detalhes externos. A ideia é simples: o core da aplicação define portas, e os adapters traduzem essas portas para tecnologias concretas. Banco de dados, interface web, APIs externas, filas, testes automatizados e outros mecanismos ficam do lado de fora. O domínio não deveria depender diretamente dessas tecnologias. Ele deveria depender de contratos mais estáveis, definidos a partir das capacidades que a aplicação precisa oferecer. Artigo original de Alistair Cockburn sobre Hexagonal Architecture

Essa ideia é extremamente útil para pensar IA corporativa. O erro mais comum é deixar o modelo atravessar a fronteira arquitetural e contaminar o core da aplicação. Isso acontece quando regras de negócio ficam dentro de prompts, quando cada serviço chama diretamente um provedor, quando formatos específicos de tool calling se espalham pelo código, quando o tratamento de erro depende de detalhes do vendor e quando a qualidade do fluxo depende de ajustes informais feitos para um modelo específico. Nesse cenário, o LLM deixa de ser infraestrutura substituível e passa a virar parte implícita do domínio.

Uma arquitetura mais saudável faz o contrário. Ela define portas internas para capacidades de IA e coloca os modelos atrás de adapters. Em vez de a aplicação chamar diretamente “Claude para classificar esse ticket” ou “GPT para revisar esse PR”, ela chama uma porta como ClassificadorDeIntencao, RevisorDePullRequest, ResumoDeAtendimento ou InvestigadorDeIncidente. Atrás dessa porta, a plataforma decide qual modelo usar, qual prompt versionado aplicar, quais evals validam o comportamento, quais traces serão armazenados, quais políticas de fallback existem e qual custo por resultado é aceitável.

Acoplado demais:
Aplicação → GPT / Claude / Gemini diretamente

Mais saudável:
Aplicação → Porta de capacidade → Adapter de IA → Modelo atual

A diferença parece pequena no desenho, mas é enorme na operação. No primeiro caso, cada aplicação começa a carregar detalhes do fornecedor. Ela conhece o modelo, conhece o formato da chamada, conhece o estilo da resposta, conhece os erros específicos, conhece o prompt e, muitas vezes, conhece até as limitações daquele provedor. No segundo caso, a aplicação conhece uma capacidade do negócio. O modelo continua importante, mas virou implementação. Se amanhã outro modelo for melhor, mais barato, mais rápido ou mais adequado para requisitos de privacidade, a troca acontece no adapter e nos critérios da plataforma, não no coração do sistema.

O erro é deixar o modelo virar domínio

O problema não é usar GPT, Claude, Gemini, Llama ou qualquer outro modelo. O problema é deixar o domínio da empresa depender diretamente da forma como um fornecedor interpreta instruções, organiza ferramentas, responde em JSON, cobra por token ou lida com contexto. Isso parece abstrato, mas aparece de forma bem concreta em sistemas reais.

Imagine um agente de atendimento que classifica mensagens de clientes. Na primeira versão, a aplicação chama diretamente um modelo com um prompt do tipo: “classifique essa mensagem em uma das categorias abaixo”. O prompt contém as categorias, algumas exceções, exemplos de respostas, instruções de tom e regras de escalonamento. O resultado vem em um formato esperado pela aplicação. O fluxo funciona, o time fica satisfeito e a solução começa a escalar.

Algumas semanas depois, a política de atendimento muda. O time edita o prompt. Depois, o modelo começa a ficar caro, e alguém sugere trocar para outro. O novo modelo responde com um JSON ligeiramente diferente, interpreta uma exceção de outra forma e passa a classificar alguns casos sensíveis com menos confiança. O problema não é apenas “o modelo mudou”. O problema é que a aplicação estava acoplada demais ao comportamento de um modelo específico, e parte da regra de negócio estava escondida no prompt.

Se esse mesmo fluxo fosse desenhado como uma porta interna, a conversa seria diferente. A aplicação chamaria algo como classificarIntencao(mensagem, contexto). Essa porta teria um contrato claro: categorias possíveis, nível de confiança, justificativa curta, política de fallback e formato de resposta. O adapter de IA implementaria esse contrato usando o modelo disponível naquele momento. O prompt seria versionado. Os evals testariam casos reais. Os traces mostrariam qual modelo, contexto e prompt foram usados. A aplicação não precisaria saber se a implementação atual usa GPT, Claude, Gemini ou um modelo interno menor.

Core do negócio
  └── Porta: Classificar intenção do cliente
        ├── Adapter OpenAI
        ├── Adapter Anthropic
        ├── Adapter Gemini
        └── Adapter modelo interno

Esse desenho não elimina o trabalho de trocar modelo, mas muda completamente o tamanho do problema. A troca deixa de ser uma cirurgia espalhada pela aplicação e passa a ser uma mudança controlada em uma camada específica. Ainda será necessário rodar evals, comparar qualidade, ajustar prompt, medir custo e observar regressões. Mas a empresa preserva o que realmente importa: a definição da tarefa, os critérios de sucesso, os exemplos reais, o histórico de falhas, a memória institucional e a capacidade de decidir com evidência.

Prompt não deveria ser fonte de verdade

Um dos sinais mais claros de dependência mal desenhada é quando o prompt vira fonte de verdade. Isso acontece porque o prompt é rápido de alterar e parece flexível. Uma política de atendimento, uma exceção comercial, uma regra de escalonamento, um tom de comunicação ou uma restrição operacional entram no prompt porque isso resolve o problema do dia. O fluxo melhora, a resposta fica mais adequada e o time sente que avançou. Aos poucos, porém, o prompt deixa de ser uma instrução para o modelo e passa a ser uma espécie de repositório informal de regra de negócio.

Esse é um erro arquitetural. Prompt pode orientar comportamento, mas não deveria ser o único lugar onde regras críticas moram. Regras importantes precisam viver em bases versionadas, documentos com ownership, sistemas de domínio, políticas testáveis ou contratos explícitos. O prompt pode consumir essas informações e explicar ao modelo como usá-las, mas não deveria ser o cofre onde a empresa guarda conhecimento operacional sensível. Quando o prompt vira a única cópia de uma regra, trocar de modelo deixa de ser uma troca de infraestrutura e passa a ser uma reinterpretação arriscada do negócio.

Esse ponto conversa diretamente com o artigo Structured Prompt-Driven Development: quando o prompt vira artefato de engenharia. Se o prompt influencia comportamento relevante, ele precisa ser tratado como artefato versionado, revisável e testável. Ainda assim, mesmo quando o prompt é bem tratado, ele continua sendo apenas uma peça da arquitetura. A empresa erra quando coloca intenção, regra, exceção, formato, política, fallback e critério de qualidade dentro de uma instrução solta, sem separação clara entre domínio e adapter.

No desenho mais saudável, o prompt fica no adapter ou em uma camada de plataforma associada à porta de capacidade. Ele traduz a intenção da porta para o modelo específico. Se o modelo muda, o prompt pode mudar também, mas a porta continua estável. A aplicação continua pedindo a mesma capacidade. Os evals continuam medindo o mesmo comportamento. Os traces continuam comparáveis. Essa é a proteção que a arquitetura deveria oferecer.

Contexto também precisa ficar fora do fornecedor

O mesmo raciocínio vale para contexto. Contexto é tudo aquilo que o modelo precisa saber para executar uma tarefa de forma útil: documentação, decisões arquiteturais, incidentes, RFCs, políticas, contratos, métricas, regras de negócio, tickets, postmortems e exemplos históricos. Em sistemas simples, jogar esse material dentro de uma ferramenta e deixar o modelo consultar pode parecer suficiente. Em sistemas corporativos, isso rapidamente vira uma camada crítica da arquitetura.

Pense em um assistente interno de engenharia que responde dúvidas sobre deploy, arquitetura, incidentes antigos e guidelines de segurança. Se alguém conecta alguns documentos a uma ferramenta de IA e o assistente começa a responder bem, a primeira impressão é positiva. Mas a pergunta arquitetural é outra: quem faz a curadoria desses documentos? Quem remove conteúdo antigo? Qual fonte vence quando dois documentos se contradizem? Que versão do contexto foi usada em uma resposta errada? O mesmo contexto pode ser consumido por outro modelo? Existe controle de permissão por área, produto ou confidencialidade? Existe rastreabilidade entre resposta, documento consultado e decisão tomada?

Quando a empresa não consegue responder a essas perguntas, ela não tem uma camada de contexto; ela tem uma integração. Uma integração pode funcionar para um caso específico, em uma ferramenta específica, com um modelo específico. Uma camada de contexto precisa ser governada, reutilizável, observável e relativamente agnóstica ao modelo. O modelo pode mudar, mas o mecanismo que organiza, protege, recupera e versiona conhecimento institucional deveria permanecer.

Esse ponto é uma continuação natural do artigo Context engineering: quando o problema deixa de ser prompt e vira arquitetura. Em produção, a pergunta deixa de ser apenas “qual prompt devo escrever?” e passa a ser “como desenho a arquitetura que decide que contexto entra, quando entra, com qual granularidade, com qual segurança e com qual rastreabilidade?”. Se essa camada é fraca, trocar de modelo vira uma ameaça. Se ela é forte, o modelo passa a consumir uma memória institucional que pertence à empresa, não ao fornecedor.

Evals são os testes da porta, não do fornecedor

Em uma arquitetura hexagonal, uma das vantagens de definir portas é conseguir testar o comportamento esperado sem depender diretamente da infraestrutura real. Com IA, a lógica é parecida. A empresa não deveria avaliar apenas se um modelo “parece bom”. Ela deveria avaliar se determinada capacidade interna cumpre seus critérios de qualidade. O objeto do teste não é apenas o fornecedor; é a porta de capacidade que a empresa decidiu expor.

Imagine a porta responderPoliticaDeReembolso. O contrato dessa porta não deveria ser “gerar uma resposta bonita”. Ele deveria incluir critérios como aderência à política atual, clareza para o cliente, identificação de exceções, limite do que pode ser prometido, necessidade de escalonamento e indicação da fonte usada. Os evals deveriam refletir esses critérios. Quando a empresa testa GPT, Claude, Gemini ou um modelo interno, ela está avaliando qual adapter implementa melhor aquela porta dentro de custo, latência e risco aceitáveis.

Essa mudança de perspectiva é importante porque evita que a empresa escolha modelo por ranking genérico. Um modelo pode ser ótimo em benchmarks públicos e ruim em uma tarefa específica da organização. Outro pode ser barato e suficiente para classificação simples, mas inadequado para análise regulatória. Um terceiro pode ser excelente em código, mas pior em atendimento sensível. Sem evals próprios, a escolha vira opinião. Com evals próprios, a escolha vira engenharia.

Na prática, evals podem começar simples. Um agente de atendimento pode ter casos reais de cancelamento, reembolso, prazo, exceções comerciais e escalonamento. Um agente de engenharia pode ter casos de análise de incidente, sugestão de rollback, explicação de contrato, geração de teste e revisão de PR. Um agente jurídico ou regulatório pode ter casos em que a resposta deve citar fonte, evitar afirmações não suportadas ou pedir revisão humana. O importante é que esses casos pertençam à empresa e rodem contra múltiplos adapters, não apenas contra o modelo usado no momento.

Traces são a memória operacional da implementação

Outra parte essencial do desenho é guardar traces de forma padronizada. Em sistemas tradicionais, logs e traces ajudam a entender o que aconteceu. Em sistemas com IA, eles são ainda mais importantes, porque a resposta final não mostra toda a trajetória. Um agente pode dar uma resposta ruim porque recuperou o documento errado, chamou a ferramenta errada, ignorou uma evidência, recebeu contexto demais, recebeu contexto antigo ou interpretou mal uma instrução. Se a empresa só guarda a resposta final, ela perde a chance de aprender com o comportamento do sistema.

Um trace útil deveria mostrar qual porta foi chamada, qual adapter foi usado, qual modelo respondeu, qual versão do prompt estava ativa, que contexto foi recuperado, quais ferramentas foram chamadas, quais decisões intermediárias foram tomadas, quanto a execução custou, quanto demorou e qual foi o resultado final. Esse registro não serve apenas para debugging. Ele é uma forma de memória operacional. Ao longo do tempo, traces mostram padrões de falha, ajudam a criar novos evals, revelam documentos problemáticos, indicam ferramentas mal descritas e permitem comparar modelos em situações reais.

No artigo Observabilidade para agentes: por que logs e traces tradicionais já não bastam, a tese era que agentes precisam ser observados por trajetória, contexto, ferramentas e qualidade da decisão, não apenas por latência e erro HTTP. Aqui, essa observabilidade ganha outra função: ela reduz dependência de fornecedor. Quando a empresa possui os traces e consegue analisá-los fora da interface de um único modelo, ela transforma uso real em aprendizado próprio. Sem traces, cada erro vira anedota; com traces, cada erro pode virar melhoria do sistema.

Como esse desenho reduz dependência de modelo

A forma mais simples de pensar nesse problema é separar o que deve pertencer ao fornecedor do que deve pertencer à empresa. O fornecedor oferece modelos, infraestrutura de inferência, APIs, capacidades multimodais, janelas de contexto, performance e ferramentas específicas. A empresa deveria possuir portas de capacidade, intenção, contexto, evals, traces, workflows, políticas, exemplos, memória institucional e critérios de sucesso. Quando essa separação fica clara, a arquitetura começa a ficar menos frágil.

O primeiro movimento prático é criar uma camada interna de acesso a modelos. Essa camada não precisa nascer como uma plataforma gigante. Ela pode começar como uma API interna que recebe uma tarefa, aplica políticas mínimas, escolhe o modelo configurado, registra a execução e devolve uma resposta em formato padronizado. Com o tempo, essa camada pode evoluir para roteamento por tipo de tarefa. Tarefas simples de classificação podem usar um modelo mais barato e rápido. Análises de incidente podem usar um modelo mais forte. Geração de código pode usar um modelo especializado. Atendimento sensível pode exigir guardrails adicionais, evals obrigatórios ou fallback humano.

O segundo movimento é criar um catálogo de tarefas ou capacidades, não apenas um catálogo de modelos. Em vez de orientar os times por nomes de fornecedores, a empresa passa a organizar o uso por tipos de trabalho: resumir conversa de atendimento, classificar intenção, responder dúvida com base em política, revisar PR, gerar teste unitário, investigar incidente, extrair informação de contrato, comparar versões de documento ou sugerir rollback. Para cada tarefa, a plataforma pode definir modelo padrão, modelos alternativos, custo esperado, latência aceitável, riscos, evals obrigatórios, dados permitidos, necessidade de revisão humana e formato esperado da saída.

O terceiro movimento é rodar modelos candidatos em modo sombra antes de migrar. O modelo atual continua respondendo ao usuário, enquanto o modelo candidato recebe as mesmas entradas em paralelo. As respostas do candidato não afetam o usuário final, mas são armazenadas e comparadas contra evals, critérios humanos e métricas do fluxo. Esse processo permite descobrir, por exemplo, que um novo modelo é mais barato em resumos, mas pior em casos regulatórios; ou que funciona melhor em código, mas pior em atendimento; ou que reduz latência, mas aumenta escalonamento humano.

O quarto movimento é tratar fallback como decisão de risco, não apenas como disponibilidade. Uma tarefa de baixo risco, como resumir uma conversa interna, pode tentar outro modelo, entregar um resultado parcial ou pedir revisão leve. Já uma tarefa regulatória, jurídica, financeira ou de segurança talvez não deva cair automaticamente para qualquer modelo alternativo. Em alguns casos, o fallback correto é outro modelo. Em outros, é reduzir o escopo da resposta. Em outros, é escalar para humano. Em outros, é bloquear a ação até que haja mais contexto. A plataforma precisa permitir essa diferença.

O quinto movimento é medir custo por resultado, não apenas por token. Um modelo barato pode sair caro se aumentar retrabalho, escalonamentos humanos ou respostas incorretas. Um modelo caro pode compensar se resolver mais casos críticos com segurança. Por isso, uma estratégia mais madura mede custo por outcome: custo por atendimento resolvido, por PR aceito, por incidente investigado até uma hipótese útil, por contrato analisado com precisão aceitável, por ticket classificado corretamente ou por tarefa concluída sem retrabalho. Esse raciocínio impede que a escolha de modelo vire religião e transforma a troca de LLM em decisão econômica e arquitetural.

Um exemplo prático: agente de engenharia

Imagine um agente que ajuda desenvolvedores a investigar incidentes. Na versão frágil, ele recebe uma pergunta, consulta alguns documentos, chama uma ferramenta de logs e responde. O prompt está no código, o contexto vem de uma base pouco curada, os traces são parciais, a avaliação é manual e o modelo é fixo. Quando a resposta é ruim, alguém ajusta o prompt. Quando o modelo muda, o time espera que o comportamento continue parecido. Se não continuar, começa uma nova rodada de tentativa e erro.

Na versão mais madura, a tarefa “investigar incidente” é tratada como uma porta de capacidade. Ela possui modelos permitidos, fallback, custo esperado, evals e critérios de qualidade. O agente recupera contexto de fontes versionadas, como runbooks, postmortems, dashboards, ownership de serviços e incidentes similares. Cada execução registra trace. Quando a resposta é ruim, o erro é classificado: contexto errado, ferramenta errada, raciocínio ruim, falta de dado, prompt inadequado ou lacuna de documentação. Com o tempo, esses erros viram evals.

Quando um novo modelo aparece, a empresa não precisa discutir apenas se ele “parece melhor”. Ela roda os mesmos casos históricos e compara. O novo modelo encontrou a causa mais rápido? Usou menos contexto? Chamou ferramentas melhores? Inventou menos? Custou menos? Pediu ajuda humana nos casos certos? Nesse cenário, a empresa tem uma estratégia porque construiu um sistema capaz de aprender e comparar. O modelo continua importante, mas deixou de ser o lugar onde a expertise mora.

Um exemplo prático: agente de atendimento

Agora imagine um agente de atendimento ao cliente. Na versão frágil, ele depende de um modelo específico e de um prompt grande com várias políticas coladas. Quando a política de reembolso muda, alguém edita o prompt. Quando o modelo muda, ninguém sabe se todos os casos continuam corretos. Quando uma resposta ruim acontece, a discussão vira “o modelo alucinou”, mesmo que a causa real possa ter sido contexto desatualizado, regra ambígua, falta de eval ou ausência de fallback humano.

Na versão mais madura, a política de reembolso fica em uma base versionada, com owner e data de atualização. A aplicação chama uma porta como responderSobreReembolso(cliente, pedido, contexto). O adapter de IA recupera a política aplicável, monta o prompt apropriado para o modelo atual, registra qual fonte foi usada, segue um formato de resposta e passa por evals com casos reais. Os traces mostram qual documento orientou a resposta. Casos sensíveis têm fallback para humano. Trocas de modelo são testadas em modo sombra antes de afetar usuários. O custo é medido por atendimento resolvido, não apenas por chamada ao modelo.

Esse desenho torna a organização menos dependente porque separa o que é conhecimento da empresa do que é capacidade do modelo. A política de reembolso pertence à empresa. Os evals pertencem à empresa. Os traces pertencem à empresa. O workflow de atendimento pertence à empresa. O modelo executa parte desse fluxo, mas não é o dono do aprendizado. Quando a empresa troca de modelo, ela testa, compara e calibra; não precisa torcer.

Um teste simples: seu LLM é adapter ou virou core?

Uma empresa provavelmente deixou o modelo virar core quando prompts críticos vivem espalhados e sem versionamento, cada squad chama modelos diretamente, regras de negócio aparecem dentro de instruções, não existem evals privados por tipo de tarefa, traces não são armazenados de forma útil, contexto institucional está preso a uma ferramenta específica, custo é medido só por token e trocar de modelo exige redescobrir o comportamento inteiro do sistema.

Por outro lado, uma empresa começa a tratar LLM como adapter quando modelos ficam atrás de portas de capacidade, prompts e workflows são versionados, contexto tem curadoria e rastreabilidade, evals rodam contra múltiplos modelos, traces alimentam melhoria contínua, fallback depende da criticidade da tarefa, custo é analisado por outcome e a troca de modelo pode ser testada antes de virar migração.

Esse teste não exige uma plataforma gigantesca no primeiro dia. Ele exige uma mudança de desenho. A empresa precisa parar de tratar IA como uma chamada direta para um fornecedor e começar a tratá-la como capacidade arquitetural. O modelo continua sendo uma peça central, mas deixa de ser o centro do aprendizado. O centro passa a ser o sistema que captura, avalia, observa e evolui o uso da IA no contexto real da organização.

Fechando a ideia

A próxima fase da IA corporativa não será vencida apenas por quem escolher o melhor modelo. Modelos vão mudar, custos vão mudar, fornecedores vão mudar e capacidades vão mudar. A vantagem duradoura estará em construir uma arquitetura que permita aprender continuamente, comparar alternativas e trocar infraestrutura sem perder a memória da organização.

O modelo é infraestrutura porque deveria ser substituível, comparável, roteável e governável. Em termos de desenho, ele deveria se comportar como adapter. O core do negócio não deveria depender diretamente de um LLM específico, e sim de capacidades internas com contratos claros. O modelo atual implementa essas capacidades; a plataforma decide quando, como e por que trocar essa implementação.

Quando a empresa entende isso, trocar de modelo deixa de ser uma ameaça. Vira apenas mais uma decisão de engenharia.