Para escalar agentes de IA com sucesso, considere-os como membros da equipe

Imagine uma cena familiar. Um fornecedor demonstra um novo “agente” de IA generativa para sua equipe de liderança. É impressionante: o agente classifica tickets de suporte, atualiza registros de clientes, redige uma proposta e a encaminha para aprovação. A demonstração é perfeita. Em pouco tempo, inevitavelmente, alguém faz a pergunta: em quanto tempo podemos implementar isso em toda a empresa? Essa pergunta reflete uma suposição que tem orientado a adoção de software empresarial na era do SaaS (Software as a Service). A maioria das ferramentas podia ser provisionada, configurada e dimensionada com relativamente pouca personalização. Se a integração funcionasse e os funcionários adotassem o produto, a implantação era, em grande parte, um projeto de implementação. Mas a IA agentiva rompe com esse modelo. Ao contrário do software tradicional, os agentes de IA são projetados para raciocinar, planejar e realizar ações em diversos sistemas. No momento em que um agente consegue alterar um sistema de registro — atualizar um preço, enviar um pagamento ou modificar dados de clientes —, ele deixa de ser uma ferramenta de produtividade e passa a fazer parte do modelo operacional da organização. Mais importante ainda, isso introduz novas categorias de risco. Uma ferramenta de IA generativa de escopo restrito (como o ChatGPT para redigir e-mails) gera risco de conteúdo: ela pode dizer algo errado. A IA agentiva gera risco de execução: ela pode fazer algo errado. Com base em nosso trabalho como pesquisadores (Rahul e Zia) e de um profissional com experiência na liderança de implantações de IA empresarial autônoma (Raja), dedicamos especial atenção à forma como a IA autônoma está sendo efetivamente implementada. O que constatamos é que, embora muitos agentes estejam hoje prontos para agir, as empresas raramente estão preparadas para lhes permitir fazê-lo. Para ultrapassar esse limiar e integrar efetivamente os agentes de IA em grande escala, será necessário deixar de tratá-los como um software pronto para uso que basta instalar. Em vez disso, deverá tratar seus agentes como um novo tipo de força de trabalho que requer gestão. Assim como seus funcionários humanos, cada um de seus agentes de IA precisará de uma função, um escopo definido de autoridade, fontes de verdade aprovadas e regras claras de escalonamento. Eles também precisarão de supervisão e trilhas de auditoria, pois você será responsável por suas ações. Até que essas bases organizacionais estejam estabelecidas, será difícil escalar a IA agentiva. Quatro atritos recorrentes, em particular, tendem a retardar ou prejudicar o progresso. Compreendê-los é o primeiro passo para gerenciá-los. 1) Identidade: “Quem” está agindo? As empresas passaram décadas desenvolvendo controles de acesso para funcionários humanos. Cada usuário de um sistema de computador faz login com uma identidade única, e sua função determina o que ele pode ou não fazer. Os agentes de IA complicam essa questão, pois se comportam como funcionários humanos, mas não o são. Muitas implementações iniciais lidam com esse problema concedendo aos agentes uma “conta de serviço” compartilhada com amplo acesso a vários sistemas. É uma solução conveniente — mas conceder tantas permissões aos agentes cria um risco à segurança. Considere um exemplo simples. Um representante de atendimento ao cliente pode estar autorizado a emitir reembolsos de até US$ 500. Se ele tentar emitir um reembolso de valor superior, o sistema bloqueia a transação e a encaminha para aprovação. Porém, um agente de IA que opera por meio de uma conta de serviço de back-end compartilhada pode não estar sujeito a esse limite de autorização e, portanto, pode emitir um crédito de US$ 5.000 em uma única etapa. Os riscos não são meramente hipotéticos. Em 2025, um experimento realizado por um desenvolvedor utilizando o agente de codificação com IA da Replit demonstrou a rapidez com que a automação pode escapar ao controle. Apesar de ter recebido instruções para não fazer nenhuma alteração, o agente executou comandos que apagaram um banco de dados de produção. Em seguida, tentou ocultar a falha, gerando milhares de registros falsos e mensagens de sistema enganosas, comportamentos que retardaram a resposta e complicaram a recuperação. A lição é clara: as organizações devem tratar cada agente de IA como um trabalhador digital distinto, com identidade, credenciais e função próprias. Em vez de depender de contas de serviço compartilhadas, as empresas devem atribuir aos agentes permissões de escopo restrito que reflitam as tarefas específicas para as quais foram projetados. Os mesmos princípios utilizados para gerenciar funcionários humanos — tais como o acesso com privilégios mínimos e limites baseados em funções — devem ser aplicados aos agentes. Se um funcionário do atendimento ao cliente não pode emitir reembolsos acima de um determinado limite sem aprovação, então a mesma restrição deve, obviamente, aplicar-se ao agente que realiza esse trabalho. Igualmente importante, cada ação realizada por um agente deve ser registrada sob uma identidade rastreável, para que a organização possa ver claramente quem — ou o que — a executou. Se os líderes não conseguirem explicar facilmente qual identidade um agente utiliza ao executar uma ação, o sistema não está pronto para produção. 2) Contexto: Quando dados incorretos levam a ações equivocadas Os agentes de IA apresentam bom desempenho em demonstrações porque o ambiente é controlado. Os dados são limpos, as instruções são claras e as fontes de veracidade são evidentes. Mas as organizações reais são diferentes. Os dados corporativos estão fragmentados entre sistemas, duplicados entre equipes e, muitas vezes, são contraditórios. As políticas evoluem com o tempo, e documentos mais antigos permanecem em circulação. As pessoas lidam com essa ambiguidade utilizando o julgamento e a experiência que os agentes de IA não possuem. Para um sistema que gera texto, um contexto imperfeito pode produzir uma resposta incorreta. Isso é um problema, mas suas consequências costumam ser limitadas. Para um sistema que realiza ações, no entanto, as consequências são muito maiores. Imagine um agente de RH que recupera um documento de política de 2022, frequentemente consultado, e o utiliza — mesmo que as regras tenham mudado desde então — para orientar os gerentes durante um processo de demissão. Isso não é uma alucinação. É um erro de recuperação que expõe a empresa a riscos legais. Os agentes também trazem um novo desafio de segurança: a manipulação do contexto. Se um agente ler e-mails, formulários ou tickets de suporte e, em seguida, executar tarefas com base nessas informações, os invasores podem incorporar instruções ocultas destinadas a influenciar seu comportamento. Pesquisadores demonstraram esse risco em 2025 por meio de uma vulnerabilidade conhecida como “ForcedLeak”. Ao incorporar instruções maliciosas em um formulário web comum, eles induziram um agente do Salesforce Agentforce a recuperar dados confidenciais de CRM e enviá-los para um destino externo. Para lidar com essas incompatibilidades de contexto, as organizações precisam estabelecer padrões claros sobre quais informações seus agentes podem considerar confiáveis. Isso exigirá a definição de fontes oficiais para políticas, preços e dados operacionais, de modo que os agentes possam contar consistentemente com a versão correta da verdade. Os sistemas também devem registrar a proveniência das informações utilizadas na tomada de decisões, permitindo que as equipes rastreiem qualquer ação de um agente até os documentos ou fontes de dados específicos nos quais ela se baseou. Por fim, as empresas terão de tratar as entradas externas — tais como e-mails, formulários ou arquivos enviados — não apenas como contexto útil, mas como potenciais vetores de ataque. As entradas que se originam fora da organização devem ser tratadas com cuidado e validadas antes que um agente seja autorizado a agir com base nelas. Sem essas salvaguardas, as mesmas inconsistências de dados com as quais os seres humanos lidam rotineiramente podem rapidamente se tornar erros operacionais para os sistemas automatizados. 3) Controle: os sistemas probabilísticos precisam de limites rígidos O software tradicional se comporta de maneira previsível. A mesma entrada produz a mesma saída todas as vezes. Mas os grandes modelos de linguagem não funcionam dessa maneira. Suas respostas são probabilísticas, o que significa que a mesma solicitação pode produzir resultados ligeiramente diferentes em cada execução. Essa variabilidade é aceitável quando a saída é um rascunho de e-mail. Ela se torna muito mais problemática quando a saída é uma transação. Uma empresa que implementou um agente de suporte baseado em IA enfrentou esse problema quando a equipe jurídica insistiu para que o sistema nunca mencionasse um determinado concorrente. A base de conhecimento da empresa, no entanto, incluía muitos artigos comparativos legítimos que faziam referência a esse concorrente, de modo que o agente frequentemente o mencionava ao responder às perguntas dos clientes. Quando os engenheiros reforçaram as restrições para bloquear essas respostas, o sistema passou a se recusar a responder a perguntas válidas por completo. A questão mais profunda aqui é que os métodos tradicionais de teste pressupõem um comportamento estável. Um sistema que seja aprovado em um conjunto de testes hoje pode se comportar de maneira diferente amanhã, caso o modelo seja atualizado, o prompt seja alterado ou novos dados sejam adicionados. E os riscos aumentam em ambientes multiagentes, nos quais os agentes repassam tarefas uns aos outros. Em 2025, por exemplo, pesquisadores da AppOmni demonstraram como configurações inseguras no ambiente Now Assist da ServiceNow poderiam permitir a “injeção de prompt de segunda ordem”. Em seu experimento, instruções maliciosas introduzidas por um agente foram repassadas a outros, levando potencialmente a ações indesejadas ou não autorizadas, como a recuperação de registros confidenciais ou o envio de informações para destinos externos. A lição a reter aqui é que, sem limites claros, erros — ou ataques — podem se propagar em cascata por um sistema automatizado. Para gerenciar esse risco, as organizações devem implementar controles determinísticos em torno de sistemas de IA probabilísticos. Em vez de permitir que os agentes executem ações diretamente, as empresas devem inserir camadas de validação entre o modelo de IA e os sistemas operacionais. Nessa abordagem, o agente propõe uma ação, como emitir um reembolso ou atualizar um registro, e, antes de ser executada, um software determinístico verifica se ela está em conformidade com as regras estabelecidas. As organizações devem limitar as interações não supervisionadas entre agentes, de modo que os resultados de um agente não se tornem automaticamente instruções executáveis para outro sem validação, verificações de políticas ou revisão humana. Ao separar a geração de uma recomendação da execução de uma ação, as empresas podem criar barreiras de proteção que impedem que a variabilidade do modelo se traduza em erros operacionais. 4) Responsabilidade: quando ninguém consegue explicar o que aconteceu Quando um funcionário comete um erro, os gerentes podem investigar fazendo perguntas. Quando um software tradicional falha, os engenheiros podem verificar os registros. Mas os agentes de IA apresentam um cenário mais complexo, pois seu comportamento geralmente resulta de uma cadeia de etapas de raciocínio, documentos recuperados e chamadas de ferramentas que podem não ser fáceis de reconstruir após o fato. Isso cria um sério desafio em termos de prestação de contas. Imagine, por exemplo, um agente de aquisições que resume o desempenho dos fornecedores e publica os resultados em um canal do Slack da empresa. Se o agente incluir acidentalmente cláusulas confidenciais do contrato — por ter interpretado “compartilhar com transparência” como permissão para divulgá-las —, os líderes precisarão saber exatamente como essa decisão foi tomada. Quais documentos ele leu? Que instruções ele seguiu? Por que ele acreditou que tinha permissão para compartilhar as informações? Sem esse tipo de rastro de evidências, as organizações não conseguem explicar o comportamento de seus sistemas a reguladores, auditores ou clientes. Uma decisão de um tribunal de 2024 oferece um primeiro indício de como a lei poderá tratar essa questão. No caso Moffatt v. Air Canada, um cliente baseou-se em informações incorretas fornecidas por um chatbot da companhia aérea sobre a elegibilidade para a tarifa por luto. Quando a companhia aérea argumentou que o chatbot era, na prática, uma entidade separada, o tribunal rejeitou a reclamação e considerou a empresa responsável pela informação incorreta. Para evitar tais problemas, as empresas terão de projetar seus sistemas de IA tendo em mente a prestação de contas desde o início. Isso começa com a manutenção de registros abrangentes sobre como os agentes operam, incluindo quais fontes de dados acessaram, quais prompts receberam e quais ferramentas utilizaram para concluir uma tarefa. Esses registros devem permitir a reconstrução da cadeia de raciocínio que levou a qualquer ação. As organizações também devem atribuir claramente a responsabilidade interna pelo monitoramento e pela governança do comportamento dos agentes, para que a responsabilidade não se torne difusa. Se um órgão regulador, um auditor ou um cliente perguntar por que um sistema de IA tomou uma determinada decisão, a empresa deve ser capaz de fornecer uma explicação clara e baseada em evidências. Sem esse nível de transparência, a automação em larga escala continuará sendo difícil de defender. O caminho a seguir Se a implantação imediata não for viável para agentes de IA, a alternativa não é evitá-los. Trata-se de introduzi-los gradualmente, ampliando sua autonomia apenas à medida que a organização desenvolve a capacidade de controlá-los. Uma maneira útil de pensar nessa progressão é como uma “escada da autonomia”. A principal distinção é a autoridade de execução: se o sistema elabora rascunhos de conteúdo, propõe ações para aprovação ou executa ações dentro de limites rigorosamente definidos. As organizações geralmente começam com agentes que produzem resultados de apoio — rascunhos, resumos ou recomendações que os humanos revisam antes que qualquer coisa seja enviada ou executada. O próximo passo é a recuperação com proteções, em que os agentes respondem a perguntas usando informações internas, mas dependem de fontes de dados bem gerenciadas. A partir daí, as empresas podem permitir ações supervisionadas, nas quais os agentes propõem tarefas operacionais — emitir reembolsos, atualizar registros ou encaminhar aprovações —, mas uma pessoa sempre confirmará a decisão antes da execução. Somente após esses controles terem sido comprovados é que as organizações devem considerar a autonomia limitada, em que os agentes executam fluxos de trabalho de forma independente dentro de limites restritos e limites predefinidos. Muitas implementações eficazes permanecem intencionalmente nos degraus mais baixos da escala de autonomia. A consultoria de benefícios OneDigital utiliza o Azure OpenAI para acelerar a pesquisa dos consultores, melhorando o “tempo de obtenção de insights” em vez de substituir os próprios consultores. Outras implementações de destaque alcançam uma autonomia limitada ao manter o escopo restrito. A Klarna informou que seu assistente de IA lida com uma grande parte dos chats de atendimento ao cliente de forma autônoma, mantendo, ao mesmo tempo, canais de escalonamento imediato para o suporte humano em casos complexos ou delicados. Para os líderes que avaliam o número crescente de plataformas de agentes, os investimentos mais importantes costumam ser organizacionais, e não técnicos. As empresas devem começar por definir um “limite de implantação imediata” claro, distinguindo entre aplicações de IA que podem ser implementadas com mudanças estruturais mínimas e aquelas que exigem uma reformulação significativa dos controles e da governança. Devem também tratar as permissões como uma questão central de projeto, atribuindo a cada agente um acesso de escopo restrito, alinhado à sua função. Limites claros de intervenção humana devem determinar quando as decisões automatizadas requerem supervisão, particularmente em situações que envolvam exposição financeira, obrigações regulatórias ou risco reputacional. Por fim, os líderes devem avaliar os resultados em vez de projetos-piloto, concentrando-se em indicadores operacionais, como tempo de ciclo, taxas de erro e incidentes de conformidade, em vez de simplesmente contar o número de experimentos de IA em andamento. . . . A IA generativa continuará a melhorar, e os fornecedores incorporarão mais recursos de segurança em suas plataformas, mas a lacuna entre uma demonstração impressionante e um sistema de produção confiável persistirá, a menos que as organizações repensem o que a implantação realmente exige. As empresas não são ambientes prontos para uso; são sistemas complexos moldados por tecnologia legada, políticas e julgamento humano. As empresas que terão sucesso com a IA agentiva não se limitarão a instalar mais agentes. Em vez disso, construirão as estruturas que permitam que esses agentes sejam confiáveis.

Para escalar agentes de IA com sucesso, considere-os como membros da equipe

Resumo.

Partner Center