Che cosa deve dirvi il rapporto tecnico di un modello prima che lo installiate?

Il 27 luglio 2026, alle 13:31 UTC, il primo commit del repository moonshotai/Kimi-K3 su Hugging Face ha reso scaricabili 96 file di pesi, circa 1,56 terabyte. Poco più di un’ora e mezza dopo, su GitHub, è comparso un PDF di 47 pagine: il rapporto tecnico. Del modello ci siamo già occupati. Il punto vale per qualunque modello aperto: di quei due artefatti il primo è opaco per costruzione, il secondo è l’unico che potete leggere.

Un file di pesi non dichiara nulla di sé. Tutto ciò che direte a un’autorità o a una rappresentanza sindacale su come quel sistema è stato costruito e misurato deve venire dal documento che lo accompagna. Conviene sapere che cosa quel documento contiene, e che cosa quasi mai contiene.

Il rilascio, per quello che si verifica

La data sta nei commit, non nella scheda. Il repository risulta creato il 13 giugno 2026, ma la cronologia parte il 27 luglio: prima non c’era nulla di pubblico. Per datare un’adozione la scheda del modello non fa fede.
Un solo esemplare. Niente checkpoint di base, niente taglie ridotte, niente versioni intermedie. Un unico formato — pesi MXFP4, attivazioni MXFP8 — con la quantizzazione ottenuta in addestramento, non applicata dopo.
La licenza è un testo proprio, la «Kimi K3 License»: permesso ampio con due soglie — accordo separato per chi rivende inferenza oltre 20 milioni di dollari di ricavi in dodici mesi, attribuzione in interfaccia oltre 100 milioni di utenti mensili. Come si legge una licenza di pesi l’abbiamo scritto.
Il rapporto sta in un repository, non su arXiv: nessun identificativo persistente, nessuna revisione fra pari, sostituibile senza lasciare traccia. Archiviatelo con la sua impronta il giorno in cui lo leggete.

Che il modello al centro del dibattito sulle restrizioni ai pesi aperti sia ora un file scaricabile è una notizia. Non la parte utile.

Che cosa il rapporto dichiara

L’abbiamo letto. Sull’architettura è generoso: 93 strati, 896 esperti di cui 16 attivi per token, 104 miliardi di parametri attivati su 2,78 trilioni totali. Sulle valutazioni è, per il genere, insolitamente rigoroso: dichiara i parametri di campionamento, quale impalcatura d’agente ha usato per ciascun modello e che alcuni punteggi di terze parti sono ripresi da elenchi pubblici «al 23 luglio 2026». Dichiara anche le proprie debolezze: sui test di ragionamento a livello di ricerca scrive che restano «una direzione chiave di miglioramento», e nomina le prove in cui resta indietro.

Poi un capitolo che in un documento di ingegneria non ci si aspetta: la misura delle proprie capacità offensive in ambito cyber. Su un insieme interno di 36 compiti di sviluppo di exploit, misurato dal laboratorio stesso, il modello ne risolve 14, e il rapporto definisce quel risultato «un limite inferiore» della capacità reale. Cita poi una valutazione congiunta di UK AI Security Institute e CAISI statunitense: lì il dato che riguarda un’azienda non è il punteggio, è la frase secondo cui le protezioni del modello «non hanno impedito» tentativi di sviluppo di exploit.

Che cosa non c’è

La sezione sui dati di addestramento è lunga quindici righe. Nomina quattro domini testuali — web, codice, matematica, conoscenza — più un corpus visivo, e i metodi: euristiche, punteggi di qualità con classificatori, deduplicazione, riscrittura con verifica di fedeltà. Non c’è altro: non quanto testo, non da dove viene, non a che data si ferma, non a che titolo è stato usato, non se contenga dati personali.

Non c’è una sezione sui limiti: quelli dichiarati sono scarti di punteggio, non avvertenze su dove il sistema non va messo. Nulla sui comportamenti di rifiuto, sulla misura di risposte dannose, su discriminazione o equità. E non una riga su che cosa succede a tutto questo se il modello viene riaddestrato — che è la prima cosa che farete.

Non è il difetto di un laboratorio: è il genere. Un rapporto tecnico è un documento di ingegneria, scritto per chi costruisce modelli, non la documentazione di prodotto di un fornitore.

Il punto di rottura è la lettera d)

Qui il discorso smette di essere accademico. L’art. 1-bis del D.lgs. 152/1997 impone di comunicare al lavoratore e alle rappresentanze sindacali la logica e il funzionamento del sistema (lettera c), le categorie di dati e i parametri principali usati per programmarlo o addestrarlo (lettera d) e il livello di accuratezza, robustezza e cybersicurezza con le metriche usate e i loro impatti potenzialmente discriminatori (lettera f).

Mettete il rapporto accanto all’elenco. La lettera c) la coprite, meglio che con quasi ogni prodotto commerciale. La f) a metà: le metriche ci sono, con condizioni e date, ma gli impatti discriminatori delle metriche non sono materia trattata. La d) no: quattro nomi di dominio non sono categorie di dati in senso utile, e i parametri dell’addestramento non sono pubblicati.

È l’asimmetria dei pesi aperti. Con un fornitore quelle informazioni si mettono a contratto, e se mancano l’inadempimento ha un titolare. Con un file scaricato sotto una licenza unilaterale «AS IS» non esiste controparte a cui chiederle: avete guadagnato il diritto di eseguire il modello e perso qualcuno da obbligare. Davanti all’ispettore il soggetto obbligato restate voi.

Che cosa cercare, e che cosa chiedere se non c’è

Origine e perimetro dei dati. Se il rapporto non li dà, la richiesta scritta va a chi vi integra il modello — fonti, periodo coperto, dati personali — e la dichiarazione entra in contratto.
Condizioni delle misure. Un punteggio senza chi lo ha misurato, con quale impalcatura e a che data non è una misura: non entra in nessun documento vostro.
Debolezze ammesse. Un rapporto che non ne dichiara è meno affidabile, non più. Se non ci sono, chiedete l’elenco dei casi d’uso sconsigliati.
Tenuta dopo l’adattamento. Chiedete se i comportamenti misurati sopravvivono alla messa a punto. Senza risposta, ogni numero riguarda un modello che smetterete di avere appena lo adattate.
La vostra prova. Nessuna valutazione pubblicata riguarda i vostri documenti, la vostra lingua, il vostro processo: i risultati arrivano al vostro caso solo attraverso un insieme di prova costruito da voi.

Come lo risolviamo noi

La documentazione serve a poco se il modello gira dove non potete guardare: un rapporto dice come un sistema è stato costruito, non chi vede i vostri dati mentre lo usate. Per questo lavoriamo in due modalità e nessun’altra: on-premise nell’ambiente del cliente, oppure sul nostro cloud dedicato — riservato al singolo cliente, accesso via VPN dedicata, data center residente in Italia, locali che presidiamo direttamente. In entrambe ciò che il rapporto non dichiara lo misurate voi, sui vostri dati, dentro il vostro perimetro. È il metodo con cui teniamo l’AI aziendale sotto controllo dimostrabile: architettura, non promessa commerciale.

Dovete far approvare un modello a pesi aperti e nessuno sa dire con quali dati è stato addestrato? Mezz’ora con un nostro esperto: leggiamo insieme il rapporto tecnico e scriviamo la lista di ciò che va chiesto per iscritto.