IA offline per le piattaforme di messaggistica: perché contano i modelli locali

Quasi tutte le funzioni di IA che oggi trova nel software di messaggistica sono un contratto da inquilino. Girano sui server di qualcun altro, sono contate secondo il listino di qualcun altro e funzionano soltanto finché la linea tra il Suo edificio e il loro resta in piedi. Per la maggior parte degli acquirenti è uno scambio accettabile. Per una banca che gestisce una piattaforma di messaggistica dentro una DMZ, per un ente pubblico su una rete isolata, o per un rivenditore in un mercato la cui valuta si è mossa del 30 per cento quest’anno, non è praticabile e basta. Questa guida parla di cosa succede davvero quando toglie il cloud dall’equazione: cosa sa fare onestamente un modello locale, cosa non sa fare, e il pattern di progettazione che Le permette di avere entrambe le cose senza scommettere il prodotto su nessuna delle due.

Perché l’IA in cloud non è praticabile nei deployment in DMZ e regolamentati

Ci sono tre muri distinti, e gli acquirenti ci sbattono di solito in quest’ordine.

Il muro della rete. Una piattaforma di messaggistica che termina OTP per una banca non sta sulla internet aperta. Sta in una DMZ, o più in profondità, con una policy di firewall scritta da qualcuno il cui mestiere è dire di no. Un HTTPS in uscita verso un fornitore di IA non è una casella da spuntare: è una richiesta di modifica, una revisione, una voce nel registro dei rischi e, nel caso isolato, è semplicemente impossibile, perché da quella stanza non esiste alcuna via d’uscita. Qualunque funzione che telefoni a casa è una funzione che per quel cliente non esiste. Non è un’ipotesi e non è raro: è la forma normale dei clienti più preziosi di questo settore.

Il muro dei dati. Anche dove la via d’uscita c’è, il problema è il contenuto. Una richiesta di riscrittura porta con sé il corpo del messaggio, e il corpo del messaggio è il nome di un cliente, un riferimento di conto, una password usa e getta, un sollecito di pagamento, un appuntamento medico. Mandarlo a un terzo significa rispondere a domande su accordi di trattamento, sub-responsabili, conservazione, giurisdizione e trasferimento transfrontaliero, per ogni messaggio, per sempre. Ad alcune di quelle domande esistono buone risposte. In un mercato regolamentato, “il testo non esce mai dall’edificio” è una conversazione molto più corta di tutte quante.

Il muro commerciale. Il prezzo dell’IA in cloud è una decisione presa nel consiglio di un’altra azienda. Le tariffe cambiano, i piani gratuiti chiudono, i modelli vengono ritirati secondo un calendario che non fissa Lei, e una chiave può essere revocata o limitata un martedì qualunque. Se la funzione di punta del Suo prodotto dipende da questo, ha costruito un’attività su una dipendenza che non controlla. Gli operatori dei mercati emergenti lo sentono più forte di tutti, perché un prezzo denominato in USD e un fatturato denominato in valuta locale non si muovono insieme.

Nessuno di questi muri significa che l’IA sia fuori discussione. Significano che l’IA deve poter vivere dentro il Suo edificio.

Cosa sanno fare davvero i modelli locali, e cosa no

Qui l’onestà conta più dell’entusiasmo, perché la distanza tra il marketing e la macchina è il punto in cui i progetti muoiono.

In cosa sono bravi. Un modello piccolo addestrato a seguire istruzioni, qualcosa da 3 a 8 miliardi di parametri, quantizzato e servito in locale tramite llama.cpp oppure Ollama su CPU normale, è davvero bravo nel lavoro di testo circoscritto. Riscrivere un messaggio perché suoni più cordiale, più breve o più formale. Sistemare tono e grammatica. Preparare la bozza di una traduzione che poi approva una persona. Rispondere a una domanda di assistenza partendo da un documento recuperato. Classificare l’intento per un chatbot e produrre una risposta breve, quasi da copione. Sono esattamente i compiti che servono a una piattaforma di messaggistica, e hanno tutti la stessa forma: input corto, output corto, compito stretto, una persona lì accanto.

