Robôs já correm mais que Bolt. Por que conectar um cabo importa mais para a automação

Uma automação está pronta para produção quando consegue concluir o trabalho real de forma repetível, lidar com variações e se recuperar de desvios sem transformar cada exceção em intervenção humana. É uma régua menos espetacular do que velocidade, demonstrações impecáveis ou um benchmark isolado — e justamente por isso costuma ser mais útil.

Os Jogos Mundiais de Robôs Humanoides, realizados em Pequim entre 22 e 26 de agosto, colocaram essa diferença em evidência. Em 23 de agosto, a Reuters resumiu o contraste em uma pergunta simples: robôs já conseguem superar recordes humanos de corrida, mas conseguem conectar um cabo, abastecer uma prateleira ou operar num armazém quando o ambiente não coopera perfeitamente?

O evento mistura 30 competições esportivas com 21 provas baseadas em cenários. A página oficial do governo de Pequim descreve tarefas em fábricas, hotéis, casas, varejo, logística, escritórios e situações de emergência. Mais importante: muitas provas são sequenciais. Em vez de demonstrar uma habilidade isolada, o robô precisa percorrer um fluxo completo, preservando contexto e precisão entre uma etapa e outra.

Para quem trabalha com agentes de IA, automação de processos ou implantação de software, essa é uma boa provocação. A demo costuma provar que a tecnologia pode fazer alguma coisa. A operação precisa provar que ela consegue fazer a coisa certa, muitas vezes, em condições imperfeitas, sem exigir um especialista ao lado para salvar o caso.

O trabalho banal é um benchmark mais cruel

Correr cem metros exige potência, equilíbrio e controle. Ainda assim, a trajetória é relativamente clara: existe uma pista, uma direção e um objetivo único. Já conectar um cabo traz uma coleção de pequenas incertezas. O conector pode estar alguns milímetros fora de posição, o objeto pode exigir rotação, a visão pode estar parcialmente obstruída e a força aplicada precisa ser suficiente sem danificar a peça.

Em 20 de agosto, uma página oficial de Pequim detalhou oito provas de destreza manual: montagem com ferramenta elétrica, pesagem de pó, construção com blocos, fixação, abertura de garrafa, desembalagem, manipulação com pinça e conexão de cabos. O ponto declarado era testar movimentos finos com execução autônoma. No dia seguinte, outra publicação descreveu cenários industriais em que os robôs precisavam mover caixas, selecionar peças e realizar montagem em sequência; quando alguns tocavam barreiras, ajustavam a trajetória e continuavam.

É justamente esse tipo de trabalho que separa uma demonstração de uma capacidade operacional. Em software, o equivalente não é perguntar se um agente consegue responder a um e-mail perfeito. É observar o que acontece quando falta um anexo, quando o cliente muda de assunto no meio da conversa, quando dois sistemas discordam, quando uma aprovação expira ou quando o dado que deveria estar no ERP simplesmente não está.

O artigo sobre redesenhar processos antes de automatizar pergunta se o fluxo escolhido merece existir. Depois que a resposta é sim, surge a pergunta deste caso: a automação consegue sobreviver ao fluxo como ele realmente acontece?

Caminho feliz mede habilidade; variação mede operação

Uma prova de conceito normalmente começa pelo caminho feliz por um motivo razoável. Antes de lidar com exceções, é preciso demonstrar que a ideia básica funciona. O erro é tratar esse primeiro sucesso como evidência suficiente para ampliar autonomia.

Ambientes produtivos têm distribuição, não um único caso. Nota fiscal vem com campos diferentes. Cliente responde fora de ordem. Usuário muda uma configuração. Integração retorna erro intermitente. Um documento chega duplicado. Um responsável entra de férias. Uma solicitação parece simples até revelar uma regra fiscal ou comercial específica.

Por isso, a avaliação precisa incluir variação deliberada. Em vez de apenas contar quantas vezes a automação acerta, vale observar em quais tipos de situação ela degrada, quanto trabalho humano reaparece quando isso acontece e se o sistema reconhece que perdeu confiança antes de executar uma ação difícil de reverter.

Essa discussão complementa — sem repetir — o artigo da Munnius sobre métricas de automação usando a Copa como benchmark. Ali, a questão era escolher a régua certa e comparar com um baseline. Aqui, o foco está no conjunto de casos que alimenta essa régua: se o teste só contém situações limpas, uma ótima métrica ainda pode certificar uma automação que não aguenta produção.

Recuperar-se faz parte da tarefa

Existe uma diferença importante entre não errar e saber o que fazer depois do erro. Sistemas reais eventualmente encontram algo que não estava previsto. A pergunta operacional é se um pequeno desvio encerra a execução ou se existe uma rota segura para continuar.

Nos cenários relatados em Pequim, a capacidade de ajustar posição depois de tocar uma barreira é tão interessante quanto acertar o movimento de primeira. Isso aproxima a competição de um problema empresarial conhecido: o valor não está apenas em executar a sequência nominal, mas em detectar que a sequência saiu do esperado.

