O cemitério dos pilotos: seis razões por que os projetos agênticos são cancelados
As demonstrações melhoram todos os meses. Qualquer pessoa põe de pé numa tarde algo que parece um agente autónomo, e o entusiasmo na administração é real. À superfície, a adoção parece estar a acelerar.
Só que os números por baixo contam uma história mais dura. Cerca de 60% das empresas reportam nenhum valor mensurável vindo da IA (BCG), aproximadamente 1% considera-se madura em IA (McKinsey QuantumBlack), e projeta-se que cerca de 40% dos projetos de IA agêntica sejam cancelados até 2027 (Thoughtworks). É um cemitério, e o que nele impressiona é a pouca variedade das causas de morte. Os projetos não falham de mil maneiras criativas. Falham de umas seis, e todas são evitáveis se desenhar para elas antes de começar.
Aqui ficam as seis, e o que fazer em vez disso.
Razão 1: escalaram uma automação de portátil, não uma arquitetura
A causa de morte mais comum é confundir uma demonstração que funciona com um sistema de produção. Um script feito por alguém da equipa passa na demonstração, declara-se vitória, e o plano passa a ser "escalar isto".
Mas uma automação de portátil e um agente em produção estão separados por um abismo que escalar não atravessa. A automação nunca teve de tratar identidade, privilégio mínimo, drift, auditoria ou input não confiável, porque numa máquina nada disso estava em âmbito. Escalar o script limita-se a escalar os alicerces que lhe faltam.
Como evitar. Trate a demonstração como prova de que a ideia tem mérito, não como o sistema. Antes de escalar, pergunte o que é que a coisa precisa e o portátil nunca lhe deu: uma identidade, uma fronteira à volta do que lê, um registo do que decide. Se isso falta, não está a escalar um sistema, está a escalar um passivo.
Razão 2: o agente não conseguia alcançar o contexto de que precisava
O segundo cemitério é mais silencioso, porque o agente funciona perfeitamente, só não consegue ver o suficiente para importar. O contexto dele vive espalhado pelo CRM, o core, o repositório documental, e a pessoa que conhece a única exceção. A organização nunca construiu a camada que permite a um agente alcançar esse contexto em segurança.
Por isso o projeto divide-se em duas más opções. Ou o agente fica demasiado isolado para ser útil, ou é ligado com credenciais amplas e permanentes que o comité de segurança não aprovará. Ambos os caminhos levam ao cancelamento.
Como evitar. Reserve orçamento para a camada de contexto como trabalho a sério, não como canalização. O agente deve alcançar os seus sistemas através de capacidades tipadas e com nome, atuar sob a sua identidade de privilégio mínimo, e ser estruturalmente incapaz de tratar dados não confiáveis como instrução. Se essa camada não está no plano, a escolha do modelo é irrelevante.
Razão 3: não passou no comité de segurança
Muitos pilotos morrem não em produção mas na revisão de homologação, e a constatação é quase sempre a mesma: o agente corre sob o token pessoal de quem o fez, com acesso permanente a produção. É uma chave-mestra, e nenhum comité de segurança sério aprova isso.
O projeto era tecnicamente impressionante e estruturalmente inaprovável. A equipa otimizou para "funciona?" e nunca perguntou "passa na revisão?", que numa empresa regulada é a pergunta que de facto controla a entrada em produção.
Como evitar. Desenhe para o comité de segurança desde o primeiro dia, não como último obstáculo. Cada agente corre sob a sua identidade não humana, com credenciais de curta duração e privilégio mínimo e uma allow-list de saída explícita, para que não haja segredo estático para roubar e a identidade só consiga fazer as poucas coisas para que foi delimitada. Mapeie cada risco agêntico num controlo com nome e testável, para que o comité aprove um controlo, e não uma garantia.
Razão 4: a governação de TI não conseguia governar um sistema que se desvia
Alguns projetos passam no comité de segurança e são cancelados uns meses depois, quando a governação descobre que não tem forma de segurar a coisa. O comité de alterações foi construído para software determinístico: mesmo input, mesmo output, entregas com controlo de alterações. Não tem mecanismo para um sistema que mudou porque um modelo foi atualizado de noite e ninguém entregou nada.
O resultado é um projeto que parecia governado, porque passou pelo processo normal, e se revela ingovernável na prática. Passou no gate errado.
Como evitar. Acrescente uma camada de governação feita para agentes ao lado da sua governação de TI, e não por cima dela. Os agentes conquistam autonomia numa escada graduada controlada por evals, a monitorização de drift consegue despromover um agente automaticamente assim que ele sai da sua fasquia, e a unidade de governação passa a ser cada decisão, e não cada entrega. A governação determinística continua a fazer aquilo em que é boa. A camada nova assume o drift.
Razão 5: o comité de risco não conseguia aprovar uma caixa negra
O quinto cemitério é um comité que continua a dizer que não. O sistema pode funcionar, mas ninguém consegue explicar, depois do facto, por que tomou uma decisão específica. Sem isso, um comité de risco não consegue aprovar, e um projeto que não consegue ser aprovado não consegue escalar.
É aqui que "o modelo é impressionante" deixa de importar. O comité não está a avaliar o modelo. Está a avaliar se consegue defender o sistema perante um regulador, e não consegue defender o que não consegue inspecionar.
Como evitar. Torne cada decisão inspecionável antes de se concretizar. Cada uma deixa um registo de evidências append-only e encadeado por hash, escrito antes de a decisão produzir efeito, por isso, se a evidência não puder ser escrita, a decisão não acontece. As decisões com consequência resolvem-se numa pessoa, por política, e as regras de compliance são código de que a sua equipa de compliance é dona e que assina. Nessa altura, o comité está a aprovar um controlo documentado e testável, que é um sim que consegue dar.
Razão 6: apostaram alto, não mediram nada, e não tinham saída
A última causa de morte é uma falha de formato do projeto, e mata boas arquiteturas a par das más. A organização compromete-se à partida com um lançamento alargado, nunca estabelece uma linha de base auditável, nunca define um gate go/no-go, e por isso não tem forma honesta de saber se a coisa está a funcionar. Acumulam-se meses de custo sem maneira de provar retorno e, a certa altura, alguém desliga um projeto que até podia estar bem, porque ninguém conseguia mostrar que estava.
Como evitar. Não aposte a empresa para testar a arquitetura. Comprometa-se antes com uma Fundação: um processo de alta consequência, levado a agente governado em produção em cerca de seis a oito semanas, medido contra uma linha de base auditável, com um gate go/no-go explícito antes de alguém se comprometer a escalar.
Uma sequência aproximada torna isto concreto. Nos primeiros 30 dias, prove a fronteira: monte a camada de contexto e as identidades para esse processo, com o agente em Sombra, a propor enquanto as pessoas decidem. Dos 30 aos 60 dias, prove a governação: ligue o trilho de evidências e o ponto de decisão de políticas, passe o agente a Supervisionado, e deixe o comité de risco inspecionar um controlo real em vez de um slide. Dos 60 aos 90 dias, prove o valor no gate: meça custo por unidade, latência, ganho de qualidade e concordância com a revisão humana contra a linha de base, e decida escalar com base em evidência.
Se ultrapassar a fasquia, escala com prova. Se não, gastou oito semanas e aprendeu algo real sem exposição em produção, o que é muito melhor do que descobri-lo depois de um lançamento alargado.
O reenquadramento
Repare no que as seis razões têm em comum. Nenhuma é "o modelo não era suficientemente bom". Todas as mortes no cemitério são arquiteturais ou processuais: uma camada em falta, uma identidade inaprovável, um modelo de governação que não vê o drift, uma decisão não auditável, ou uma aposta feita antes de algo estar provado.
Por isso a pergunta não é "estamos atrasados na IA?". É no nosso processo mais consequente, temos uma identidade para o agente, uma fronteira à volta do que ele lê, um registo do que decide, uma camada de governação que o vê desviar-se, e um gate definido à partida? E, se não, qual é a Fundação mais pequena que nos permitiria descobri-lo a sério, antes de apostarmos no segundo processo?
Se quiser uma leitura honesta de onde um dos seus processos aterraria, marque uma reunião.