Governare l’intelligenza artificiale prima di usarla: la compliance comincia dall’architettura

intervista a Amir Topalovic, CEO di AISMA

Il workshop “IA al lavoro” del 6 ottobre a Palazzo Cusani parla di responsabilità del committente, supply chain e Decreto Controlli. Che cosa c’entra la governance dell’intelligenza artificiale?

C’entra perché il principio è lo stesso. Il committente risponde anche di ciò che non esegue direttamente: dei fornitori, dei subappalti, delle condizioni di lavoro lungo la filiera, della manutenzione degli impianti affidata a terzi. Con l’intelligenza artificiale accade qualcosa di analogo. Un’organizzazione risponde delle decisioni prese con il supporto di strumenti di cui spesso non conosce il funzionamento, che elaborano dati di cui non sempre controlla la provenienza.
Oggi l’adozione dell’AI procede più velocemente della sua governance, e il rischio non è più soltanto tecnologico: è organizzativo, reputazionale e regolamentare. Proprio per questo gli strumenti di monitoraggio della compliance, se basati sull’AI, devono essere a loro volta governati.
Pensiamo al Decreto Controlli: un sistema che monitora scadenze di manutenzione e qualifiche dei tecnici è utile solo se le sue segnalazioni sono affidabili e ricostruibili. Una segnalazione mancata o non documentata non riduce il rischio del committente: lo sposta, rendendolo meno visibile.

Che cosa significa, concretamente, governare un progetto di intelligenza artificiale?

Significa poter rispondere in ogni momento a una domanda precisa: chi ha l’autorità di applicare una determinata conoscenza, in quale versione, con quali vincoli e con quale tracciabilità? Non basta sapere quali documenti l’AI ha consultato. Occorre sapere se quella conoscenza poteva essere usata per quella decisione, da quella persona, con quella autorizzazione. È la distinzione tra governance della conoscenza e governance della decisione.
In pratica, servono una mappa strutturata della conoscenza aziendale, confini espliciti entro cui l’AI può operare, regole di business applicate direttamente al livello dell’AI, permessi granulari su utenti e dati e un punto di controllo unico per tutte le applicazioni. Senza queste condizioni un’AI può produrre risposte convincenti ma non verificabili, e nessuno è in grado di ricostruire a posteriori perché una decisione sia stata presa. La governance non è un documento da allegare al progetto: è un’infrastruttura.

Quali riferimenti normativi deve tenere presenti chi avvia un progetto oggi?

Come sottolinea l’avv. Francesca Niola, responsabile legal e compliance di AISMA, AI Act, NIS2 e DORA non vanno letti come tre percorsi paralleli, perché si intersecano sulla stessa infrastruttura tecnologica. Una soluzione basata sull’AI svolge inoltre due funzioni giuridiche insieme.
È uno strumento di conformità, perché genera log, report e tracciabilità utili a dimostrare l’adempimento degli obblighi. Può però essere anche oggetto di conformità: se ricade tra i sistemi ad alto rischio dell’AI Act, deve rispettarne a sua volta i requisiti. È il caso, ad esempio, dei sistemi impiegati nella selezione e nella gestione del personale: qui l’AI Act chiede al datore di lavoro di informare preventivamente i rappresentanti dei lavoratori e i lavoratori interessati, e la legge 132/2025 affianca obblighi informativi specifici sull’uso dell’AI nel rapporto di lavoro. Il Regolamento (UE) 2026/1744 ha spostato al 2 dicembre 2027 gli obblighi per questi sistemi, ma il tempo guadagnato serve a progettare, non ad attendere.
Anche la supply chain è coinvolta: NIS2 include la sicurezza della catena di fornitura tra le misure di gestione del rischio, e DORA disciplina in modo dettagliato i fornitori ICT degli enti finanziari.

Dalla norma all’architettura: quali caratteristiche deve avere una soluzione governata?

Alcune caratteristiche devono esserci di serie. La prima è un audit trail generato automaticamente. Il log che l’AI Act richiede per i sistemi ad alto rischio è lo stesso che un’ispezione NIS2 o DORA chiede di esibire: progettato bene, un obbligo diventa una prova già pronta.
La seconda è la provenienza verificabile, cioè la possibilità di sapere per ogni risposta da quali fonti deriva, in quale versione e con quali citazioni.
La terza, per noi decisiva, è che quando manca un riscontro fattuale il sistema non produca comunque una risposta verosimile, ma si fermi e dichiari l’assenza di evidenza.
Servono poi una sorveglianza umana configurabile, con ruoli e soglie di intervento definiti, e permessi assegnati per singola azione, non soltanto per profilo.
Infine l’indipendenza dal modello: poter sostituire il modello linguistico senza ricostruire la conoscenza accumulata riduce la dipendenza dal fornitore e tutela il know-how.
Su questi principi abbiamo costruito Cogniss, il Cognitive Control Plane di AISMA: un’infrastruttura di governo su cui far operare le applicazioni di intelligenza artificiale, non l’ennesimo strumento di reportistica.

Quale consiglio darebbe a una PMI o a un committente che vuole iniziare?

Di partire da un perimetro circoscritto e di seguire un metodo. Primo, classificare la soluzione in base alla finalità e al settore di impiego.
Secondo, mappare gli obblighi applicabili incrociando AI Act, NIS2 e DORA.
Terzo, verificare il fornitore: documentazione tecnica, log disponibili, clausole contrattuali.
Quarto, definire chi sorveglia, con quali soglie e con quali responsabilità interne.
Quinto, monitorare nel tempo, perché la conformità di un sistema che apprende non è una fotografia. Per le imprese minori il punto è ancora più rilevante: l’entità delle sanzioni e dei possibili risarcimenti può comprometterne la continuità.
Una governance progettata prima, e non aggiunta a posteriori, costa meno, protegge l’azienda e trasforma un obbligo in un elemento di fiducia verso clienti, autorità e lavoratori.

Contatti:
AISMA Srl
info@aisma.it - aismasrl.it