La prova di Fermat verificata in Lean 4: cosa cambia

Il fatto: una prova storica tradotta in linguaggio formale

Il 4 settembre 2026 il laboratorio di ricerca Anthropic ha reso pubblica la traduzione completa dell'Ultimo Teorema di Fermat nel linguaggio formale Lean 4, verificata a macchina in undici giorni di lavoro computazionale, come riportato dal laboratorio stesso in un documento tecnico dedicato^[1].

Il codice risultante conta 13 milioni di righe, distribuito su un repository pubblico consultabile su GitHub^[2].

La formalizzazione dichiara tre assiomi di partenza. Un comparator indipendente e un secondo kernel di verifica, costruito con logica distinta dal primo, confermano la coerenza dell'intera catena deduttiva.

La dimostrazione matematica del teorema resta quella pubblicata da Andrew Wiles e Richard Taylor nel 1995: il lavoro del 2026 formalizza e verifica quella prova, restando distinto da una versione alternativa generata da un sistema artificiale.

Il valore del rilascio risiede raramente nel risultato matematico, già stabilito da tempo, e piuttosto nella sua tracciabilità end-to-end: ogni passaggio deduttivo resta ispezionabile dal kernel di verifica, un livello di dettaglio raramente disponibile nei processi decisionali aziendali basati su agenti.

Il precedente del 1976: quattro colori, una lezione lunga

Nel 1976 Kenneth Appel e Wolfgang Haken pubblicarono la prima dimostrazione del teorema dei quattro colori ottenuta con l'ausilio di un computer, come documentato su Wikipedia^[3].

Quella prova analizzava un numero enorme di configurazioni riducibili, un'operazione impraticabile per una verifica manuale completa. La comunità matematica discusse a lungo cosa contasse come verifica accettabile, proprio perché un essere umano isolato risultava incapace di ripercorrere l'intero calcolo a mano.

Nel 1997 Robertson, Sanders, Seymour e Thomas ridussero il numero di configurazioni a 633, restando comunque su un'analisi di casi estremamente estesa. Nel 2005 Georges Gonthier verificò l'intero teorema con software di dimostrazione automatica di uso generale, chiudendo un capitolo aperto da quasi trent'anni.

La vicenda del 1976 mostra come l'accettazione di una prova computazionale richieda tempo istituzionale, indipendentemente dalla sua correttezza tecnica.

Il parallelo con il caso Fermat è diretto: entrambe le prove spostano il baricentro della fiducia dalla lettura umana riga per riga alla verifica computazionale strutturata.

Alcuni osservatori matematici hanno sostenuto in passato che una prova verificata da macchina resti comunque priva del valore esplicativo di una dimostrazione leggibile da un essere umano. La formalizzazione Lean 4 del 2026 riapre la stessa tensione, applicata a un teorema di portata culturale ancora maggiore rispetto ai quattro colori.

Output plausibile e output verificato: dove si sposta la responsabilità

Un sistema generativo produce testo, codice o dimostrazioni con un grado di plausibilità stimato statisticamente. Un verificatore formale, come il kernel Lean 4 impiegato in questo caso, applica regole logiche deterministiche e restituisce un giudizio binario: la catena deduttiva regge oppure fallisce.

Questa distinzione conta perché cambia il soggetto accountable. Quando l'output è plausibile, la responsabilità grava su chi lo produce e su chi lo rilascia in assenza di controllo indipendente.

Quando l'output è verificato da un secondo sistema indipendente, con assiomi dichiarati e log conservati, la responsabilità si sposta parzialmente su chi certifica il verificatore e su chi ne custodisce la configurazione. È il verificatore, in questo schema, a diventare l'artefatto centrale della governance, più del contenuto stesso della dimostrazione.

Un'obiezione ricorrente sostiene che il verificatore stesso richieda fiducia cieca, spostando semplicemente il problema di un livello. La risposta operativa consiste nel rendere pubblico il codice del verificatore e nell'affiancare un secondo kernel indipendente, come avvenuto in questo caso, per ridurre la dipendenza da un singolo sistema.

Per un'organizzazione che rilascia output generati da agenti, il quesito diventa operativo: quale ruolo interno certifica il verificatore, per iscritto, prima del rilascio?

