Lo scorso trimestre, uno studio contabile di Chicago da 40 persone si è sentito fare una domanda precisa dal legale esterno di un nuovo cliente: potete confermare che nessuno dei nostri documenti fiscali verrà elaborato su un server fuori dagli Stati Uniti? Lo strumento AI di revisione documentale dello studio girava su un’API di cloud pubblico, senza alcuna garanzia contrattuale su dove avvenisse davvero l’inferenza. Nessuno in ufficio sapeva rispondere con certezza, e il cliente se n’è andato.
Quella scena si sta ripetendo in questi mesi in tutti i settori, su entrambe le sponde dell’Atlantico. Un gruppo sanitario che valuta uno strumento AI di trascrizione clinica deve pensare a HIPAA e ai business associate agreement prima ancora che all’accuratezza della trascrizione. Un asset manager di medie dimensioni a Londra deve pensare all’EU AI Act e al GDPR prima di chiedersi quale modello scriva il riassunto più pulito. Una volta la domanda era quale strumento AI funziona meglio. Sempre più spesso è dove gira lo strumento e chi altro può arrivare ai dati mentre lo fa.
Non tutte le PMI devono reagire montando un server GPU nello sgabuzzino. Ma il calcolo attorno al far girare l’AI su un’infrastruttura che controlli, invece di affittarla a token da un vendor che non controlli, è cambiato abbastanza negli ultimi diciotto mesi da meritare uno sguardo onesto: cosa è possibile oggi, cosa serve per gestirla bene e quando l’API pubblica resta la scelta più intelligente ed economica.
Perché “dove finiscono i dati” è diventata una domanda da contratto
La riservatezza verso i clienti è il fattore scatenante più comune. Studi legali, studi contabili, boutique di gestione patrimoniale e strutture sanitarie gestiscono tutti documenti che sono tenuti a proteggere per contratto o per etica professionale, e “vanno a un’API di terze parti” non è più una risposta soddisfacente per un numero crescente di clienti, assicuratori e revisori.
La normativa dà forza legale a quell’istinto. In Europa il GDPR copre qualsiasi trattamento di dati personali di residenti UE, a prescindere da dove abbia sede l’azienda che li tratta, e l’EU AI Act aggiunge sopra obblighi di trasparenza e di gestione del rischio, con scadenze che entrano in vigore per le diverse fasce di rischio tra il 2026 e il 2027. Negli USA, HIPAA copre le informazioni sanitarie protette lungo tutta la filiera: un soggetto coperto dalla norma deve avere un business associate agreement firmato con qualsiasi vendor AI prima che i dati dei pazienti possano anche solo sfiorarlo. Le istituzioni finanziarie americane hanno un obbligo parallelo con la Safeguards Rule del Gramm-Leach-Bliley Act, che rende la supervisione continuativa dei fornitori un dovere legale permanente e non una casella da spuntare alla firma.
La giurisdizione complica ulteriormente le cose. Un server fisicamente a Francoforte o a Dublino non mette automaticamente i dati fuori dalla portata legale americana se l’azienda che lo gestisce è americana: il CLOUD Act permette alle autorità USA di imporre la consegna dei dati a qualsiasi provider con sede negli Stati Uniti, ovunque si trovino i suoi server. Per un’azienda europea che tratta dati sotto GDPR è un conflitto aperto, e le autorità di protezione dei dati di diversi paesi UE lo hanno detto pubblicamente.
Altre due pressioni c’entrano meno con la compliance e più con il normale buon senso commerciale. Il lock-in del vendor è reale: prezzi, rate limit e disponibilità dei modelli escono dal tuo controllo nel momento in cui un flusso di lavoro è costruito interamente attorno all’API di un solo fornitore. I costi per token, poi, sembrano irrisori in un pilot ma a volumi di produzione sostenuti si accumulano in fretta, una dinamica che vale la pena modellare onestamente prima di impegnarsi in una direzione o nell’altra (i conti veri sono più sotto).
È esattamente il tipo di vincolo che determina come un servizio di ingegneria AI embedded imposta un progetto fin dal primo incontro. Che il controllo dell’infrastruttura sia una preferenza o un requisito rigido cambia l’architettura prima che venga scritta una sola riga di codice.
Cosa gira davvero bene fuori da un’API pubblica, oggi
La tecnologia si è mossa così in fretta nel 2025 e nel 2026 che i consigli di due anni fa oggi valgono quasi zero. Una manciata di famiglie di modelli open-weight regge ormai il confronto con i modelli proprietari di frontiera sui compiti che compongono la maggior parte dei carichi di lavoro di una PMI: Q&A sui documenti, classificazione, stesura di testi, riassunti ed estrazione di dati strutturati.
La famiglia Llama 4 di Meta, uscita ad aprile 2025, include Scout, un modello mixture-of-experts da 17 miliardi di parametri attivi che, una volta quantizzato, sta su una singola GPU di fascia alta, e una variante più grande chiamata Maverick. Mistral ha rilasciato Large 3 a dicembre 2025, un mixture-of-experts da 675 miliardi di parametri (41 miliardi attivi per passaggio) sotto la permissiva licenza Apache 2.0, la stessa scelta da Alibaba per Qwen 3.5, arrivato a ondate tra febbraio e marzo 2026. La svizzera Apertus, costruita da ETH di Zurigo, EPFL e Centro Svizzero di Calcolo Scientifico e rilasciata a settembre 2025, va ancora oltre: pesi, dati di addestramento e codice di training sono tutti pubblici, ed è stata progettata pensando esplicitamente agli obblighi di trasparenza dell’EU AI Act.
| Famiglia di modelli | Uscita | Perché interessa alle PMI | Licenza |
|---|---|---|---|
| Llama 4 (Meta) | Aprile 2025 | La variante Scout, quantizzata, gira su una sola GPU di fascia alta; finestra di contesto molto ampia | Gratuita, con restrizioni d’uso sopra i 700M di utenti attivi mensili |
| Mistral Large 3 | Dicembre 2025 | 41B attivi su 675B totali; buon ragionamento generale | Apache 2.0 |
| Qwen 3.5 (Alibaba) | Feb-mar 2026 | Forte su multilingua e codice; uscite anche varianti dense più piccole | Apache 2.0 |
| Apertus (ETH Zurigo / EPFL / CSCS) | Settembre 2025 | Completamente aperta, dati di training inclusi; costruita pensando alle regole di trasparenza UE | Apache 2.0 |
Tratta questa tabella come una fotografia. Nuove uscite arrivano ogni pochi mesi, i benchmark si spostano e le licenze contano quanto la capacità pura: la community license di Llama è gratuita per la stragrande maggioranza delle PMI, ma aggiunge restrizioni d’uso e un obbligo di attribuzione che le alternative sotto Apache non hanno. Qualunque modello tu scelga oggi, metti in conto di sostituirlo entro dodici o diciotto mesi.
L’hardware on-premise puro non è l’unica opzione, e per la maggior parte delle PMI non dovrebbe nemmeno essere la prima da considerare. Un deployment in private cloud, cioè un’istanza GPU dedicata affittata da un provider UE o USA con un data processing agreement serio e una giurisdizione legale nota, porta gran parte del beneficio di sovranità senza l’esborso di capitale né l’onere di manutenzione di server tuoi. L’on-premise completo tende a ripagare il suo costo solo quando perfino un tenant cloud dedicato è inaccettabile, il che in pratica significa i carichi di lavoro sanitari, finanziari o del settore pubblico più strettamente regolamentati.
Perché a fermare le PMI sono le competenze, non il budget hardware
Comprare una GPU è la parte facile. Una singola scheda in grado di far girare un modello ben quantizzato da 20-70 miliardi di parametri costa tra i 25.000 e i 70.000 dollari a seconda della configurazione, oppure si affitta a ore da un provider di GPU cloud per circa 1-4 dollari l’ora a seconda della scheda e del fornitore. Quella è una voce di budget. Il piano di progetto è tutto ciò che viene dopo.
A decidere se un deployment self-hosted funziona è un insieme di discipline ingegneristiche continuative di cui la maggior parte delle PMI non ha mai avuto bisogno prima:
- Dimensionamento dell’hardware. Far combaciare dimensione del modello, livello di quantizzazione e utenti concorrenti attesi con una configurazione GPU specifica, e rifare quel conto ogni volta che il modello cambia.
- Selezione del modello. Scegliere un modello sul tuo compito e sulla tua lingua reali, non su un punteggio di leaderboard misurato su un benchmark che la tua azienda non toccherà mai.
- Retrieval sui tuoi documenti. Far rispondere un modello capace a domande su PDF interni disordinati, fogli di calcolo ed email è un problema di ricerca e ranking prima che di linguaggio. Un retrieval ingenuo produce risposte sicure e sbagliate più spesso di quanto i team si aspettino.
- Valutazione. Un set di test con domande reali e risposte corrette note, eseguito prima di ogni cambio di modello o di prompt, è l’unico modo affidabile per intercettare una regressione prima che lo faccia un cliente.
- Monitoraggio. Tenere d’occhio latenza, costi e qualità delle risposte in produzione. L’uptime da solo non ti dirà se le risposte sono ancora buone.
- Aggiornamenti. Nuove versioni dei modelli arrivano ogni pochi mesi, e ognuna va rivalutata sul tuo set di test prima di avvicinarsi alla produzione, in genere un paio di giorni di lavoro di un ingegnere per aggiornamento.
Uno studio del MIT ha rilevato che circa il 95% dei pilot enterprise di AI generativa non mostrava alcun effetto misurabile sul conto economico, e ha ricondotto i fallimenti soprattutto a lacune di integrazione più che alla qualità dei modelli (la metodologia è stata contestata, quindi prendi la cifra come indicativa, non come precisa). I deployment self-hosted falliscono nello stesso modo: il modello va bene in demo, poi degrada in silenzio sui documenti reali e sui casi limite che gli utenti digitano davvero, e nessuno se ne accorge finché non se ne accorge un cliente.
Un team di data science è sovradimensionato per questo lavoro. Basta una persona che l’abbia già fatto: qualcuno che dimensioni l’hardware correttamente al primo colpo, faccia funzionare il retrieval sul tuo set di documenti reale e costruisca l’abitudine alla valutazione prima del go-live, non dopo la prima risposta sbagliata e imbarazzante.
Quando l’API vince ancora, e quando il locale ripaga
Fai i conti prima di decidere qualsiasi cosa. A metà 2026 i prezzi delle API di frontiera vanno all’incirca da 0,10 a 25 dollari per milione di token, a seconda del modello e della direzione (l’input costa in genere meno dell’output), e per la maggior parte delle PMI a volumi da pilot o da prima produzione si tratta di un errore di arrotondamento rispetto al costo del personale. Un team di supporto che risponde a 200 domande di clienti al giorno tramite una pipeline di retrieval sui documenti aziendali, con circa 8.000 token di contesto recuperato e risposta per domanda, brucia più o meno 1,6 milioni di token al giorno. A una tariffa media tipica di 3 dollari per milione di token fanno meno di 150 dollari al mese, comodamente dentro la normale spesa software.
Il volume deve salire molto più di quanto la maggior parte delle persone immagini prima che l’aritmetica favorisca l’acquisto di hardware. Prendi un caso illustrativo più carico: un’azienda da 60 persone con un agente di supporto rivolto ai clienti che gestisce 3.000 conversazioni al giorno, ognuna con circa 4.000 token tra dati di prodotto recuperati, cronologia della conversazione e risposta generata. Fanno circa 360 milioni di token al mese. Alla stessa tariffa media di 3 dollari per milione, la bolletta API annuale si aggira sui 13.000 dollari: una voce di budget vera, ma ancora ben sotto i 40.000-70.000 dollari che costa comprare un server GPU dedicato all’altezza. Prima di fare questo conto sul serio, chiedi un preventivo reale per il tuo modello, il tuo volume e la tua configurazione hardware; queste cifre sono illustrative, servono a mostrare la forma del compromesso, non un business case finito.
Quel divario merita una riflessione. Il puro pareggio sul costo dei token giustifica raramente l’acquisto di hardware dedicato per una PMI tipica. Servirebbero volumi da call center, sostenuti ventiquattr’ore su ventiquattro, prima che la sola aritmetica penda verso la proprietà. Ciò che spinge la maggior parte delle PMI verso un’infrastruttura locale o in private cloud è il requisito di controllare dove stanno fisicamente i dati e chi può accedervi. Il costo diventa un fattore secondario una volta che quel requisito è già deciso, e a quel punto affittare un’istanza GPU in private cloud è di solito il modo più conveniente di soddisfarlo rispetto a comprare un server.
La decisione si riduce di solito a due variabili che contano per ragioni diverse: quanto sono sensibili i dati, che decide se il controllo dell’infrastruttura ti serve davvero, e quanto elabori, che decide se affittare o comprare è il modo più sensato di ottenerlo.
L’API è ancora la risposta giusta quando:
- Il volume è basso o discontinuo, qualche migliaio di richieste al mese invece di milioni
- I dati non sono regolamentati né sensibili per contratto
- La velocità di iterazione sul prodotto conta più del controllo sull’infrastruttura che ci sta sotto
- Nessuno nel team può ancora farsi carico di aggiornamenti dei modelli e valutazione sul lungo periodo
L’infrastruttura locale o in private cloud comincia a vincere quando:
- Il volume è sostenuto e prevedibile abbastanza da pianificarci attorno l’hardware
- I dati sono regolamentati (cartelle cliniche, dati finanziari, segreto professionale) o comportano obblighi contrattuali di riservatezza reali
- Un cliente, un assicuratore o un revisore ha richiesto esplicitamente la residenza dei dati o un luogo di elaborazione preciso
- Qualcuno nel team, o in fase di assunzione, può farsi carico del lavoro di ingegneria continuativo
Perché questo lavoro richiede un ingegnere dentro le tue mura
Tutto ciò che fa funzionare l’AI self-hosted avviene dentro i tuoi sistemi, con i tuoi dati, e deve farlo qualcuno che capisce il business quanto l’infrastruttura. Dimensionare l’hardware sul carico di lavoro reale e tarare il retrieval sui tuoi documenti veri sono lavori da dentro, e lo è anche la sorveglianza continua sulla qualità in produzione. Niente di tutto questo si può definire da una presentazione, né consegnare una volta sola e poi lasciare lì.
È il modello che l’industria AI ha adottato per i suoi deployment più difficili. OpenAI, Anthropic e AWS hanno tutte costruito team di implementazione dedicati negli ultimi due anni, in gran parte perché la capacità generica dei modelli si è rivelata l’80% facile del problema. L’ultimo miglio, la parte che gira dentro lo stack di una specifica azienda, sui dati di quell’azienda e sotto i suoi vincoli, richiedeva ingegneri integrati sul posto, non un ticket di supporto. Quel pattern oggi ha un nome: forward deployed engineering. Cos’è davvero un forward deployed engineer, e come si confronta con assumere un freelancer o affidare l’intero progetto a un’agenzia, vale la pena capirlo prima di decidere chi te lo costruisce: vedi ingegnere AI embedded vs freelancer vs agenzia.
Se la tua azienda sta da qualche parte nel mezzo, oltre il punto in cui la semplicità dell’API pubblica compensa il rischio di compliance, ma non ancora sicura di quali hardware, modello o team servirebbero per gestire tutto in casa, vale la pena parlarne prima di firmare un ordine d’acquisto. Una call di 30 minuti può dirti onestamente se l’AI on-premise o in private cloud è adatta al tuo volume e alla sensibilità dei tuoi dati, se il tuo team può tenerla in piedi, o se restare sull’API per un altro anno è la mossa più intelligente.
Domande frequenti
Una piccola impresa può davvero far girare la propria AI, o l'on-premise è realistico solo per le grandi aziende?
Una piccola impresa può far girare modelli open-weight capaci come Llama 4, Mistral Large 3 o Qwen 3.5 su un singolo server GPU ben dimensionato, oppure affittare capacità equivalente da un provider di private cloud. Il budget hardware raramente è quello che ti limita. La parte scarsa è una persona che sappia dimensionare bene il deployment, tarare il retrieval sui tuoi documenti e continuare a valutarlo man mano che modelli e dati cambiano.
Fare self-hosting di un modello AI ci rende automaticamente conformi a GDPR o HIPAA?
No. Far girare un modello su un'infrastruttura che controlli elimina un rischio specifico, il trasferimento incontrollato di dati a un fornitore terzo in una giurisdizione incerta, ma ti servono comunque una base giuridica per il trattamento, controlli sugli accessi, log di audit e, dove la normativa lo richiede, un business associate agreement firmato o un equivalente. Il self-hosting è un controllo tra tanti, non un programma di compliance completo.
Quali modelli open-weight sono davvero abbastanza buoni da sostituire un'API a pagamento a metà 2026?
Llama 4 (Meta, aprile 2025), Mistral Large 3 (dicembre 2025) e Qwen 3.5 (Alibaba, rilasciato a ondate tra febbraio e marzo 2026) reggono il confronto sui compiti aziendali comuni come Q&A sui documenti, classificazione e stesura di testi. Il settore si muove in fretta, con uscite rilevanti ogni pochi mesi, quindi valida qualsiasi scelta specifica sui tuoi casi di test prima di impegnarti.
Quando conviene economicamente restare su un'API a consumo invece di fare self-hosting?
Quando il volume è basso o imprevedibile, in genere qualche migliaio di richieste al mese invece di milioni, e i dati non sono regolamentati né sensibili per contratto. A quella scala, un server GPU dedicato o un'istanza di private cloud costa di solito di più, tra acquisto, esercizio e manutenzione, della bolletta API che andrebbe a sostituire.
Qual è l'errore più comune delle PMI che gestiscono la propria infrastruttura AI?
Trattarla come un acquisto hardware una tantum invece che come una responsabilità di ingegneria continuativa. I team dimensionano una GPU, mettono in produzione un modello e dichiarano vittoria, poi la qualità del retrieval degrada sui documenti reali o un aggiornamento del modello cambia in silenzio il comportamento in produzione senza che nessuno lo valuti. È una lacuna ricorrente di competenze a far rendere poco la maggior parte dei progetti AI self-hosted, molto più spesso di quanto lo faccia il costo del capitale.