Decidir após piloto de IA: escalar, estender ou encerrar

Para decidir após um piloto de IA, compare os resultados com os critérios de sucesso escritos antes do início e escolha um de três desfechos. Escale se todos os critérios de passagem forem atendidos, estenda uma única vez se restar uma lacuna nomeada e encerre se a evidência mostrar um problema estrutural ou um risco que você não consegue limitar. Demonstrações e relatos soltos não contam como evidência. Resultados medidos, erros revisados e um responsável nomeado contam.

Principais pontos

• Escreva a regra de decisão antes de os resultados chegarem e vincule-a ao critério de sucesso definido no início do piloto.
• Escale apenas quando todos os critérios de passagem forem atendidos: resultado, confiabilidade, adoção, controle, custo e responsabilidade.
• Estenda uma única vez, para uma pergunta nomeada, com data de término e um desfecho padrão caso a pergunta continue aberta.
• Encerre quando a causa da falha for estrutural ou o risco não puder ser limitado, e trate o trabalho já feito como um ativo a preservar.
• Evidência ausente também é uma resposta: se o piloto não consegue mostrar resultados, o problema foi a medição, e corrigi-la vem antes de qualquer expansão.

Por que o fim do piloto é o pior momento para decidir?

Um piloto termina com pessoas apegadas a ele. A equipe que o construiu quer que funcione, o patrocinador já falou dele internamente e os usuários que gostaram são as vozes mais altas da sala. Nada disso é evidência, mas tudo isso molda a reunião.

Três erros se repetem. O primeiro é escalar por embalo: a demonstração foi boa, então o agente vai para mais áreas antes de alguém estudar seus erros. O segundo é estender por desconforto: ninguém quer dizer sim ou não, o piloto ganha mais um período com as mesmas metas vagas e chega à mesma incerteza. O terceiro é encerrar por causa de um erro visível, quando o registro revisado mostra que esse erro foi raro, barrado por uma etapa de aprovação e corrigível.

Uma regra de decisão protege contra os três. Ela não elimina o julgamento. Ela o desloca para o momento anterior aos resultados, quando ainda dá para ser honesto sobre o que mudaria sua opinião. Se você ainda não escreveu os critérios, o guia de avaliação de desempenho de agente de IA mostra como definir metas e evidências. Já por que pilotos de IA não saem do papel ajuda a entender o que um piloto, especificamente, deve provar.

Que evidências devem estar na mesa?

Leve um pacote curto de evidências, não uma apresentação. Tudo nele deve poder ser conferido por um colega cético.

• O critério de sucesso, a linha de base usada como comparação e o resultado, todos na mesma unidade.
• Uma amostra de saídas revisadas, incluindo as falhas, cada uma classificada por causa e por gravidade.
• O uso por parte das pessoas para quem o piloto foi desenhado e os motivos apresentados por quem não o usou.
• Limites de aprovação: com que frequência o agente chegou a um limite e se as pessoas permaneceram dentro das regras.
• Um registro de incidentes e mudanças: o que deu errado, a rapidez do tratamento e o que foi alterado depois.
• Custo de operação por unidade de trabalho concluída, não o gasto total durante o piloto.
• O responsável de negócio, pelo nome, e como o agente seria operado se quem o construiu não estivesse disponível.
• Permissões e acesso a dados como estão hoje, comparados com o que foi aprovado no início.

Repare no que não está na lista: depoimentos e capturas de tela de respostas impressionantes. Guarde isso para o comunicado, não para a decisão.

Dois hábitos tornam esse pacote confiável. Avaliações recorrentes sobre um conjunto fixo de tarefas representativas mostram se a qualidade se manteve ou oscilou, algo que uma única semana boa não revela. O custo por unidade de trabalho, ideia central da economia unitária em FinOps, mostra quanto custaria escalar, o que a conta total de um piloto pequeno nunca mostrará.

Que regra separa escalar, estender e encerrar?

Aplique a regra nesta ordem. Primeiro, teste se todos os critérios de passagem para escalar foram atendidos. Se não, verifique os gatilhos de encerramento. Se nenhum se aplica, teste se as condições de extensão são satisfeitas. Cada critério é marcado como atendido, não atendido ou desconhecido, e desconhecido conta como não atendido.

