Assistenti AI su Misura per PMI: Chatbot WhatsApp, CRM e Obblighi 2026

Il pattern che vediamo più spesso è l'inverso di quello giusto: si sceglie prima la tecnologia, di solito il modello più pubblicizzato del momento, poi si cerca un compito da assegnarle. Il risultato è un bot che sa rispondere a domande generiche sul settore, ma non conosce il listino aggiornato, non sa se un ordine è già partito, e non passa la conversazione a una persona finché il cliente non scrive "operatore" tre volte. Un chatbot che risponde in modo fluente non dimostra da solo di aver risolto il problema del cliente, e non dimostra nemmeno che il sistema sia conforme alla normativa che lo riguarda.

Fino al 2025 la conformità normativa era quasi sempre un argomento da progetto enterprise, qualcosa che una PMI rimandava a "quando saremo più grandi". Dal 2 agosto 2026 questo non è più vero per un caso specifico e molto comune: un chatbot che risponde direttamente a un cliente. Il regolamento europeo sull'intelligenza artificiale, all'articolo 50, stabilisce che i fornitori devono garantire che «AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system», salvo i casi in cui questo sia già ovvio dal contesto per una persona ragionevolmente informata. Le sanzioni non sono simboliche: fino a 15 milioni di euro o al 3% del fatturato globale annuo, a seconda di quale importo sia più alto.

Per una PMI che sta valutando un fornitore, la domanda pratica cambia: non basta più chiedere "il bot risponde bene", serve chiedere "dove e come dichiara di essere un'AI". La maggior parte dei preventivi che circolano non menziona questo punto, perché parla di tecnologia e non di conformità. È un errore che si paga dopo il lancio, non prima.

Un chatbot su WhatsApp basta da solo, o serve un CRM dietro?

Da solo, no. Un chatbot che risponde bene ma dimentica ogni conversazione al messaggio successivo produce lo stesso problema che vuole risolvere: il cliente deve ripetere tutto. Senza un collegamento al CRM, ogni scambio resta isolato in un log che nessuno rilegge finché non serve per un reclamo, ed è già troppo tardi per intervenire prima. La conversazione WhatsApp deve diventare un evento leggibile nella scheda del cliente: chi ha scritto, cosa ha chiesto, cosa ha ricevuto, se è stato passato a una persona. Senza questo collegamento, l'automazione riduce il lavoro di battitura ma non aumenta la qualità del servizio, che è quello che il cliente percepisce davvero.

Dove si nasconde il rischio quando il bot legge messaggi esterni

Un assistente collegato a WhatsApp riceve testo scritto da chiunque scriva a quel numero, incluso testo pensato per manipolare il comportamento del modello. OWASP descrive il rischio in modo diretto: «Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files», nel riferimento OWASP sulla prompt injection. Un messaggio WhatsApp è a tutti gli effetti un input esterno: un cliente, o chiunque scriva a quel numero, può provare a far dire al bot cose che non dovrebbe dire, o a fargli eseguire azioni non autorizzate se il bot ha accesso a strumenti che modificano dati.

La conseguenza pratica non è rinunciare all'automazione, ma separare con cura cosa il bot può fare da solo (rispondere, consultare la knowledge base, proporre una bozza) da cosa richiede un'autorizzazione esplicita (modificare un ordine, autorizzare un rimborso, cambiare un contatto). Anche l'accesso tecnico va limitato: la OWASP Secrets Management Cheat Sheet è netta sul punto, «Engineers should not have access to all secrets in the secrets management system, and the Least Privilege principle should be applied», e lo stesso principio vale per i token che collegano il bot a WhatsApp e al CRM: non li condividi via chat, non li dai a chi non ne ha bisogno per il proprio ruolo.

L'architettura che proponiamo separa nettamente il canale di comunicazione, la fonte di conoscenza, la logica che decide se rispondere o passare la mano, e il punto in cui il sistema si dichiara. È uno schema da adattare al processo reale, non l'affermazione che ogni progetto Skalo implementi identici componenti: il perimetro cambia in base a cosa il cliente vuole automatizzare davvero.