Cosa richiede il Regolamento (UE) 2024/1689

Il Regolamento (UE) 2024/1689, noto come AI Act, fissa tre obblighi rilevanti per questo scenario, consultabili nel testo integrale su EUR-Lex^[4].

L'articolo 50 impone trasparenza sui contenuti generati da sistemi di intelligenza artificiale, con l'obbligo di segnalare in modo chiaro la natura artificiale dell'output, in giurisdizione UE.

Gli articoli 11 e l'Allegato IV richiedono, per i sistemi classificati ad alto rischio, documentazione tecnica dettagliata e tracciabilità completa del processo che ha generato l'output: versioni del modello, parametri, log di esecuzione.

L'articolo 14 impone sorveglianza umana effettiva sui sistemi ad alto rischio, con un soggetto identificato capace di interrompere o correggere il processo prima che l'output produca effetti.

Per il General Counsel, l'esposizione legale concreta riguarda la prova che la sorveglianza umana prevista dall'articolo 14 sia stata esercitata realmente, con un soggetto nominato capace di bloccare il rilascio prima della pubblicazione, oltre la previsione meramente formale sulla carta.

Una postura di conformità calibrata sull'output testuale generico risulta oggi scarsamente adeguata di fronte a output verificabili a macchina: cambia l'oggetto della sorveglianza, cambia l'artefatto da conservare.

Matrice decisionale per General Counsel e Board

Tre categorie di decisione emergono per chi governa l'adozione di sistemi agentici capaci di produrre output formalmente verificabile.

• Quale artefatto conservare: assiomi dichiarati, versione del linguaggio formale, log completo del comparator e del secondo kernel, con marcatura temporale verificabile.
• Chi certifica il verificatore: un ruolo tecnico interno, per iscritto, con autorità distinta da chi produce l'output, coerente con l'articolo 14 del Regolamento.
• Chi ha l'autorità di bloccare un rilascio: il Board Audit & Risk Committee richiede visibilità su questa catena decisionale prima della pubblicazione di qualunque risultato verificato a macchina destinato a uso esterno.

Per il Chief Risk Officer, il framework di rischio aggiornato distingue oggi tra output plausibile e output verificato, assegnando profili di esposizione distinti a ciascuna categoria.

Il Board Audit & Risk Committee richiede, per ciascun rilascio verificato a macchina destinato a uso esterno, evidenza documentale della catena di certificazione, comprensiva di data, responsabile nominato e esito del secondo kernel di verifica.

Per il CEO, la decisione strategica riguarda la velocità di adozione: accelerare il rilascio di output verificabile offre un vantaggio competitivo misurabile, a condizione che la governance dell'artefatto sia già operativa.

Il CEO valuta inoltre l'opportunità di investire in un audit trail strutturato: l'assenza di questa infrastruttura genera un costo di ricostruzione retroattiva superiore, qualora un regolatore richieda evidenza a posteriori.

Tre decisioni per il prossimo trimestre

1. Mappare quali processi interni producono output candidato alla verifica formale, e definire per ciascuno il livello di rischio secondo la classificazione dell'AI Act.
2. Nominare per iscritto il ruolo responsabile della certificazione del verificatore, prima di qualunque deployment che coinvolga output verificato a macchina.
3. Costruire un audit trail standard, comprensivo di assiomi, versioni, log del comparator, conservato in un formato accessibile al Board Audit & Risk Committee.

L'audit resta richiesto: cambia il perimetro dell'oggetto da controllare, dal testo prodotto al processo di verifica che lo certifica.

Regulatory horizon

Il Regolamento (UE) 2024/1689 risulta in vigore nell'Unione Europea, con applicazione scaglionata per obblighi distinti fino al 2027. L'articolo 50 sulla trasparenza dei contenuti generati si applica secondo il calendario di implementazione già pubblicato nel testo di legge.

Fuori dall'Unione Europea manca, a oggi, un framework equivalente specifico per output verificato a macchina in ambito agentico. La domanda che resta aperta riguarda quale ruolo nominato, per iscritto, prima del deployment, risulti accountable per l'output verificato, dentro ciascuna organizzazione che adotta questi sistemi.