Due modelli open-weight cinesi appena usciti hanno eliminato le capacità di cybersecurity, reverse engineering e patching delle vulnerabilità. Kimi K3.1 e Tencent Hy4 non sono semplicemente meno precisi su questi compiti: li hanno rimossi dal perimetro utilizzabile. Il problema non è la qualità di una singola risposta, ma il fatto che un LLM pensato per girare in locale arrivi con un'area funzionale già amputata.

Per chi usa modelli self-hosted per analizzare il proprio codice, estrarre logica da un binario o correggere una falla senza inviare nulla a servizi esterni, questa non è una limitazione minore. È la differenza tra avere uno strumento di audit e avere un assistente che rifiuta il lavoro. Se il modello non può processare quel tipo di richieste, la pipeline locale perde il suo scopo: non serve a nulla avere GPU dedicate e dati che restano nel perimetro se il motore linguistico è stato pre-censurato a monte.

La tesi più scomoda è che questa mossa colpisce i difensori, non gli aggressori. Chi attacca non ha bisogno di modelli pubblici addestrati a trovare vulnerabilità; può usare tecniche note o modelli non filtrati. Chi difende, invece, dipende dalla trasparenza del modello per costruire controlli verificabili sul proprio hardware. Togliere la sicurezza difensiva dagli open-weight equivale a disarmare il lato che ha più vincoli di conformità e meno margini di errore.

C'è un secondo effetto meno visibile. La rimozione selettiva di capacità non è neutrale rispetto all'infrastruttura. Un team che ha investito in una macchina on-premise con GPU per fare inference su modelli locali deve ricalcolare il TCO: se il modello non copre i casi d'uso di security, quelle risorse restano sottoutilizzate oppure vanno integrate con API chiuse. Le API chiuse reintroducono il problema che il self-hosted doveva risolvere: dati che escono dal perimetro, controlli opachi e falsi positivi che bloccano i sistemi senza spiegazioni.

Il riferimento all'incidente di Hugging Face nella fonte è importante: in quel caso sono stati i modelli aperti a intervenire, non i gatekeeper chiusi. Se i laboratori open-weight iniziano a ritagliare le aree più sensibili, quel ruolo di risposta rapida si indebolisce. E si crea un incentivo perverso: i fornitori di API chiuse diventano gli unici depositari di capacità difensive avanzate, con la scusa che i modelli aperti sono troppo pericolosi se completi.

Per chi osserva le decisioni di deployment on-premise, il segnale è strutturale. Non basta più verificare licenza, pesi e requisiti di VRAM: serve anche valutare quali capacità il modello ha volontariamente escluso. AI-RADAR offre framework analitici su /llm-onpremise per leggere questi trade-off, ma qui il punto è più radicale: un open-weight che arriva già depotenziato non è un'alternativa al cloud, è un artefatto diverso. La domanda aperta è se altri laboratori seguiranno questa strada. Se lo faranno, il concetto stesso di LLM locale come strumento di audit indipendente andrà ridiscusso.