Um agente de onboarding pode descobrir que o cliente ainda não enviou uma credencial. Uma boa operação não precisa inventar a credencial nem travar silenciosamente. Pode registrar o bloqueio, pedir a informação correta, atualizar a previsão, acionar o responsável e retomar quando a condição estiver satisfeita. Um extrator de documentos pode reconhecer que um campo não possui evidência suficiente e enviar o caso para revisão, em vez de preencher algo plausível.

Essa lógica é central quando agentes de IA saem do piloto para produção. Escalonamento humano não é sinal de fracasso. O fracasso é depender de intervenção informal, não registrada e imprevisível para que a automação pareça autônoma.

Autonomia útil não é ausência de humanos

O evento de Pequim também diferencia execução autônoma de teleoperação. Isso importa porque uma máquina pode parecer extremamente competente quando uma pessoa está corrigindo trajetória, escolhendo a próxima ação ou assumindo o controle nos momentos difíceis. O mesmo acontece com produtos digitais.

Uma automação pode anunciar que “resolve 90% dos casos” e esconder uma equipe revisando entradas, reescrevendo instruções e corrigindo saídas antes que o cliente as veja. Não há problema em manter pessoas no processo. O problema é medir autonomia ignorando o custo humano necessário para sustentá-la.

Uma leitura honesta deveria incluir taxa de conclusão sem intervenção, tempo humano por exceção, frequência de reabertura, capacidade de retomar depois de um bloqueio e impacto dos casos difíceis sobre o ciclo total. Não é preciso transformar isso num painel de vinte indicadores. Poucas medidas ligadas ao trabalho real já mostram se a tecnologia está retirando esforço ou apenas deslocando-o para bastidores menos visíveis.

Fluxos longos expõem o custo de pequenas falhas

Outro avanço interessante dos Jogos é a ênfase em tarefas com lógica de negócio completa. A programação oficial cita cenários como limpeza doméstica, serviço de hotel, produção industrial, emergência, biblioteca, varejo e escritório. Em um hotel, por exemplo, o valor não está em o robô conseguir segurar uma toalha; está em conseguir receber uma demanda, navegar pelo ambiente, transportar itens, executar ações em ordem e encerrar o serviço de forma verificável.

Fluxos longos são difíceis porque pequenas probabilidades de erro se acumulam. Se cada etapa de um processo tiver 95% de chance de funcionar e cinco decisões independentes forem necessárias, a chance de atravessar tudo sem falha já é menor do que o número inicial sugere. Na prática, as dependências nem são totalmente independentes, o que torna a leitura mais complexa.

Esse efeito aparece em automações empresariais. Classificar um e-mail pode ser excelente. Extrair uma data também. Atualizar o CRM talvez funcione quase sempre. Criar uma tarefa, enviar mensagem e confirmar o retorno são outras etapas. Quando o valor depende da cadeia inteira, avaliar apenas cada feature separadamente superestima o resultado percebido pelo usuário.

A demo ainda tem valor — só não deve receber o cargo errado

Há um contraponto importante. Demonstrações espetaculares não são inúteis. Elas empurram limites técnicos, atraem capital, mostram progresso e ajudam equipes a descobrir problemas que antes nem apareciam. Uma corrida de robôs testa controle dinâmico de uma forma que um armazém talvez não teste. Uma prova de destreza revela desafios diferentes de uma tarefa de navegação.

O erro está em confundir capacidade de fronteira com prontidão comercial. O próprio CEO da Unitree, Wang Xingxing, disse à Reuters em 20 de agosto que um “momento ChatGPT” para robôs pode estar a alguns anos de distância e reconheceu que humanoides atuais ainda são menos eficientes que trabalhadores humanos em muitas tarefas. A distância entre a demonstração e a economia da operação continua sendo parte da história.

Isso vale para IA generativa. Um modelo novo pode abrir possibilidades reais sem justificar imediatamente um agente autônomo em cada processo. A pergunta madura é onde a nova capacidade reduz um gargalo suficiente para pagar integração, supervisão, exceções e manutenção.

Antes de colocar a automação em produção, teste o que estraga a demo

O melhor aprendizado dos Jogos não é copiar suas provas. É mudar a seleção de casos. Depois de demonstrar o caminho feliz, coloque no teste aquilo que normalmente seria removido de uma apresentação: dados incompletos, pequenas divergências, ordem diferente, objetos fora de posição, indisponibilidade temporária, resposta inesperada e necessidade de retomar depois de uma interrupção.

Observe também o trabalho invisível. Quem prepara entradas? Quem corrige contexto? Quem precisa ficar disponível para destravar a execução? Quanto tempo a recuperação leva? Que evidência confirma que o resultado foi concluído de verdade? A mesma preocupação aparece na análise sobre confiabilidade e testes de recuperação: procedimento escrito descreve intenção; exercício em condições reais demonstra capacidade.

Quando uma automação passa por esse tipo de teste, a conversa muda. A empresa deixa de perguntar apenas “o que a IA consegue fazer?” e começa a perguntar “qual trabalho ela consegue assumir com responsabilidade?”. É uma pergunta menos vistosa do que bater um recorde. Para produção, costuma ser muito mais valiosa.