Durante anos, o help desk interno teve um formato imutável: o funcionário abre um chamado, o ticket entra numa fila, alguém do time de TI pega, resolve e fecha. O tempo entre "preciso de acesso" e "acesso liberado" era medido em horas — às vezes dias. No Summer '26, a Salesforce colocou uma peça que muda essa coreografia: o Agentforce IT Service, um conjunto de mais de 50 agentes de IA pré-construídos que resolvem pedidos de funcionário direto no Slack, no Microsoft Teams e em portais internos — reset de senha, provisionamento de licença, tickets Tier-1 — sem passar pela fila humana, e configuráveis, segundo a Salesforce, em "6 cliques ou menos".
Ontem a manchete era o agente que atende o cliente. Hoje é o que atende o funcionário. É a virada do "digital labor" para dentro da empresa, e ela chega com uma promessa sedutora: reduzir o Tier-1, dar resolução 24/7 e liberar o time de TI para o que importa. Mas existe uma condição que raramente aparece no anúncio, e é ela que decide se esses 50 agentes viram menos fila ou apenas mais uma. A condição é integração. Um agente interno só "resolve" se enxerga a identidade, a política de acesso e o sistema de provisionamento por trás do pedido. Sem isso, ele responde bonito e reabre o problema.
O que mudou: o Agentforce IT Service e os 50+ agentes prontos em Slack e Teams
O Agentforce IT Service é a aplicação do padrão Agentforce ao domínio de TI interna. Em vez de um assistente genérico que responde perguntas, ele traz agentes especializados — cada um treinado para uma tarefa inteira dentro do service desk. A biblioteca de mais de 50 agentes cobre os pedidos que mais entopem a fila: recuperação e troca de senha, desbloqueio de conta, provisionamento e revogação de licenças de software, criação de acessos, respostas a dúvidas de política e a resolução do grosso dos chamados Tier-1.
O ponto de contato também mudou. Esses agentes não vivem num portal separado que ninguém abre: eles operam onde o funcionário já está — no Slack e no Teams. Alguém digita "esqueci minha senha do ERP" no mesmo canal em que conversa com o time, e o agente conduz a resolução ali, em linguagem natural. A proposta de configuração em "6 cliques" reforça a mensagem: a Salesforce quer que ativar um agente de TI seja tão simples quanto ligar um app, não um projeto de meses.
É uma mudança real de patamar. O que antes exigia um humano lendo o chamado, verificando a identidade do solicitante e executando uma ação num sistema de backoffice agora pode acontecer em segundos, a qualquer hora. Para operações com milhares de funcionários e um time de TI crônico em falta de gente, o apelo é óbvio. A questão não é se a ideia é boa — é o que precisa estar no lugar para que ela funcione.
"Resolver antes do ticket": o que isso significa na prática
A frase de efeito do lançamento é "resolver o chamado antes de ele existir". Traduzindo para a operação: em vez de o funcionário abrir um ticket e esperar, o agente entende a intenção na conversa e executa a ação imediatamente. Vale a pena olhar três exemplos concretos, porque eles revelam onde está o trabalho de verdade.
Reset de senha. Parece trivial, mas não é só "trocar uma string". O agente precisa confirmar que quem pede é mesmo o dono da conta (autenticação e verificação de identidade), respeitar a política de senha da empresa e escrever a mudança no diretório de identidade correto — Active Directory, Entra ID, Okta, o que for. Se o agente não fala com esse diretório, ele não reseta nada; ele orienta o funcionário a abrir um chamado. A fila volta com outro nome.
Provisionamento de licença. "Quero acesso ao Figma." O agente tem que saber se há licença disponível no contrato, se o cargo do solicitante autoriza aquele software, se existe orçamento, e então executar a atribuição no sistema de gestão de licenças ou no IdP. Cada uma dessas verificações é uma integração com um sistema diferente. Sem elas, o agente ou nega tudo por precaução, ou concede o que não deveria — os dois desfechos custam caro.
Ticket Tier-1. "O VPN caiu." Resolver isso pode significar consultar a base de conhecimento, checar o status de um serviço, reiniciar uma sessão, ou escalar para o time certo com o contexto já montado. Um agente que só tem acesso à base de conhecimento responde com um artigo; um agente integrado ao ITSM e aos sistemas de monitoramento age. A diferença entre os dois é inteiramente uma diferença de encanamento.
A conta escondida: agente sem identidade e provisionamento integrados só empurra a fila
Aqui está o detalhe que o palco não destaca: um agente de IA no service desk é tão capaz quanto os sistemas que ele consegue enxergar e acionar. A inteligência do modelo — sua capacidade de entender o pedido em linguagem natural — nunca foi o gargalo. O gargalo é a ponte entre "entendi o que você quer" e "executei a mudança no sistema onde ela precisa acontecer".
Quando essa ponte não existe, acontece o pior dos mundos: uma camada a mais, não a menos. O funcionário conversa com o agente, o agente entende, dá uma resposta educada — e no fim gera um ticket para o humano resolver, porque ele não tinha permissão nem conexão para agir. O que se prometeu como redução de fila virou um recepcionista simpático na frente da mesma fila. Pior: agora existe uma etapa de conversa a mais antes de o chamado chegar a quem resolve.
Há ainda um risco de segurança que caminha junto. Um agente que executa provisionamento e concede acessos é, por definição, um ator privilegiado. Se ele não está amarrado à política de acesso — quem pode pedir o quê, com qual aprovação — ele vira uma superfície nova de erro e de exploração. "Configurar em 6 cliques" é ótimo para a velocidade e péssimo se os 6 cliques não incluem o mapeamento de identidade, os limites de permissão e a trilha de auditoria. Automatizar a concessão de acesso sem governança não acelera a TI: acelera o próximo incidente.
O padrão é o de sempre, agora com consequência operacional direta. A IA resolve muito bem a parte de entender e conversar. O que ela pressupõe — e não constrói sozinha — é o fluxo íntegro que conecta o pedido ao diretório de identidade, à base de conhecimento, ao ITSM e ao provisionamento. Sem esse fluxo, 50 agentes não são 50 problemas a menos; são 50 pontos de conversa a mais.
Checklist: o que precisa estar conectado antes de ligar os agentes
Antes de soltar uma frota de agentes no Slack, vale conferir se o encanamento que eles pressupõem existe. Cinco conexões separam o agente que resolve do agente que só responde.
1. Diretório de identidade (IAM/IdP). O agente precisa ler e, em alguns casos, escrever no Active Directory, Entra ID ou Okta — para verificar quem é o solicitante, checar grupos e executar resets e provisionamentos. Sem essa integração, todo pedido que toca identidade vira escalonamento.
2. Política de acesso e aprovação. As regras de "quem pode pedir o quê, e o que exige aprovação" têm que estar disponíveis para o agente — idealmente como políticas versionadas e auditáveis, não como conhecimento tácito na cabeça do time de TI. É isso que impede o agente de conceder demais ou de menos.
3. Base de conhecimento. Para responder Tier-1 com precisão, o agente precisa de RAG sobre a documentação real, atualizada, da empresa — runbooks, políticas, FAQs internas. Base desatualizada gera resposta confiante e errada, que é pior do que não responder.
4. ITSM. ServiceNow, Jira Service Management ou equivalente: o agente precisa criar, atualizar, escalar e fechar tickets no sistema de registro, para que a resolução automática e a humana convivam numa única fonte de verdade — e para que exista métrica e auditoria.
5. Provisionamento. A ponte final: os sistemas que efetivamente concedem licenças e acessos. É a diferença entre "vou pedir para o time liberar" e "liberado". Sem ela, o agente nunca fecha o ciclo.
Repare que nenhuma dessas cinco conexões é sobre a IA em si. Todas são projetos de integração e de governança de identidade. É esse trabalho — invisível no anúncio — que decide se os 50 agentes entregam.
Como a CCX implementa IA para negócios com os sistemas conversando de verdade
É exatamente nesse recorte — antes de ativar o agente, não depois — que a CCX Company atua. A plataforma da Salesforce resolve muito bem a parte de entender o pedido e conduzir a conversa; o que a CCX entrega é o que o agente pressupõe e não vem pronto: o fluxo que conecta identidade, conhecimento e execução, com a governança no lugar.
Nossa prática de IA para Negócios implementa agentes internos com RAG sobre a base real de conhecimento e as políticas da empresa, e com as integrações que transformam intenção em ação — leitura e escrita no IdP, mapeamento de permissões, conexão ao ITSM e ao provisionamento. Quando o agente precisa tocar a stack Salesforce e o Data Cloud, combinamos isso com a implementação de Agentforce e Salesforce Data Cloud, para que o agente enxergue um dado unificado em vez de silos. E porque conceder acesso é ação privilegiada, tratamos limites de permissão, aprovação e trilha de auditoria como parte do projeto, não como ajuste posterior.
Antes de soltar 50 agentes no Slack, conecte-os ao seu diretório de identidade, à sua base de conhecimento e ao seu provisionamento — com governança desde o primeiro clique. A CCX implementa IA para negócios com os sistemas realmente integrados, começando por um diagnóstico de agentes em duas semanas. Implementar IA no meu negócio →
FAQ — Perguntas frequentes
O que é o Agentforce IT Service da Salesforce? É um conjunto de mais de 50 agentes de IA pré-construídos, lançado no Summer '26, que resolve pedidos de TI de funcionários — reset de senha, provisionamento de licença, tickets Tier-1 — direto no Slack, no Microsoft Teams e em portais internos, sem passar pela fila do time de TI, e configuráveis em poucos cliques.
O agente de IA substitui o time de TI? Não. Ele automatiza o Tier-1 repetitivo e libera o time para trabalho de maior valor. Mas ele só resolve o que consegue executar — o que depende de integração com identidade, ITSM e provisionamento. Sem esse encanamento, o agente escala para o humano, e o time continua na jogada.
Por que integração é pré-requisito para um agente de service desk? Porque "resolver" um pedido significa executar uma ação num sistema — resetar senha no diretório, atribuir uma licença no IdP, fechar um ticket no ITSM. Se o agente não está conectado a esses sistemas, ele entende o pedido mas não age: gera outro ticket. A capacidade de conversar não vale sem a capacidade de executar.
Quais sistemas preciso integrar antes de ativar agentes internos de IA? Cinco: o diretório de identidade (Active Directory, Entra ID, Okta), as políticas de acesso e aprovação, a base de conhecimento (para RAG), o ITSM (ServiceNow, Jira Service Management) e o sistema de provisionamento de licenças e acessos. Sem eles, o agente vira uma camada a mais na fila, não a menos.
Ativar agentes que concedem acesso não é um risco de segurança? Sim, se feito sem governança. Um agente que provisiona acessos é um ator privilegiado. É preciso mapear limites de permissão, exigir aprovação nas ações sensíveis e manter trilha de auditoria completa — tratando isso como parte do projeto de integração, não como um ajuste posterior.