
A evolução dos LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → está produzindo uma mudança importante. Durante muito tempo, discutimos IA principalmente como uma tecnologia capaz de gerar texto, código, imagens ou análises. Agora estamos colocando esses modelos dentro de sistemas capazes de planejar tarefas, utilizar ferramentas, acessar APIs, consultar dados, modificar arquivos e executar ações com diferentes graus de autonomia.
Um erro em uma resposta de um chatbot pode produzir uma informação incorreta. Um erro de um agente conectado à infraestrutura de uma empresa pode alterar configurações, apagar dados, interromper serviços ou expor informações sensíveis.
Isso já deixou de ser apenas uma hipótese. Em abril de 2026, foi relatado um incidente no qual um agente de programação, diante de um problema de credenciais, encontrou um token disponível em um arquivo e utilizou uma chamada de API que apagou um volume de produção, levando também à perda dos backups que estavam naquele volume.
O detalhe mais importante, porém, não é o erro específico. É a natureza do erro. O agente não precisava estar “mal-intencionado”. Bastou interpretar incorretamente a situação, encontrar uma credencial disponível e possuir permissões suficientes para transformar uma decisão errada em uma consequência operacional.
Esse é um problema diferente daquele que normalmente associamos a software tradicional. Um agente baseado em LLM introduz uma camada probabilística na interpretação do contexto, no planejamento e na escolha das ações. Ele pode decidir quais ferramentas utilizar e quais passos intermediários executar sem que cada decisão tenha sido explicitamente programada.
Por isso, simplesmente colocar “guardrails” em torno do modelo não é suficiente. Precisamos controlar a autonomia na arquitetura.
Um agente que analisa documentos pode ter ampla liberdade para ler, mas nenhuma para alterá-los. Um agente que escreve código pode criar uma branch e executar testes, mas não fazer deploy em produção. Um agente financeiro pode preparar uma operação, mas não autorizá-la.
A regra deve ser simples: quanto maior o impacto potencial e menor a reversibilidade de uma ação, maior deve ser o nível de controle exigido.
Isso significa combinar least privilege, identidades próprias para agentes, isolamento de ambientes, autorização por ação, aprovação humana para operações críticas, monitoramento, testes, logs e trilhas de auditoria. E deve existir também a capacidade de revogar rapidamente credenciais ou interromper a execução. Essas preocupações já aparecem explicitamente nas recomendações de OWASP e nas iniciativas do NIST para identidade e autorização de agentes.
Há ainda uma questão organizacional. A velocidade de evolução dos modelos está sendo maior do que a velocidade com que muitas empresas conseguem adaptar arquitetura, processos, segurança e governança.
Adotar agentes simplesmente porque eles prometem produtividade pode criar uma situação em que a empresa acelera justamente aquilo que ainda não sabe controlar.
Por isso, a discussão sobre IA agêntica precisa sair do entusiasmo com autonomia e entrar na engenharia de sistemas. O verdadeiro desafio não é construir agentes que façam cada vez mais coisas. É construir agentes capazes de fazer mais dentro de limites que possamos compreender, testar, monitorar, auditar e interromper.
Na IA agêntica, autonomia sem arquitetura de controle não é inovação. É risco operacional em alta velocidade.






