A ressaca dos agentes de IA: a conta chegou!

Participei recentemente de uma reunião com executivos de uma empresa que enfrentava um problema que, acredito, veremos com frequência crescente no mundo corporativo.

A empresa havia embarcado com entusiasmo na onda dos agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →. Investiu em plataformas de mercado, promoveu treinamentos e incentivou funcionários de diferentes áreas a desenvolver suas próprias soluções. Em pouco tempo, milhares de agentes haviam sido criados, muitos deles já em produção.

Inicialmente, tudo parecia um sucesso. Os funcionários estavam engajados, novas automações surgiam continuamente e a quantidade de agentes criados havia se transformado em um indicador informal de maturidade digital.

Mas a conta começou a chegar. Agentes desenvolvidos por funcionários que já haviam deixado a empresa continuavam operando sem responsáveis definidos. Outros executavam processos que haviam mudado, utilizavam regras desatualizadas ou mantinham permissões incompatíveis com suas necessidades. Havia soluções duplicadas, integrações frágeis e agentes cuja finalidade original ninguém conseguia explicar.

O mais preocupante eram os erros silenciosos. Alguns agentes continuavam funcionando tecnicamente, mas produziam resultados incorretos ou executavam ações inadequadas. Em determinados casos, os problemas só eram descobertos semanas depois, quando seus efeitos já haviam se propagado pelos processos de negócio.

Também surgiram situações de exposição indevida de dados, credenciais sem gestão adequada e dificuldades para identificar quais informações eram compartilhadas com serviços externos. Alguns agentes haviam se tornado dependências operacionais de processos importantes, sem que isso estivesse documentado.

A empresa havia democratizado a criação de agentes, mas não havia desenvolvido, na mesma velocidade, a capacidade de administrá-los.

Durante a conversa, ficou evidente que o problema não era apenas tecnológico. Era, principalmente, organizacional.

As áreas de negócio conheciam seus processos e haviam encontrado maneiras criativas de automatizá-los. Mas conhecer um processo não significa dominar engenharia de software, segurança, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →, gestão de identidades ou avaliação de sistemas baseados em LLMs.

A TI, por sua vez, nem sempre sabia quais agentes existiam, quem os havia desenvolvido ou quais sistemas corporativos estavam sendo acessados.

Reconheci ali uma versão mais complexa de um problema antigo: aplicações criadas fora dos mecanismos tradicionais de governança. A diferença é que determinados agentes não apenas produzem informações. Eles podem alterar registros, acionar ferramentas e desencadear operações com consequências reais.

A combinação de comportamento probabilístico, integrações corporativas e diferentes graus de autonomia amplia os desafios de controle. Falhas silenciosas não são exclusivas da IA, mas a variabilidade das respostas e das trajetórias de execução torna sua identificação potencialmente mais difícil.

Em determinado momento surgiu a pergunta de um milhão de dólares: o que fazer agora, com milhares de agentes espalhados pela organização?

Minha posição foi que interromper indiscriminadamente todas as iniciativas seria um erro. Muitos agentes poderiam estar entregando valor e já integravam rotinas importantes. Mas isso não significava manter tudo funcionando enquanto a empresa tentava organizar a situação.

O caminho discutido foi recuperar o controle por prioridades, começando pelos riscos mais relevantes.

A primeira medida seria construir um inventário corporativo, identificando agentes ativos, responsáveis, sistemas utilizados, dados acessados, ferramentas disponíveis e permissões concedidas. Sempre que possível, esse levantamento deveria aproveitar registros das plataformas, identidades e logs de execução, evitando depender exclusivamente de declarações dos usuários.

A segunda seria classificar os agentes conforme seu impacto potencial. Assistentes que apenas consultam informações públicas não exigem os mesmos controles daqueles que alteram cadastros, aprovam pagamentos ou interferem em operações críticas.