In cosa sono scarsi. Il ragionamento lungo a più passaggi. Tenere insieme un contesto ampio e complicato. La scrittura creativa sfumata che deve andare a segno al primo colpo. Tutto ciò in cui la differenza tra una buona risposta e una eccellente vale soldi veri. Un modello di frontiera in cloud è nettamente migliore in tutto questo, e fingere il contrario non aiuta nessuno.

Il vincolo che tutti dimenticano: la velocità. Un modello locale su CPU produce all’incirca da 10 a 25 token al secondo. Una riscrittura da 200 token richiede quindi qualcosa come da 8 a 20 secondi. Per un utente che clicca “riscrivi” e aspetta, è accettabile. Per un chatbot dal vivo che risponde ai clienti sotto volume è tirato, ed è il punto in cui Lei aggiunge una GPU modesta, tiene le risposte corte, oppure manda quella singola funzione a un motore in cloud. Non c’è astuzia che trasformi una CPU in un data center.

La conseguenza pratica. Progetti i Suoi prompt contro il modello nativo, non contro quello in cloud. Il nativo è il motore più debole che Le capiterà mai di far girare, ed è proprio per questo che è il pavimento: se un prompt produce una risposta utilizzabile lì, la produrrà ovunque. Se lo mette a punto contro un modello di frontiera e poi ripiega sul nativo, quel ripiego è il momento in cui la Sua funzione La mette in imbarazzo, e succederà nell’istante peggiore. Costruisca sul pavimento e ogni miglioramento sarà un regalo.

Il pattern del motore selezionabile: nativo di default, la Sua chiave come opzione

L’errore è trattarla come una scelta binaria. Locale o cloud, ne scelga uno e ci conviva. La risposta migliore è rendere il motore un’impostazione e l’interfaccia un contratto.

Nel design dell’IA offline di Smppcube l’amministratore sceglie il motore una volta sola nelle impostazioni globali. I modelli locali nativi sono il default e sono sempre disponibili. Un provider cloud con la chiave dell’amministratore stesso è opzionale, per i deployment che vogliono più potenza e hanno una via verso internet. Tutto quello che sta a valle, riscrittura, traduzione, chatbot, journey, testi di campagna, RAG, chiama una sola interfaccia interna e non sa né gli interessa cosa ci sia dietro. Cambi l’impostazione e ogni funzione la segue nello stesso istante, senza ricablare niente.

Tre dettagli fanno funzionare tutto questo nella pratica e non solo su una slide.

Una sola forma, costruita sullo standard. L’interfaccia è costruita sul contratto chat-completions compatibile con OpenAI, che copre il server nativo e la grande maggioranza dei provider con un unico percorso di codice. Anthropic riceve un solo adattatore in più. Questa è tutta la superficie di integrazione, ed è il motivo per cui aggiungere un provider è un cambio di impostazioni e non un progetto.

Gli embedding sono un’impostazione separata. Il retrieval e la chat sono lavori diversi con economie diverse, e il modello di embedding si sceglie indipendentemente dal modello di chat. Può far girare il retrieval in locale sui Suoi documenti mentre punta la chat a un motore in cloud, o il contrario, e sostituire l’uno non tocca mai l’altro.

Il ripiego sul nativo è il pavimento di sicurezza. Le chiavi sono cifrate a riposo, oscurate nei log e limitate da un tetto di spesa rigido per motore. Quando il tetto viene raggiunto, quando il provider ha un disservizio, quando la linea cade, la piattaforma torna al nativo in automatico e la funzione continua a lavorare. Nessuno viene svegliato di notte e nessuna schermata si rompe. È questo il pezzo che rende sicura la scelta del cloud: non sta affidando al fornitore la Sua continuità di servizio, sta prendendo in prestito la sua potenza con un pavimento sotto i piedi.

E un confine che vale la pena dire ad alta voce: qui l’IA è di supporto, non autonoma. Le campagne restano approvate da una persona. Le risposte RAG portano con sé una barriera “non è nella documentazione” invece di inventare qualcosa di plausibile. Un modello offline che si inventa le cose con sicurezza è peggio di nessun modello, e la barriera conta di più quanto più il modello è piccolo.

L’unico compito che è sempre nativo: lo spam

C’è esattamente una funzione di IA che non riceve mai la scelta del motore, e il motivo è istruttivo.

