Em 2025, um artigo da MIT Sloan Management Review levantou um problema que a maioria das empresas não quer ouvir: colocar IA para fazer uma tarefa isolada — resumir um documento, responder um e-mail, gerar um trecho de código — raramente move o resultado da empresa. O ganho de verdade aparece quando alguém para, olha o processo inteiro e pergunta por que aquela tarefa existe daquele jeito. Uma empresa de serviços financeiros citada no artigo refez, sob essa lógica, o processo de atendimento a pedidos de clientes e chegou a 50% menos esforço, 40% menos custo e quase 20% menos rotatividade na equipe — números que nenhuma automação pontual entrega sozinha.
A pesquisa State of AI 2025, da McKinsey, mediu a mesma distância em escala: entre quase 2 mil empresas ouvidas, apenas 5,5% relataram retorno financeiro real dos investimentos em IA. O que separa esse grupo pequeno do resto não é o modelo de IA usado, nem o orçamento — é que as empresas de melhor desempenho têm quase três vezes mais chance de ter redesenhado o fluxo de trabalho por completo, em vez de encaixar a IA numa etapa do processo antigo.
Para empresas brasileiras e latino-americanas, que em boa parte ainda testam IA em tarefas pontuais — um chatbot de atendimento aqui, um resumo de contrato ali —, esse dado funciona como alerta específico. Esse padrão se repete área por área: o atendimento testa uma ferramenta, o financeiro testa outra, cada uma resolve uma tarefa isolada dentro do próprio departamento. Cada área mostra uma vitória pequena numa reunião interna, mas ninguém consegue apontar, no fim do trimestre, quanto disso mudou o número que a diretoria acompanha.
Por que a tarefa isolada rende tão pouco
A tentação de automatizar tarefa por tarefa é compreensível: é rápido de testar, não exige mexer em nada além daquele passo e dá uma vitória visível em poucas semanas. O problema é que uma tarefa isolada normalmente existe dentro de um processo desenhado para outra realidade — um fluxo pensado quando cada etapa dependia de uma pessoa, com filas, aprovações redundantes e retrabalho embutido como parte do "jeito que sempre foi feito".
Colocar IA numa etapa desse processo faz a etapa ficar mais rápida. Não faz o processo ficar melhor. Se a etapa seguinte ainda depende de alguém revisar tudo de novo porque não confia na anterior, ou se a tarefa automatizada nunca deveria ter existido como um passo separado, a empresa só passou a produzir mais rápido o mesmo retrabalho de antes.
Um exemplo comum ajuda a enxergar isso na prática. Muitas empresas colocam um agente de IA para resumir e-mails ou chamados de suporte, mas mantêm intacto o passo seguinte: uma pessoa lê o resumo, desconfia dele e vai conferir o texto original mesmo assim. O resumo ficou mais rápido de gerar; a decisão continua levando o mesmo tempo de antes, porque a etapa que realmente travava o processo — a desconfiança de quem decide — nunca foi tratada.
A McKinsey chama esse padrão de incrementalismo: a IA some dentro do processo existente e entrega ganho marginal, quando o processo em si é que precisava mudar. É a diferença entre colocar um motor mais forte num carro com o freio de mão puxado e simplesmente soltar o freio.
Quando automatizar a tarefa piora o resultado
Um experimento de campo conduzido pela Harvard Business School com a consultoria Boston Consulting Group tornou esse risco concreto. Pesquisadores dividiram 758 consultores em grupos com e sem acesso a um modelo de IA e mediram o desempenho em tarefas reais do dia a dia da consultoria.
Nas tarefas dentro do que os pesquisadores chamaram de fronteira da capacidade da IA — aquilo que ela consegue fazer bem —, quem usou IA completou 12,2% mais tarefas, 25,1% mais rápido, com qualidade até 40% superior. Fora dessa fronteira, numa tarefa desenhada para estar além da capacidade real do modelo, o grupo com IA teve desempenho pior: confiando na resposta errada, chegou à solução certa 19 pontos percentuais menos vezes do que quem trabalhou sem IA.
O ponto central do estudo não é que a IA seja boa ou ruim. É que a fronteira entre o que ela resolve bem e o que ela resolve mal é irregular, e só aparece quando alguém mapeia a tarefa dentro do processo — não quando a tarefa é automatizada isoladamente, na confiança de que "a IA resolve".
Para uma empresa, a lição prática não é abandonar a IA nas tarefas fora dessa fronteira. É não confiar cegamente nela ali, e usar a própria tarefa como termômetro: se o resultado piora com IA, aquela etapa ainda exige alguém experiente por perto — e essa informação só aparece quando o processo inteiro é olhado, não quando a ferramenta é aprovada isoladamente "para ajudar todo mundo".
O que precisa existir na prática
Redesenhar um processo com IA, na prática, significa colocar alguns mecanismos no lugar antes de qualquer etapa virar automática.
Mapear o processo antes de automatizar qualquer etapa dele. Isso significa listar cada passo, quem faz, por que existe e o que aconteceria se ele sumisse — antes de perguntar onde a IA entra. Boa parte das etapas "automatizáveis" nem deveria existir como passo separado.
Agentes trabalhando em etapas coordenadas, não isolados. Um agente que resume, outro que consulta o histórico, outro que prepara a resposta — cada um com escopo definido e passando o trabalho adiante, em vez de uma pessoa colando à mão o resultado de várias ferramentas soltas.
Aprovação humana conforme o risco de cada etapa, não em toda etapa. Uma tarefa dentro da parte segura do processo segue direto; uma decisão sensível para na conversa e pede confirmação antes de avançar.
Reutilização do que funciona, com controle de quem pode usar o quê. Quando uma pessoa da equipe encontra o roteiro certo para um processo, esse roteiro fica disponível para o time todo, com alcance definido por papel e permissão — não solto para qualquer um.
É assim que a Skyller foi desenhada: agentes atuando em etapas coordenadas, aprovação conforme o risco, e mais de 170 modelos de processos prontos para começar o redesenho sem partir do zero.
O ganho que aparece no resultado, não só na tarefa
O motivo pelo qual esse redesenho custa mais caro de decidir do que ligar mais uma ferramenta é o mesmo motivo pelo qual ele paga: mexe em como o trabalho é dividido entre pessoas e IA, não em qual botão apertar.
Quando o processo é redesenhado, o ganho aparece em indicadores que a diretoria já acompanha — tempo de ciclo, custo por atendimento, rotatividade da equipe — e não apenas em quantas pessoas usaram um chatbot no mês. É essa diferença que separa, segundo a McKinsey, os 5,5% de empresas com retorno financeiro real das demais: elas medem o processo, não a ferramenta.
Há também um efeito interno menos falado: quando o redesenho é feito com a equipe, e não decidido por fora dela, a IA entra como algo que tira trabalho repetitivo do caminho — não como ameaça a um emprego. Isso ajuda a explicar por que o caso citado pela MIT Sloan também reduziu rotatividade, não só custo: a equipe deixa de repetir a parte do trabalho que ninguém gostava de fazer, e passa a decidir a parte que realmente exigia alguém pensando.
Perguntas para levar à próxima reunião
Antes de aprovar mais uma automação pontual, vale levar estas perguntas para quem lidera a área e para a equipe de TI:
- Por que esta etapa existe do jeito que existe? Se a resposta for "sempre foi assim", ela é candidata a desaparecer, não a ser automatizada.
- O que acontece na etapa seguinte se esta ficar mais rápida? Se a próxima etapa ainda vai revisar tudo de novo, o ganho de velocidade não chega ao processo inteiro.
- Esta tarefa está dentro ou fora do que a IA realmente resolve bem hoje? Testar antes de confiar evita o resultado pior que o estudo da Harvard/BCG mediu fora da fronteira.
- Quem no time já resolveu um problema parecido, e esse conhecimento está disponível para os outros? Se a resposta for "só na cabeça de uma pessoa", o redesenho ainda não aconteceu.