Il canale: la Cloud API di WhatsApp e il pricing per messaggio

Per collegare un chatbot a WhatsApp servono un business portfolio, un WhatsApp Business Account (WABA) e un numero di telefono business, come documentato nella panoramica Cloud API di Meta for Developers: «Business phone numbers, real or virtual, are used for sending and receiving WhatsApp messages». Non è la stessa cosa di un numero WhatsApp personale con automazioni artigianali: la Cloud API funziona via richieste HTTP autenticate, riceve gli eventi tramite webhook, e ogni messaggio resta protetto dal protocollo di cifratura di Signal.

La piattaforma impone limiti tecnici precisi che vanno progettati, non scoperti in produzione: di default un numero business può inviare fino a 80 messaggi al secondo, con un tetto per singolo utente di un messaggio ogni 6 secondi verso lo stesso contatto, per evitare comportamenti simili a spam. Per una PMI questo significa che il sistema deve mettere in coda i messaggi in uscita, non semplicemente sparare una risposta per ogni evento ricevuto: un picco di richieste, una promozione o un disservizio, può facilmente superare la soglia se non è previsto un accodamento.

Il punto che è cambiato negli ultimi due anni riguarda il costo, non solo il limite tecnico. Dal 1° luglio 2025 Meta è passata da un modello di prezzo per conversazione a un modello di prezzo per messaggio, con categorie distinte: marketing, utility, autenticazione e servizio. I messaggi di servizio, quelli generati dal bot per rispondere entro la finestra aperta dal cliente, sono gratuiti dal novembre 2024 e restano tali secondo la documentazione ufficiale alla data di questa guida. Ma la storia recente del pricing WhatsApp mostra revisioni periodiche per mercato (rate aggiornate su singoli paesi anche più volte l'anno): per una PMI che dimensiona un preventivo, la mossa corretta non è fidarsi di un numero letto un anno fa, ma ricontrollare la pagina prezzi ufficiale di Meta prima di firmare, ed è quello che facciamo prima di ogni preventivo.

Webhook e finestra di servizio: cosa resta gratis oggi, e cosa va ricontrollato

I messaggi in arrivo, gli aggiornamenti di stato e le modifiche all'account arrivano al sistema tramite webhook: come specifica la guida Meta ai webhook della Cloud API, «Webhooks are HTTP requests containing JSON payloads that Meta's servers send to a server of your designation». Il server che riceve questi payload è un componente da progettare e mantenere: un endpoint che non risponde, o risponde in ritardo, può far perdere l'evento di un messaggio in arrivo, con l'effetto pratico di un cliente che scrive e non riceve mai una risposta.

Il vincolo che continua a valere è la finestra di servizio. Quando un cliente scrive per primo, si apre una finestra di 24 ore, e in quel periodo i messaggi liberi restano possibili secondo la documentazione Meta sui prezzi WhatsApp. Scaduta la finestra, per riaprire la conversazione serve un template approvato in anticipo da Meta. I messaggi di servizio dentro quella finestra restano gratuiti secondo la documentazione ufficiale alla data di questa guida: non diamo per scontato che lo restino per sempre, perché Meta ha già cambiato una volta l'intero modello di fatturazione (da conversazione a messaggio, luglio 2025) e aggiorna le tariffe per mercato con un preavviso limitato. Un assistente ben progettato tiene traccia di quando si è aperta la finestra per ogni cliente e del volume di messaggi generati, così il preventivo si può ricalcolare in fretta se la pagina prezzi ufficiale cambia.

Bot a regole vs assistente generativo controllato: la differenza che conta

Un bot a regole risponde solo a ciò che è stato previsto: bottoni, parole chiave, percorsi fissi. È prevedibile e facile da collaudare, ma ogni caso nuovo richiede una modifica manuale, e un cliente che scrive in modo naturale ("il pacco non è ancora arrivato, sono tre giorni che aspetto e nessuno mi risponde") spesso non trova la strada giusta nell'albero di risposte.

Un assistente generativo controllato usa un modello linguistico per interpretare il messaggio libero, ma non gli lascia campo aperto: consulta prima la base di conoscenza dell'azienda, genera una risposta vincolata a quel contesto, la confronta con una soglia di confidenza prima di inviarla, e dichiara la propria natura automatizzata nel primo scambio utile. La differenza non è "quale tecnologia è più avanzata", ma quale compito stai automatizzando: un menu di opzioni fisse (orari, indirizzo, stato spedizione con numero d'ordine) può restare a regole senza perdere nulla; un'interazione che richiede di capire il tono e il contenuto reale di un messaggio libero ha bisogno del secondo approccio. La maggior parte dei progetti seri unisce entrambi: regole per i casi semplici e frequenti, generazione controllata per il resto.

