Em que canal pôr um agente de IA: a decisão tomada no fim que manda desde o princípio
Em que canal pôr um agente de IA é uma pergunta que chega quase sempre no fim, quando o agente já funciona e é preciso mostrá-lo a alguém. E chega tarde, porque não é uma decisão de apresentação: é a que determina quem o vai usar a sério, quanto tempo tem para responder, com que permissões nasce e o que fica escrito quando se enganar. Escolher superfície é escolher arquitetura, orçamento de latência e modelo de segurança ao mesmo tempo.
A tese desta guia é simples e comprova-se em qualquer empresa: o agente que vive onde as pessoas já trabalham é usado; o que vive num separador à parte morre sozinho, por muito bom que seja. Não é uma questão de entusiasmo nem de formação. É que cada superfície nova que pedes para abrir é uma portagem de atenção que alguém paga todos os dias, e essa portagem tem preço medido: a investigação publicada pela Harvard Business Review em agosto de 2022, sobre 137 trabalhadores de três empresas da Fortune 500, contabilizou cerca de 1.200 saltos diários entre aplicações e janelas, perto de quatro horas por semana — à volta de 9 % do tempo de trabalho — consumidas só a reorientar-se. Fonte: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, agosto de 2022.
O contexto também não ajuda a que uma ferramenta nova abra caminho. O relatório da Microsoft WorkLab sobre a jornada infinita, publicado em junho de 2025 a partir de sinais agregados e anonimizados do Microsoft 365, situa uma interrupção a cada dois minutos ao longo do dia — 275 por dia nos 20 % de utilizadores que mais notificações recebem — entre reuniões, correio e chats. Fonte: Breaking down the infinite workday, Microsoft WorkLab, junho de 2025. Contra esse ruído, pedir que alguém se lembre de mais um separador não é um pedido pequeno: é competir pelo espaço mais caro que a tua equipa tem.
As cinco superfícies reais e quem está do outro lado de cada uma
Na prática só há cinco sítios onde um agente de empresa se instala, e cada um traz um utilizador diferente colado. A superfície não se escolhe por gosto: escolhe-se identificando onde está essa pessoa no momento exato em que o trabalho aparece.
- Dentro do CRM ou do ERP. Utilizador: o colaborador que já vive ali oito horas por dia. É a superfície com melhor adoção e pior visibilidade para quem compra: ninguém faz uma demo brilhante de um painel lateral. Em troca, o agente aparece ao lado do registo que vai mexer, com a conta e o histórico à frente, e não é preciso explicar a ninguém onde o encontrar.
- Slack ou Teams. Utilizador: a equipa, em conversa. Serve para o trabalho que nasce a falar — «alguém sabe se este cliente tem contrato de suporte?» — e para processos onde a decisão é coletiva. Vantagem real: a pergunta e a resposta ficam à vista de todos, e isso acelera a confiança muito mais depressa do que um chat privado.
- WhatsApp. Utilizador: o cliente que já te escreve por ali. É o canal com mais tração comercial em Portugal, Espanha e Itália, e o que arrasta mais regras de plataforma. Escolhe-se quando o cliente já lá está, nunca para o levar para lá.
- O chat do site. Utilizador: um visitante anónimo que está a decidir. É a superfície mais exigente em latência e a mais pobre em contexto: não sabes quem é. O trabalho dele é qualificar e captar, não resolver casos de cliente.
- O email. Utilizador: o processo, mais do que a pessoa. Faturas de fornecedor, encomendas, pedidos que já chegam a uma caixa. É a superfície menos glamorosa e a que esconde mais trabalho repetitivo, porque ninguém olha para ela como um canal: olha para ela como uma pasta.
Falta uma sexta que quase toda a gente escolhe por omissão e que ficou fora da lista de propósito: o separador próprio, a aplicação interna com o seu URL e o seu login. Não é que nunca sirva — serve para trabalho profundo, com sessões longas e um utilizador perito que vai ali de propósito —, é que se escolhe pela comodidade de quem constrói, não por onde está o trabalho. Se o caso de uso é «resolver algo que surge enquanto fazes outra coisa», o separador próprio é a pior opção disponível.
Latência: quanto silêncio aguenta cada canal antes de perder o utilizador
Cada superfície tem um orçamento de tempo implícito que ninguém escreve e toda a gente respeita. Nota-se quando é ultrapassado: o utilizador dá o agente por morto e vai-se embora. Estas são as ordens de grandeza com que convém desenhar.
| Superfície | Orçamento de resposta | O que te obriga a montar |
|---|---|---|
| Chat do site | Segundos | Modelo rápido + resposta parcial enquanto trabalha; nada de esperar pela resposta completa |
| Segundos a um par de minutos | Aviso de receção imediato; o cliente não tem o ecrã aberto à espera | |
| Slack / Teams | Dezenas de segundos | Reação ou «estou nisso» e depois a mensagem boa; a assincronia já está aceite |
| Dentro do CRM / ERP | Segundos se for um botão; minutos se escrever no registo | Decidir se é interação ou processo de fundo — são dois desenhos diferentes |
| Horas | Quase nada: aqui a latência deixa de ser o problema e passa a sê-lo a rastreabilidade |
A consequência que mais custa a aceitar é que o canal manda sobre o modelo. Se a superfície exige segundos, não podes dar-te ao luxo de três chamadas encadeadas ao modelo mais capaz por muito bem que respondam; vais ter de repartir — barato para classificar e encaminhar, capaz para decidir — e devolver algo antes de terminar. Essa repartição está desenvolvida em que modelo usar num agente de IA, e é uma decisão que se toma depois da de superfície, não antes.
Permissões: cada superfície chega com as suas já ligadas
Instalar um agente numa superfície não é neutro em segurança: herda o modelo de permissões dessa superfície, e por omissão pede quase sempre a mais. Convém olhar para isso antes de assinar, não depois do primeiro incidente.
- CRM / ERP: herda, e isso é o que tem de bom. O agente pode correr com o papel do utilizador que o invoca, por isso se o comercial não vê aquela conta, o agente também não. É o único caso em que a superfície te oferece o trabalho feito. O que há a vigiar é a tentação de lhe dar um utilizador de serviço com permissões de administrador «para que não falhe nada».
- Slack / Teams: âmbitos próprios, e o perigoso é o histórico. Instala-se como aplicação com as suas permissões. Ler o histórico completo de um canal é muito mais do que costuma ser preciso: para a maioria dos casos basta receber as mensagens em que é mencionado. Pedir o histórico inteiro transforma o agente num leitor permanente de conversas internas, e isso é uma decisão que merece ser consciente.
- Chat do site: desconhecidos. Fala com visitantes sem autenticar, por isso não pode ter acesso de leitura a dados de clientes concretos. Tudo o que cheire a «diz-me o estado da minha encomenda» exige um passo de identificação antes, ou acabas com uma fuga de dados elegantemente desenhada.
- WhatsApp: identidade frágil. Um número de telefone não é uma identidade verificada: os números reciclam-se e os telemóveis emprestam-se. Para qualquer ação com consequências, é preciso uma verificação adicional.
- Email: o âmbito é a armadilha. Dar acesso a uma caixa é dar acesso a todo o seu histórico. O âmbito limita-se por etiqueta, pasta ou alias dedicado, nunca por caixa completa.
A regra comum às cinco: a permissão pede-se por caso de uso e revê-se com data, não se aceita a que vem com o instalador. O desenvolvimento completo — o que se lhe dá, como se retira e o que fica registado — está em que permissões dar a um agente de IA.
O que fica registado e o que se evapora ao fechar o separador
No dia em que o agente se enganar — e vai acontecer — a pergunta não vai ser «porquê?», vai ser «onde é que eu vou ver?». A superfície decide se essa pergunta tem resposta em dois minutos ou em dois dias.
O Slack e o Teams são a melhor superfície neste eixo e quase ninguém tem isso em conta ao escolher: a conversa fica escrita, com quem perguntou, o que o agente respondeu e quem lhe levou a contrária, num sítio que a empresa já retém e já sabe exportar. Dentro do CRM passa-se algo parecido se o agente escrever no registo em vez de num painel volátil: a nota fica colada ao cliente e ao caso. O chat do site é o extremo oposto: a sessão fecha-se e, se não montaste a persistência de propósito, não fica nada para auditar a não ser o que o teu fornecedor decidir guardar e por quanto tempo.
Isto liga ao que acontece quando o agente hesita ou fica sem resposta: o traspasse a uma pessoa só é barato se a superfície conservar o contexto. No Slack ou no CRM, a pessoa entra e lê o que já lá está. Num chat de site sem persistência, a pessoa começa do zero e o cliente repete tudo. O que tem de viajar nesse traspasse está em o que faz um agente quando não sabe a resposta.
As regras de canal que não se negoceiam: WhatsApp e o email
Duas das cinco superfícies trazem normativa de plataforma própria, e não é orientativa: se a ignorares, o canal deixa de funcionar. Convém saber isto antes de prometer uma experiência que a plataforma não permite.
No WhatsApp, quando um utilizador te escreve abre-se uma janela de apoio ao cliente de 24 horas; dentro dessa janela podes responder com mensagens livres, e se o utilizador voltar a escrever o contador reinicia-se. Fora dela só podes contactar através de modelos aprovados previamente, classificados por categoria — utilidade, autenticação, marketing — com regras e custo diferentes consoante o tipo. Fonte: documentação oficial da Meta, Política de mensajería de WhatsApp Business, consultada a 14 de setembro de 2026. A tradução operacional para o desenho do agente é direta: um agente de WhatsApp é reativo por omissão, e qualquer fluxo que exija iniciar a conversa tem de ser desenhado como modelo aprovado antes de escrever uma linha de código. O detalhe do que permite e do que não permite está em o que a Meta permite num agente de IA no WhatsApp, e a versão comercial do caso, em responder WhatsApp 24 horas.
O email não tem uma plataforma que te sancione, mas tem duas restrições igualmente duras: a identidade do remetente (se o agente responder a partir de um endereço genérico, a taxa de resposta afunda; se responder a partir do de uma pessoa, essa pessoa é responsável pelo que ele disser) e o fio (responder criando um fio novo parte o seguimento de qualquer processo). Nenhuma das duas é técnica e as duas decidem se o canal serve.
A tabela de decisão: quatro perguntas, uma superfície
A decisão fecha-se numa tarde com quatro perguntas, por esta ordem. A ordem importa: a primeira elimina metade das opções e as restantes afinam.
- Quem é o utilizador e o que tem aberto quando este trabalho aparece? Colaborador dentro de um sistema → esse sistema. Equipa a falar → Slack ou Teams. Cliente que já te escreve → o canal dele. Visitante anónimo → chat do site. Ninguém, porque o trabalho chega sozinho → email.
- Quanto pode esperar sem se dar por abandonado? Se a resposta são segundos, a arquitetura tem de devolver algo antes de terminar. Se são horas, sobra-te orçamento e podes gastá-lo a verificar melhor.
- Que permissões é que essa superfície me obriga a pedir, e quantas delas preciso mesmo? Se o mínimo que a superfície permite já é mais do que o caso justifica, é um motivo legítimo para mudar de superfície.
- Quando falhar, onde é que está escrito? Se não há resposta, ou montas a persistência antes de lançar ou escolhes outra superfície.
E uma regra de arquitetura que torna tudo o anterior reversível: o agente é um serviço, o canal é uma camada fina por cima. Se a lógica — os passos, as condições, as chamadas aos teus sistemas — vive dentro do construtor visual do fornecedor de chat, mudar de superfície não é mover, é voltar a construir. Se vive do teu lado, atrás de um contrato de entrada e saída, mover o mesmo agente do site para o WhatsApp ou de um separador próprio para o Teams é trabalho de dias. É essa condição que transforma a decisão de superfície em algo que podes corrigir quando os dados de utilização te contradisserem.
Nós começamos por aqui, antes do modelo e antes do prompt: onde está o trabalho, quem o faz e o que tem aberto nesse momento. É o que está por baixo de Adoção IA para equipas — porque ter IA na empresa não é o mesmo que a empresa usar IA — e o que se monta com infraestrutura de IA empresarial quando o agente tem de viver dentro de sistemas que já estão em produção. O resto da montagem — permissões, autonomia, memória, evals — está em criar um agente de IA que aguente produção.