Escalar agentes de IA antes de redesenhar o trabalho pode multiplicar o problema

A tecnologia já consegue decidir e agir. O desafio é saber em que processo ela deve entrar, com quais limites e sob responsabilidade de quem.

Uma empresa conecta um agente de inteligência artificial ao atendimento ao cliente. A promessa é conhecida: consultar dados, interpretar pedidos, tomar decisões e encaminhar a próxima ação sem depender de uma pessoa em cada etapa.

O piloto funciona. A apresentação para a diretoria funciona melhor ainda.

Então começa a escala.

É nesse momento que aparecem as perguntas que deveriam ter vindo antes: qual sistema contém o dado correto? Que exceções o agente pode resolver? O que ele pode alterar? Quando precisa parar e escalar para um humano? Quem responde se a decisão estiver errada?

O problema não é apenas técnico. É de desenho do trabalho.

Essa é a tese central de um artigo publicado pela McKinsey em 14 de setembro de 2026. A consultoria afirma que muitas empresas estão ampliando o uso de agentes de IA mais rapidamente do que redesenham as atividades que esses sistemas precisam executar. O resultado pode ser uma automação veloz de processos mal definidos, com custo e risco ampliados na mesma velocidade.

Um agente não é só um chatbot mais competente

Sistemas agênticos não se limitam a gerar uma resposta. De acordo com o National Cyber Security Centre (NCSC), órgão britânico de cibersegurança, eles podem acessar fontes de dados, manter contexto, usar ferramentas, tomar decisões e executar ações em direção a um objetivo. Também podem operar sem intervenção humana contínua e, em alguns casos, criar subagentes para tarefas específicas.

Essa autonomia muda a unidade de análise.

Ao avaliar um chatbot, a pergunta costuma ser: a resposta está correta? Ao avaliar um agente, é preciso acrescentar: ele tinha autorização para agir? Usou a fonte certa? Interpretou corretamente a regra? Registrou o que fez? A ação pode ser revertida? A pessoa responsável consegue interrompê-lo?

A diferença parece semântica, mas é operacional. Um erro em uma resposta pode exigir correção. Um erro em um agente pode disparar uma sequência de alterações em sistemas, clientes e registros financeiros antes que alguém perceba.

O padrão perigoso: automatizar o processo quebrado

O primeiro dos cinco padrões de falha listados pela McKinsey é automatizar processos sem redesenhá-los. A lógica é simples: agentes não corrigem, por conta própria, um fluxo confuso. Eles tornam o fluxo confuso mais rápido e mais difícil de acompanhar.

Imagine um processo de aprovação com três planilhas, dois responsáveis e uma regra que só existe na cabeça de uma gerente. Um agente pode ser conectado a esse processo e reduzir o tempo de execução. Mas, se cada planilha tiver uma versão diferente do cliente ou se a exceção não estiver documentada, a velocidade não produz confiabilidade. Produz inconsistência em escala.

É o velho problema da automação de uma rotina que nunca foi entendida. A diferença é que, com agentes, a rotina pode deixar de esperar uma ordem humana a cada passo. O sistema passa a interpretar e agir. A ambiguidade, antes contida por uma pessoa experiente, vira comportamento do software.

Por isso, a pergunta “qual ferramenta vamos comprar?” é prematura. Antes dela vem “como o trabalho acontece de verdade?”.

Dados espalhados viram decisões instáveis

A McKinsey também chama atenção para a preparação dos dados. Não basta a empresa dizer que seus sistemas são integrados. É preciso saber qual informação é autoritativa, como versões conflitantes são resolvidas e quais dados o agente pode consultar.

No exemplo relatado pela consultoria, uma empresa global de tecnologia médica desenvolvia um agente para atendimento e descobriu, durante a construção, divergências de controle de versão e outros problemas nos sistemas de registro. A McKinsey afirma que a correção acrescentou de quatro a cinco semanas de retrabalho, que uma auditoria na fase de planejamento poderia ter identificado.

O caso é uma alegação baseada no trabalho da própria consultoria, não uma medição independente do mercado. Ainda assim, ele ilustra uma questão recorrente em qualquer automação: o sistema só é tão consistente quanto a definição de fonte, regra e responsabilidade por trás dele.