Il controllo antispam gira sul percorso caldo del messaggio. Ogni singolo messaggio ci passa dentro, il che significa che il controllo deve costare praticamente nulla e non può mai aspettare un salto di rete. In Smppcube è fastText più regole, che girano in circa un decimo di millisecondo, mai un LLM. Con 3.000.000 di messaggi al mese, una chiamata cloud da 200 ms per messaggio non è un problema di costo, è un problema di fisica: il Suo throughput crolla e la Sua coda si ingorga dietro la latenza di un terzo.

La policy conta quanto il meccanismo: segnalare, non bloccare. Il filtro marca ciò che sembra spam e lascia a Lei la decisione di inviare. Un falso positivo che uccide in silenzio il traffico OTP di un cliente è un errore molto più caro di un messaggio segnalato che una persona controlla con un’occhiata. È la regola generale dell’IA su un percorso caldo, ed è il motivo per cui il classificatore veloce, noioso e offline è lo strumento giusto, e non quello che fa scena.

I conti, onestamente

Salti il “l’IA costa cara” detto a vanvera e faccia l’aritmetica, perché la risposta cambia davvero a seconda del volume.

L’uso assistito leggero costa poco in cloud. Cinquanta utenti clienti che fanno quaranta riscritture al giorno ciascuno sono circa 60.000 chiamate al mese. A mille token per chiamata fanno 60 milioni di token, che su un modello di fascia media si collocano intorno a 30 a 60 USD al mese. Chi Le dice che la sola bolletta dei token giustifica il passaggio al nativo con quel volume Le sta vendendo qualcosa. A quella scala si va sul nativo per la DMZ e per i dati, non per la fattura.

I chatbot cambiano la forma. Adesso metta un chatbot con RAG davanti al traffico in ingresso. Ventimila conversazioni al mese a sei turni ciascuna sono 120.000 chiamate, e ognuna porta con sé il contesto recuperato, diciamo 4.500 token tra input e output. Fanno circa 540 milioni di token al mese, da 200 a 400 USD a seconda del modello, ovvero da 2.400 a 4.800 USD all’anno. La parte scomoda è la direzione di marcia: quella bolletta cresce ogni volta che cresce il business, quindi il successo Le alza i costi esattamente nel trimestre in cui voleva il margine.

Il nativo non ha contatore. Il costo di una chiamata nativa è zero. Il costo del nativo è la macchina: un server esistente con un po’ di respiro, oppure circa da 40 a 80 USD al mese di capacità aggiuntiva, piatti, che faccia mille chiamate o un milione. A fronte di una licenza di piattaforma una tantum che vive già sul Suo ferro, secondo la stessa logica di affittare o possedere della guida al gateway self-hosted, la voce IA smette di essere un costo variabile e diventa parte della macchina che ha già comprato.

Il riassunto onesto: per un uso leggero vada sul nativo per la sovranità e sul cloud per la qualità, e i soldi saranno un errore di arrotondamento in entrambi i casi. Per i volumi da chatbot il nativo è nettamente più economico e, soprattutto, prevedibile. La prevedibilità è ciò che Le permette di dare a un cliente un prezzo valido per un anno intero.

Scegliere onestamente

Se il Suo deployment ha una via pulita verso internet, nessun vincolo di residenza dei dati e Lei vuole il risultato migliore possibile su una manciata di compiti ad alto valore, usi un motore in cloud con la Sua chiave. È una buona decisione e il pattern qui sopra la sostiene in pieno. Nativo per lo spam e il retrieval, cloud per la scrittura, e il ripiego sempre attivo.

Vada sul nativo per primo quando è vera una qualsiasi di queste: la Sua piattaforma vive in una DMZ o su una rete isolata; i Suoi clienti chiedono dei sub-responsabili prima di chiedere il prezzo; il Suo fatturato è in una valuta che non segue l’USD; oppure il Suo volume di IA ha la forma di un chatbot e sta crescendo. E vada sul nativo per primo, comunque, se consegna un prodotto a clienti di cui non controlla gli ambienti, perché una funzione che ha bisogno di una via verso internet è una funzione che, in silenzio, non esiste per una fetta del Suo mercato.

La cosa che vale la pena progettare non è locale contro cloud. È che la scelta appartenga a chi possiede i server, che sia un’impostazione e non una ricostruzione, e che il pavimento lì sotto tenga sempre. Stacchi il cavo e continua a pensare. Tutto il resto è una preferenza.