In quale canale mettere un agente IA: la decisione presa per ultima che comanda dall'inizio
In quale canale mettere un agente IA è una domanda che arriva quasi sempre alla fine, quando l'agente già funziona e tocca farlo vedere a qualcuno. E arriva tardi, perché non è una decisione di presentazione: è quella che determina chi lo userà davvero, quanto tempo ha per rispondere, con quali permessi nasce e cosa resta scritto quando sbaglia. Scegliere la superficie è scegliere architettura, budget di latenza e modello di sicurezza tutto insieme.
La tesi di questa guida è semplice e si verifica in qualsiasi azienda: l'agente che vive dove la gente già lavora viene usato; quello che vive in una scheda a parte muore da solo, per quanto sia bravo. Non è una questione di entusiasmo né di formazione. È che ogni superficie nuova che chiedi di aprire è un pedaggio di attenzione che qualcuno paga tutti i giorni, e quel pedaggio ha un prezzo misurato: la ricerca pubblicata da Harvard Business Review nell'agosto 2022, su 137 lavoratori di tre aziende Fortune 500, ha contato circa 1.200 salti al giorno tra applicazioni e finestre, quasi quattro ore a settimana — intorno al 9 % del tempo di lavoro — consumate solo per riorientarsi. Fonte: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, agosto 2022.
Nemmeno il contesto aiuta uno strumento nuovo a farsi strada. Il report di Microsoft WorkLab sulla giornata infinita, pubblicato nel giugno 2025 a partire da segnali aggregati e anonimizzati di Microsoft 365, colloca un'interruzione ogni due minuti durante la giornata — 275 al giorno nel 20 % di utenti che riceve più notifiche — tra riunioni, email e chat. Fonte: Breaking down the infinite workday, Microsoft WorkLab, giugno 2025. Contro quel rumore, chiedere a qualcuno di ricordarsi di un'altra scheda non è una richiesta piccola: è competere per lo spazio più caro che ha il tuo team.
Le cinque superfici reali e chi c'è dall'altra parte di ciascuna
In pratica ci sono solo cinque posti dove un agente aziendale si installa, e ognuno arriva con un utente diverso attaccato. La superficie non si sceglie per gusto: si sceglie individuando dove sta quella persona nel momento esatto in cui compare il lavoro.
- Dentro il CRM o l'ERP. Utente: il dipendente che ci vive già dentro otto ore al giorno. È la superficie con la migliore adozione e la peggiore visibilità per chi compra: nessuno fa una demo memorabile di un pannello laterale. In cambio, l'agente compare accanto al record che dovrà toccare, con l'anagrafica e lo storico davanti, e non devi spiegare a nessuno dove trovarlo.
- Slack o Teams. Utente: il team, in conversazione. Serve per il lavoro che nasce parlando — «qualcuno sa se questo cliente ha un contratto di supporto?» — e per processi dove la decisione è collettiva. Vantaggio reale: domanda e risposta restano sotto gli occhi di tutti, e questo accelera la fiducia molto più in fretta di una chat privata.
- WhatsApp. Utente: il cliente che ti scrive già lì. È il canale con più trazione commerciale in Italia, Spagna e Portogallo, e quello che si porta dietro più regole di piattaforma. Si sceglie quando il cliente è già lì, mai per portarcelo.
- La chat del sito. Utente: un visitatore anonimo che sta decidendo. È la superficie più esigente in latenza e la più povera di contesto: non sai chi è. Il suo lavoro è qualificare e catturare, non risolvere casi cliente.
- La posta. Utente: il processo, più che la persona. Fatture fornitore, ordini, richieste che arrivano già in una casella. È la superficie meno glamour e quella che nasconde più lavoro ripetitivo, perché nessuno la guarda come un canale: la guarda come una cartella.
Ne manca una sesta che quasi tutti scelgono per default e che non sta nell'elenco di proposito: la scheda propria, l'applicazione interna con il suo URL e il suo login. Non è che non serva mai — va bene per lavoro profondo, con sessioni lunghe e un utente esperto che ci va apposta — è che si sceglie per comodità di chi costruisce, non per dove sta il lavoro. Se il caso d'uso è «risolvere una cosa che salta fuori mentre ne stai facendo un'altra», la scheda propria è la peggiore opzione disponibile.
Latenza: quanto silenzio regge ogni canale prima di perdere l'utente
Ogni superficie ha un budget di tempo implicito che nessuno scrive e tutti rispettano. Si nota quando viene sforato: l'utente dà l'agente per morto e se ne va. Questi sono gli ordini di grandezza con cui conviene progettare.
| Superficie | Budget di risposta | Cosa ti obbliga a montare |
|---|---|---|
| Chat del sito | Secondi | Modello veloce + risposta parziale mentre lavora; niente attese fino alla risposta completa |
| Da secondi a un paio di minuti | Conferma di ricezione immediata; il cliente non ha lo schermo aperto ad aspettare | |
| Slack / Teams | Decine di secondi | Reaction o «ci sto lavorando» e poi il messaggio buono; l'asincronia è già accettata |
| Dentro il CRM / ERP | Secondi se è un bottone; minuti se scrive nel record | Decidere se è interazione o processo di fondo — sono due progetti diversi |
| Posta | Ore | Quasi niente: qui la latenza smette di essere il problema e il problema diventa la tracciabilità |
La conseguenza più difficile da accettare è che il canale comanda sul modello. Se la superficie esige secondi, non puoi permetterti tre chiamate concatenate al modello più capace per quanto rispondano bene; dovrai distribuire — economico per classificare e instradare, capace per decidere — e restituire qualcosa prima di finire. Quella distribuzione è sviluppata in quale modello usare in un agente di IA, ed è una decisione che si prende dopo quella di superficie, non prima.
Permessi: ogni superficie arriva con i suoi già accesi
Installare un agente su una superficie non è neutro in termini di sicurezza: eredita il modello di permessi di quella superficie, e per default quasi sempre chiede più del necessario. Conviene guardarlo prima di firmare, non dopo il primo incidente.
- CRM / ERP: eredita, ed è un bene. L'agente può girare con il ruolo dell'utente che lo invoca, quindi se il commerciale non vede quell'anagrafica, l'agente nemmeno. È l'unico caso in cui la superficie ti regala il lavoro già fatto. Quello da sorvegliare è la tentazione di dargli un utente di servizio con permessi da amministratore «così non si rompe niente».
- Slack / Teams: ambiti propri, e quello pericoloso è lo storico. Si installa come applicazione con i suoi permessi. Leggere lo storico completo di un canale è molto più di quanto serva di solito: per la maggior parte dei casi basta ricevere i messaggi in cui viene menzionato. Chiedere tutto lo storico trasforma l'agente in un lettore permanente di conversazioni interne, ed è una decisione che merita di essere consapevole.
- Chat del sito: sconosciuti. Parla con visitatori non autenticati, quindi non può avere accesso in lettura ai dati di clienti specifici. Tutto quello che sa di «dimmi lo stato del mio ordine» esige un passaggio di identificazione prima, o finisci con una fuga di dati progettata con eleganza.
- WhatsApp: identità fragile. Un numero di telefono non è un'identità verificata: i numeri si riciclano e i telefoni si prestano. Per qualsiasi azione con conseguenze serve una verifica aggiuntiva.
- Posta: la trappola è l'ambito. Dare accesso a una casella è dare accesso a tutto il suo storico. L'ambito si delimita per etichetta, cartella o alias dedicato, mai per casella intera.
La regola comune a tutte e cinque: il permesso si chiede per caso d'uso e si rivede con una data, non si accetta quello che porta l'installer. Lo sviluppo completo — cosa gli dai, come lo ritiri e cosa viene registrato — sta in quali permessi dare a un agente di IA.
Cosa resta a registro e cosa evapora quando chiudi la scheda
Il giorno in cui l'agente sbaglierà — e succederà — la domanda non sarà «perché?», sarà «dove guardo?». La superficie decide se quella domanda ha risposta in due minuti o in due giorni.
Slack e Teams sono la superficie migliore su questo asse e quasi nessuno ne tiene conto quando sceglie: la conversazione resta scritta, con chi ha chiesto, cosa ha risposto l'agente e chi lo ha contraddetto, in un posto che l'azienda già conserva e già sa esportare. Dentro il CRM succede una cosa simile se l'agente scrive nel record invece che in un pannello volatile: la nota resta attaccata al cliente e al caso. La chat del sito è l'estremo opposto: la sessione si chiude e, se non hai montato la persistenza apposta, non resta niente da verificare a parte quello che il tuo fornitore decide di salvare e per quanto tempo.
Questo si collega a cosa succede quando l'agente dubita o resta senza risposta: il passaggio di consegne a una persona è economico solo se la superficie conserva il contesto. Su Slack o nel CRM, la persona entra e legge quello che c'è già. In una chat del sito senza persistenza, la persona parte da zero e il cliente ripete tutto. Quello che deve viaggiare in quel passaggio sta in cosa fa un agente quando non sa la risposta.
Le regole di canale che non si negoziano: WhatsApp e la posta
Due delle cinque superfici portano normativa di piattaforma propria, e non è orientativa: se la ignori, il canale smette di funzionare. Conviene saperlo prima di promettere un'esperienza che la piattaforma non permette.
Su WhatsApp, quando un utente ti scrive si apre una finestra di assistenza clienti di 24 ore; dentro quella finestra puoi rispondere con messaggi liberi, e se l'utente scrive di nuovo il contatore riparte. Fuori da lì puoi contattarlo solo tramite template approvati in anticipo, classificati per categoria — utilità, autenticazione, marketing — con regole e costi diversi a seconda del tipo. Fonte: documentazione ufficiale di Meta, WhatsApp Business Messaging Policy, consultata il 14 settembre 2026. La traduzione operativa per il progetto dell'agente è diretta: un agente WhatsApp è reattivo per default, e qualsiasi flusso che richieda di iniziare la conversazione va progettato come template approvato prima di scrivere una riga di codice. Il dettaglio di cosa è permesso e cosa no sta in cosa permette Meta in un agente di IA su WhatsApp, e la versione commerciale del caso in rispondere su WhatsApp 24 ore.
La posta non ha una piattaforma che ti sanziona, ma ha due vincoli altrettanto duri: l'identità del mittente (se l'agente risponde da un indirizzo generico, il tasso di risposta crolla; se risponde da quello di una persona, quella persona è responsabile di quello che dice) e il thread (rispondere creando un thread nuovo rompe il tracciamento di qualsiasi processo). Nessuno dei due è tecnico e tutti e due decidono se il canale serve.
La tabella di decisione: quattro domande, una superficie
La decisione si chiude in un pomeriggio con quattro domande, in quest'ordine. L'ordine conta: la prima scarta metà delle opzioni e le altre affinano.
- Chi è l'utente e cosa ha aperto quando compare questo lavoro? Dipendente dentro un sistema → quel sistema. Team che parla → Slack o Teams. Cliente che ti scrive già → il suo canale. Visitatore anonimo → chat del sito. Nessuno, perché il lavoro arriva da solo → posta.
- Quanto può aspettare senza darsi per abbandonato? Se la risposta è secondi, l'architettura deve restituire qualcosa prima di finire. Se sono ore, ti avanza budget e puoi spenderlo per verificare meglio.
- Quali permessi mi obbliga a chiedere quella superficie, e quanti di questi mi servono davvero? Se il minimo che la superficie consente è già più di quanto il caso giustifichi, è un motivo legittimo per cambiare superficie.
- Quando fallirà, dov'è scritto? Se non c'è risposta, o monti la persistenza prima di lanciare o scegli un'altra superficie.
E una regola di architettura che rende reversibile tutto quello che c'è sopra: l'agente è un servizio, il canale è uno strato sottile sopra. Se la logica — i passi, le condizioni, le chiamate ai tuoi sistemi — vive dentro il costruttore visuale del fornitore di chat, cambiare superficie non è spostare, è ricostruire. Se vive dalla tua parte, dietro un contratto di ingresso e uscita, spostare lo stesso agente dal sito a WhatsApp o da una scheda propria a Teams è lavoro di giorni. Quella condizione è ciò che trasforma la decisione di superficie in qualcosa che puoi correggere quando i dati d'uso ti contraddicono.
Noi partiamo da qui, prima che dal modello e prima che dal prompt: dove sta il lavoro, chi lo fa e cosa ha aperto in quel momento. È quello che sta sotto l'adozione IA per team — perché avere IA in azienda non è la stessa cosa che l'azienda usi IA — ed è quello che si monta con l'infrastruttura di IA aziendale quando l'agente deve vivere dentro sistemi che sono già in produzione. Il resto del montaggio — permessi, autonomia, memoria, eval — sta in creare un agente di IA che regga la produzione.