Nos casos de maior risco, seria necessário revisar imediatamente permissões, credenciais e limites de autonomia. Agentes envolvidos em incidentes graves ou sem condições mínimas de controle deveriam ter suas operações restringidas ou suspensas de forma segura, considerando as dependências existentes.

Também discutimos a necessidade de estabelecer responsáveis formais pelo resultado de negócio e pela sustentação técnica. Um agente em produção não pode depender exclusivamente da pessoa que o criou. A saída de um funcionário precisa desencadear a revisão de acessos, credenciais, propriedade e continuidade das soluções sob sua responsabilidade.

Outra prioridade seria implementar avaliações contínuas. Não basta verificar disponibilidade ou ausência de erros técnicos. É necessário testar se os resultados continuam corretos, se as regras de negócio permanecem válidas e se alterações em modelos, prompts, ferramentas ou dados modificaram o comportamento esperado.

Isso exige testes de regressão comportamental, observabilidade, trilhas de auditoria e mecanismos de contenção. Para agentes críticos, supervisão humana e procedimentos de recuperação devem complementar os controles automatizados.

Uma discussão importante envolveu a arquitetura. Em vez de cada área desenvolver seus próprios conectores, mecanismos de autenticação, recuperação de informações e monitoramento, esses recursos poderiam ser disponibilizados por uma plataforma corporativa compartilhada.

A lógica é permitir inovação descentralizada sobre uma infraestrutura governada, com controles proporcionais ao risco e sem transformar cada pequena automação em um projeto burocrático.

Também defendi uma revisão do portfólio. Alguns agentes poderiam ser consolidados, outros desativados e determinados casos substituídos por fluxos determinísticos mais simples, previsíveis e econômicos.

Nem toda necessidade exige um agente. E nem todo agente criado merece continuar em produção.

Outro ponto pouco discutido é o custo total de propriedade. O gasto não se limita a licenças, tokens e infraestrutura. Inclui integração, testes, monitoramento, segurança, suporte, manutenção, incidentes e retrabalho. Sem relacionar esses custos aos resultados efetivamente entregues, a empresa pode estar automatizando atividades sem criar valor econômico líquido.

Saí da longa reunião com uma percepção ainda mais clara de algo que venho defendendo: estamos confundindo democratização do desenvolvimento com maturidade no uso corporativo da IA.

Depois de décadas acompanhando a evolução do software corporativo, reconheço um padrão familiar. Já vimos algo semelhante com planilhas críticas sem controle, aplicações departamentais e iniciativas de shadow IT. A tecnologia reduz a barreira de entrada, a inovação acelera e a governança chega atrasada.

Com agentes de IA, essa defasagem pode ter consequências mais amplas quando sistemas com diferentes graus de autonomia passam a executar ações sobre processos operacionais, financeiros e regulados.

Mas a principal lição daquela reunião não foi sobre inventários, plataformas ou ferramentas de segurança. Foi sobre responsabilidade.

A empresa havia democratizado a capacidade de criar agentes, mas não havia estabelecido quem responderia por seu funcionamento, seus riscos e suas consequências ao longo do tempo.

Esse, para mim, foi o erro fundamental. Não se trata de transformar cada funcionário em engenheiro de software ou especialista em segurança. Trata-se de estabelecer um modelo operacional no qual as áreas de negócio possam inovar, enquanto responsabilidades por engenharia, sustentação, segurança e governança estejam claramente atribuídas.

A maturidade de uma empresa em IA não será demonstrada pela quantidade de agentes que seus funcionários conseguem criar durante um treinamento. Será demonstrada pela capacidade de manter os agentes certos funcionando corretamente, produzindo resultados mensuráveis, com custos sustentáveis e riscos controlados.

Democratizar a criação de agentes sem estabelecer responsabilidade por seu ciclo de vida não é maturidade digital. É uma maneira mais rápida de acumular dívida técnica e risco operacional.

A grande lição daquela reunião foi simples: a governança não pode começar quando a empolgação termina. Ela precisa fazer parte da arquitetura da inovação desde o primeiro dia.