Platform engineering para serviços de IA — golden paths para times que usam LLMs
Quando times de produto começam a usar LLMs, a plataforma precisa evoluir. O que aprendi construindo infraestrutura para IA dentro de uma empresa.
Em 2023, um time de produto me perguntou: "como a gente usa LLM aqui dentro de forma que segurança aprove?"
Essa pergunta parece simples. Ela representa meses de trabalho.
Golden path é um conceito de platform engineering: você constrói o caminho mais fácil e mais seguro para um caso de uso comum, de forma que os times de produto possam usar sem precisar reinventar a infraestrutura.
Para APIs REST, o golden path inclui autenticação, rate limiting, observabilidade, e padronização de erro — tudo pronto, o time de produto só implementa a lógica de negócio.
Para LLM, o golden path precisa incluir coisas que não existiam em infraestrutura três anos atrás:
Roteamento de modelo. Qual modelo usar para qual caso de uso, com qual fallback quando o modelo primário está degradado ou caro demais para aquele contexto. Isso não pode ficar hardcoded em cada serviço — precisa ser centralizado e configurável.
Budget e custo por serviço. Cada serviço tem um orçamento de tokens. Quando estoura, o comportamento precisa ser definido: fallback para modelo mais barato, degradação graciosa, ou bloqueio. Sem isso, um bug num serviço pode gerar fatura de milhares de dólares em horas.
Cache de prompt. Prefixos de sistema idênticos cachear automaticamente. Implementar isso em cada serviço é duplicação — implementar na camada de plataforma multiplica o benefício para todos os times.
Auditoria. Cada chamada de LLM que processa dados de usuário precisa ser auditável. O que foi enviado, por qual serviço, com qual resultado, com qual latência. Não opcionalmente.
O que aprendi sobre adoção:
Se o golden path for mais trabalhoso do que integrar direto com a API do provider, os times ignoram. Isso não é desobediência — é engenharia: eles escolhem o caminho de menor resistência.
Por isso a interface precisa ser simples ao extremo. O time de produto não precisa saber que tem cache, roteamento, ou auditoria acontecendo. Eles chamam uma função, passam o contexto, recebem a resposta. A plataforma faz o resto.
Quando a interface está certa, os times adotam não porque são obrigados — porque é mais fácil do que construir do zero.
O segundo aprendizado: evolução de modelo não pode quebrar os times.
Provedores de LLM atualizam modelos frequentemente. Quando o modelo muda, o comportamento pode mudar — sutilmente, de formas que quebram a aplicação. Se cada time integra diretamente, cada time precisa gerenciar essa evolução.
Na camada de plataforma, você pode controlar quando cada serviço migra para um modelo novo. Teste o modelo novo com o golden set antes de rotacionar. Rotacione um serviço de cada vez. Tenha rollback imediato.
Isso é governança de LLM. E é onde a plataforma entrega mais valor do que qualquer time individual conseguiria sozinho.
O que ainda é aberto:
Avaliação automatizada de qualidade de resposta. É o problema mais difícil. Latência, custo e disponibilidade são métricas objetivas. "A resposta foi boa?" ainda depende de julgamento humano ou de um LLM avaliador — que também pode errar.
Não tenho resposta pronta. Mas tenho a pergunta: você sabe hoje se a qualidade das respostas do seu agente degradou na última semana?
Essa semana: se você trabalha com plataforma e times de produto já usam LLM de forma ad hoc, mapeie: quantas integrações diretas com provider existem? Esse número representa duplicação de custo e risco.