AIforce da Salesforce: o que muda na prática para arquitetos de solução
Anunciado no Dreamforce 2026, o AIforce expõe dados e permissões da org no Claude, no Slack e no Lightning, mas a governança continua sendo o verdadeiro teste
A Salesforce anunciou o AIforce no Dreamforce 2026, uma camada de interface que leva dados, permissões e workflows da org para Claude, Slack e Lightning através de Claudeforce, Slackforce e Agentforce Coworker. O discurso de governança é forte no papel, mas preço, GA e detalhes independentes ainda são escassos.
Toda vez que a Salesforce anuncia uma "nova camada" eu fico com um pé atrás, porque na prática costuma significar que vou passar os próximos seis meses explicando pro cliente por que aquilo não substitui governança nenhuma. Mas o AIforce, anunciado no keynote do Dreamforce 2026, merece uma leitura mais fria antes do veredito.
A ideia central não é um produto novo pra vender separado. É uma camada de interface que expõe dados, permissões, workflows e regras de negócio da sua org onde quer que as pessoas já estejam trabalhando, seja no Claude, no Slack ou na própria tela Lightning. O discurso oficial é "parem de pedir pra pessoa vir até o Salesforce, deixem o Salesforce ir até ela". É dado limpo, permissionamento bem desenhado e processo de negócio que faça sentido antes de qualquer agente sair executando ação.
As três superfícies de lançamento
- Claudeforce: empacota dados e permissões da Salesforce dentro de um servidor MCP pronto no Claude, com 37 skills de vendas prontas e um plugin de desenvolvimento com mais de 40 skills pro Claude Code. Serve pra rep de vendas, dev e admin que já vive fora da tela do Salesforce.
- Slackforce: traz o contexto da org pro Slack através de Surfaces (interfaces vivas e compartilháveis), Slackbot (assistente de raciocínio cruzando Slack e CRM), Slack CRM (atualiza registro direto de um prompt no Slack) e Slack Code (multiplayer coding dentro do Slack). Faz sentido pra time que já vive de canal e nunca abriu um app Lightning por opção própria.
- Agentforce Coworker: um "colega de trabalho" de IA dentro da própria interface Lightning, raciocinando sobre conta e histórico, operando 100% dentro das permissões existentes. Esse é o caminho natural pra quem já é usuário Salesforce e não quer trocar de tela.
A arquitetura por trás chama Headless Toolkit, expondo MCPs, APIs, plugins e skills, com o AgentExchange como marketplace onde parceiros como Anthropic, AWS, Google, Microsoft, Docusign, Gamma, Jasper e Rippling plugam seus próprios agentes. É uma mudança de postura relevante: a Salesforce historicamente queria você dentro da UI dela. Agora ela quer ser o backend confiável não importa onde você trabalhe.
O que sustenta o discurso de governança
Aqui está o ponto que interessa de verdade pra quem é arquiteto de solução, não só marketing:
- Toda requisição roda em cima da permissão já existente do usuário. O agente só vê o que aquela pessoa já poderia ver.
- Zero Data Retention: o dado de negócio responde a pergunta pontual e não fica retido pelo provedor do modelo.
- Sem novo modelo de permissão, sem migração, sem trabalho de integração customizada, segundo a própria Salesforce. O admin conecta uma vez.
Isso é exatamente o tipo de garantia que time de segurança e compliance vai cobrar antes de deixar alguém "só usar o Claude pra isso" com dado de CRM sensível.
O que ainda falta
Não tem preço público. Os release notes da própria Salesforce dizem que pricing e packaging estão sujeitos a mudança e disponibilidade varia por região. Não tem data de GA fechada pra todas as superfícies: Salesforce in Claude está em beta, o resto rola em ritmos diferentes. E cobertura independente confirma o anúncio, mas ainda é cedo, os detalhes que vão além do material oficial da própria Salesforce ainda são escassos.
Porque muda o ponto de entrada da sua org sem mudar a fundação. Se sua governança de permission set e role hierarchy já é sólida, o AIforce herda essa solidez e vira um multiplicador de alcance real, gente que nunca abriu um dashboard passa a consultar e atualizar registro por chat. Se sua governança é furada, o AIforce só distribui o furo pra mais lugares, mais rápido, com uma aparência de "governado" que engana quem não olhou o desenho por baixo.
Pra quem trabalha com Agentforce Revenue Management e Revenue Cloud isso pesa duplo: a superfície de interação aumenta exatamente na camada onde regra de preço, aprovação e exceção comercial vivem. Um Flow Approval Process mal desenhado que hoje só incomoda dentro do Lightning pode virar um problema de escala se o agente no Slack começa a disparar transação sem o contexto completo que um usuário humano naturalmente para pra questionar.
Gosto da tese de fundo (dado e lógica de negócio acessíveis onde a pessoa já trabalha), mas isso só é bom notícia pra quem já fez o dever de casa de dado, processo e permissão antes de abrir a porta pro agente. Pra quem ainda não fez, o AIforce só troca o lugar onde o problema aparece: antes era na tela, agora vai ser dentro do Slack.
- Antes de habilitar Claudeforce ou Slackforce, audite permission set e profile como se um agente fosse literalmente o usuário mais curioso da sua base. Se você não confiaria naquele acesso pra um humano novo, não confie pra um agente.
- Valide onde estão as regras de negócio críticas (pricing procedure, transaction management, aprovação) e garanta que elas continuam sendo respeitadas independente da superfície de entrada. Não adianta a regra existir só quando o usuário passa pela tela Lightning.
- Comece pelo Agentforce Coworker se sua org ainda está redesenhando processo. Ele opera dentro do Lightning existente, é o caminho de menor risco pra validar comportamento do agente antes de abrir pra Claude ou Slack.
- Trate Zero Data Retention como cláusula contratual a confirmar, não como slide de marketing. Peça pro seu representante Salesforce detalhar isso por escrito antes de qualquer rollout com dado sensível.
Sem preço público e sem data de disponibilidade geral fechada, qualquer decisão de arquitetura agora é diretriz, não compromisso comercial. Não venda pro cliente como se fosse pacote fechado.
A promessa de "sem novo modelo de permissão, sem migração" é forte demais pra aceitar sem teste. Toda vez que um vendor promete zero esforço de configuração, a experiência de projeto real mostra que o esforço só migrou de lugar, geralmente pra fase de validação e teste de regressão de segurança.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.