OpenComplAI è progettato per mantenere separata la logica di valutazione dei rischi dell’IA dalle regole usate per rappresentare uno specifico framework normativo. In un post pubblicato su DEV Community il 27 ottobre, lo sviluppatore del progetto ha descritto questo approccio come un motore riutilizzabile per valutare controlli ed evidenze, con i requisiti specifici delle normative gestiti in un livello di mappatura.
L’attenzione immediata resta sull’EU AI Act: lo sviluppatore afferma che attualmente la maggior parte delle regole codificate in OpenComplAI riguarda tale normativa. L’obiettivo architetturale, tuttavia, è evitare che il motore stesso dipenda dalla terminologia dell’EU AI Act. Questa separazione dovrebbe consentire di adattare il sistema ad altri framework senza ricostruirne il meccanismo centrale di valutazione.
Un motore generale con mappature specifiche per i framework
In questo design, il motore centrale valuta i controlli e le relative evidenze, mentre una mappatura delle policy collega questi elementi sottostanti ai requisiti di un framework scelto. La distinzione è importante: un controllo è un elemento costitutivo della valutazione, mentre una mappatura spiega in che modo tale elemento si rapporta a una specifica policy o normativa.
Lo sviluppatore afferma che il pacchetto centrale non ha dipendenze HTTP e non usa nomi specifici delle normative nelle proprie primitive. Gli strumenti da riga di comando e i servizi usano invece il motore e applicano la mappatura caricata. In questo modo il sistema stabilisce un confine tra le funzioni generali di valutazione dei rischi e l’interpretazione specifica del framework che vi si sovrappone.
Secondo lo sviluppatore, codificare direttamente nella logica di valutazione la formulazione di una singola normativa renderebbe più oneroso supportare ogni framework aggiuntivo. L’aggiunta di un’altra giurisdizione o standard potrebbe quindi richiedere modifiche in tutto il motore o la creazione di un fork separato. Con un livello di mappatura, l’alternativa prevista è lasciare invariato il processo generale di valutazione e aggiungere, quando necessario, una nuova mappatura delle policy.
Lo sviluppatore descrive questa scelta come una scommessa architetturale, non come un risultato dimostrato. Il post invita a fornire riscontri ai team che lavorano con un secondo framework, anziché basarsi soltanto su un’ipotesi formulata in fase di progettazione. L’esperienza pratica con un altro framework rappresenta quindi il prossimo test significativo dell’approccio.
Funzionalità attualmente supportate dal progetto
Il repository GitHub di OpenComplAI descrive il progetto come uno strumento open source per la conformità, in grado di eseguire valutazioni dei rischi nelle pipeline CI/CD. Indica che l’EU AI Act viene valutato in modo nativo, mentre la valutazione rispetto a NIST AI RMF è ricavata dalle stesse evidenze tramite una crosswalk. Il repository definisce parziale e non verificato il supporto a NIST e specifica che non esiste uno scanner NIST separato.
Il repository descrive diversamente ISO/IEC 42001: offre un pacchetto basato su attestazioni, nel quale le voci restano non verificate finché non viene registrata un’attestazione. Indica inoltre DORA ed EBA come semplicemente mappati. Queste distinzioni sono importanti perché una mappatura di un framework non equivale necessariamente a un’implementazione completa e valutata in modo indipendente.
Il post dello sviluppatore e la descrizione più dettagliata del repository pongono l’accento su aspetti diversi. Il post afferma che l’architettura può supportare una mappatura a NIST RMF o ISO 42001 senza riscrivere la logica di valutazione dei rischi. Il repository, invece, precisa che la copertura attuale di NIST e ISO è parziale e non verificata e spiega che i due framework vengono gestiti in modi diversi. La possibilità architetturale non va quindi interpretata come un’affermazione secondo cui ogni framework è già pienamente supportato.
Il progetto chiarisce inoltre che i suoi risultati non costituiscono una certificazione di conformità. Il repository descrive artefatti di evidenza, controlli e flussi di lavoro per la documentazione, precisando che la documentazione generata può contenere segnaposto quando non sono state fornite informazioni richieste. I team devono comunque fornire e verificare le evidenze, decidere quali obblighi si applicano e valutare se la copertura dello strumento soddisfa le proprie esigenze.
Perché la separazione è importante per gli sviluppatori
Il lavoro sulla conformità dell’IA può coinvolgere requisiti di prodotto, controlli tecnici, evidenze a supporto e processi di rilascio. Quando questi aspetti sono legati direttamente a un unico framework all’interno di una codebase, le modifiche all’ambito normativo possono intrecciarsi con quelle alla logica di rischio sottostante. Separare la mappatura dal motore offre agli sviluppatori un modo per mantenere più distinti questi aspetti.
Questa struttura può anche rendere il software più facile da esaminare. Un team può chiedersi quali controlli verifica il motore, quali evidenze richiede e in che modo il framework selezionato viene mappato su tali controlli. La mappatura diventa una parte verificabile dell’implementazione della conformità, anziché un presupposto implicito disseminato nel codice di valutazione.
Per i team che usano l’integrazione continua, strumenti di questo tipo possono avvicinare i controlli di conformità al flusso di lavoro di sviluppo. Il repository di OpenComplAI descrive controlli automatizzati eseguibili prima del rilascio, che producono esiti positivi o negativi. In generale, un gate della pipeline può aiutare i team a individuare durante lo sviluppo controlli o evidenze mancanti, ma la sua utilità dipende da ciò che verifica effettivamente e dall’aggiornamento e completezza dei dati in ingresso.
La separazione ha anche dei limiti. Una mappatura può rappresentare soltanto ciò che è stato codificato e verificato. Se due framework definiscono obblighi diversi, trasferire le evidenze da un insieme all’altro può risultare incompleto o inappropriato. Le descrizioni qualificate della copertura NIST e ISO nel repository sottolineano perché i team dovrebbero esaminare lo stato specifico di ciascun framework, anziché presumere che un motore condiviso garantisca la stessa profondità per tutti i regimi.
Prossime valutazioni per i team
OpenComplAI viene presentato come software open source per integrare i controlli di conformità dell’IA nelle pipeline di sviluppo. Il repository descrive un’interfaccia a riga di comando, un SDK Python e integrazioni CI, oltre a servizi per attività quali la valutazione dei rischi e la gestione delle evidenze. La pagina dei prezzi afferma che la versione open source è gratuita con licenza AGPL-3.0; l’offerta Enterprise aggiunge una dashboard ospitata, supporto e altri servizi destinati alle organizzazioni.
Per gli sviluppatori che valutano questo approccio, un passo successivo utile consiste nell’esaminare il confine tra il nucleo e le sue mappature, quindi testare lo strumento su un sistema reale e sugli obblighi del framework pertinenti a quel sistema. I team dovrebbero verificare quali controlli sono nativi, quali sono derivati o basati su attestazioni, quali evidenze sono richieste e come vengono gestite quelle incomplete o obsolete. Dovrebbero inoltre confermare in che modo la licenza del progetto si applica all’uso previsto.
Il prossimo test per il progetto è una convalida più ampia. Lo sviluppatore desidera ricevere riscontri da chi applica lo stesso motore a un secondo framework. Se questo lavoro dimostrerà che è possibile aggiungere una nuova mappatura senza modifiche invasive al nucleo, sosterrà l’affermazione centrale del design. Se invece farà emergere presupposti incorporati nelle primitive di valutazione, potrebbe essere necessario modificare l’architettura.
Per ora, OpenComplAI offre un esempio concreto di policy normative trattate come un livello sovrapposto a un meccanismo riutilizzabile di valutazione dei rischi. Questa distinzione è utile agli sviluppatori perché rende visibile il confine del framework. La flessibilità architetturale, tuttavia, non dimostra la completezza della conformità: sono ancora le mappature, le evidenze e il processo di revisione a determinare ciò che un sistema può valutare in modo significativo.
Fonti: DEV Community, The Verge, TechCrunch, GitHub, Opencomplai
