Quando un lettore ci ha raccontato di aver perso una bicicletta elettrica durante la consegna e di essere precipitato in un ‘inferno di chatbot’ nel tentativo di recuperarla, abbiamo colto il segnale di un malessere più profondo. Non è solo un aneddoto divertente: è il sintomo di una scelta tecnica che sta plasmando il customer service contemporaneo, spesso con risultati disastrosi.

L’azienda coinvolta non ha reso pubblico il proprio stack, ma è lecito supporre che dietro a quel chatbot frustrante ci sia un Large Language Model servito via API da uno dei grandi provider cloud. La tentazione è comprensibile: zero investimenti in hardware, aggiornamenti automatici, integrazione con una riga di codice. Peccato che il conto arrivi dopo, sotto forma di clienti insoddisfatti e conversazioni che girano a vuoto.

Perché i chatbot basati su LLM generici falliscono così spesso quando devono gestire un problema concreto? Il motivo è duplice. Primo, manca un collegamento reale con i sistemi interni dell’azienda: magazzino, logistica, database dei clienti. Il bot può solo scusarsi e ripetere frasi di circostanza, perché non ha accesso ai dati che gli servirebbero per capire dove sia finita la bici. Secondo, questi modelli sono addestrati per chiacchierare, non per risolvere: senza un fine-tuning specifico sull’operatività dell’azienda, restano in superficie.

Qui entra in gioco la sovranità dei dati e il controllo effettivo che un’impresa può esercitare sulla propria AI. Quando si delega tutto a un servizio cloud di terze parti, si rinuncia a gran parte della capacità di personalizzare il comportamento del modello e, soprattutto, a integrare profondamente l’agente conversazionale con l’infrastruttura aziendale. Un modello servito on-premise, per quanto più costoso da gestire, può accedere direttamente ai database interni, rispettare vincoli GDPR senza intermediari e persino essere sottoposto a fine-tuning periodico sulla base dei nuovi casi di assistenza. Non è una soluzione magica, ma restituisce all’azienda la leva per costruire un’esperienza coerente.

Certo, schierare un LLM in locale non è indolore. Richiede GPU con VRAM sufficiente per eseguire modelli di dimensioni adeguate, competenze per orchestrare il serving e un investimento iniziale non trascurabile. Ma il Total Cost of Ownership va messo a confronto con il costo dei clienti persi e del supporto umano aggiuntivo che deve intervenire quando il chatbot incespica. Chi si affida esclusivamente alle API cloud magari risparmia sul CapEx, ma paga con una rigidità che alla lunga si traduce in danno reputazionale.

Non è una questione di ‘cloud cattivo, on-prem buono’. È un problema di incentivi: le piattaforme cloud guadagnano quanto più il cliente standardizza sui loro servizi facili e non esce dall’ecosistema. Le aziende che vogliono differenziarsi davvero nel servizio clienti devono accettare un grado maggiore di complessità tecnica e, spesso, una scelta architetturale più vicina ai propri dati. L’episodio della bici elettrica smarrita è il campanello d’allarme che ricorda quanto sia facile costruire chatbot che sanno parlare ma non sanno ascoltare—perché ascoltare davvero significa avere accesso alla realtà operativa, non solo a un prompt ben scritto.

Per chi sta valutando un deployment on-premise, AI-RADAR offre framework analitici per soppesare i trade-off tra TCO, latenza e controllo dei dati. Ma al di là delle tabelle comparative, resta un principio semplice: se un’azienda non è disposta a investire nell’integrazione e nella personalizzazione della propria AI, i suoi clienti continueranno a trovare porte chiuse, mascherate da chatbot sorridenti.