Cos'è una traccia di ragionamento (reasoning trace)?

Una traccia di ragionamento è la sequenza di passaggi intermedi che un reasoning model produce prima di formulare la risposta finale: ipotesi provate e scartate, calcoli, verifiche, cambi di direzione. Va tenuta distinta da due cose che le somigliano. Non è la risposta, che è il testo consegnato all'utente, e non è il riassunto della traccia, che è quello che le interfacce mostrano quando mostrano qualcosa. La documentazione di OpenAI dichiara di non esporre i token di ragionamento grezzi e di restituirne, su richiesta, soltanto un riassunto; quella di Anthropic dice che il testo di un blocco thinking è un riassunto e che nessuna impostazione restituisce la catena di pensiero grezza. Al posto della traccia in chiaro le API restituiscono un blob cifrato, che il client conserva e rimanda al server nei turni successivi perché la conversazione resti coerente.

Perché i laboratori la tengono nascosta

La traccia è, in buona parte, ciò che rende un modello quello che è: esposta, permette a un concorrente di addestrare un modello più piccolo a imitarne il percorso di ragionamento, cioè di fare distillazione a spese di chi l'ha addestrato. Che la protezione non sia solida lo dice la ricerca, non il marketing. Un lavoro di tre ricercatori di Cornell Tech, How to Steal Reasoning Without Reasoning Traces, mostra che tracce sintetiche molto sovrapponibili a quelle vere si possono ricostruire osservando solo input, risposte e riassunti, e che addestrare uno studente su quelle tracce invertite ne migliora sensibilmente il ragionamento. Un secondo lavoro, Stealing Reasoning Traces from Proprietary LLM APIs, sfrutta invece un difetto di architettura: i blocchi cifrati risultavano intercambiabili fra sessioni, utenti e modelli dello stesso fornitore, e da lì gli autori ricavano più vettori per farne riprodurre il contenuto in chiaro. Scrivono anche che ad agosto 2026 quei risultati non sono più riproducibili con gli attacchi descritti nel paper, per le mitigazioni introdotte dai fornitori dopo la segnalazione.

Un esempio enterprise

È il secondo lavoro a contenere il punto che riguarda direttamente chi costruisce applicazioni. Gli autori hanno raccolto 6.708 trascrizioni di sessioni di agenti pubblicate su GitHub e Hugging Face, ne hanno ricostruito 315.320 tracce di ragionamento e ne hanno estratto 367 elementi di dati personali e 182 credenziali, tra cui chiavi API, password e token di accesso. Il dettaglio che conta: 64 dei 704 artefatti recuperati dal ragionamento non comparivano affatto nella cronologia visibile della conversazione, esistevano solo dentro il blocco cifrato. Immaginate un team che apre un ticket su un agente di supporto interno e allega la trascrizione completa della sessione a un repository pubblico per far riprodurre il bug: il log è stato controllato a occhio, non contiene nulla di sensibile in chiaro, e la credenziale che l'agente aveva letto da una variabile d'ambiente sta nel blob che nessuno ha guardato perché illeggibile.

Perché conta per chi decide

Questa non è una questione da girare al fornitore del modello. È igiene dei log e governance: chi decide deve sapere che i blocchi di ragionamento sono dati applicativi come tutti gli altri, che vanno trattati alla stregua di un segreto anche quando sono illeggibili, e che l'illeggibilità non è una garanzia di riservatezza. Tre conseguenze operative immediate: i blob cifrati non finiscono nei log persistenti se non servono; una trascrizione di sessione non lascia il perimetro aziendale senza che quei campi siano stati rimossi; e la policy su cosa un agente può leggere vale anche per il suo ragionamento, non solo per il suo output. Sono controlli che appartengono al perimetro dell'agent ops, cioè al ciclo di vita degli agenti in produzione, e costano poco se decisi prima di pubblicare il primo log.