Resposta rápida: o piloto de IA que funciona e morre em seguida é mais comum do que o piloto que falha, e ele produz um dano maior, porque queima credibilidade interna com um resultado positivo desperdiçado. O mecanismo é estrutural: pilotos são patrocinados por quem tem interesse em provar a tese, e a operação exige alguém disposto a assumir orçamento recorrente, responsabilidade sobre erro e trabalho de manutenção. Essas duas pessoas raramente são a mesma. Quando ninguém assume, o piloto entra num limbo em que segue rodando sem manutenção, degrada em silêncio e é desligado meses depois sem que ninguém decida formalmente. O que resolve é definir o dono da operação antes do piloto começar, com quatro compromissos escritos: orçamento recorrente, alocação de pessoa para supervisão, critério de sucesso que ele mesmo aceita, e responsabilidade sobre a decisão de escalar ou encerrar. Eu recomendo tratar essa definição como pré-requisito, e jamais como assunto para depois.
Por que o piloto bem-sucedido é o mais difícil de escalar?
Um piloto que falha resolve a questão sozinho: a hipótese estava errada, o time aprende e segue. Um piloto que funciona abre uma pergunta bem mais difícil, que é quem paga a conta permanente e quem responde quando aquilo errar diante de um cliente. Essas duas perguntas raramente aparecem no desenho do piloto, porque a fase de teste opera com orçamento de projeto e com tolerância elevada a erro.
A passagem para operação muda as três condições que faziam o piloto funcionar. O orçamento deixa de ser investimento pontual e vira linha recorrente que compete com outras prioridades da área. A tolerância a erro cai, porque o volume aumenta e o público deixa de ser um grupo selecionado. E a atenção especializada desaparece, porque a equipe de projeto se dissolve e a operação assume com o pessoal que já tem.
Esse conjunto de mudanças produz um piloto que funcionava com dez casos por dia acompanhados por três pessoas atentas e que passa a operar com quatrocentos casos por dia sob a responsabilidade de alguém que tem outras seis prioridades. A degradação que se segue raramente é falha da tecnologia, e ela é frequentemente lida como tal, o que produz a conclusão errada de que aquele caso de uso deixou de funcionar. Esse mecanismo é o assunto do artigo sobre do piloto para a operação e o vale da escala.
Quem patrocina um piloto e por que essa pessoa raramente assume a operação?
Pilotos de IA costumam ser patrocinados por três perfis, e nenhum deles opera o processo no dia a dia. O primeiro perfil é o executivo que precisa mostrar movimento em IA para o conselho ou para o mercado, com interesse legítimo em resultado demonstrável e prazo curto.
O segundo perfil é a área de tecnologia ou de inovação, que tem competência para construir e carece de responsabilidade sobre o processo de negócio. Pilotos patrocinados por essa área funcionam bem tecnicamente e enfrentam a maior dificuldade de transferência, porque a área operacional recebe algo que outra pessoa desenhou.
O terceiro perfil é o entusiasta individual, alguém de área de negócio que se interessou, construiu por conta própria e provou valor. Esse perfil produz os pilotos mais bem ajustados ao processo real e a transferência mais frágil de todas, porque o conhecimento vive numa pessoa que raramente tem mandato para institucionalizar aquilo.
Em nenhum dos três casos o patrocinador é naturalmente o dono da operação, e a suposição implícita de que ele será resolve zero problema. Nomear o dono da operação explicitamente, com aceite dele, é o que separa piloto que escala de piloto que morre aplaudido.
O que exatamente falta quando dizemos que falta dono?
Faltam quatro coisas distintas, e confundi-las produz soluções parciais. A primeira é a autoridade orçamentária: alguém precisa ter o orçamento que sustenta a operação e aceitar essa linha na própria conta. Sem isso, o custo fica órfão e aparece em rateio genérico que ninguém defende na revisão de orçamento.
A segunda é a responsabilidade sobre resultado, incluindo o erro. Quando o agente falha diante de um cliente, alguém precisa responder por aquilo, tomar a decisão de corrigir ou suspender e prestar contas. Pilotos sem essa definição produzem paralisia no primeiro incidente, com áreas discutindo alçada enquanto o problema segue ativo.
A terceira é a capacidade de manutenção, que significa uma pessoa com tempo alocado para revisar saídas, ajustar configuração e acompanhar indicadores. Essa alocação precisa ser explícita em horas, porque a alternativa é alguém fazendo isso nas sobras da agenda, que é como agentes degradam.
A quarta é a autoridade sobre o processo. O dono precisa poder alterar o desenho do trabalho ao redor do agente, porque manter o processo antigo e acrescentar o agente por cima produz o pior resultado possível. Quando essas quatro coisas ficam com pessoas diferentes, o agente segue vivo e ninguém está no comando.
Quais custos aparecem na passagem de piloto para operação?
O primeiro custo é o de consumo em escala. Um piloto com volume pequeno tem custo desprezível, e o mesmo agente com volume completo produz uma linha relevante que precisa entrar no orçamento anual da área. Empresas que aprovam pilotos sem estimar esse valor produzem surpresas desagradáveis no momento da transferência.
O segundo custo é o de integração definitiva. Pilotos frequentemente operam com integrações provisórias, planilhas intermediárias e trabalho manual de ponte. Transformar isso em operação exige desenvolvimento real, que costuma equivaler a uma fração significativa do custo do piloto inteiro.
O terceiro custo é o de supervisão, que precisa ser dimensionado em horas por semana com base na taxa de casos que exigem revisão. Esse número é mensurável no piloto e ele raramente é medido, o que produz uma transferência sem qualquer noção de quanta gente a operação exige.
O quarto custo é o de treinamento do time operacional, que precisa aprender a trabalhar com o agente, reconhecer quando ele erra e saber o que fazer nesse caso. Somados, esses quatro custos costumam representar de duas a quatro vezes o custo do piloto, e apresentá-los antes evita a impressão de que a operação seria uma continuação natural e barata.
Como identificar o dono certo?
A pergunta que resolve é direta: quem responde hoje pelo resultado do processo que o agente atende. Essa pessoa é o dono natural, independentemente de quem construiu ou patrocinou. Quando a resposta envolve duas ou três áreas, o processo atravessa fronteiras e a definição exige uma decisão de diretoria em vez de negociação entre pares.
Existe um teste complementar útil: quem sofre quando o processo falha. Se o agente errar e o problema aparecer numa área específica, essa área tem incentivo natural para manter a qualidade, o que faz dela um dono melhor do que qualquer área de apoio.
O erro comum é entregar a propriedade à área de tecnologia por ela ter construído. Isso produz um arranjo em que quem responde pela qualidade do processo carece de autoridade sobre a ferramenta, e quem tem autoridade sobre a ferramenta carece de contato com a consequência do erro. Tecnologia sustenta a plataforma, e o dono do processo responde pelo resultado, divisão que o artigo sobre Chief AI Officer como cargo ou papel distribuído desenvolve na dimensão organizacional.
O que o dono precisa receber junto com a responsabilidade?
O primeiro item é o orçamento correspondente, transferido junto com a responsabilidade. Entregar a propriedade de um agente sem o orçamento que o sustenta é uma forma elegante de garantir que ele será desligado na próxima revisão de custos.
O segundo item é a documentação completa: como o agente funciona, quais regras ele aplica, onde ele falha, como ajustar e como reverter para o modo manual. Essa documentação precisa existir antes da transferência, e produzi-la é responsabilidade de quem construiu.
O terceiro item é o acesso e a capacidade de alterar. Um dono que precisa abrir solicitação a outra área para cada ajuste de configuração carece de propriedade real, e a distância entre a necessidade e a mudança produz degradação. Autonomia de ajuste dentro de limites definidos resolve isso.
O quarto item é um período de suporte de transição, tipicamente de sessenta a noventa dias, em que quem construiu permanece disponível para dúvidas e problemas. Esse período custa pouco e ele evita o abandono por dificuldade nas primeiras semanas, quando o time novo ainda desconhece o comportamento do sistema.
Como estruturar a passagem de bastão?
A passagem que funciona tem quatro marcos. O primeiro é o aceite formal do dono, com o documento que lista as quatro responsabilidades e o que ele recebe em contrapartida, assinado antes de qualquer transferência técnica. Sem esse aceite, tudo o que vem depois é suposição.
O segundo marco é a operação assistida, um período de trinta dias em que o time novo opera e quem construiu acompanha diariamente. Esse período revela as lacunas de documentação e de treinamento com clareza, e corrigi-las nesse momento custa uma fração do que custaria depois.
O terceiro marco é a revisão de trinta dias, com os indicadores comparados aos do piloto. Diferenças esperadas aparecem, e o importante é distinguir degradação por escala, que exige ajuste técnico, de degradação por falta de domínio, que exige treinamento.
O quarto marco é o encerramento formal do projeto, com o registro de que a operação está transferida, o dono nomeado e o suporte de transição concluído. Projetos que jamais encerram formalmente deixam a propriedade ambígua indefinidamente, e essa ambiguidade é a origem do agente órfão.
Que sinais indicam que um piloto está órfão?
O primeiro sinal é a ausência de resposta imediata para a pergunta sobre quem responde por aquele agente. Quando a resposta exige investigação ou vem em forma de duas ou três áreas, a propriedade é ambígua na prática.
O segundo sinal é a ausência de qualquer ajuste na configuração por três meses ou mais. Agentes vivos recebem ajustes conforme o negócio muda; agentes órfãos ficam congelados na configuração original, o que garante divergência crescente em relação à realidade.
O terceiro sinal é o custo aparecendo em rateio genérico sem correspondência com nenhuma área. Esse padrão indica que ninguém assumiu a linha, e ele antecede o desligamento por corte de custo em algum trimestre difícil.
O quarto sinal é a ausência de qualquer indicador acompanhado. Quando ninguém sabe dizer quantos casos o agente processou no último mês nem qual a taxa de correção humana, o agente opera sem supervisão, e a diferença entre isso e um agente desligado é apenas a exposição que o primeiro mantém ativa.
O que fazer com o piloto que ninguém quer assumir?
Essa situação merece uma leitura honesta antes de qualquer tentativa de convencimento. Quando nenhuma área quer assumir um piloto que funcionou, existe geralmente um dos três motivos, e apenas um deles se resolve com negociação.
O primeiro motivo é orçamentário: a área reconhece o valor e carece de espaço no orçamento. Esse caso se resolve com decisão de diretoria sobre alocação, e ele é o mais simples dos três.
O segundo motivo é a relação desfavorável entre benefício e trabalho. A área calculou que o ganho justifica pouco o esforço de supervisão e manutenção, e essa leitura frequentemente está correta. Nesse caso, o encerramento é a decisão certa, e forçar a adoção produz um agente mal supervisionado.
O terceiro motivo é a ausência de dono claro do processo, quando o piloto atende algo que atravessa áreas sem responsável único. Esse caso exige decisão estrutural sobre propriedade do processo, que vai além do agente e costuma ser um problema que já existia antes dele.
Em qualquer dos casos, a decisão explícita de encerrar vale mais do que a manutenção de um piloto no limbo. Encerrar com registro do motivo preserva o aprendizado e libera o custo; deixar rodando sem dono acumula exposição sem produzir valor.
Como o desenho do piloto evita esse problema desde o início?
A providência mais eficaz é nomear o dono da operação antes de o piloto começar, com o aceite dele por escrito e o critério de sucesso definido por ele. Quando quem vai operar define o critério, o piloto testa o que importa para a operação em vez de testar o que impressiona numa apresentação.
A segunda providência é dimensionar o custo de operação em escala já na proposta do piloto, com a estimativa de consumo, de supervisão e de integração definitiva. Essa estimativa transforma a conversa de aprovação, porque o comitê aprova um piloto sabendo o compromisso que ele implica caso funcione.
A terceira providência é medir no piloto os números que a operação precisará: taxa de casos que exigem revisão, tempo médio de supervisão por caso, distribuição de erros por tipo. Pilotos desenhados para provar viabilidade medem acerto médio; pilotos desenhados para escalar medem o custo de operar. A diferença entre os dois desenhos é o que separa um piloto que informa a decisão de um piloto que apenas a antecipa, tema que o artigo sobre por que projetos de IA travam no piloto desenvolve.
Que papel o patrocinador executivo cumpre?
O patrocinador cumpre três funções que ninguém mais consegue exercer. A primeira é a alocação de orçamento entre áreas quando o benefício aparece numa área e o custo em outra. Essa decisão pertence a quem tem visão sobre as duas, e ela trava indefinidamente quando fica entre pares.
A segunda função é a decisão sobre propriedade quando o processo atravessa fronteiras. Definir que determinada área responde por um processo compartilhado é decisão de estrutura, e ela precisa da autoridade correspondente.
A terceira função é a cobrança do encerramento formal. Patrocinadores que acompanham o piloto até a apresentação de resultado e desaparecem depois deixam a transferência sem sustentação. Uma reunião de trinta minutos noventa dias após a transferência, com o dono apresentando os indicadores, garante que a passagem se completou de fato.
Existe uma quarta função menos óbvia e bastante valiosa: autorizar o encerramento sem constrangimento. Quando o patrocinador declara explicitamente que encerrar um piloto que funcionou é uma decisão legítima diante de uma relação desfavorável entre benefício e esforço, ele remove o incentivo de manter agentes vivos apenas para preservar a aparência de sucesso.
Como medir se a transferência funcionou?
O primeiro indicador é a manutenção do resultado noventa dias depois, comparado ao piloto. Alguma queda é esperada com o aumento de volume, e uma queda acentuada indica problema de treinamento ou de supervisão insuficiente.
O segundo indicador é a frequência de ajustes na configuração. Um agente transferido que recebe ajustes regulares tem dono ativo; um que ficou congelado tem dono nominal. Esse indicador é simples de acompanhar e ele é bastante confiável.
O terceiro indicador é a presença da linha de custo no orçamento da área, com o valor correto. Custos que continuam em rateio genérico revelam transferência incompleta, mesmo com documento assinado.
O quarto indicador é qualitativo e vale a conversa: perguntar ao time operacional se eles preferem manter o agente ou voltar ao método anterior. Uma resposta hesitante indica que o agente foi imposto em vez de adotado, e essa condição raramente sobrevive ao primeiro trimestre difícil. A gestão dessa transição é parte do papel que o artigo sobre o gerente de projeto na era dos agentes descreve.
O que muda quando o piloto atravessa várias áreas?
Processos que passam por três ou quatro áreas produzem a situação mais difícil de resolver, porque o benefício se distribui e o esforço de supervisão se concentra em quem opera a etapa central. Esse desequilíbrio produz a resistência clássica: todos querem o resultado e nenhuma área quer a conta.
O arranjo que funciona nomeia um dono único, geralmente a área que executa a etapa de maior volume, e reparte o custo entre as áreas beneficiadas conforme uma proporção acordada. O dono único preserva a clareza de responsabilidade, e a repartição de custo resolve o desequilíbrio de incentivo.
A segunda providência é um foro trimestral curto com as áreas envolvidas, em que o dono apresenta indicadores e as áreas beneficiadas trazem demandas de ajuste. Esse foro evita o padrão em que áreas periféricas reclamam sem canal e o dono decide sozinho sobre necessidades que desconhece.
A terceira providência é a documentação da fronteira: onde termina a responsabilidade do agente e começa a de cada área. Processos que atravessam fronteiras acumulam ambiguidade nas interfaces, e é exatamente ali que os erros aparecem sem responsável identificado.
Conclusão
O piloto que funciona e morre em seguida é uma das formas mais custosas de fracasso em IA, porque ele consome investimento, prova o valor e desperdiça essa prova. Pior do que isso, ele produz um aprendizado organizacional invertido: a próxima proposta de piloto enfrenta a memória de um caso que funcionou e parou no meio do caminho, o que alimenta o ceticismo justamente sobre o mérito da tecnologia em vez do defeito de estrutura que causou o abandono.
O que resolve é anterior ao piloto e ele cabe em quatro definições escritas: o dono da operação nomeado com aceite dele, o critério de sucesso definido por quem vai operar, o custo de operação em escala estimado antes da aprovação e a alocação de orçamento resolvida em caso de benefício e custo em áreas diferentes. Essas quatro definições transformam a natureza do piloto, que passa a testar a operação em vez de testar a tecnologia.
Na Groovia, eu insisto que o critério de sucesso de um piloto seja definido por quem vai operar aquilo depois, e jamais por quem patrocina ou constrói. Essa inversão simples muda tudo, porque quem vai operar mede o que importa na rotina: quantos casos exigem revisão, quanto tempo a supervisão consome, onde o agente falha de forma incômoda. Pilotos avaliados por esse critério chegam ao fim com a informação que a decisão de escalar exige, enquanto pilotos avaliados por acerto médio chegam com um número bonito e nenhuma resposta sobre quem assume a conta na segunda-feira seguinte.