Conviene sempre l'AI generativa, o a volte basta un flusso a regole?

No, e chi lo sostiene sta vendendo tecnologia, non un sistema. Quando la maggior parte delle richieste di un servizio clienti riguarda orari, indirizzo o stato di una spedizione con numero d'ordine, quelle richieste si gestiscono bene con regole semplici e un collegamento diretto al gestionale, senza generazione di testo. L'AI generativa aggiunge valore dove il messaggio è libero e imprevedibile: un reclamo articolato, una domanda su un prodotto non ancora in catalogo, una richiesta che mescola più argomenti. Va scelta per il compito, non applicata di default a ogni scambio solo perché è la tecnologia del momento, e va scelta sapendo che comporta comunque l'obbligo di dichiararsi come AI quando genera testo rivolto direttamente al cliente.

Dove va mostrata la dichiarazione che è un'intelligenza artificiale?

L'articolo 50 impone il risultato (l'utente deve sapere che sta parlando con un'AI), non un formato unico per raggiungerlo. Nella pratica, il punto più semplice da progettare è il primo messaggio della conversazione o il messaggio di apertura della finestra di servizio: una riga che identifica l'assistente come automatizzato, prima che il modello risponda al contenuto della richiesta. L'eccezione prevista dalla norma riguarda i casi in cui la natura artificiale è già ovvia dal contesto per una persona ragionevolmente attenta: un caso limite che, per un servizio clienti su WhatsApp collegato a un normale numero business, difficilmente si applica senza una dichiarazione esplicita. Non è un problema che si risolve con una frase generica in fondo alla pagina del sito: va progettato nel flusso conversazionale, perché è lì che l'utente interagisce davvero.

Schema dell'architettura proposta

Il diagramma distingue il flusso ordinario dai casi che richiedono un template WhatsApp, una dichiarazione esplicita di apertura o un intervento umano. I nomi dei sistemi possono cambiare in base a cosa già usa l'azienda; devono restare chiari i confini tra recupero di conoscenza, generazione della risposta e verifica della confidenza prima dell'invio.

Il metodo che usiamo parte da un campione di conversazioni reali, non da una lista di funzionalità. Il risultato della prima fase può anche essere "non serve un modello generativo, bastano tre regole": è una conclusione legittima, non un fallimento del progetto.

Fase 1: raccogliere conversazioni reali, non immaginare casi d'uso

Prendi le ultime settimane di messaggi ricevuti dal servizio clienti (email, WhatsApp esistente, chat del sito) e classificali per intento: informazioni, stato ordine, reclamo, richiesta commerciale, altro. È lo stesso principio richiamato da Building effective agents: partire dal compito reale, non dalla tecnologia disponibile. Conta quante richieste sono davvero ripetitive e prevedibili, e quante richiedono di leggere il contesto specifico del cliente. Questo campione, non l'entusiasmo per la tecnologia, decide quanto del lavoro può passare a un flusso a regole e quanto ha bisogno di un modello che interpreta testo libero.

Fase 2: costruire la base di conoscenza e il prompt

