O problema não é só responder: é agir
Um agente pode resumir uma solicitação corretamente e, ainda assim, executar uma ação que a empresa não autorizou. Alterar um cadastro, enviar uma proposta ou encerrar um atendimento tem consequências diferentes de produzir um rascunho. Quando a IA ganha acesso aos sistemas, a pergunta deixa de ser apenas “a resposta está boa?” e passa a incluir “essa ação deveria acontecer?”.
Para gestores, o desafio é transformar essa distinção em regras operacionais. Quem define os limites? Quem analisa uma exceção? Como interromper o processo? Nossa recomendação é responder a essas perguntas antes do piloto, junto com as pessoas que conhecem a rotina. A autonomia deve ser uma decisão explícita sobre cada atividade, não uma configuração genérica aplicada à empresa inteira.
Comece pelo caminho mais simples
A Anthropic distingue fluxos com etapas previamente definidas de agentes que decidem dinamicamente como usar ferramentas. Em seu guia de arquitetura, recomenda aumentar a complexidade apenas quando necessário. Essa distinção ajuda a evitar que uma sequência previsível de validações seja transformada, sem justificativa, em uma decisão aberta do modelo.
Na prática, desenhe primeiro o processo: entrada, consulta, interpretação, proposta de ação e execução. Identifique onde existe ambiguidade que exige interpretação e onde uma regra determinística resolve. Um sistema pode usar IA para compreender uma mensagem e código convencional para validar campos obrigatórios. Não é necessário delegar todas as etapas ao mesmo componente.
Separe três níveis de atuação
Como ponto de partida, propomos três níveis. No primeiro, o agente apenas consulta informações autorizadas e prepara sugestões. No segundo, executa ações delimitadas e reversíveis, como adicionar uma etiqueta interna. No terceiro, prepara ações sensíveis, mas aguarda aprovação explícita antes de executá-las. Essa classificação é uma proposta de desenho, não uma norma universal.
A classificação depende do contexto. Uma etiqueta pode alterar a prioridade de um atendimento e afetar um cliente; portanto, “reversível” não significa “sem risco”. Para cada ação, registre o impacto possível, o alcance dos dados, o responsável e a condição de interrupção. Se a equipe não consegue explicar como detectar e corrigir um erro, mantenha a execução assistida.
Exemplo hipotético: uma solicitação comercial
Imagine uma distribuidora que recebe pedidos de alteração de prazo por e-mail. Este é um exemplo hipotético, não um caso de cliente da NM Solutions. O agente lê a mensagem, identifica o pedido e consulta os dados permitidos. Em seguida, prepara um resumo com a solicitação, os registros consultados e as informações ausentes.
Se o identificador não corresponde a um pedido válido, o fluxo encaminha a ocorrência para conferência, sem adivinhar. Se houver um pedido válido, o agente pode elaborar uma resposta preliminar. A alteração do prazo e o envio ao cliente ficam separados: o responsável vê exatamente o que será alterado e aprova ou rejeita aquela proposta específica.
Depois da aprovação, uma integração executa a mudança e registra o resultado. Se o sistema de pedidos estiver indisponível, o atendimento permanece pendente. O cliente não recebe uma confirmação falsa. Também é necessário reconhecer tentativas repetidas: reenviar uma mensagem ou repetir uma chamada não deve produzir uma segunda alteração ou um segundo envio indevido.
Aprovação precisa ser útil, não simbólica
Uma tela com apenas “aprovar” e “rejeitar” transfere trabalho sem oferecer contexto. Recomendamos apresentar o pedido original, os dados relevantes, a ação proposta e seu efeito esperado. Se a proposta mudar após a revisão, a autorização anterior não deve valer automaticamente para uma ação diferente.
A OWASP relaciona o risco de autonomia excessiva a funcionalidades, permissões e liberdade de ação além do necessário. Entre as medidas de mitigação estão limitar ferramentas e acessos e exigir aprovação humana para ações de alto impacto. Esses controles precisam existir no sistema que executa a ação, não apenas no texto de instruções enviado ao modelo.
Também é importante tratar mensagens, documentos e páginas consultadas como dados, não como autorização para mudar o processo. Um texto recebido de fora pode tentar induzir o agente a realizar outra tarefa. Regras de acesso, validações independentes e supervisão ajudam a reduzir a exposição, mas não eliminam todos os riscos.
Meça qualidade antes de ampliar autonomia
Antes do piloto, registre como a equipe trabalha hoje. Acompanhe tempo total por atendimento, retrabalho, erros de encaminhamento e quantidade de casos que exigem análise especializada. Durante o teste, inclua custo por caso concluído, propostas rejeitadas, falhas de integração e esforço gasto na revisão. Uma resposta rápida que exige muita correção pode não melhorar a operação.
Defina critérios de avanço e de suspensão com os responsáveis pelo processo. Teste situações incompletas, contraditórias e repetidas, além dos exemplos fáceis. Não use uma taxa agregada de acerto para esconder erros graves em uma categoria específica. Expandir o escopo deve depender de evidências e da capacidade da equipe de acompanhar a mudança.
Um primeiro passo com responsabilidade
Escolha um processo com fronteiras claras, um responsável disponível e uma forma verificável de avaliar o resultado. Mantenha um caminho manual para exceções e documente quem pode interromper o agente. O objetivo inicial não é eliminar toda intervenção humana, mas descobrir onde a automação ajuda sem transferir risco silenciosamente.
A NM Solutions ajuda a mapear processos, integrações e limites de atuação para estruturar iniciativas de IA conectadas à operação. Se sua empresa está avaliando esse caminho, uma conversa de diagnóstico pode ajudar a definir o escopo do primeiro piloto.