Systems Design Meditation · Edition 1
O agente não é o sistema
Porque é que a IA se está a tornar um problema de infraestrutura
Edward Calderón
Arquiteto de Software
A IA está a começar a desaparecer na infraestrutura.
Não porque importe menos. Porque está a descer para camadas mais profundas da stack.
Durante vários anos, a conversa pública centrou-se no modelo. Qual é o modelo que raciocina melhor? Qual é o modelo que tem o maior contexto? Qual é o modelo que escreve melhor código? Essas perguntas continuam a ser úteis. Mas já não são suficientes.
Um modelo responde. Um agente pode agir. Quando o sistema consegue agir, a arquitetura torna-se tão importante como a inteligência.
A unidade de análise mudou
Um modelo de linguagem mapeia uma entrada numa saída probabilística. Um agente operacional envolve esse modelo com memória, ferramentas, identidade, políticas, filas, bases de dados e feedback. Pode ler um ticket, consultar telemetria de produção, alterar uma configuração e notificar um cliente. Cada passo atravessa uma fronteira de confiança. A qualidade da frase gerada é apenas uma pequena parte do resultado.
É por isso que o modelo não é o sistema. O modelo é um participante dentro do sistema.
As perguntas úteis de hoje são familiares a qualquer pessoa que tenha operado infraestrutura na nuvem ou distribuída: A que consegue o agente aceder? Quem delegou a sua autoridade? O que pode modificar? Que estado mantém? Como é observada a ação? O que acontece se estiver errada? A ação pode ser revertida? Quem é responsável?
O acesso a ferramentas converte um erro de raciocínio numa possível transição de estado. Se um chatbot inventa uma política de reembolsos, a saída está errada. Se um agente executa o reembolso, atualiza o livro-razão e encerra o caso, a organização à sua volta mudou. O modelo de falhas já não se limita ao texto.
Conceber para uma ação limitada
Uma infraestrutura de agentes fiável precisa de vários limites. A identidade deve ser específica da carga de trabalho, e não uma chave de API partilhada. A autorização deve ser restrita, de curta duração e explícita quanto aos recursos e às ações permitidos. As operações de alto impacto precisam de pontos de aprovação. Cada invocação de uma ferramenta precisa de dados de auditoria estruturados: ator, delegante, entrada, decisão de política, saída e estado resultante.
A observabilidade também tem de ir além do rastreio comum de pedidos. Um trace pode dizer-nos que uma chamada foi bem-sucedida enquanto a ação de negócio estava incorreta. Precisamos de ligar as decisões do modelo às invocações de ferramentas e as invocações de ferramentas aos efeitos duradouros. A medida relevante não é apenas a latência ou o consumo de tokens. É se o invariante pretendido continua válido.
A reversão é igualmente concreta. Algumas ações podem ser compensadas: uma implementação pode regressar a uma revisão anterior. Outras não podem ser realmente revertidas: um e-mail foi enviado, um segredo foi exposto, um pagamento foi liquidado. A arquitetura deve classificar as ações antes de um agente as receber, e não depois de um incidente.
Considere um agente que presta assistência a alterações de infraestrutura. Pode inspecionar métricas e propor um patch sem qualquer risco. Aplicar esse patch a uma sandbox pode exigir uma credencial de âmbito restrito. A produção precisa de avaliação de políticas, aprovação humana para alterações arriscadas, implementação progressiva, verificações de saúde e uma condição de paragem automática. O agente pode participar em todo o processo sem se tornar um administrador sem limites.
Este padrão assemelha-se ao DevSecOps maduro porque o problema subjacente é familiar: fazer avançar alterações num sistema sem perder o controlo do risco. Os agentes tornam a interface mais flexível, mas a flexibilidade não elimina a disciplina operacional.
Capacidade não é fiabilidade
Um modelo muito capaz dentro de uma infraestrutura mal concebida produz um produto frágil. Um modelo um pouco menos capaz dentro de uma arquitetura excelente pode produzir um sistema muito mais fiável. O segundo sistema consegue limitar a incerteza, detetar falhas e recuperar.
É também por isso que a adoção empresarial será desigual. As demonstrações otimizam em função da capacidade visível. Os sistemas de produção têm de lidar com o ciclo de vida da identidade, os limites de dados, a resposta a incidentes, os controlos de custos, as evidências regulamentares e as dependências degradadas. Estas camadas não são canalizações periféricas. São elas que determinam se é possível confiar trabalho à inteligência.
Os padrões de agentes emergentes são úteis, mas nenhum protocolo substitui a arquitetura. Uma framework de agentes não pode decidir a tolerância ao risco de uma organização. Um fornecedor de modelos não pode definir que transições de estado são reversíveis. Essas decisões pertencem ao sistema em torno do modelo.
A direção prática não é, portanto, a autonomia em todo o lado. É uma autonomia graduada: observar, recomendar, agir dentro de um limite estreito, ganhar uma autoridade mais ampla através de fiabilidade comprovada. Isto dá às equipas uma forma de aprender sem fingir que os componentes probabilísticos são determinísticos.
A inteligência, por si só, não cria infraestrutura fiável.
A arquitetura, sim.