Raccogli le fonti che il modello deve consultare: catalogo, policy di reso, FAQ interne, orari, procedure di escalation. Il prompt deve indicare esplicitamente cosa il modello può e non può affermare, e cosa fare quando l'informazione richiesta non è nella base di conoscenza: la risposta corretta è spesso "non lo so con certezza, ti metto in contatto con una persona", non un tentativo di indovinare. Vale anche quando la risposta rispetta un formato controllato: rispettare uno schema tecnico non equivale a dire la verità sull'ordine di un cliente, perché un campo compilato nel formato giusto può comunque contenere un valore sbagliato se la conoscenza da cui è stato generato era incompleta o ambigua.

Fase 3: collegare la Cloud API e verificare il pricing aggiornato

Configura il WABA, il numero business e i webhook per ricevere i messaggi. Prepara in anticipo i template per i casi in cui la finestra di 24 ore si chiude prima che la pratica sia risolta: un promemoria, un aggiornamento sullo stato di un reclamo, un follow-up commerciale. Ricorda che i template richiedono approvazione preventiva da parte di Meta e che, come indicato nella documentazione Cloud API, «You must obtain user opt-in before sending message templates»: non puoi scrivere per primo a un numero che non ha mai contattato l'azienda senza un consenso esplicito raccolto altrove (sito, modulo, altro canale). Da qui in avanti, ricontrolla la pagina prezzi ufficiale di Meta prima di chiudere il preventivo: il modello per messaggio introdotto nel 2025 aggiorna le tariffe per mercato più spesso di quanto una PMI sia abituata a monitorare.

Fase 4: progettare la dichiarazione AI Act nel flusso conversazionale

Decidi in quale punto esatto della conversazione compare la dichiarazione che il cliente sta parlando con un sistema automatizzato, coerentemente con l'obbligo in vigore dal 2 agosto 2026. Il punto più semplice, e più difendibile in caso di controllo, è il primo messaggio utile della conversazione o l'apertura di ogni nuova finestra di servizio. Questa fase non è consulenza legale, che resta compito di un legale, ma è una decisione tecnica che cambia il prompt e il flusso: un sistema che deve dichiararsi ha bisogno di un messaggio dedicato, non di una frase aggiunta a posteriori nel footer del sito.

Fase 5: sincronizzare col CRM e definire l'escalation

Ogni conversazione deve produrre un evento leggibile nella scheda del cliente: contenuto, esito, se è stata gestita dal bot o passata a una persona. Definisci la soglia di confidenza sotto la quale il bot smette di rispondere e mette in coda la conversazione, con il contesto già preparato per chi la riprende in mano. Una coda senza contesto costringe l'operatore a ripartire da zero, vanificando il vantaggio dell'automazione proprio nei casi più delicati.

Ogni conversazione sincronizzata nel CRM contiene dati personali del cliente, e questo richiede scelte esplicite su cosa salvare. La guida EDPB alle basi della protezione dei dati è chiara sul principio di limitazione della finalità, «Your organisation can only collect personal data for specified, explicit and legitimate purposes», e su quello di minimizzazione, «Your organisation can only process personal data that is necessary and proportionate in light of the purpose envisaged». In pratica, la scheda cliente dovrebbe conservare il contenuto utile a gestire la richiesta, non l'intero scambio con ogni dettaglio personale emerso di passaggio nella conversazione.

Fase 6: collaudare i casi limite prima del traffico reale

Prova un messaggio ambiguo, un tentativo di manipolare le istruzioni del bot, una richiesta fuori perimetro (una domanda legale, una minaccia, una richiesta di sconto non autorizzato), e un cliente che scrive fuori dalla finestra di 24 ore. Verifica che la dichiarazione AI Act compaia davvero al momento giusto, non solo nel prompt di test. Verifica anche cosa succede se il CRM non risponde: la conversazione deve restare accessibile, non perdersi. Solo dopo questo collaudo ha senso collegare il numero business definitivo al traffico reale del servizio clienti.

Quanto tempo serve per lanciare un assistente AI collegato a WhatsApp e CRM?