Escale quando todos estes pontos forem verdadeiros:

• Resultado: o critério de sucesso foi atendido na medida combinada, contra a linha de base, em um período longo o bastante para incluir dias comuns e dias difíceis.
• Confiabilidade: as falhas revisadas são em sua maioria leves, nenhuma falha grave está sem solução e o padrão de falhas é estável ou está melhorando.
• Adoção: os usuários previstos recorrem ao agente por escolha própria e você sabe por que os demais não o fazem.
• Controle: o agente permaneceu dentro das permissões e dos limites de aprovação definidos, e todo incidente foi tratado e registrado.
• Custo: o custo de operação por unidade de trabalho é conhecido e razoável diante do valor desse trabalho.
• Responsabilidade: existe um responsável de negócio nomeado e há um modo documentado de operar o agente sem quem o construiu.

Escalar é um novo trabalho, não uma continuação. A próxima área precisa de escopo definido, revisão de permissões e uma visão de capacidade. O texto sobre adicionar um segundo agente de IA na empresa mostra o que reaproveitar e o que separar nessa sequência.

Estenda quando todos estes pontos forem verdadeiros:

• O resultado é promissor, mas uma lacuna específica impede um sim claro, como uma fonte de dados que chegou tarde ou um grupo de usuários que quase não participou.
• A lacuna pode ser fechada com uma mudança nomeada, dentro de uma janela curta e fixa.
• Você consegue dizer de antemão qual resultado transformaria a extensão em escala e qual a transformaria em encerramento.
• Nenhum risco grave está em aberto.

Encerre quando qualquer um destes pontos for verdadeiro:

• O critério de sucesso não foi atingido e a causa é estrutural: o processo varia demais, os dados necessários não podem ser alcançados ou o trabalho é infrequente demais para importar.
• Usuários que tiveram uma chance justa não adotaram o agente, e os motivos não se resolvem com treinamento ou pequenos ajustes.
• O risco não pode ser limitado: o agente precisaria de acesso ou autonomia que você não aprovaria, ou erros graves continuam aparecendo apesar das mudanças.
• O custo de operação por unidade supera o valor do trabalho, sem caminho realista para mudar isso.

Uma ressalva sobre o que é desconhecido. Se o piloto não conseguiu produzir a evidência, não dá para escalar com honestidade. Estenda com uma única pergunta, que é como obter a medição que falta, ou encerre se ninguém souber dizer como.

Como conduzir a reunião de decisão?

A ordem da reunião importa tanto quanto a regra. Uma abertura persuasiva pode ancorar todos antes de os dados serem vistos.

• Releia os critérios exatamente como foram escritos no início do piloto, sem edições.
• Peça ao responsável pelo processo de negócio, não a quem construiu o agente, que resuma o resultado em linguagem simples.
• Revise as falhas em voz alta, começando pelas mais graves.
• Percorra os critérios de passagem um a um e marque cada um como atendido, não atendido ou desconhecido.
• Se algum critério não for atendido, verifique os gatilhos de encerramento. Se nenhum se aplicar, teste as condições de extensão.
• Registre a decisão, o responsável, a data e o que acontece em seguida, em uma página.

Quem responde pelo processo toma a decisão, com a opinião do responsável, do operador e de quem responde pelo risco. Quem construiu o agente apresenta as evidências, mas não decide.

Como estender ou encerrar sem desperdiçar o trabalho?

Uma extensão é um contrato consigo mesmo. Sem termos, ela vira uma forma discreta de evitar a decisão. Registre cinco itens:

• A única pergunta que a extensão existe para responder.
• A data de término, fixa e curta.
• O responsável que relatará a resposta.
• A evidência que vale como resposta, definida antes de a janela abrir.
• O desfecho padrão se a pergunta ainda estiver aberta na data de término. Que seja encerrar, ou escalar um escopo menor, nunca uma segunda extensão.

Permita uma extensão por piloto. Uma segunda costuma indicar que o piloto foi mal desenhado, e o melhor caminho é redesenhá-lo com critérios mais claros.

Encerrar é um resultado legítimo. Um piloto que mostra com clareza que um processo ainda não está pronto cumpriu seu papel, e custou muito menos do que uma implantação fracassada. O que importa é como você o fecha:

