Verifica formale: l'unico modo per soddisfare i regolatori dell'IA
La conversazione che non va mai bene
Immaginate questa scena. Accade ogni settimana nelle sale riunioni di tutta Europa, nelle riunioni di revisione della FDA, negli uffici di sottoscrizione assicurativa. Un ingegnere di IA presenta il suo ultimo sistema a regolatori, avvocati o valutatori del rischio.
«Il nostro microinfusore autonomo per insulina ha raggiunto il 99,97% di precisione su 50 milioni di scenari di test», annuncia con orgoglio l'ingegnere, cliccando su una slide piena di metriche impressionanti. «Stato dell'arte. Meglio di qualsiasi endocrinologo umano.»
La stanza cade nel silenzio. La regolatrice si sporge in avanti.
«Quindi mi sta dicendo», dice lentamente, «che su ogni 10.000 dosi di insulina somministrate da questo dispositivo... tre potrebbero essere sbagliate?»
L'ingegnere si sposta a disagio. «Beh, statisticamente parlando...»
«Solo in Germania, circa 7 milioni di persone hanno il diabete e necessitano di terapia insulinica. Se ogni persona riceve solo quattro dosi al giorno, si tratta di 28 milioni di somministrazioni giornaliere. Con il suo tasso di errore dello 0,03%...» Fa i calcoli sul suo taccuino. «Sono 8.400 potenziali errori di dosaggio. Ogni singolo giorno.»
«Ma la maggior parte di questi non sarebbe clinicamente significativa...»
«Può dirmi quali lo sarebbero?»
Silenzio.
«Può dirmi quando si verificherà il prossimo guasto? Può dirmi perché fallirà?»
Ancora silenzio.
«Allora temo che non possiamo approvare questo dispositivo.»
Questa conversazione, in varie forme, si ripete costantemente mentre l'IA passa dai laboratori di ricerca al mondo fisico. E rivela un divario epistemologico fondamentale tra come gli ingegneri dell'IA concepiscono la sicurezza e come la concepiscono i regolatori, gli avvocati e i tribunali.
La barriera linguistica che non riguarda la lingua
Quando l'ingegnere di IA dice "accurato al 99,97%", crede sinceramente di descrivere qualcosa di impressionante e sicuro. Nel mondo dei benchmark di machine learning, quel numero verrebbe celebrato. Verrebbero pubblicati articoli. Gli investitori sarebbero entusiasti.
Ma il regolatore sente qualcosa di completamente diverso. Sente: "C'è una probabilità piccola ma non nulla che questo sistema fallisca in modo catastrofico, e non abbiamo idea di quando, dove o perché accadrà."
Non è un problema di comunicazione. Non è che gli ingegneri abbiano bisogno di migliori capacità di presentazione o che i regolatori abbiano bisogno di formazione tecnica. È uno scontro fondamentale tra due concetti diversi di cosa significhi davvero "sapere che qualcosa funziona".
Nel software consumer, gli approcci probabilistici sono perfettamente accettabili. Se Netflix ti consiglia un film che odi, nessuno muore. Se Spotify suggerisce una canzone che non corrisponde ai tuoi gusti, il caso peggiore è un lieve fastidio. Questi sistemi possono permettersi di sbagliare a volte perché il costo del fallimento è trascurabile.
Ma l'IA si sta muovendo rapidamente oltre i consigli consumer verso domini in cui il fallimento ha conseguenze fisiche, legali e morali: veicoli autonomi che prendono decisioni in frazioni di secondo sui pedoni, dispositivi medici che calcolano i dosaggi dei farmaci, robot industriali che operano accanto a lavoratori umani, sistemi finanziari che approvano o negano il credito che determina se le famiglie possono comprare casa.
In questi domini, "abbastanza sicuro che funzioni" non è sufficiente. I tribunali non accettano distribuzioni di probabilità come prove. Gli attuari assicurativi non possono prezzare le polizze per modalità di guasto sconosciute. I regolatori non possono approvare dispositivi che potrebbero uccidere persone per ragioni che nessuno sa spiegare.
Perché i test, per quanto estesi, non possono garantire la sicurezza
Il paradigma dominante nella valutazione dell'IA oggi è il test empirico su dataset trattenuti. Addestri il tuo modello sul Dataset A, poi lo valuti sul Dataset B. Se funziona bene su B, assumi che abbia "imparato" il compito sottostante e che generalizzerà alla distribuzione nel mondo reale.
Questo approccio ha tre problemi fondamentali che nessuna quantità di test può risolvere.
Problema uno: lo spazio di input infinito
I test possono solo dimostrare la presenza di bug, mai la loro assenza. Non importa quanti casi di test esegui, stai campionando da uno spazio di input infinito. Un sistema che controlla un dispositivo medico deve gestire non solo gli scenari di test che hai immaginato, ma ogni possibile combinazione di fisiologie del paziente, condizioni ambientali, letture dei sensori e casi limite che il mondo reale produrrà alla fine.
Immagina di cercare di dimostrare che non ci sono aghi in un pagliaio raccogliendo a caso pezzi di paglia. Dopo aver esaminato un milione di pezzi senza trovare aghi, non puoi concludere che il pagliaio sia privo di aghi. Puoi solo dire che non ne hai ancora trovato uno. I test funzionano allo stesso modo. Non importa quanti scenari superino, il prossimo potrebbe fallire.
Problema due: la vulnerabilità avversaria
Le reti neurali profonde sono particolarmente vulnerabili agli input avversari. Si tratta di perturbazioni accuratamente progettate che causano il fallimento catastrofico dei modelli pur apparendo normali agli osservatori umani.
Un modello potrebbe classificare correttamente i segnali di stop nel 99,99% dei casi, ma un piccolo adesivo posizionato in un punto specifico potrebbe indurlo a classificare con sicurezza il segnale come limite di velocità. Un modello potrebbe identificare con precisione condizioni mediche in migliaia di radiografie, ma uno specifico pattern di rumore, invisibile ai radiologi umani, potrebbe fargli mancare tumori evidenti.
Non sono preoccupazioni teoriche. I ricercatori hanno dimostrato attacchi avversari contro ogni grande classe di architettura di rete neurale. E gli attacchi stanno diventando più facili da costruire mentre le difese rimangono incomplete.
Il testing non può proteggere dalle vulnerabilità avversarie perché la superficie di attacco è infinita. Dovresti testare non solo gli input normali, ma ogni possibile perturbazione di ogni input normale. È matematicamente impossibile.
Problema tre: lo spostamento distribuzionale
Il mondo reale non sta fermo. La distribuzione dei dati su cui il tuo modello è stato addestrato si sposterà nel tempo. Le popolazioni di pazienti cambiano. Le condizioni di guida si evolvono. I processi di produzione variano. Il degrado dei sensori si verifica.
Un modello che funziona perfettamente sui dati di oggi potrebbe fallire silenziosamente quando i dati di domani si spostano fuori dalla sua distribuzione di addestramento. E a differenza degli errori espliciti che mandano in crash i programmi, questi fallimenti spesso producono output sbagliati ma sicuri e plausibili.
Testare sui dati di oggi non ti dice nulla sulle prestazioni di domani. Quando osservi il fallimento in produzione, il danno è già avvenuto.
Verifica formale: la matematica come linguaggio universale della sicurezza
La verifica formale offre un approccio completamente diverso. Invece di chiedersi "il sistema ha funzionato su questi casi di test?" si chiede "possiamo dimostrare matematicamente che il sistema soddisferà una proprietà per tutti i possibili input?"
La differenza è profonda. Il testing campiona lo spazio degli input. La verifica ragiona in modo esaustivo sull'intero spazio.
Consideriamo un braccio robotico che lavora insieme agli esseri umani in una fabbrica. Vogliamo garantire una proprietà di sicurezza: "Il braccio non deve mai superare i 2 metri al secondo quando viene rilevata la presenza di un essere umano entro 1 metro."
L'approccio del testing fa eseguire al braccio migliaia di scenari con esseri umani simulati in varie posizioni e velocità, misurando se il limite di sicurezza viene mai violato. Se non si osservano violazioni, il sistema viene dichiarato "sicuro". Ma lo scenario successivo, quello che non è stato testato, potrebbe essere quello che ferisce un lavoratore.
L'approccio della verifica è fondamentalmente diverso. Prendiamo il modello matematico del sistema di controllo, inclusa la rete neurale che elabora i dati dei sensori e il controller che genera i comandi motori. Esprimiamo la proprietà di sicurezza come un vincolo formale. Poi usiamo algoritmi specializzati chiamati risolutori SMT (Satisfiability Modulo Theories) per rispondere a una domanda precisa: "Esiste UNA qualsiasi configurazione di input, nell'intervallo operativo valido, per cui la velocità di uscita supera i 2 m/s quando viene rilevata la prossimità di un essere umano?"
Il risolutore non testa punti casuali. Analizza la struttura matematica dell'intero sistema. Ragiona sulla geometria dello spazio delle funzioni. Se restituisce "UNSAT" (insoddisfacibile), abbiamo una prova matematica che non esiste alcun input violante. La proprietà di sicurezza vale non solo per i casi che abbiamo testato, ma per ogni caso possibile che possa mai verificarsi.
Questa è la differenza tra "ho controllato molti ponti e nessuno è crollato" e "la fisica di questi materiali garantisce matematicamente che questo ponte non può crollare sotto questo carico". La prima è un'osservazione empirica soggetta a revisione. La seconda è una certezza logica.
Perché l'IA moderna resiste alla verifica
Se la verifica formale è così potente, perché non la usa tutti? Perché aziende come OpenAI e Google si affidano al "red teaming" (esseri umani che cercano di far fallire il modello) invece che a prove matematiche?
La risposta sta nelle scelte architetturali che l'industria ha fatto. I moderni modelli linguistici di grandi dimensioni e le reti neurali profonde sono progettati per l'espressività, non per la verificabilità. Sono ottimizzati per generare output creativi, non per essere matematicamente analizzabili.
Un tipico modello transformer ha miliardi o trilioni di parametri. Usa funzioni di attivazione complesse e non lineari come GeLU o Swish. La complessità matematica della verifica di un tale sistema cresce esponenzialmente con il numero di neuroni e la profondità della rete.
Dimostrare una proprietà su un transformer con un miliardo di parametri è computazionalmente intrattabile. L'universo raggiungerebbe la morte termica prima che il risolutore finisca di esplorare tutti i rami matematici. L'industria ha costruito sistemi così complessi che nemmeno i loro creatori possono analizzarli completamente.
Questa è una scelta progettuale, non un'inevitabilità. Il settore si è ottimizzato per demo impressionanti e punteggi benchmark senza considerare se i sistemi risultanti potessero mai essere implementati in modo sicuro in ambienti regolamentati.
L'architettura Dweve: verificabile per progettazione
In Dweve abbiamo fatto scelte architetturali diverse. Abbiamo progettato i nostri sistemi da zero per essere verificabili, perché abbiamo capito che i clienti enterprise e industriali avrebbero prima o poi dovuto soddisfare i regolatori, non solo impressionarli.
Il nostro approccio combina due innovazioni chiave che rendono trattabile la verifica.
Binary Constraint Discovery: matematica semplice
Invece di enormi reti neurali a virgola mobile con miliardi di parametri continui, i sistemi Dweve usano Binary Constraint Discovery. La conoscenza è rappresentata come vincoli logici discreti piuttosto che come pesi continui appresi.
La nostra libreria Dweve Core contiene 1.937 algoritmi ottimizzati per l'hardware basati su operazioni binarie: XNOR, AND, OR, POPCNT. Queste operazioni hanno proprietà matematiche semplici e ben comprese. Un vincolo binario o vale o non vale. Non c'è incertezza probabilistica.
Limitando la matematica a semplici relazioni lineari e logica booleana, riduciamo drasticamente lo spazio di ricerca della verifica. Problemi che sarebbero intrattabili per le reti neurali continue diventano risolvibili per i nostri sistemi a vincoli binari. Il problema della verifica si trasforma da ottimizzazione non lineare impossibile a problemi risolvibili di Mixed Integer Linear Programming (MILP) o SAT.
Questi restano problemi computazionalmente difficili, ma per le dimensioni dei sistemi che implementiamo in applicazioni critiche per la sicurezza, i solver moderni possono gestirli in secondi o minuti, non in secoli.
L'architettura a sei livelli di autonomia limitata
Non cerchiamo di verificare ogni aspetto della percezione dell'IA. Riconoscere che "una griglia di pixel rappresenta un essere umano" è intrinsecamente un giudizio vago e probabilistico. Non si può dimostrare formalmente che il riconoscimento di pattern sia sempre corretto, perché la correttezza dipende da definizioni soggettive.
Implementiamo invece un'architettura di sicurezza a livelli in cui i componenti probabilistici dell'IA sono delimitati da vincoli logici verificati formalmente. L'IA può suggerire azioni, ma quei suggerimenti devono passare attraverso gate di sicurezza verificati prima dell'esecuzione.
Dweve Nexus implementa sei livelli di applicazione della sicurezza:
- Verifica dell'intento: valida che le azioni dell'IA siano allineate agli obiettivi dichiarati
- Autonomia limitata: limiti rigidi su quali azioni sono consentite a prescindere dai suggerimenti dell'IA
- Moderazione dei contenuti: filtra gli output per sicurezza e appropriatezza
- Applicazione dell'etica: garantisce il rispetto dei vincoli etici definiti
- Rilevamento delle anomalie: identifica quando il comportamento dell'IA si discosta dai pattern attesi
- Monitoraggio runtime: verifica continua che gli invarianti di sicurezza siano mantenuti
L'intuizione critica è che dobbiamo verificare formalmente solo i livelli di sicurezza, non l'intero sistema di IA. Anche se l'IA sottostante commette un errore, il livello di autonomia limitata garantisce matematicamente che i comandi pericolosi non raggiungano mai gli attuatori.
La matematica regolatoria: perché la verifica crea valore commerciale
Per i nostri clienti, la verifica formale non è un esercizio accademico. È un vantaggio competitivo che si traduce direttamente in risultati di business.
Approvazione regolatoria più rapida
Quando un produttore di dispositivi medici si presenta alla FDA o all'EMA con un sistema basato sull'IA, i regolatori sono giustamente cauti. Sanno che l'IA può essere imprevedibile. I processi di approvazione standard richiedono anni di sperimentazioni cliniche per dimostrare statisticamente la sicurezza.
Ma un produttore che utilizza componenti Dweve formalmente verificati può cambiare il discorso. Invece di presentare risultati di test che dimostrano "non abbiamo ancora osservato guasti", può presentare prove matematiche che dimostrano "i guasti sono impossibili entro questi limiti".
"Non ci limitiamo a pensare che questo microinfusore non somministrerà dosi eccessive ai pazienti. Ecco la prova formale che il dosaggio in uscita è matematicamente vincolato dal peso del paziente e dai vincoli di glucosio. La violazione non è semplicemente improbabile. È logicamente impossibile."
Questo consente percorsi di revisione accelerati. I regolatori possono verificare la prova in modo indipendente. Non devono fidarsi del processo di test; possono esaminare direttamente la matematica.
Premi assicurativi ridotti
Gli attuari assicurativi affrontano un problema impossibile con i sistemi di IA tradizionali. Come si prezza il rischio per modalità di guasto che non si possono prevedere o spiegare? Il risultato è o premi estremamente elevati per coprire rischi sconosciuti, o clausole di esclusione che rendono l'assicurazione praticamente inutile.
I sistemi verificati cambiano il calcolo attuariale. Se una prova matematica garantisce che certi tipi di guasto non possono verificarsi, quelle modalità di guasto possono essere escluse dal modello di rischio. I rischi rimanenti sono quantificabili. I premi diminuiscono di conseguenza.
Alcuni dei nostri clienti hanno visto i costi dell'assicurazione di responsabilità civile diminuire del 40-60% dopo l'implementazione di livelli di sicurezza verificati, semplicemente perché gli assicuratori ora possono calcolare rischi limitati invece di prezzare un'incertezza illimitata.
Difendibilità legale
Quando i sistemi di IA causano danni, seguono le cause legali. Nelle implementazioni di IA tradizionali, difendere il sistema è quasi impossibile. "Come ha fatto il suo sistema a prendere questa decisione?" "Non lo sappiamo esattamente, è una rete neurale con miliardi di parametri..." Questa risposta non soddisfa nessun giudice o giuria.
I sistemi verificati offrono una difesa diversa: "Ecco il vincolo di sicurezza. Ecco la prova matematica che il vincolo non può essere violato. Il danno si è verificato al di fuori del confine verificato, indicando fattori esterni, non un guasto del sistema."
Non si tratta di evitare la responsabilità. Si tratta di poter dimostrare esattamente quali garanzie sono state fornite e se sono state rispettate. I tribunali comprendono la logica formale. Comprendono le prove matematiche. Non comprendono gli intervalli di confidenza probabilistici.
L'AI Act dell'UE: la verifica diventa obbligatoria
I vantaggi teorici della verifica formale stanno diventando requisiti pratici. L'AI Act dell'UE, entrato in vigore nel 2024 con attuazione graduale fino al 2027, cambia radicalmente ciò che è legalmente richiesto per le implementazioni di IA in Europa.
Per i sistemi di IA "ad alto rischio", che includono dispositivi medici, decisioni di assunzione, valutazioni di affidabilità creditizia e molte applicazioni industriali, l'Atto richiede:
- Sistemi di gestione del rischio che identifichino e mitighino i rischi prevedibili
- Dati di addestramento di alta qualità con provenienza documentata
- Capacità di registrazione che consentano di tracciare il comportamento del sistema
- Trasparenza verso gli utenti riguardo alle decisioni prese dall'IA
- Meccanismi di supervisione umana che permettano l'intervento
- Accuratezza, robustezza e cybersicurezza adeguate all'applicazione
Notate il linguaggio: "rischi prevedibili", "comportamento tracciabile", "accuratezza adeguata all'applicazione". Non sono vaghe aspirazioni. Sono requisiti legali con denti di enforcement, incluse multe fino a 35 milioni di euro o il 7% del fatturato globale.
Come si dimostra di aver identificato e mitigato i "rischi prevedibili" per una rete neurale con miliardi di parametri il cui processo decisionale è opaco persino ai suoi creatori? Come si mostra che il comportamento è "tracciabile" quando il sistema produce output attraverso moltiplicazioni matriciali incomprensibili?
Le architetture IA tradizionali non possono soddisfare questi requisiti con la sola documentazione e i test. Ma i sistemi verificati sì. La prova è la documentazione. La garanzia matematica è la mitigazione. I vincoli logici sono la tracciabilità.
I 456 specialisti di dominio: scala verificabile
Un'obiezione comune all'IA verificata è che la verifica non scala. Per sistemi semplici con poche regole, sì, la verifica funziona. Ma l'IA del mondo reale deve gestire percezione e ragionamento complessi. Come può funzionare la verifica su larga scala?
Dweve Loom dimostra che verifica e capacità non si escludono a vicenda. Il nostro modello di base utilizza 456 insiemi di vincoli specializzati, ciascuno contenente 64-128MB di vincoli binari. Ma solo 4-8 specialisti di dominio si attivano per ogni singola query.
Questa architettura, che chiamiamo attivazione ultra-sparsa, significa che lo sforzo di verifica scala con il sottoinsieme attivo, non con l'intero modello. Non dobbiamo verificare tutte le 456 combinazioni di specialisti di dominio simultaneamente. Verifichiamo la logica di routing che seleziona gli specialisti di dominio e verifichiamo l'insieme di vincoli di ciascuno specialista in modo indipendente.
Il sistema di routing Permuted Agreement Popcount (PAP) utilizza il rilevamento di pattern strutturali per selezionare gli specialisti di dominio pertinenti. Questo livello di routing è esso stesso formalmente verificabile perché opera su operazioni binarie discrete con proprietà matematiche ben definite.
Il risultato è un sistema in grado di gestire compiti complessi del mondo reale mantenendo la trattabilità della verifica. Otteniamo i vantaggi di capacità delle architetture mixture-of-experts con i vantaggi di sicurezza della verifica formale.
Implementazione: come appare realmente la verifica
Per le organizzazioni che considerano l'implementazione di IA verificata, il processo pratico prevede diverse fasi.
Fase 1: specifica delle proprietà
Prima che la verifica inizi, è necessario definire quali proprietà devono essere verificate. Questo è spesso il passo più difficile, che richiede una stretta collaborazione tra esperti di dominio, ingegneri e team legali/di conformità.
Le proprietà devono essere precise e matematicamente esprimibili. "Il sistema dovrebbe essere sicuro" non è una proprietà verificabile. "Il comando di velocità del motore non deve superare V_max quando il sensore di prossimità indica una distanza inferiore a D_min" è verificabile.
In Dweve aiutiamo i clienti in questo processo di specifica utilizzando Spindle, la nostra piattaforma di governance della conoscenza aziendale. La gerarchia di 32 agenti include specialisti in conformità normativa che aiutano a tradurre i requisiti legali in vincoli formali.
Fase 2: mappatura dell'architettura
L'architettura del sistema di IA deve essere mappata in un modello formale che gli strumenti di verifica possano analizzare. Per i sistemi Dweve questa mappatura è semplice, perché la nostra architettura a vincoli binari è stata progettata per la verificabilità.
Per le organizzazioni con implementazioni di reti neurali esistenti, questa fase può richiedere modifiche architetturali. Aggiungere livelli di autonomia limitata attorno ai modelli esistenti, implementare vincoli di sicurezza come wrapper verificati o, in alcuni casi, sostituire componenti non verificabili con equivalenti Dweve.
Fase 3: esecuzione della verifica
I moderni solver SMT e gli strumenti di verifica formale analizzano il modello di sistema per dimostrare le proprietà specificate o identificare controesempi. I controesempi sono preziosi perché rivelano esattamente quali input potrebbero violare i vincoli di sicurezza, consentendo correzioni mirate.
Per i sistemi Dweve la verifica richiede in genere da minuti a ore, a seconda della complessità dei vincoli. I 1.937 algoritmi di Dweve Core sono già stati pre-verificati per le proprietà di sicurezza comuni, quindi la verifica spesso consiste nel comporre componenti pre-verificati piuttosto che partire da zero.
Fase 4: certificazione e documentazione
Le proprietà verificate generano artefatti di prova che fungono da evidenza per la certificazione. Queste prove sono verificabili meccanicamente, il che significa che i regolatori possono verificarle in modo indipendente con strumenti standard di controllo delle prove, senza doversi fidare del processo di verifica originale.
Dweve Fabric, la nostra dashboard unificata della piattaforma, genera automaticamente la documentazione di conformità dai risultati della verifica. Le stesse prove che soddisfano il solver diventano il pacchetto di evidenza per la presentazione normativa.
Il futuro: l'IA verificata come pratica standard
Siamo a un punto di svolta nell'implementazione dell'IA. L'era del "muoviti in fretta e rompi le cose" sta finendo per le applicazioni ad alto rischio. Il contesto normativo si sta inasprendo. L'esposizione alla responsabilità legale sta aumentando. Le sfide assicurative si stanno accumulando.
Le organizzazioni che implementano l'IA in settori regolamentati devono fare una scelta. Possono continuare con le architetture tradizionali e affrontare un'attrito crescente: processi di approvazione più lunghi, costi assicurativi più elevati, maggiore esposizione legale, potenziale esclusione dal mercato man mano che le normative entrano in vigore.
Oppure possono adottare architetture verificate che soddisfano i regolatori con certezza matematica anziché con speranza statistica.
La rivoluzione della verifica non consiste nel rendere l'IA meno capace. Consiste nel rendere l'IA affidabile in modi che contano per tutti coloro che stanno oltre il laboratorio di ricerca: pazienti, operatori, assicuratori, regolatori e tribunali. Si tratta di costruire un'IA che gli esseri umani possano davvero implementare con fiducia.
In Dweve crediamo che il futuro appartenga ai sistemi di IA che possono dimostrare la propria sicurezza, non solo prometterla. La nostra architettura, dai 1.937 algoritmi verificati in Core ai sei livelli di autonomia limitata in Nexus ai 456 set di vincoli specialistici di dominio in Loom, è costruita da zero per questo futuro.
La matematica della certezza non è un vincolo al progresso dell'IA. È il fondamento per la distribuzione dell'IA su larga scala.
Pronti a distribuire un'IA che i regolatori possano approvare? L'architettura formalmente verificata di Dweve offre le garanzie matematiche che trasformano gli ostacoli normativi in vantaggi competitivi. Contattateci per discutere di come la verifica possa accelerare il vostro percorso verso il mercato riducendo al contempo la vostra esposizione alla responsabilità.