Dipende dal perimetro, non da una cifra standard: un bot che copre solo informazioni statiche (orari, indirizzo, stato ordine con numero) richiede molto meno lavoro di un assistente che gestisce reclami articolati con escalation al CRM. La parte spesso sottostimata non è il collegamento tecnico alla Cloud API, che è documentato e stabile, ma la costruzione e il collaudo della base di conoscenza: un catalogo disordinato o una policy di reso scritta in modo ambiguo rallentano il progetto più di qualunque integrazione software. Anche la fase di dichiarazione AI Act, se progettata da subito e non aggiunta a fine progetto, non allunga sensibilmente i tempi.

Questi due progetti documentano capacità concrete di gestione di conversazioni e dati commerciali. Li presentiamo per ciò che è verificabile nel portfolio pubblico Skalo alla data di questa revisione, distinguendo cosa è descritto come capacità dimostrata da cosa è architettura consigliata qui sopra, inclusa la dichiarazione AI Act e la verifica del pricing WhatsApp, che restano principi generali da applicare caso per caso sul progetto specifico.

Skalo AI Hub: dashboard, prompt universale e knowledge base multi-tenant

L'AI Hub Intelligent Chatbot nel portfolio nasce da un problema che conosciamo bene: un chatbot generico può rispondere male e creare sfiducia, e serve controllo su conoscenza, tono, prompt e casi d'uso. La risposta è una piattaforma SaaS multi-tenant con dashboard amministrativa, gestione clienti, gestione del prompt, simulatori per testare le risposte prima della pubblicazione e integrazioni operative, con l'obiettivo di offrire assistenti AI più affidabili, configurabili e integrabili nei processi del cliente.

La capacità multi-tenant è il punto utile da trasferire a una PMI che valuta un fornitore: significa che ogni cliente ha il proprio prompt, la propria conoscenza e la propria configurazione, senza che una modifica per un cliente influenzi gli altri. Il portfolio elenca tra le capacità dimostrate anche una gestione WhatsApp: non deduciamo da questa voce che ogni implementazione includa già, per ogni cliente, tutti i dettagli di gestione della finestra di servizio, del nuovo costo dei messaggi e della dichiarazione AI Act descritti sopra; quella parte resta architettura consigliata basata sulla documentazione ufficiale di Meta e sul testo del regolamento, da verificare caso per caso sul progetto specifico.

L'osservazione di prima mano che portiamo da questo progetto è concreta: il valore non sta nel modello linguistico scelto, che cambia nel tempo, ma nella capacità di correggere prompt e conoscenza senza toccare il codice, e di simulare una conversazione prima che la veda un cliente vero. È il controllo, non la fluidità del testo generato, il fattore che decide se un'azienda si fida di lasciare un assistente a rispondere da solo, ed è anche il fattore che rende più semplice inserire un punto di dichiarazione quando la normativa lo richiede.

Call Recorder & Quality Analyzer: quando il canale non è il testo ma la voce

Il Call Recorder & Quality Analyzer nel portfolio affronta un problema diverso ma collegato: dopo una chiamata si perdono dettagli, obiezioni, segnali e prossimi passi, e annotare tutto manualmente è fragile. La soluzione è un'app desktop che registra, trascrive e analizza le chiamate commerciali, sincronizzando i dati con il CRM, con l'obiettivo dichiarato che le chiamate diventino dati consultabili: meno dimenticanze, script migliori e follow-up più precisi.

Il punto che vale anche per un assistente su WhatsApp è lo stesso: un'interazione con un cliente, testuale o vocale, ha valore solo se diventa un dato collegato alla scheda del cliente nel CRM, non un file isolato che nessuno riascolta. Un chatbot che risponde bene ma non lascia traccia nel CRM ha lo stesso limite di una chiamata registrata ma mai trascritta: il lavoro tecnico è fatto, ma non arriva a chi deve usarlo per il passaggio successivo.

Non deduciamo dal portfolio percentuali di riduzione del tempo di gestione o incrementi di conversione: sono misure che vanno verificate sul processo specifico di ogni azienda, non promesse a priori. Quello che il portfolio documenta è la capacità tecnica di collegare canale, trascrizione o generazione di risposta, e CRM in un unico flusso.