E se la governance dell’IA fosse parte integrante del software?
C’è un momento, in quasi ogni azienda che sviluppa software, che conosco bene. Il sistema di intelligenza artificiale è stato finalmente completato. I modelli sono addestrati, le API collaudate, l’infrastruttura scalata. A quel punto, qualcuno si alza dalla sedia e domanda: “E ora, come facciamo a dimostrare che questo coso è conforme al Regolamento Europeo sull’IA?”.
Quello che segue è quasi sempre lo stesso copione. Si innescano processi di compliance paralleli. Consulenti legali stilano documenti; i tecnici aggiungono moduli di logging ai margini del codice esistente; si scrivono procedure per permettere a un essere umano di sovrascrivere la macchina. Si crea, di fatto, un gap strutturale tra l’intelligenza artificiale che prende le decisioni e gli strati esterni che cercano di giustificarle.
Questo approccio non è solo inefficiente. È pericoloso. Perché basa la conformità a una legge severa – l’AI Act, Regolamento (UE) 2024/1689 – su controlli che possono essere aggirati, dimenticati o, peggio, manipolati.
Da questa riflessione nasce PENSAI. Non come una nuova intelligenza artificiale, ma come un tentativo di risolvere il problema a monte.
Il divario tra la norma e l’implementazione
Il Regolamento Europeo non parla di algoritmi. Parla di proprietà che il sistema deve avere. L’Articolo 12 impone un registro automatico dei log. L’Articolo 14 richiede che un umano possa sovrascrivere la decisione della macchina. L’Articolo 9 chiede il monitoraggio continuo del rischio, il cosiddetto drift detection.
Nella pratica ingegneristica standard, questi requisiti vengono letti come funzionalità da aggiungere. Serve un override? Aggiungiamo un bottone nell’interfaccia e un UPDATE nel database che cambia lo stato della decisione. Serve l’audit? Scriviamo le azioni in un file di log.
Il problema è che un bottone o un UPDATE possono essere richiamati da un codice malevolo, o semplicemente buggati. Un file di log su disco può essere modificato da un amministratore di sistema con privilegi elevati. In caso di controversia legale o di audit formale, la dogana tra ciò che il software dovrebbe fare e ciò che ha fatto effettivamente si basa sulla fiducia.
La fiducia, in informatica, non è una misura di sicurezza accettabile.
PENSAI: Un framework deterministico di governance decisionale
PENSAI è un framework di governance. Non è un modello di Machine Learning, non genera testo, non riconosce immagini. È un motore logico progettato per gestire decisioni Multi-Criterio (MCDA – Multi-Criteria Decision Analysis) in modo strettamente deterministico.
Il suo scopo è valutare un insieme di opzioni sulla base di una rubrica di pesi e vincoli, producendo una classifica finale. Può essere usato per selezionare un fornitore, assegnare un punteggio di credito o prioritizzare interventi.
La differenza rispetto a un normale sistema di scoring sta nell’architettura. In PENSAI, i requisiti dell’AI Act non sono documentati in un manuale esterno. Sono tradotti in vincoli architetturali del codice stesso. In gergo tecnico, un approccio di Compliance by Construction.
Cosa fa e cosa non fa
È fondamentale essere precisi. PENSAI non rende un sistema “sicuro” per definizione magica. Se i dati in ingresso sono errati o la rubrica di valutazione è ingiusta, il risultato sarà errato o ingiusto. Il framework garantisce un’altra cosa: che il processo decisionale, una volta definito, si svolga esattamente secondo le regole dichiarate, senza deviazioni silenti, e che ogni passo sia matematicamente inalterabile.
“Compliance by Construction”: la traduzione architetturale
Vediamo concretamente come un requisito normativo si trasforma in un vincolo di programmazione.
Dalla tracciabilità all’immutabilità
L’AI Act richiede che le decisioni siano tracciabili e che i log non possano essere alterati. Invece di scrivere funzioni che “impediscano” la modifica, PENSAI utilizza il paradigma dell’immutabilità assoluta.
In PHP, il linguaggio con cui è scritto, le classi che rappresentano lo stato del sistema sono definite final e le loro proprietà readonly. Questo significa che, una volta che una decisione è stata calcolata, il compilatore stesso vieta qualsiasi modifica a quella variabile in memoria. Non c’è un database sottostante che possa essere aggiornato con una query SQL. L’oggetto decisionale esiste, e muore, in quello stato. La tracciabilità non è una policy applicata; è una proprietà fisica del sistema.
L’override umano senza distruzione
L’Articolo 14 dell’AI Act è forse il più interessante da un punto di vista ingegneristico. Stabilisce che se un umano prende il controllo, questo deve essere documentato e non deve eliminare la traccia di ciò che l’IA aveva decotto prima.
Nella maggior parte dei software, l’override sovrascrive il record precedente. In PENSAI, la classe Decision gestisce l’override tramite una OverrideChain. Quando un operatore umano interviene, il sistema non modifica la decisione originaria. Genera un nuovo stato decisionale che contiene al suo interno, incapsulata e sigillata, la decisione precedente insieme ai metadati dell’intervento umano (chi, quando, perché). È concettualmente simile a come funziona una blockchain: non si riscrive la storia, si aggiunge un blocco confermato.
Analisi tecnica e meccanismo di salvaguardia
Questa rigidità architetturale si estende all’integrità dei dati. Prima di elaborare qualsiasi cosa, il sistema verifica che la rubrica di valutazione (i pesi assegnati ai criteri) non sia cambiata di nascosto rispetto a una registrazione precedente, confrontando gli hash crittografici SHA-256. Se anche un solo decimale del peso di un criterio è stato alterato, il sistema si ferma. Rifiuta di procedere (fail-safe).
Per la sicurezza dell’input, invece di affidarsi a espressioni regolari lente e fallibili, PENSAI implementa l’algoritmo di Aho-Corasick per scansionare in modo deterministico e simultaneo migliaia di pattern di iniezione (come attacchi XSS o SQL injection) annidati nei metadati, prima che questi raggiungano la logica decisionale.
Critica, limiti e onestà intellettuale
Descrivere l’architettura non significa ignorarne i confini. Una valutazione onesta deve evidenziare dove questo approccio incontra i propri limiti.
In primo luogo, PENSAI è strettamente deterministico. Questo lo rende inadatto per domini in cui la decisione richiede stocasticità, come l’elaborazione del linguaggio naturale generativo o la visione computazionale. Si applica a contesti dove le regole di valutazione possono essere espresse come vincoli logici e matematici espliciti.
In secondo luogo, la gestione dell’incertezza al suo interno è attualmente euristicamente lineare, non probabilistica. Se un dato in ingresso ha un’incertezza, il sistema applica una penalità proporzionale al caso peggiore. È un approccio pragmatico, ma non eguaglia la robustezza di reti bayesiane o simulazioni Monte Carlo per la valutazione del rischio sotto incertezza profonda. È un aspetto che sto esplorando per evoluzioni future del framework.
Infine, l’architettura impone un rigore che ha un costo in termini di complessità iniziale di sviluppo. Definire oggetti immutabili e gestire catene di override richiede una disciplina ingegneristica che non tutti i team sono pronti ad adottare senza un ripensamento dei loro flussi di lavoro.
Il ruolo della documentazione e del dialogo aperto
Un’architettura solida non basta se il contesto normativo rimane oscuro. Per questo motivo, oltre al codice, ho ritenuto indispensabile affiancare una documentazione che mappasse esplicitamente ogni riga chiave del framework agli articoli specifici del Regolamento Europeo.
Se desideri approfondire questi temi in modo più discorsivo, è disponibile anche il podcast di pensai.eu, dove vengono affrontati aspetti tecnici, normativi e progettuali con esempi pratici, cercando di smontare la complessità dell’AI Act passo dopo passo.
Conclusioni
Non esiste una soluzione tecnica che risolva i problemi etici o sociali dell’intelligenza artificiale. Questi rimangono di competenza umana, legislativa e filosofica.
Tuttavia, quando il legislatore scrive una legge con impatti ingegneristici, l’informatica ha il dovere di rispondere con strumenti adeguati. Continuare a trattare la compliance come un esercizio di redazione testuale post-hoc significa costruire edifici senza fondamenta, sperando che non ci sia un terremoto.
PENSAI dimostra che, almeno per i sistemi decisionali deterministici classificati ad alto rischio, è possibile tradurre i requisiti giuridici in proprietà matematiche del software. Non è una bacchetta magica. È semplicemente ingegneria applicata al diritto.
Bibliografia e Fonti Ufficiali
- Parlamento Europeo, Regolamento (UE) 2024/1689 del Parlamento Europeo e del Consiglio del 13 giugno 2024 relativo all’intelligenza artificiale (AI Act). Pubblicato sulla Gazzetta Ufficiale dell’Unione Europea.
- T. L. Saaty, Decision making with the analytic hierarchy process, Int. J. Services Sciences, 2008. (Per i fondamenti teorici dell’analisi multi-criterio MCDA).
- M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002. (Per i concetti di architettura esagonale e immutabilità).
- A. V. Aho, M. J. Corasick, Efficient string matching: An aid to bibliographic search, Communications of the ACM, 1975. (Per l’algoritmo di pattern matching implementato nel layer di sicurezza).
- M. G. Kendall, A new measure of rank correlation, Biometrika, 1938. (Per la metrica statistica alla base del rilevamento del drift).
Salvatore Martino Autore del framework PENSAI e fondatore di OfflineMind.
Podcast mp3
Si occupa di governance dell’intelligenza artificiale, sistemi decisionali deterministici e progettazione di architetture software orientate alla trasparenza, all’auditabilità e alla conformità normativa.
Sito Ufficiale: https://pensai.eu –
Blog: https://offlinemind.com
