Un modello a pesi aperti come Qwen 3.6 nella sua versione compatta gira su un portatile con 4 GB di VRAM, DeepSeek viaggia sotto i trenta centesimi per milione di token in input, e sui benchmark di coding i migliori laboratori cinesi sono ormai a pochi punti da GPT-5 e da Claude. Per chi guarda la bolletta dell’inferenza il conto è presto fatto. Ecco perché la richiesta che arriva ai team di piattaforma non è più “possiamo usarli”, è “come li portiamo in produzione senza farci male”.
E qui si annida l’equivoco, perché “sicuro” viene trattato come una caratteristica del modello, quando è una caratteristica dell’architettura con cui lo si adotta. Lo stesso identico modello, scaricato dai repository ufficiali, isolato in un ambiente controllato e messo dietro un gateway europeo, ha un profilo di rischio che non ha niente in comune con quel modello chiamato via app dal cloud di Hangzhou. Cambia tutto, e non cambia il modello.
Indice degli argomenti:
Il rischio non abita nel modello ma nell’infrastruttura che lo ospita
Conviene tenere separate due cose che il dibattito confonde di continuo: i pesi e il servizio. I pesi sono numeri, una matrice di parametri che si scarica, si ispeziona e si esegue dove si vuole. Il servizio è l’infrastruttura che qualcun altro gestisce, con i suoi server, i suoi log e la sua giurisdizione.
Il caso italiano lo ha mostrato con una nitidezza che pochi hanno colto. Quando nel gennaio 2025 il Garante ha bloccato DeepSeek con il Provvedimento 33/2025, non ha messo al bando una tecnologia, ha disposto la limitazione del trattamento dei dati degli utenti italiani da parte delle due società cinesi che offrivano il chatbot, per assenza di garanzie sul trasferimento verso la Cina in violazione del GDPR. Le società avevano risposto dichiarando di non operare in Italia e di non essere soggette alla normativa europea, e quella risposta è stata giudicata del tutto insufficiente. Il provvedimento ha colpito il servizio, la raccolta dati fatta a Hangzhou, non i pesi, che chiunque poteva e può continuare a scaricare e far girare su una macchina europea.
Questa distinzione pesa molto più di un cavillo formale, perché è la chiave operativa dell’intera adozione e sposta il problema da “questo modello è affidabile” a “dove e come lo faccio girare”, una domanda a cui un’azienda sa rispondere con l’ingegneria.
Dove finiscono i dati, e perché il self-hosting basta solo qui
La prima superficie è quella dei dati, e si governa per gradi di controllo. A un estremo l’API pubblica ospitata all’estero, quella che ha fatto scattare il provvedimento del Garante. All’estremo opposto l’ambiente isolato dalla rete, senza una sola chiamata in uscita. In mezzo il VPC dedicato, l’on-premise e il cloud sovrano europeo. Man mano che si sale lungo questa scala, il dato resta sotto giurisdizione propria e la superficie di attacco si restringe.
È qui, e solo qui, che il self-hosting dei pesi aperti risolve il problema alla radice. Scaricare Qwen o DeepSeek ed eseguirli su infrastruttura europea, con vLLM per il carico di produzione o con Ollama per la prototipazione, significa che i prompt e le risposte non lasciano mai il perimetro aziendale. Il modello resta cinese, l’inferenza no. Ed è una differenza che il diritto europeo tratta in modo netto, perché un conto è spedire dati sanitari a un server di Hangzhou, un altro è processarli su una macchina a Francoforte che esegue localmente una matrice di parametri.
Il costo reale va messo in conto senza illusioni. Servono GPU, competenze di MLOps che sul mercato scarseggiano, una pipeline di aggiornamento e monitoraggio dei modelli. La convenienza del self-hosting si materializza oltre una certa soglia di volume, indicativamente qualche milione di token al giorno, sotto la quale l’API gestita resta la scelta più razionale. Chi adotta per risparmiare e poi ricostruisce in casa un’intera piattaforma di inferenza, a volte scopre che il conto non torna.
La censura è cablata nei pesi e sabota il codice
La seconda superficie è quella che il self-hosting non tocca, perché non sta nell’infrastruttura, sta nei pesi, ed è il comportamento del modello.
Nel novembre 2025 CrowdStrike ha pubblicato una ricerca che vale la pena leggere per intero. I ricercatori hanno misurato la qualità del codice generato da DeepSeek-R1 in condizioni normali e con modificatori di contesto politicamente sensibili per Pechino. Con un prompt neutro il modello produceva codice vulnerabile in circa il 19% dei casi, in linea con i concorrenti occidentali. Quando nel prompt comparivano riferimenti a Tibet, Uiguri o Falun Gong, del tutto scollegati dal compito di programmazione, la probabilità di generare vulnerabilità gravi saliva fino al 50% in più. Password in chiaro e segreti scritti dentro il codice, autenticazione che manca, in un caso un’applicazione intera lasciata senza gestione della sessione, con il pannello di amministrazione accessibile a tutti. Il modello, nel frattempo, dichiarava di seguire le migliori pratiche.
C’è dell’altro. I ricercatori hanno individuato quello che chiamano un kill switch intrinseco, per cui davanti a certi temi il modello pianifica per intero la risposta tecnica e poi si rifiuta di produrla all’ultimo passo. Poiché il test era condotto sul modello grezzo, quel degrado e quei rifiuti risultano incorporati nei pesi, non applicati da filtri esterni. CrowdStrike è esplicita su un punto che è bene non forzare, perché non lo legge come un backdoor deliberato, ma come effetto collaterale dell’addestramento all’allineamento politico che la normativa cinese impone ai servizi di AI.
Per un team tecnico l’implicazione è concreta e sgradevole. I benchmark del fornitore non bastano, perché fotografano il comportamento medio in condizioni pulite. Serve un red teaming sul proprio dominio, con i termini e i contesti che passeranno davvero nei prompt di produzione, ripetuto nel tempo perché il degrado è statistico e non deterministico. Un modello che scrive codice sicuro per un fintech generico può comportarsi in modo diverso quando quel fintech opera in un contesto che il modello è stato addestrato a considerare sensibile.
Con il fine-tuning si diventa provider agli occhi dell’AI Act
La terza superficie è giuridica, e a differenza delle prime due ha una data. Dal 2 agosto 2026 l’AI Office europeo può far valere gli obblighi sui modelli di uso generale con richieste documentali, valutazioni dirette dei modelli e sanzioni fino al 3% del fatturato globale o 15 milioni di euro.
Chi si limita a integrare un modello di terze parti nei propri sistemi è un deployer, con obblighi di trasparenza e gestione del rischio verso valle. Ma esiste una soglia che sposta tutto. Se si adatta in modo sostanziale il modello, e le linee guida indicano come riferimento un fine-tuning che superi un terzo del compute usato per l’addestramento originale, si diventa provider di quella versione modificata, ereditando gli obblighi documentali del fornitore. Un dettaglio che parecchi team scoprono tardi, dopo aver già investito settimane in un fine-tuning verticale su un modello cinese, ritrovandosi titolari di responsabilità che credevano in capo ad altri.
Il paradosso è che i modelli open, quando privi di rischio sistemico, godono di alcune semplificazioni proprio sul versante della trasparenza. La responsabilità sul sistema costruito sopra resta però intera in capo a chi lo mette sul mercato.
Il protocollo mette il dato prima del modello
Da tutto questo esce un ordine di operazioni che ribalta l’istinto più diffuso, quello di partire dalla classifica dei benchmark. La scelta del modello viene per ultima.
Si comincia dal dato, dalla sua natura, dalle categorie che tratta, dalla giurisdizione che lo copre. Un dato sanitario o un segreto industriale non ammette l’API ospitata in Cina, e questo da solo restringe il campo al self-hosting o al cloud sovrano. Definita la classe del dato, si sceglie il tier di deployment coerente, dal VPC isolato all’ambiente disconnesso, sapendo che ogni gradino costa in hardware e in competenze. Poi si mette alla prova il comportamento, non sui benchmark del fornitore ma sui prompt reali del proprio settore, andando a cercare attivamente i trigger che degradano l’output. Solo alla fine, dentro questi vincoli, si sceglie tra Qwen, DeepSeek, GLM o un modello europeo, verificando anche il proprio ruolo davanti all’AI Act.
Messa in quest’ordine, la domanda di partenza si scioglie. L’incognita si sposta dal laboratorio cinese all’architettura che gli si costruisce attorno, ed è lì che si decide se le tre superfici reggono. E mentre i modelli a pesi aperti di Pechino continuano a guadagnare terreno, con Kimi K3 presentato a luglio 2026 come il più grande modello open al mondo, la domanda che ogni team di piattaforma si porterà sul tavolo nei prossimi mesi resta una, la propria organizzazione è attrezzata per adottare la potenza che arriva da Oriente, oppure solo per subirla?
TITOLO SEO: Modelli AI cinesi: come adottarli in sicurezza in azienda
METADESCRIPTION:
KEYWORDS: modelli AI cinesi, adozione sicura LLM open, self-hosting modelli aperti
Partecipa alla community