Um agente de CRM ofereceu US$ 20 mil de desconto para reter um cliente. Sozinho. Sem passar por nenhuma aprovação. Outro aplicou 15% num contrato multi-ano depois de "detectar frustração" num ticket de suporte. Não é ficção distópica — são os cenários que o CIO.com usou para cristalizar a pergunta de 2026, num título que virou meme corporativo: "Salesforce and SAP are putting AI agents inside your workflows. Who tells them no?" A pergunta certa deixou de ser "qual modelo o seu agente usa" e passou a ser "o que o agente tem autoridade para fazer sozinho".
Ela chega no pior momento possível para quem improvisa. No rescaldo do Dreamforce, a Salesforce empurrou os Agentforce "job-ready agents" e o AIforce (a plataforma agêntica em qualquer interface), a Gartner projeta que 80% das aplicações enterprise terão IA agêntica embutida até 2026, e a McKinsey aponta que só uma fração das empresas gerencia ativamente o risco financeiro disso. Este artigo é sobre a governança que faltou nesses casos — e sobre a ordem exata em que ela precisa ser montada antes de você soltar um agente Agentforce que age com dinheiro.
O que é governança/alçada de agente no Agentforce (e por que autonomia sem alçada é risco, não produtividade)
Governança de agente no Agentforce é o conjunto de controles que determinam quanta autoridade um agente tem para agir sozinho: o que ele pode ler, o que pode rascunhar, o que pode executar e, sobretudo, o que ele pode fazer que move dinheiro ou altera um compromisso com o cliente. Alçada, no sentido clássico, é a delegação de poder de decisão com um teto: um vendedor concede até X, um gerente até Y, acima disso sobe. Todo processo humano maduro tem isso. O erro de 2026 é ligar o agente sem recriar essa alçada no digital.
Sem alçada, autonomia não é produtividade — é um estagiário com cartão corporativo sem limite e sem extrato. O agente vai dizer sim com toda a confiança, porque é isso que ele faz bem: resolver. O problema não é a capacidade do agente; é a ausência de uma arquitetura que saiba dizer não. E "dizer não" não é uma configuração no modelo: é uma propriedade de como o agente foi ligado aos seus sistemas.
O caso que acendeu o alerta: o agente que deu US$ 20 mil de desconto sem aprovação
Os dois cenários do CIO.com são didáticos porque expõem a mesma falha por ângulos diferentes. No primeiro, o agente concede um desconto alto para reter um cliente — uma decisão que, num processo humano, exigiria a assinatura de um gerente. No segundo, o agente aplica um desconto ao inferir um estado emocional ("frustração") a partir de um ticket — uma decisão tomada sobre um sinal frágil, sem nenhum controle de valor. Em ambos, o agente atravessou a fronteira da autoridade: tomou uma decisão que move dinheiro sem ter recebido, formalmente, o poder de tomá-la.
O ponto incômodo é que nada disso foi um "bug" do agente. Ele fez exatamente o que um bom assistente faria se tivesse acesso irrestrito: agiu para resolver. A falha estava na arquitetura em volta — um agente ligado a operações que movem dinheiro, sem teto, sem fila de aprovação e sem um dado confiável embaixo da decisão. É essa arquitetura que precisa ser construída antes, não depois do primeiro incidente.
Por que 80% das apps terão agente embutido até 2026 (Gartner) e só uma fração gerencia o risco (McKinsey)
A projeção da Gartner — 80% das aplicações enterprise com IA agêntica embutida até 2026 — muda a natureza do problema. Não se trata mais de "adotar ou não" agentes: eles vêm embutidos nas plataformas que você já usa, o Agentforce entre elas. A decisão que sobra para quem opera não é se haverá agentes, mas com qual autoridade eles vão operar. E é aí que o dado da McKinsey pesa: se só uma fração das empresas gerencia ativamente o risco financeiro, a maioria vai descobrir a alçada do agente pelo primeiro desconto indevido — não pelo desenho.
Quando o agente vem embutido, a governança não pode ser um projeto para "depois que estabilizar". A janela entre ligar o agente e a primeira decisão que move dinheiro é curta. A ordem de prioridade abaixo é o que separa autonomia com freio de autonomia com cartão sem limite.
Prioridade 1 — Autoridade delegada (permission tiers): ler ≠ rascunhar ≠ executar ≠ mover dinheiro
A primeira prioridade é recriar a alçada no digital, em camadas. Permission tiers significam separar, explicitamente, o que o agente pode fazer em cada nível: ler um registro é uma permissão; rascunhar uma proposta para revisão humana é outra; executar uma ação operacional é outra; e mover dinheiro — conceder desconto, emitir crédito, alterar um contrato — é o nível mais restrito de todos. Cada nível tem um teto, e o que passa do teto entra numa fila de aprovação humana, não num "confie no agente".
Na prática, isso é o princípio de menor privilégio aplicado ao Agentforce: o agente recebe o escopo mínimo para a tarefa e nada além. Um agente de retenção pode até propor um desconto de US$ 20 mil — mas propor não é conceder, e conceder acima de um valor exige um humano no circuito. É a diferença entre um agente que sugere e um agente que gasta. Sem essa camada, todas as demais viram cosmética.
Prioridade 2 — Data 360 governado: o agente não pode decidir sobre desconto lendo dado sujo
A segunda prioridade é o dado sobre o qual o agente decide. Um agente com alçada perfeita ainda concede errado se o Data 360 embaixo dele estiver sujo: cliente duplicado, histórico desatualizado, valor de contrato que não bate com o ERP nem com o financeiro. Um agente que lê um dado furado vai decidir certo sobre número errado — e com toda a confiança. Governar a alçada sem governar o dado é blindar a porta e deixar a janela aberta.
Salesforce Data Cloud (Data 360) governado significa dado unificado, deduplicado e com linhagem: o agente vê o mesmo cliente que o ERP e o financeiro veem, sabe de onde veio cada informação e quando foi atualizada. É o que impede que o "detectar frustração" do segundo caso vire uma concessão sobre um ticket mal interpretado e um histórico incompleto. Alçada define quanto o agente pode; Data 360 governado define se ele decide sobre a verdade.
Prioridade 3 — Integração cross-system: alçada e dado que batem entre CRM ↔ ERP ↔ e-commerce ↔ financeiro
A terceira prioridade é a mais esquecida: o agente não vive dentro do Salesforce. Quando ele concede um desconto, isso reverbera no ERP (a margem), no e-commerce (o preço praticado) e no financeiro (o faturamento). Se a alçada existe só dentro do CRM, mas o dado e o limite não batem com esses outros mundos, o agente decide com base numa foto parcial — e a divergência aparece depois, na conciliação. Governança de agente que para na borda do Salesforce é meia governança.
Integração cross-system é o que faz a alçada e o dado atravessarem CRM ↔ ERP ↔ e-commerce ↔ financeiro de forma consistente: o teto que o agente respeita no CRM é o mesmo teto que o financeiro reconhece, e o cliente que ele lê é o mesmo em todos os sistemas. É a diferença entre um agente que "resolve" dentro de uma tela e um agente cuja decisão é coerente com a operação inteira.
Como a CCX liga alçada, dado governado e integração antes de soltar o agente
Na CCX, o trabalho começa antes de o agente ir ao ar. A frente de Salesforce Commerce & Data Cloud desenha os permission tiers do agente Agentforce — escopo, teto por ação e fila de aprovação — e governa o Data 360 (unificação, deduplicação, ativação) sobre o qual ele decide, para que ele não conceda sobre dado duplicado. Salesforce entra como a plataforma da vez, dentro do nosso princípio agnóstico: a mesma disciplina de alçada vale para qualquer stack agêntico.
Sobre isso vem Integrações & APIs Enterprise — REST, GraphQL, gRPC e arquitetura event-driven (Kafka/RabbitMQ), com integrações Salesforce ↔ ERP ↔ financeiro — para que a alçada e o dado batam entre os sistemas, não só dentro do CRM. E a Consultoria em Tecnologia faz, antes de tudo, o diagnóstico frio: o que precisa ter alçada, teto e aprovação antes de soltar qualquer agente que age com dinheiro. Na semana passada tratamos a fundação (Data 360 + integração) acima do modelo e, antes, o ROI do Agentforce que depende do Data 360; hoje a fundação inclui a alçada que segura o agente.
Quer dar autonomia ao agente Salesforce sem dar um cartão sem limite? A CCX liga as três camadas na ordem certa: permission tiers com teto por ação e fila de aprovação, Data 360 governado para ele não decidir sobre dado errado, e integração cross-system entre CRM, ERP e financeiro — porque o CIO.com já mostrou o agente que deu US$ 20 mil de desconto sozinho, e a Gartner diz que 80% das apps terão agente embutido até 2026. O agente diz sim; a arquitetura tem que saber dizer não. Falar com especialista Salesforce →
Perguntas frequentes (FAQ)
Como limitar o que o Agentforce pode fazer?
Com permission tiers: separando explicitamente ler, rascunhar, executar e mover dinheiro, cada nível com um teto e com fila de aprovação humana acima do teto. Some a isso um Data 360 governado (para o agente não decidir sobre dado sujo) e integração cross-system (para o limite bater entre CRM, ERP e financeiro). O limite passa a ser uma propriedade da arquitetura, não uma confiança no modelo.
O que são permission tiers no Agentforce?
São níveis de autoridade delegada ao agente: cada nível define o que ele pode fazer e até que valor, do simples ler ao crítico mover dinheiro. O que ultrapassa o teto de um nível sobe para aprovação humana, recriando no digital a alçada que qualquer processo humano já tem.
Um agente de IA pode dar desconto sozinho?
Pode — e já deu: o CIO.com relatou um agente de CRM que concedeu US$ 20 mil de desconto sem aprovação. A questão não é técnica, é de governança: sem um teto de alçada e uma fila de aprovação, o agente concede com confiança. Com permission tiers, propor um desconto é diferente de concedê-lo, e conceder acima de um valor exige um humano no circuito.
Como colocar aprovação humana em agente Salesforce?
Definindo, por nível de permissão, um teto de valor acima do qual a ação do agente vira uma proposta que aguarda aprovação humana (human in the loop), integrada ao fluxo do Salesforce e refletida no ERP e no financeiro. É o mecanismo que transforma "o agente executou" em "o agente propôs e um humano aprovou" para as decisões que movem dinheiro.
Autonomia sem alçada não é produtividade — é um estagiário com cartão corporativo sem limite e sem extrato. O agente pode dizer sim; a arquitetura é quem tem que saber dizer não. Desenhar a alçada do seu agente com a CCX →