---
title: "Che cosa deve dirvi il rapporto tecnico di un modello prima che lo installiate?"
description: "Il 27 luglio sono usciti i pesi di Kimi K3 e un rapporto tecnico di 47 pagine. Che cosa dichiara davvero quel documento, che cosa tace e perché vi serve."
url: https://csidia.com/note-operative/rapporto-tecnico-modello-cosa-dichiara/
lang: it
date: 2026-07-28
label: "Osservatorio"
publisher: CSIDIA S.r.l. (https://csidia.com/)
english: https://csidia.com/en/notes/rapporto-tecnico-modello-cosa-dichiara/
---

# 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](https://csidia.com/note-operative/kimi-k3-moonshot-microsoft-copilot). 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](https://csidia.com/note-operative/licenze-pesi-aperti-openmdw-cosa-permettono).
- **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](https://csidia.com/note-operative/modelli-aperti-restrizioni-cosa-resta-installato) 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](https://csidia.com/note-operative/obbligo-informativo-sistemi-automatizzati-lavoratori) 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.

## Fonti

- [Hugging Face — moonshotai/Kimi-K3: pesi, scheda del modello, testo della licenza e cronologia dei commit](https://huggingface.co/moonshotai/Kimi-K3)
- [Moonshot AI — Kimi K3, rapporto tecnico integrale (PDF, 47 pagine)](https://github.com/MoonshotAI/Kimi-K3/blob/main/k3_tech_report.pdf)
- [UK AI Security Institute e CAISI — Preliminary Assessment of Kimi K3’s Cyber Capabilities (23 luglio 2026)](https://www.aisi.gov.uk/blog/preliminary-assessment-of-kimi-k3s-cyber-capabilities)

Nota di CSIDIA S.r.l. (Vignola, MO): https://csidia.com/note-operative/rapporto-tecnico-modello-cosa-dichiara/ · Chi siamo e che cosa facciamo: https://csidia.com/in-breve/ · engagement@csidia.com