Sono le sei di sera, il rilascio è previsto per domani mattina e c’è un errore che non si riesce a chiudere. Uno dei tuoi ragazzi copia il log, lo incolla nel chatbot e chiede aiuto.
Dentro quel log ci sono le query, i nomi delle tabelle, la struttura di un database e tre indirizzi email di utenti reali. Il database, tra l’altro, non è vostro: è del cliente. Trenta secondi dopo arriva la risposta, l’errore si risolve e si va a casa.
Nessuno ha fatto niente di male, ed è proprio questo che rende la faccenda seria. Non stiamo parlando di una leggerezza o di un comportamento sbagliato, ma di un gesto normale che persone competenti ripetono decine di volte al giorno solo per lavorare meglio.
Ora prova a immaginare la stessa scena moltiplicata per tutte le persone della tua azienda, e poi ancora per tutti i clienti di cui gestisci l’infrastruttura.
Se l’intelligenza artificiale è ormai entrata nei processi di chiunque, la domanda che conta non è più se usarla, ma dove gira il modello a cui stai affidando il lavoro tuo e quello dei tuoi clienti. Da quella scelta discende praticamente tutto il resto: che cosa esce dall’azienda, chi risponde quando qualcosa va storto e quanto ti ritrovi in fattura alla fine dell’anno.
Che cosa affidi davvero a un modello pubblico
Quando usi un’intelligenza artificiale attraverso le API pubbliche, tutto quello che le passi viene elaborato altrove. Il modello non gira sui tuoi server, quindi per farlo lavorare devi mandargli i dati. È una banalità tecnica, ma le conseguenze non lo sono affatto, perché l’elenco di ciò che finisce fuori dall’azienda è quasi sempre più lungo di quanto si immagini.
Ci sono anzitutto i dati personali: nomi, indirizzi email, numeri di telefono, contenuti dei ticket, testi di contratti. Materiale protetto dal GDPR che, nella maggior parte dei servizi più diffusi, viene elaborato su infrastrutture statunitensi.
Poi c’è il tuo know-how, che è la parte a cui nessuno pensa mai. Il codice, le architetture, i preventivi, il modo in cui affronti i problemi: tutto quello che i tuoi clienti pagano quando scelgono te invece di un altro. Lo stai mandando fuori a pezzi, una richiesta alla volta.
Ci sono infine i dati dei tuoi clienti, e qui il discorso cambia di peso. Se lavori come System Integrator, come software house o come agenzia, le informazioni che tratti spesso non sono nemmeno tue: appartengono a qualcuno che si è fidato di te. Davanti a quel cliente il responsabile del trattamento sei tu, non il fornitore del modello, e questa è una differenza che si sente tutta nel momento in cui qualcosa va storto.
Resta la questione del riuso per l’addestramento, che dipende dal piano sottoscritto e dalle impostazioni attive. Il che significa due cose: che va verificata contratto alla mano, e che nel tempo può cambiare senza che nessuno se ne accorga.
C’è poi una domanda che quasi nessuno si fa, ma che un cliente strutturato prima o poi ti porrà: chi sono i fornitori del tuo fornitore? Quel dato, una volta uscito, attraversa una catena di soggetti che non hai scelto e che non sei nelle condizioni di verificare.
Sia chiaro che non stiamo dicendo di rinunciare all’intelligenza artificiale, sarebbe una sciocchezza e per certi lavori ormai è impensabile. Stiamo dicendo che vale la pena sapere che cosa esce e decidere prima, con calma, che cosa può uscire e che cosa no.
Il datacenter europeo non basta, e con l’AI c’è un problema in più
Della questione ci siamo già occupati nell’articolo sulla sovranità digitale europea, e vale la pena richiamarla qui: avere il datacenter in Europa, da solo, non protegge nessuno. Se il fornitore è soggetto alla giurisdizione statunitense, il Cloud Act consente alle autorità americane di accedere ai dati che detiene, ovunque questi si trovino fisicamente, e spesso senza che il fornitore possa nemmeno avvisarti.
Vale per il cloud in generale, ma con l’intelligenza artificiale il peso è diverso, perché qui non stai spostando degli archivi: stai mandando fuori la sostanza del lavoro quotidiano, in chiaro, migliaia di volte al giorno.
E c’è una fragilità tipica dei modelli, che nel cloud tradizionale semplicemente non esiste. Il modello che usi oggi può cambiare mentre lo stai usando. Una versione viene dismessa, una policy viene aggiornata, il comportamento a parità di richiesta si sposta di qualche grado. Il processo che avevi tarato con cura comincia a rispondere in modo diverso senza che tu abbia toccato una riga di codice, e se quel processo è dentro un servizio che vendi a un cliente, con uno SLA firmato sotto, il problema diventa tuo il lunedì mattina.
Tradotta in pratica, la sovranità è tutta qui: poter dire dove sono i tuoi dati, chi può accedervi e chi decide quando le cose cambiano. Non è uno slogan da convegno, è una scelta di architettura, e la si fa nel momento esatto in cui si decide dove far girare il modello.
E poi arriva la fattura
Sui costi quasi tutti si fanno sorprendere, e non perché non li abbiano guardati, ma perché li hanno guardati nel momento sbagliato.
Il consumo a token è una formula geniale all’inizio: non compri nulla, non installi nulla, paghi quello che usi. Per un progetto pilota è la scelta giusta e non c’è molto da discutere. Le complicazioni arrivano dopo, e riguardano la forma di quel costo più che il suo importo.
Facciamo un esempio fittizio, giusto per capirci.
La Bottega del Codice è una software house con sette persone. Per un cliente hanno costruito un assistente che legge i ticket in arrivo, li classifica e prepara la bozza di risposta. Funziona bene. Il primo anno la spesa per il modello si aggira sulle poche centinaia di euro al mese, e nessuno in amministrazione si ferma a guardare quella voce.
Poi il cliente è soddisfatto e decide di allargare: il servizio passa da quattro reparti a tutta l’azienda, i volumi si moltiplicano per otto e qualcuno aggiunge anche il riassunto automatico degli allegati, che di token ne consuma parecchi. Nel giro di pochi mesi la spesa mensile arriva a qualche migliaio di euro.
Il guaio è che il contratto con il cliente è a canone fisso, come è normale che sia quando vendi un servizio. Così succede la cosa peggiore che possa capitare a chi lavora su progetti: più il servizio funziona, meno margine resta. E su quel costo non hai nessuna voce in capitolo, perché il listino lo scrive qualcun altro.
I numeri dell’esempio sono inventati, l’ordine di grandezza molto meno. Se vuoi, prova a rifare il conto con i tuoi.
Quando invece il modello gira su risorse dedicate, il costo è fisso, si può mettere a budget e, superata una certa soglia di volume, diventa semplicemente più basso. Esiste un punto di pareggio tra le due formule, e nella maggior parte dei casi è molto più vicino di quanto le aziende immaginino.
Le tre strade possibili
Se mettiamo le opzioni una accanto all’altra, oggi le strade sono tre.
La prima sono le API pubbliche. Il modello appartiene a qualcun altro e gira a casa sua. Parti in un pomeriggio, hai sempre l’ultima versione disponibile e paghi in base a quanto consumi. In cambio i dati escono dall’azienda e il controllo non è nelle tue mani.
La seconda è comprarsi il ferro e tenerlo in sala macchine. Un modello a pesi aperti, che sia Llama, Mistral, Qwen o un altro, che gira su hardware tuo. Il controllo è totale e i dati non si spostano di un metro. In compenso le schede grafiche costano parecchio, vanno alimentate, raffreddate e aggiornate, e serve qualcuno in azienda che se ne occupi stabilmente, non nei ritagli di tempo. Per una struttura piccola l’investimento è quasi sempre sproporzionato, con il rischio concreto di ritrovarsi tra due anni con hardware invecchiato male.
La terza è il modello privato su infrastruttura dedicata, che è la via di mezzo e oggi ha senso per la maggior parte delle aziende strutturate e dei partner IT. Il modello lo scegli tu e resta tuo, ma gira su macchine virtuali con GPU dedicate ospitate in un datacenter europeo, dentro uno spazio che non condividi con nessuno. I dati restano in un luogo che puoi documentare a un cliente e a un revisore, non compri hardware, non lo gestisci, e la spesa è a canone.
| API pubbliche | Ferro in casa | Modello privato su infrastruttura dedicata | |
|---|---|---|---|
| Dove stanno i dati | Fuori, spesso fuori dall’UE | Da te | In UE, su risorse dedicate |
| Cosa rispondi al cliente | Poco, e senza prove | Tutto, con il controllo pieno | Tutto, con la filiera documentabile |
| Investimento iniziale | Nessuno | Alto, tra GPU e contorno | Basso |
| Andamento della spesa | Variabile, cresce con l’uso | Fissa, con l’hardware da ammortizzare | Fissa e prevedibile |
| Tempi per partire | Poche ore | Settimane o mesi | Qualche giorno |
| Chi se ne occupa | Nessuno | Il tuo team, stabilmente | Il fornitore per l’infrastruttura, tu per il modello |
| Quando conviene | Prototipi e dati non sensibili | Vincoli fortissimi e struttura per reggerlo | Dati sensibili, volumi stabili, clienti che chiedono garanzie |
Come funziona, in pratica, un modello privato
Detta così sembra una faccenda da grandi aziende, e invece oggi è molto più semplice di quanto ci si aspetti. Vale la pena vedere che cosa significa davvero, perché è la parte che quasi nessuno racconta.
Il modello lo scegli tu tra quelli a pesi aperti, cioè quelli che si possono scaricare e far girare dove vuoi: Llama, Mistral, Qwen e diversi altri. Non sono ripieghi. Sulle cose che servono in azienda tutti i giorni (classificare, riassumere, tirare fuori informazioni dai documenti, preparare bozze di risposta) fanno un lavoro paragonabile a quello dei modelli più blasonati, e la distanza si accorcia a ogni versione.
Quel modello gira su macchine virtuali con GPU dedicate, ospitate in un datacenter europeo, dentro uno spazio che non condividi con nessuno. Non compri schede grafiche, non le monti e non le raffreddi: le usi.
La cosa che sorprende di più è quanto poco cambia per chi sviluppa. Le interfacce di questi sistemi sono quasi sempre compatibili con quelle dei servizi pubblici più diffusi, quindi nella pratica cambia l’indirizzo a cui l’applicazione manda le richieste. Il codice che avevi scritto resta in gran parte quello.
Poi c’è il punto che di solito convince anche i più scettici: puoi collegargli i documenti aziendali senza che escano di casa. Manuali, contratti, ticket storici, procedure interne. Il modello li consulta per rispondere, ma restano sui tuoi dischi, dentro il tuo perimetro. È esattamente la cosa che con un servizio pubblico non ti sogneresti di fare.
Ci sono altri due vantaggi, e si apprezzano col tempo.
Il primo è che il modello non cambia sotto i piedi. Resta la versione che hai scelto finché sei tu a decidere di aggiornarla. Il processo che hai tarato continua a rispondere come si è sempre comportato, e se hai firmato uno SLA con un cliente questa è una tranquillità che vale parecchio.
Il secondo è che il conto è sempre lo stesso. Non paghi a richiesta, paghi le risorse. Puoi interrogarlo dieci volte al giorno o diecimila: a fine mese la cifra è quella che avevi messo a budget. Quando un progetto cresce, questa smette di essere una comodità e diventa la differenza tra guadagnarci e rimetterci.
Detto questo, un modello privato non si accende come un server qualsiasi: va dimensionato sul lavoro che deve fare e incastrato con l’infrastruttura che hai già. Sono decisioni che conviene prendere in fase di progetto, insieme a chi queste macchine le dimensiona di mestiere, invece che a cose fatte.
L’intelligenza artificiale non vive da sola
C’è un aspetto che quasi tutti scoprono troppo tardi, e non riguarda il modello ma tutto quello che gli sta intorno.
Un carico di lavoro basato sull’AI non si comporta come un’applicazione qualunque. Occupa memoria a blocchi grossi, legge e scrive in modo irregolare e, quando arriva una richiesta pesante, si prende tutte le risorse che trova disponibili. Se lo accendi sulla stessa infrastruttura dove girano il gestionale, l’e-commerce e i database dei clienti, prima o poi questi carichi cominciano a darsi fastidio a vicenda.
Di solito succede sempre nello stesso ordine. Il modello lavora bene per settimane, poi capita la giornata di volumi alti in cui l’indicizzazione dei documenti parte insieme al picco degli ordini, e improvvisamente è il gestionale a rallentare. Nessuno collega le due cose, anche perché l’intelligenza artificiale, dal suo punto di vista, sta funzionando benissimo.
Quasi mai il collo di bottiglia è la GPU. Molto più spesso è il disco che non regge quel tipo di lettura, la banda che si satura mentre passano anche i backup, la finestra di manutenzione che si sovrappone al momento sbagliato, lo spazio occupato dai documenti indicizzati che cresce senza che nessuno lo avesse messo a piano.
Sono le stesse domande che ti faresti per qualunque altro sistema importante, e il fatto che sotto ci sia un modello non le cancella, semmai le rende più urgenti, perché questi carichi sono i più irregolari che ti capiterà di gestire. Meglio farsele in fase di progetto che a picco in corso: quanta memoria richiede davvero il modello che hai in mente, dove appoggia i documenti che indicizza, che cosa succede quando dieci persone lo interrogano nello stesso momento e, soprattutto, che cosa deve rallentare per primo se le risorse iniziano a scarseggiare.
Non è una decisione da prendere una volta sola
L’errore più diffuso è affrontare la faccenda come una scelta unica e definitiva, quando invece la risposta ragionevole quasi sempre sta nel mezzo.
Il criterio utile è classificare i dati, non i progetti, e per farlo bastano tre livelli.
Ci sono i dati che possono uscire tranquillamente: materiale già pubblico, testi di marketing, codice di esempio, documentazione online. Qui le API pubbliche vanno benissimo, sono comode e sono la scelta giusta.
Ci sono i dati che non devono lasciare l’Unione Europea: informazioni personali di clienti e dipendenti, contenuti dei ticket, documenti contrattuali. Qui serve uno spazio di cui tu possa documentare i confini.
E ci sono infine i dati che non devono uscire di casa: il codice sorgente dei prodotti, i dati sanitari o finanziari dei clienti, tutto ciò che, finendo altrove, ti farebbe perdere un contratto o ti porterebbe in tribunale.
Nella pratica la soluzione più sensata è tenere aperte due strade insieme: le API pubbliche per quello che non scotta e un modello tuo su infrastruttura dedicata per quello che scotta. Costa meno di quanto sembri e toglie di mezzo la parte più scomoda, cioè dover sperare che nessuno, un martedì sera qualsiasi, incolli la cosa sbagliata nel posto sbagliato.
Le domande da farsi oggi
Sono sei domande e portano via dieci minuti. Se anche a una sola non sai rispondere, sai già da dove cominciare.
- Sai quali dati passano oggi dalla tua azienda a un modello esterno?
- Sai in quale Paese vengono elaborati?
- Il contratto che hai firmato esclude il riuso per l’addestramento?
- Se un cliente ti chiedesse per iscritto dove finiscono i suoi dati, sapresti rispondere senza doverlo andare a cercare?
- Di quanto è cresciuta la spesa per l’AI negli ultimi dodici mesi, e con che ritmo sta crescendo?
- Se il tuo fornitore raddoppiasse il listino o dismettesse il modello che usi, quanto ti costerebbe cambiare?
L’ultima è la più fastidiosa, ed è anche quella che quasi nessuno si fa quando sarebbe il momento di farsela.
Cosa tenere a mente
Un modello di intelligenza artificiale non è un software che compri e ti porti in azienda: è un luogo dove mandi i tuoi dati a lavorare. E come per qualunque altro luogo in cui li mandi, la domanda giusta non è quanto costa oggi, ma di chi è la casa.
In sintesi:
- Con l’AI non mandi fuori degli archivi, mandi fuori il tuo lavoro. Richiesta dopo richiesta escono il know-how tuo e i dati dei tuoi clienti, e davanti a quei clienti il responsabile rimani tu.
- La sovranità è una scelta di architettura, non una dichiarazione. Il datacenter in Europa non basta: conta chi controlla l’infrastruttura e chi decide quando le regole cambiano.
- Il consumo a token non è un prezzo, è un andamento. Cresce insieme al successo del progetto e lo governa qualcun altro. Su volumi stabili, un modello privato su risorse dedicate costa meno ed è prevedibile.
- Tenersi il modello in casa oggi è alla portata. Modelli a pesi aperti su macchine con GPU dedicate in Europa: i dati non escono, la versione resta quella che hai scelto e per chi sviluppa cambia poco o niente.
- Un modello privato non è soltanto una GPU. Va inserito in un’infrastruttura progettata, altrimenti il conto lo pagano gli altri sistemi che gli girano accanto.
Se vuoi guardare il tema da altre angolazioni, trovi qualcosa anche negli articoli su come misurare la qualità di un cloud provider e sul disaster recovery.
E i tuoi dati, stasera, dove saranno?
Con ogni probabilità la tua intelligenza artificiale oggi funziona benissimo, e questo è esattamente il momento giusto per farsi qualche domanda. Farsele dopo la richiesta scritta di un cliente, o dopo una verifica, costa molto di più.
Noi di Cloudable non vendiamo intelligenza artificiale preconfezionata e non abbiamo un modello da piazzarti. Quello che facciamo è progettare con te il posto in cui la tua AI dovrà lavorare, e occuparci che stia in piedi insieme a tutto il resto della tua infrastruttura.
Vuol dire sedersi al tavolo quando il progetto è ancora un’idea, e ragionare insieme su quale modello regge il lavoro che hai in mente, quante risorse servono davvero, dove appoggiare i documenti da consultare e come far parlare tutto questo con i sistemi che già usi. Poi vuol dire darti il posto in cui farlo girare: macchine virtuali con GPU a bordo su cui far lavorare modelli avanzati che restano tuoi, datacenter europei, tecnologie open source, un team tecnico italiano con cui puoi parlare, e una filiera che sei in grado di mettere nero su bianco quando un cliente ti chiede dove sono finiti i suoi dati.
Sicura, perché i dati restano dove decidi tu. Sovrana, perché sai chi controlla l’infrastruttura e chi decide quando le cose cambiano. Sostenibile, perché il conto lo conosci in anticipo e non cresce insieme al successo del progetto.
Meglio decidere adesso dove far girare la tua AI, che scoprirlo più avanti leggendo un contratto.