• Remova os acessos e as credenciais que o piloto criou.
• Decida o destino dos dados e da memória armazenada: exportar, arquivar ou apagar, conforme o que foi combinado.
• Preserve as partes reutilizáveis: mapas de processo, conjuntos de avaliação, instruções escritas e aprendizados sobre os dados.
• Avise os usuários o que está acabando e por quê, para que o encerramento não pareça uma falha silenciosa.

Para decidir com regularidade o que manter, corrigir ou encerrar depois do piloto, veja a revisão trimestral de IA na empresa.

Um cenário ilustrativo

Este é um cenário ilustrativo, não um caso real. Uma distribuidora regional faz um piloto em que um agente redige respostas a perguntas rotineiras sobre status de pedidos e entregas para a equipe de atendimento. O critério definido no início é o tempo entre a solicitação e a resposta enviada, com cada rascunho revisado por uma pessoa e cada correção registrada.

No fim, o tempo de resposta melhorou de forma clara na linha principal de produtos. As correções dos revisores foram em sua maioria de redação. Um erro grave, uma promessa de entrega errada, foi barrado na etapa de aprovação e gerou uma nova regra. Porém, os dados da segunda linha de produtos chegaram tarde, e o agente tratou pouquíssimas solicitações dessa linha.

A liderança percorre os critérios. Resultado: atendido para a linha principal, desconhecido para a segunda. Confiabilidade: aceitável, com o erro grave resolvido. Adoção: boa. Controle: os limites se mantiveram. Custo: conhecido. Responsabilidade: a líder do atendimento está nomeada. Nenhum gatilho de encerramento se aplica, então consideram uma extensão, que passa no teste porque a lacuna é específica e pode ser fechada.

Eles estendem uma única vez. A pergunta é se o agente tem o mesmo desempenho na segunda linha de produtos. A janela é fixa, a líder do atendimento é dona da resposta e o desfecho padrão, se a pergunta continuar aberta, é escalar apenas a linha principal e retirar a segunda do escopo. Todos saem da sala sabendo o que acontece a seguir.

Como uma abordagem gerenciada trata essa decisão?

A Be Human projeta e opera agentes de IA personalizados. Um primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, seus limites de aprovação e um critério de sucesso observável, e é essa definição que torna possível a decisão no fim do piloto. Durante o piloto, a operação gerenciada pode incluir monitoramento, avaliações recorrentes, revisão de permissões e resposta a incidentes, de modo que o pacote de evidências seja montado ao longo do trabalho e não reconstruído depois. No momento da decisão, o pacote é preparado em relação ao critério escrito, e o próximo passo é combinado por escrito: operação contínua, uma extensão controlada ou um encerramento com acessos removidos e o trabalho documentado. A decisão em si permanece com a sua liderança.

Perguntas frequentes

Quanto tempo um piloto deve durar antes de decidir? O suficiente para incluir períodos comuns e difíceis do processo, como um fechamento de mês ou um pico sazonal, se isso importar para o trabalho. Defina a duração antes, com base no processo e não na conveniência. Não estenda apenas para esperar um resultado com melhor aparência.

Quem deve tomar a decisão? O líder de negócio responsável pelo processo, com a opinião do dono do processo, do operador e de quem responde pelo risco. Quem construiu o agente ou o fornecedor apresenta evidências e recomendações, mas não decide. Ter um único decisor nomeado também evita que o piloto fique circulando entre comitês.

E se os resultados são bons, mas a equipe não usa o agente? Trate a adoção como um critério de passagem, não como detalhe. Descubra o motivo: treinamento pouco claro, encaixe ruim na rotina ou baixa confiança nas respostas. Se a causa for específica e corrigível, estenda uma única vez com essa causa como pergunta. Se as pessoas que experimentaram escolheram parar, isso é um gatilho de encerramento.

Podemos escalar parte do piloto e encerrar o restante? Sim, se todos os critérios forem atendidos para uma parte claramente definida, como uma equipe ou uma linha de produtos. Escreva o escopo menor e trate o restante como encerrado, ou como uma questão separada com critérios próprios. Evite escalar um todo vago quando a evidência sustenta apenas uma parte.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.