Governança não pode ser apenas reunião e dashboard

Outro ponto relevante é o significado de governança. Um comitê que recebe relatórios mensais, mas não consegue mudar o escopo, redistribuir orçamento ou interromper um fluxo que não entrega valor, está acompanhando o projeto. Não está governando o projeto.

A McKinsey recomenda definir direitos de decisão, caminhos de escalada, critérios de “vai ou não vai” e indicadores que acompanhem adoção e valor realizado, não apenas quantidade de agentes implantados.

O NIST, instituto americano de padrões e tecnologia, chega a uma conclusão compatível por outro caminho. Seu AI Risk Management Framework organiza o gerenciamento de riscos em quatro funções contínuas: governar, mapear, medir e gerenciar. O framework recomenda definir papéis, contexto de uso, custos de erro, escopo, métricas e mecanismos de supervisão humana antes e durante a operação.

Isso ajuda a separar duas coisas que costumam ser misturadas: aprovação humana e responsabilidade humana.

Um botão de “aprovar” não resolve se a pessoa não consegue entender o que o agente fez, nem se tem tempo ou autoridade para contestar. Para ser efetiva, a supervisão precisa estar desenhada no fluxo, com informação suficiente, pontos de parada e alguém autorizado a intervir.

O blueprint é uma etapa de decisão, não um atraso

O nome que a McKinsey dá a essa preparação é blueprint. Segundo o artigo, trata-se de uma fase intensiva de quatro a oito semanas para resolver ambiguidades antes que elas sejam incorporadas à execução. A proposta reúne seis componentes:

o problema que será resolvido;

a solução e o fluxo redesenhado;

o modelo operacional capaz de absorver a mudança;

as bases técnicas e de dados;

o plano de entrega, do protótipo à escala;

a governança com decisões e indicadores claros.

A consultoria afirma, com base em sua experiência, que programas desenvolvidos a partir de uma especificação desse tipo reduziram o tempo total de construção em 30% a 40% e que a adoção após seis meses foi 40% a 60% maior quando a gestão da mudança foi desenhada desde o início. Esses números devem ser lidos como resultados relatados pela McKinsey, não como uma garantia aplicável a qualquer empresa.

O ponto mais sólido do argumento não depende desses percentuais. É a ordem das decisões.

Cinco perguntas antes de escalar

Uma empresa que pretende colocar agentes em produção deveria conseguir responder, de forma objetiva:

Qual problema de negócio será resolvido e como o valor será medido?

Como o trabalho acontece hoje, incluindo exceções e decisões informais?

Qual fonte de dados prevalece quando os sistemas discordam?

O que o agente pode consultar, decidir, executar e alterar?

Em quais situações ele deve parar, pedir revisão ou ser desligado?

Se as respostas ainda dependem de uma conversa longa com alguém que “sabe como funciona”, o processo não está pronto para escala. Talvez esteja pronto para um piloto pequeno, com escopo limitado e risco reversível. Isso é diferente.

O NCSC recomenda começar com tarefas bem delimitadas e de baixo risco, aplicar o princípio do menor privilégio e manter visibilidade sobre o comportamento do agente. Também afirma que a responsabilidade continua humana: alguém precisa ser dono do sistema, aprovar seus acessos, monitorar sua operação, revisar incidentes e ter autoridade para interrompê-lo.

A pergunta certa mudou

Durante a fase de experimentação, a pergunta era: “a IA consegue fazer isso?”.

Para a escala, ela é insuficiente.

A pergunta passa a ser: “a empresa consegue sustentar as consequências de deixar a IA fazer isso?”

Essa mudança tira a discussão do catálogo de ferramentas e leva o assunto para processo, dados, papéis, métricas e decisão. É menos vistoso do que uma demonstração de agente executando várias tarefas. Mas é onde o valor real da automação começa a ser definido.

Agente de IA não é um funcionário digital que dispensa desenho de gestão. É uma nova forma de distribuir julgamento e ação dentro da operação.

Antes de escalar o agente, redesenhe o trabalho.