Resposta rápida: O piloto de inteligência artificial morre entre o teste e a operação porque o teste acontece em condições artificiais: voluntários motivados, dados escolhidos a dedo e acompanhamento diário de alguém com autoridade. Na rotina, essas três condições desaparecem ao mesmo tempo. A travessia se sustenta com quatro elementos concretos: um dono de processo com meta no próprio bônus, o passo de inteligência artificial desenhado dentro do fluxo padrão em vez de correndo ao lado dele, um caminho de exceção claro para os casos em que a máquina hesita, e a data formal de desligamento do jeito antigo. Sem esses quatro, o resultado do piloto vira slide de apresentação e a empresa recomeça a discussão no trimestre seguinte com uma ferramenta diferente.
Eu conduzi uma conversa em maio com o COO de uma indústria de médio porte que estava genuinamente orgulhoso, e com razão. O piloto de leitura automática de notas fiscais tinha rodado por seis semanas no time de contas a pagar e cortado o tempo de conferência de doze minutos por documento para pouco mais de dois. A precisão ficou acima de noventa e cinco por cento nos lançamentos, o time gostou, o CFO viu o número e aprovou a expansão para o restante da operação fiscal. Reunião encerrada com aperto de mão e cronograma.
Eu voltei àquela empresa em julho por outro motivo e perguntei como estava o processo novo. A resposta veio com um encolher de ombros. A ferramenta continuava contratada, o acesso continuava liberado, e a equipe continuava conferindo nota fiscal do jeito antigo, doze minutos por documento, porque em algum ponto entre a aprovação e a rotina a coisa deixou de acontecer. Ninguém tomou a decisão de abandonar. O processo simplesmente escorreu pelo vão entre o piloto que terminou e a operação que jamais começou.
Essa é a morte mais frustrante de um programa de inteligência artificial, e é bem mais comum do que a falha técnica. A tecnologia funcionou, o time aprovou, o número apareceu, e mesmo assim a empresa voltou ao ponto de partida. Eu passei a chamar esse intervalo de vale da escala, e a maior parte do meu trabalho hoje acontece dentro dele.
Por que o sucesso do piloto engana a liderança
Um piloto bem conduzido é uma pergunta respondida: essa tecnologia consegue fazer esse trabalho nessa casa? Quando a resposta vem positiva, a liderança comete um erro de interpretação compreensível e caro. Ela lê o resultado como prova de que o processo novo já existe, quando na verdade o resultado prova apenas que ele é possível.
A diferença entre possível e existente é onde mora o orçamento inteiro da travessia. Um piloto entrega evidência. Uma operação entrega resultado recorrente, e resultado recorrente exige uma infraestrutura de rotina que o piloto dispensou de propósito, porque instalá-la antes de saber se a coisa funciona seria desperdício. O problema aparece quando ninguém percebe que essa infraestrutura ficou de fora e a empresa trata a expansão como uma questão de liberar mais licenças.
Eu vi o mesmo padrão em contextos completamente diferentes, de um time comercial de vinte pessoas a uma operação de atendimento com quatrocentas. O piloto termina, a liderança celebra, o cronograma de expansão é aprovado, e a expansão acontece por meio de e-mails informando que a ferramenta está disponível para todos. Disponibilidade jamais produziu adoção. Eu tratei da raiz desse mal-entendido em por que projetos de IA travam no piloto, e a travessia é o outro lado da mesma moeda.
As três condições artificiais do piloto: gente escolhida, atenção da liderança e volume protegido.
As três condições artificiais que todo piloto usa
Todo piloto decente roda dentro de uma estufa, e a estufa é construída de propósito para que a pergunta técnica receba resposta limpa. Vale reconhecer cada parede dessa estufa, porque cada uma delas desaparece na hora da escala.
A primeira condição é a seleção das pessoas. O piloto escolhe voluntários, e voluntário tem duas características que a média da casa carece: interesse pela ferramenta e disposição para tolerar imperfeição. Quando o processo vai para a operação inteira, ele chega às mãos de gente que jamais pediu para participar, que tem meta apertada e que aprendeu ao longo da carreira a desconfiar de sistema novo. A mesma ferramenta que encantou dez entusiastas irrita cem profissionais ocupados.
A segunda condição é a qualidade do material de entrada. Pilotos costumam rodar com uma amostra tratada, com documentos legíveis, cadastros arrumados e casos típicos. A operação real traz o documento amassado, o cadastro com três grafias do mesmo cliente e o caso raro que aparece toda semana em alguma unidade. A precisão de noventa e cinco por cento medida na amostra vira setenta e poucos no mundo real, e a queda destrói a confiança em duas semanas. Eu escrevi sobre a ordem correta desse trabalho em arrumar dados antes da IA.
A terceira condição é o acompanhamento. Durante o piloto existe alguém olhando o painel toda manhã, corrigindo desvio na hora e respondendo dúvida em minutos. Essa pessoa geralmente é o próprio patrocinador do projeto, com autoridade para destravar qualquer coisa. Na operação, o acompanhamento diário desaparece, a dúvida fica sem resposta por três dias, e o profissional volta ao método antigo porque ele tem prazo para cumprir hoje.
O que muda quando o processo precisa rodar todo dia
Rotina impõe exigências que teste dispensa. A primeira é previsibilidade: um processo operacional precisa entregar o mesmo resultado na terça de carnaval, no fechamento do mês e no dia em que o sistema principal fica lento. A segunda é substituibilidade: o processo precisa funcionar quando a pessoa que mais entende dele estiver de férias. A terceira é rastreabilidade, porque alguém vai perguntar em auditoria por que aquele lançamento saiu daquele jeito.
Essas três exigências transformam a natureza do trabalho. O piloto pede curiosidade e tolerância. A operação pede documentação, papel definido, alçada de decisão e registro. Eu costumo dizer aos executivos que o piloto é um experimento e a operação é um compromisso, e compromisso demanda burocracia mínima, do tipo que sustenta em vez de travar. Tratei desse equilíbrio em governança de IA para quem detesta burocracia.
Quem é o dono do processo depois que o piloto termina?
Essa é a pergunta que revela em trinta segundos se a travessia vai acontecer. Eu faço ela em toda reunião de encerramento de piloto, e a resposta mais frequente vem em forma de silêncio educado, seguida de alguma menção ao comitê ou ao time de projetos.
Comitê acompanha, projeto termina, processo precisa de dono. Dono de processo é uma pessoa específica, com nome, que responde pelo resultado daquele fluxo dentro da estrutura de linha da empresa, e que tem no próprio painel de metas o indicador que a inteligência artificial deveria melhorar. Quando o gestor de contas a pagar carrega a meta de custo por documento processado, ele defende o processo novo com unhas e dentes, porque o bônus dele passa por ali. Quando a meta continua pendurada no gerente de projetos que vai para o próximo projeto, o processo fica órfão no primeiro obstáculo.
A mudança prática é simples e política. A liderança precisa mover o indicador de dentro do projeto para dentro da linha, e isso significa renegociar meta de alguém no meio do ano. Executivos evitam essa conversa por causa do atrito, e o atrito evitado hoje custa o programa inteiro em seis meses. Eu detalhei a distribuição dessas responsabilidades em quem decide a adoção de IA na empresa.
O jeito antigo precisa de data de desligamento
Enquanto o método anterior continua disponível, ele continua vencendo. Isso tem uma explicação prática que dispensa qualquer teoria sobre resistência à mudança: sob pressão de prazo, todo profissional escolhe o caminho que ele domina, e o caminho dominado é o antigo. A convivência entre dois métodos parece prudente e funciona como sabotagem lenta.
A saída é definir data de desligamento do fluxo anterior, com anúncio antecipado e com um período de convivência curto e nomeado. Trinta dias de sobreposição bastam na maioria dos casos. Depois da data, o método antigo deixa de ser opção padrão e passa a ser exceção documentada, que exige um clique a mais e uma justificativa de uma linha. Essa assimetria de esforço muda o comportamento com muito mais eficácia do que qualquer campanha interna de comunicação.
Existe um cuidado obrigatório aqui. A data de desligamento só funciona quando o caminho novo já tem caminho de exceção, suporte respondendo rápido e uma precisão medida no material real da casa. Cortar a saída antiga sem essa preparação produz revolta legítima e destrói a credibilidade da liderança para o próximo ciclo.
Framework de como escalar piloto de IA: Por que o sucesso do piloto engana a liderança.
Onde o passo de inteligência artificial entra no fluxo padrão
O piloto costuma rodar ao lado do processo, como uma segunda tela que a pessoa consulta. A operação exige o oposto: o passo precisa estar dentro do fluxo padrão, no sistema em que a pessoa já trabalha, no momento exato em que a decisão acontece. Toda vez que a rotina obriga alguém a sair de uma tela, abrir outra, copiar informação e voltar, a empresa criou um imposto de atenção que a operação cobra em abandono.
Desenhar essa integração costuma ser o item mais caro da travessia, e é justamente ele que raramente aparece no orçamento do piloto. Envolve trabalho de sistemas, ajuste de campos, tratamento de erro e testes com o time de tecnologia. Eu descrevi as escolhas técnicas dessa etapa em como integrar IA aos sistemas da empresa.
Existe uma versão intermediária que funciona bem quando a integração completa demora. Em vez de exigir que a pessoa consulte a ferramenta, a empresa entrega o resultado da inteligência artificial já dentro do item de trabalho, como um campo pré-preenchido que a pessoa confirma ou corrige. O esforço da operação cai para um gesto de revisão, e revisão é uma tarefa que profissionais aceitam com facilidade, porque preserva o senso de julgamento próprio.
O caminho de exceção sustenta a confiança do time
Toda ferramenta hesita em alguma fração dos casos, e essa fração é justamente onde a confiança se ganha ou se perde. Se o profissional descobre por conta própria que a máquina errou num caso difícil, ele generaliza o erro para o sistema inteiro e conta a história para a área toda no café. Se a própria ferramenta sinaliza a hesitação e devolve o caso para a pessoa com um aviso claro, o mesmo evento vira prova de que o desenho é honesto.
Na prática, isso significa definir um limiar de confiança e uma rota. Abaixo do limiar, o caso vai para revisão humana com o motivo da dúvida explícito. Acima, segue direto com registro. A rota precisa ter destinatário nomeado, prazo de resposta e visibilidade, porque exceção que cai numa caixa de entrada sem dono volta a ser trabalho invisível.
Eu recomendo medir o volume dessas exceções semanalmente durante os primeiros três meses. A curva de exceções conta a história real da maturidade do processo: quando ela cai de forma consistente, o time e o modelo estão aprendendo juntos. Quando ela fica parada num patamar alto, existe um tipo de caso que o desenho ignorou, e vale reabrir o desenho em vez de pressionar as pessoas.
Como sair de uma equipe para a área inteira
Escalar por decreto geral costuma falhar. O caminho que eu vi funcionar com consistência é o de ondas curtas, com cada onda ganhando uma equipe nova e mantendo as anteriores em acompanhamento. Três ondas de duas semanas cobrem uma área média com folga e produzem algo que o decreto jamais produz: uma fila de referências internas.
Cada onda precisa de duas figuras. A primeira é o par de confiança, alguém da equipe anterior que já usa o processo e senta ao lado de quem está entrando. Essa pessoa resolve em cinco minutos a dúvida que o suporte central levaria dois dias para responder, e ela fala a língua da operação. A segunda é o gestor direto da equipe, que precisa aparecer na abertura da onda e dizer com as próprias palavras que aquele é o jeito de trabalhar da área agora. Silêncio do gestor direto vale como permissão para ignorar.
A camada gerencial merece preparo específico antes de cada onda, porque ela traduz a mudança para a realidade de cada equipe e carrega os próprios receios enquanto traduz. Eu escrevi sobre essa camada em a adoção de IA e o gerente do meio.
O que fazer com os números que o piloto produziu
O piloto entrega um número de vitrine, do tipo redução de oitenta por cento no tempo de tarefa, medido em condições de estufa. Levar esse número para a operação como promessa é armadilha, porque a realidade vai entregar menos e a diferença será lida como fracasso.
Eu prefiro converter o resultado do piloto em três números diferentes. O primeiro é a linha de base real do processo antigo, medida na operação inteira e por um período que inclua fechamento de mês e pico de demanda. O segundo é a meta operacional, sempre mais modesta que o resultado do piloto, com uma margem explícita para as imperfeições do mundo real. O terceiro é o custo total por unidade de trabalho, somando licença, infraestrutura, revisão humana e suporte, porque é esse número que o financeiro vai cobrar. Eu tratei da armadilha de contar apenas a parte boa em o que ninguém conta sobre o ROI da IA.
O orçamento da travessia é diferente do orçamento do piloto
Essa é a conversa que trava mais programas do que qualquer objeção técnica. O piloto foi barato porque usou licenças pontuais, gente emprestada e nenhuma integração. A travessia custa integração de sistemas, tempo de time de tecnologia, treinamento em ondas, documentação de processo e uma reserva para ajuste de dados. Em algumas casas, a travessia custa três vezes o piloto e entrega o retorno que o piloto apenas prometeu.
Quando o orçamento da travessia fica de fora da aprovação inicial, ele precisa ser pedido no meio do exercício, e pedido de verba fora do ciclo enfrenta a pior resistência possível. Eu recomendo aprovar as duas etapas juntas desde o começo, com o desembolso da segunda condicionado ao resultado da primeira. O financeiro entende essa estrutura com facilidade, porque ela se parece com qualquer decisão de investimento por estágio. Vale usar os argumentos que eu reuni em como defender IA no orçamento de 2027.
Matriz de decisão de como escalar piloto de IA: Quem é o dono do processo depois que o piloto.
Por que o treinamento em massa falha na escala
A empresa que atravessa a escala costuma marcar um treinamento geral de duas horas para toda a área, com apresentação da ferramenta e demonstração das funcionalidades. O formato tem custo baixo por pessoa e eficácia próxima de zero, porque adulto ocupado aprende ferramenta nova fazendo o próprio trabalho com ela, e jamais assistindo alguém fazer.
O desenho que funciona troca a aula pela sessão de trabalho acompanhado. A pessoa traz três casos reais da própria fila e processa eles com o processo novo, ao lado de alguém que já domina. Uma hora desse formato produz mais adoção do que um dia de apresentação, porque termina com a experiência de sucesso próprio em material verdadeiro. Eu escrevi sobre o erro de treinar sem mexer no processo em treinar em IA sem mudar o processo.
Sem dono, orçamento, integração e rito mensal, o piloto vira apresentação de slide.
Os quatro sinais de que a travessia está falhando
Existe uma janela de uns sessenta dias em que a recuperação é barata, e ela costuma passar em branco porque a liderança acompanha o cronograma de implantação em vez do comportamento real da operação. Quatro sinais avisam com antecedência.
O primeiro é a taxa de uso caindo depois da terceira semana de cada onda, o padrão clássico de entusiasmo inicial seguido de retorno ao hábito. O segundo é o volume de exceções parado num patamar alto, sinal de que existe uma família de casos fora do desenho. O terceiro é a permanência do fluxo antigo rodando em paralelo depois da data de desligamento, quase sempre com a justificativa de que aquele cliente ou aquela unidade é diferente. O quarto é o mais silencioso e o mais grave: a ausência de qualquer conversa sobre o processo novo nas reuniões de rotina da área. Processo que sustenta resultado aparece na pauta semanal. Processo órfão desaparece do vocabulário.
O rito mensal que mantém o processo vivo
A travessia termina quando o processo novo deixa de precisar de projeto para existir, e o marcador dessa passagem é um rito de rotina. Eu instalo uma revisão mensal de trinta minutos na reunião que a área já faz, com quatro pontos fixos: o indicador do processo comparado à linha de base, o volume e a natureza das exceções, uma decisão sobre algum ajuste, e a próxima melhoria a testar.
Trinta minutos por mês parecem pouco para um assunto que consumiu meses de trabalho, e é exatamente essa a intenção. O objetivo da travessia é transformar um programa em rotina, e rotina saudável ocupa pouco espaço na agenda. Eu descrevi a mecânica dessa cadência em rotina de melhoria contínua com IA.
O piloto é uma pergunta, a operação é um compromisso
Uma pesquisa da McKinsey aponta ganhos de produtividade entre quinze e quarenta por cento em processos redesenhados com inteligência artificial, e a palavra que sustenta essa faixa é redesenhados. O ganho vive no processo novo em operação, jamais na ferramenta contratada, e o intervalo entre uma coisa e outra é precisamente o vale que eu descrevi aqui.
Eu encerro as reuniões de encerramento de piloto com a mesma sequência de perguntas, e sugiro que qualquer executivo faça o mesmo antes de assinar a expansão. Quem é a pessoa com nome que responde pelo indicador desse processo daqui a seis meses? Qual a data em que o jeito antigo deixa de ser padrão? Em que tela do sistema o passo novo acontece? Para onde vai o caso em que a máquina hesita? Quanto custa a travessia, separada do custo do piloto?
Cinco respostas concretas valem mais do que qualquer slide com o resultado do teste. Onde elas existem, a empresa colhe o ganho no ano corrente. Onde elas faltam, a casa terá um piloto bem-sucedido a mais na coleção, um trimestre a menos de vantagem, e a mesma conversa recomeçando com uma ferramenta diferente e um entusiasmo ligeiramente menor.
Leia também
O contexto brasileiro: LGPD, ANPD e o PL 2338
No Brasil, qualquer decisão sobre uso de IA na operação passa pela LGPD (Lei 13.709/2018). A ANPD pode aplicar sanção de até 2% do faturamento da empresa no Brasil, limitada a R$ 50 milhões por infração, e o PL 2338/2023 avança para criar o marco legal da IA, com obrigações de transparência, avaliação de risco e supervisão humana em sistemas de alto impacto.
Na prática, isso significa três coisas para a liderança: registrar quais ferramentas e agentes de IA tratam dados pessoais, definir quem responde por cada decisão automatizada e manter trilha de auditoria do que foi gerado por máquina.
A Groovia acompanha essa jornada com um time de 6 humanos e 78 agentes próprios, e já conduziu 100 sócios pela Curva de Maturidade em IA, das 5 etapas que levam uma empresa de AI First a AI Native.