Software GRC: che cosa cambia con l’IA

In sintesi

• Un software GRC è l’archivio unico in cui convergono politiche, rischi, controlli, obblighi e le prove che li collegano fra loro. Il suo valore risiede nel modello dei dati, non nel cruscotto.
• Ciò che l’IA ha modificato è il perimetro di quel modello: i sistemi di IA che un’organizzazione sviluppa o acquista costituiscono ormai una categoria di asset regolati a pieno titolo.
• L’articolo 17 del regolamento europeo sull’IA elenca dodici elementi che il sistema di gestione della qualità di un fornitore deve documentare. Letto come una griglia d’acquisto, quell’elenco descrive ciò che uno strumento GRC deve contenere.
• L’Omnibus digitale ha rinviato al 2 dicembre 2027 la scadenza per i sistemi ad alto rischio dell’allegato III. Si è spostata la scadenza, non il tempo necessario a costruire una catena di prove credibile.
• Il criterio di scelta non è il numero di moduli, bensì la capacità dei risultati di reggere all’esame di un organismo notificato o di un’autorità di vigilanza del mercato.

Che cosa fa davvero un software GRC

Un software GRC rappresenta l’archivio unico in cui trovano posto le politiche di un’organizzazione, i rischi che essa ha accettato o rifiutato, i controlli che trattano tali rischi, gli obblighi ai quali quei controlli rispondono e le prove che ciascun controllo ha effettivamente operato. Le tre lettere designano tre discipline nate in direzioni aziendali diverse. Lo strumento è precisamente ciò che le costringe a condividere una struttura comune. Quella struttura costituisce il prodotto vero e proprio. Una governance priva di dati di rischio si riduce a documenti che nessuno legge. Un rischio non collegato ai controlli genera un registro che non cambia mai nulla. Una conformità senza prove resta un’affermazione. Finché le tre dimensioni vivono in fogli di calcolo separati, ogni audit diventa un esercizio di riconciliazione e ogni domanda del regolatore si trasforma in un progetto. Quando invece condividono un unico modello dei dati, una domanda del tipo «quali controlli trattano questo rischio, chi ne risponde, quando sono stati testati l’ultima volta e dove si trova la prova» ottiene risposta in pochi minuti anziché in settimane. È anche la ragione per cui la categoria resiste alle definizioni semplici. Due prodotti possono entrambi presentarsi come piattaforma GRC senza condividere quasi nulla, perché l’uno è costruito attorno alla distribuzione delle politiche e alla loro presa d’atto, l’altro attorno al collaudo dei controlli e allo svolgimento degli audit. La domanda utile non è mai se si tratti di uno strumento GRC, bensì che cosa il suo modello dei dati renda economico e che cosa renda oneroso.

Perché il modello dei dati conta più del cruscotto

Nelle dimostrazioni commerciali il cruscotto occupa la scena, perché si presta bene a essere mostrato. Si colloca però a valle. Una mappa dei rischi si produce senza difficoltà quando rischi, controlli ed esiti dei test sono correttamente collegati, e diventa impossibile da produrre onestamente quando non lo sono. Le domande che reggono davvero una valutazione riguardano la struttura. Un medesimo controllo può soddisfare più quadri normativi contemporaneamente, oppure lo strumento impone un controllo duplicato per ciascun quadro? Un obbligo può essere ricondotto all’artefatto preciso che lo assolve? Un rischio può essere agganciato a un asset e non soltanto a un processo aziendale? Da queste risposte dipende se lo strumento riduce il lavoro oppure si limita a spostarlo. La nostra guida alla governance dell’IA illustra il modello operativo che tale struttura deve sostenere.

Il modello di capacità OCEG e la collocazione reale dello strumento

La maggior parte delle presentazioni di questa categoria finisce per richiamare il GRC Capability Model dell’OCEG, pubblicato con il nome di Red Book. Esso organizza la disciplina in quattro componenti: Learn, Align, Perform e Review, sotto l’insegna della Principled Performance. Learn consiste nel comprendere contesto, cultura e portatori di interesse. Align collega obiettivi, strategia e propensione al rischio. Perform riguarda l’esecuzione dei controlli. Review misura ciò che ha effettivamente funzionato. Il modello è disponibile presso l’OCEG. La lettura onesta, quella che gran parte delle presentazioni evita, si riassume in una frase: un software strumenta bene Perform e Review e non può in alcun modo produrre Align. Uno strumento sa registrare una dichiarazione di propensione al rischio. Non dirà se l’organizzazione la condivida davvero, né se il vertice la accantonerebbe sotto pressione commerciale. Acquisire uno strumento prima di aver deciso che cosa l’organizzazione sia realmente disposta ad accettare produce una versione notevolmente ben documentata di un disaccordo irrisolto. Con l’IA tale distinzione pesa più di quanto pesasse con i controlli finanziari, perché le decisioni sull’IA vengono prese assai più in basso nella struttura. Un responsabile di prodotto può inserire un modello in un percorso rivolto al cliente nell’arco di un pomeriggio. Se la fase Align non ha avuto luogo, lo strumento registra le conseguenze anziché orientare le scelte. Ciò spiega anche la sfocatura dei confini della categoria. Un software GRC costituisce un tassello di una catena di controllo più ampia, che comprende gestione delle identità, registrazione degli eventi, registri dei modelli e monitoraggio della sicurezza, una ripartizione che esponiamo nella nostra analisi sulla piattaforma di conformità rispetto allo stack circostante.

Che cosa cambia con l’IA: il sistema diventa l’asset regolato

Fino a poco tempo fa il perimetro di un programma GRC comprendeva processi, fornitori, controlli e informativa finanziaria. L’IA vi aggiunge un oggetto per il quale il modello non era stato concepito: un asset probabilistico anziché deterministico, che si degrada silenziosamente man mano che il mondo si allontana dai suoi dati di addestramento, e che risulta regolato sistema per sistema anziché processo per processo. Ne discendono tre conseguenze. La prima riguarda l’inventario, che diventa il vincolo determinante. Non si classifica, non si controlla e non si prova ciò di cui si ignora l’esistenza, e l’adozione non dichiarata rappresenta la norma anziché l’eccezione. Tutto ciò che non si vede resta fuori dall’insieme dei controlli scritti, ed è il problema concreto che sta dietro alla shadow AI. La seconda conseguenza trasforma la classificazione in un atto giuridico anziché in una comodità interna. Secondo il regolamento europeo, il fatto che un sistema ricada fra le pratiche vietate, fra i sistemi ad alto rischio, fra quelli soggetti ai soli obblighi di trasparenza o in nessun regime particolare determina gli obblighi che vi si applicano. Tale classificazione deve essere registrata, motivata e riesaminata a ogni evoluzione del sistema. La terza conseguenza pone fine al carattere periodico del registro dei rischi. Un controllo testato una volta all’anno costituisce una risposta ragionevole per un processo di acquisto. Diventa insufficiente per un modello il cui comportamento può spostarsi dopo un aggiornamento del fornitore di cui nessuno è stato avvertito. La nostra guida alla gestione dei rischi dell’IA precisa che cosa significhi concretamente il termine continuo.

Dal GRC potenziato dall’IA al GRC sull’IA

Quasi tutti i prodotti del mercato espongono ormai funzioni di IA: sintesi delle politiche, redazione delle descrizioni dei controlli, proposta di valutazioni di rischio, smistamento dei questionari. Una parte di esse elimina realmente del lavoro. Si tratta però di un tema del tutto distinto da quello su cui interrogano le autorità. Il GRC potenziato dall’IA significa che il fornitore impiega un modello per rendere più rapido il proprio software. Il GRC sull’IA significa che la vostra organizzazione è in grado di dimostrare il controllo sui sistemi di IA che utilizza. Uno strumento può eccellere nel primo aspetto e risultare inutile nel secondo. L’intera distinzione risiede nella preposizione, e conviene essere espliciti con i fornitori su quale dei due venga effettivamente mostrato. Vi è poi un aspetto di secondo ordine. Se un modello concorre a produrre le vostre prove di controllo, quel modello rientra a sua volta nel perimetro. Una prova generata da un sistema non convalidato non vale più del sistema che l’ha prodotta.

Il regolamento europeo scrive il capitolato

L’aspetto più utile del regolamento europeo sull’IA, per chi valuta strumenti, sta nella sua precisione inconsueta riguardo a ciò che deve esistere per iscritto. Gli articoli da 8 a 15 fissano i requisiti applicabili ai sistemi ad alto rischio: sistema di gestione dei rischi (articolo 9), dati e governance dei dati (articolo 10), documentazione tecnica (articolo 11), conservazione delle registrazioni (articolo 12), trasparenza e informazioni agli utenti (articolo 13), sorveglianza umana (articolo 14), accuratezza, robustezza e cibersicurezza (articolo 15). L’articolo 16 elenca poi gli obblighi del fornitore: rispettare tali requisiti, identificarsi sul sistema, dotarsi di un sistema di gestione della qualità, conservare la documentazione, conservare i log generati automaticamente, sottoporsi alla valutazione della conformità, redigere una dichiarazione di conformità UE, apporre la marcatura CE, registrare il sistema, adottare le misure correttive necessarie, cooperare con le autorità nazionali competenti e rispettare i requisiti di accessibilità. L’articolo 17 fa emergere una griglia d’acquisto quasi alla lettera. Il sistema di gestione della qualità del fornitore deve essere documentato e comprendere almeno: una strategia per la conformità normativa comprensiva delle procedure di valutazione della conformità; le tecniche di progettazione, sviluppo e controllo della qualità; le procedure di esame e prova; le specifiche tecniche; i sistemi di gestione dei dati; un sistema di gestione dei rischi; un sistema di monitoraggio successivo all’immissione sul mercato ai sensi dell’articolo 72; le procedure di segnalazione degli incidenti gravi ai sensi dell’articolo 73; un processo di comunicazione con le autorità; un sistema di conservazione delle registrazioni; la gestione delle risorse; e un quadro di responsabilità che definisca le responsabilità della direzione e del personale. Dodici elementi, ciascuno dei quali deve trovarsi da qualche parte ed essere producibile su richiesta. Si tratta del capitolato di un archivio, che qualcuno lo chiami così oppure no. L’articolo 9 precisa la forma del lavoro sul rischio. La gestione dei rischi costituisce un processo iterativo continuo lungo l’intero ciclo di vita: individuare e analizzare i rischi per la salute, la sicurezza e i diritti fondamentali, valutare i rischi che emergono nell’uso, valutare i rischi rivelati dai dati del monitoraggio successivo all’immissione sul mercato e adottare di conseguenza le misure opportune. Anche le finalità sono fissate: eliminare o ridurre il rischio nella misura tecnicamente possibile, mitigare ciò che non può essere eliminato, fornire le informazioni di trasparenza e formare i deployer ove opportuno. Il rischio stesso è definito come la combinazione fra la probabilità di un danno e la sua gravità. Una precisazione disinnesca l’obiezione consueta secondo cui tutto ciò riguarderebbe soltanto le grandi organizzazioni. L’articolo 17, paragrafo 2, richiede che l’attuazione del sistema di gestione della qualità sia proporzionata alle dimensioni dell’organizzazione del fornitore, e il considerando 146 contempla espressamente una versione semplificata per le microimprese. La proporzionalità riguarda la quantità di processo, non l’esistenza degli obblighi. Le nostre risorse sul regolamento europeo sull’IA affrontano nel dettaglio le questioni di classificazione.

La scadenza si è spostata, il tempo di costruzione no

Il calendario si è spostato nel 2026. L’Omnibus digitale sull’IA ha rinviato al 2 dicembre 2027 gli obblighi relativi ai sistemi ad alto rischio autonomi dell’allegato III, e al 2 agosto 2028 quelli relativi all’IA integrata in prodotti già coperti dalla normativa europea sulla sicurezza dei prodotti. Diverse date non si sono mosse: gli obblighi di trasparenza e di marcatura dei contenuti dell’articolo 50 si applicano dal 2 agosto 2026, quelli relativi ai modelli di IA per finalità generali dal 2 agosto 2025 e i divieti dell’articolo 5 dal 2 febbraio 2025. Le analisi della Cloud Security Alliance e dello studio Gibson Dunn concordano su tali date. Leggere quel rinvio come una tregua costituisce un errore, per una ragione assai concreta. Il monitoraggio successivo all’immissione sul mercato e la conservazione delle registrazioni sono obblighi retrospettivi. Quando nel 2028 un’autorità chiederà come si sia comportato un sistema, la risposta si costruirà a partire da log che occorreva raccogliere mentre il sistema era in funzione. Un’organizzazione che inizi a raccogliere alla fine del 2027 disporrà di un sistema di gestione conforme e di nessuno storico da versarvi. La scadenza indica il momento in cui occorre poter mostrare la catena, il che colloca assai prima la decisione di raccogliere.

ISO 42001 e NIST AI RMF: il livello dei controlli

Il regolamento dice che cosa debba risultare vero. Non fornisce un insieme di controlli. Due riferimenti colmano tale scarto, e ogni software GRC serio deve reggerli entrambi senza duplicare il lavoro. La norma ISO/IEC 42001 specifica un sistema di gestione dell’IA, costruito come le altre norme sui sistemi di gestione, ed è certificabile. Il punto conta tanto sul piano commerciale quanto su quello interno, poiché un certificato costituisce una prova trasferibile in una trattativa d’acquisto. Si sovrappone bene agli elementi dell’articolo 17, ed è la ragione per cui molti fornitori ne fanno l’ossatura del proprio sistema qualità. Trattiamo la norma nell’articolo ISO 42001 spiegata. Il NIST AI Risk Management Framework è volontario e ha forma diversa: quattro funzioni, Govern, Map, Measure e Manage, che offrono ai team un vocabolario comune per parlare di rischio legato all’IA senza aprire prima una disputa terminologica. La sua forza sta nell’ordinare l’analisi, la sua debolezza nel valore probatorio in sede di audit, esattamente l’inverso di una norma certificabile. La nostra guida al NIST AI RMF percorre le quattro funzioni. La conseguenza per gli strumenti è concreta. La maggior parte delle organizzazioni risponde contemporaneamente a un regolamento, a una norma certificabile e a un quadro volontario, spesso in aggiunta a certificazioni di sicurezza già in essere. Uno strumento che assegni un controllo a un solo quadro impone di raccogliere più volte la medesima prova. Uno strumento che modelli il controllo una sola volta e lo colleghi a più obblighi trasforma una moltiplicazione in un’addizione. Questa sola domanda separa gli strumenti che crescono con l’organizzazione da quelli che ne triplicano silenziosamente il carico.

Una griglia di capacità per gli strumenti nell’era dell’IA

Quanto segue è ciò che conviene mettere alla prova nel valutare un software GRC, con l’obbligo al quale ciascuna capacità risponde. La griglia ragiona deliberatamente in termini di capacità e non di moduli, poiché i nomi dei moduli variano da un prodotto all’altro mentre gli obblighi non variano.

Due righe concentrano nella pratica gran parte della difficoltà. La registrazione automatica costituisce il punto di rottura degli strumenti concepiti per la conformità di processo, costruiti per convalide umane periodiche e non per flussi di eventi macchina. La tracciabilità della catena di fornitura è il punto in cui la maggior parte delle organizzazioni scopre di non saper rispondere a domande elementari su un modello che non ha addestrato, esattamente lo scarto trattato nei nostri lavori sull’auditabilità.

Prove che reggono a un audit

La maggior parte dei problemi di prova non consiste in assenze. Si tratta di artefatti che esistono e tuttavia non reggono all’esame, secondo quattro modalità ricorrenti di fallimento. La nostra guida all’audit dei sistemi di IA illustra ciò che gli esaminatori cercano davvero. La temporalità viene per prima. Una schermata dimostra che uno stato esisteva nel momento in cui qualcuno l’ha catturata, non che un controllo abbia operato lungo un intero periodo. Segue l’attribuzione: un’esportazione priva di autore, di versione di sistema e di marca temporale non si collega a nulla. La modificabilità costituisce la terza modalità, poiché un foglio di calcolo alterabile a posteriori dimostra sensibilmente meno di quanto il suo contenuto lasci intendere. La tracciabilità forma la quarta e più frequente: un artefatto che non si possa ricondurre all’obbligo preciso che assolve lascia indovinare l’esaminatore, e gli esaminatori non indovinano a vostro favore. I lavori del COSO sul controllo interno applicato all’IA generativa offrono qui una distinzione che conviene riprendere. Quando la direzione si appoggia a un output di modello come elemento di prova di un controllo, il livello di esigenza applicabile a quella prova si innalza. Rieseguire personalmente una verifica non equivale ad accettare la conclusione di un modello, e l’onere documentale differisce di conseguenza: il prompt, la configurazione e la versione del modello entrano allora nel fascicolo. La medesima pubblicazione formula un rilievo connesso che spesso sorprende i team, ossia che modelli, configurazioni, artefatti di messa a punto, embedding e indici di ricerca andrebbero trattati come elementi di configurazione soggetti a controllo degli accessi e gestione delle modifiche, e non come contenuto. La prova pratica applicabile a qualunque strumento si conduce in pochi istanti. Prendete un controllo, risalite all’obbligo al quale risponde, quindi scendete all’artefatto che ne dimostra il funzionamento nel trimestre precedente. Se quel percorso richiede più di due clic, oppure se una delle tappe poggia sulla memoria di qualcuno, lo strumento è uno schedario e non un archivio.

Acquistare, estendere o entrambi

Per dotarsi di un software GRC che copra l’IA si presentano tre opzioni oneste, e la scelta dipende dall’esistente. Estendere una piattaforma già in uso si giustifica quando un programma maturo è operativo, quando il fornitore propone un vero modulo IA anziché un registro dei rischi ribattezzato e quando la libreria di controlli esistente è realmente riutilizzabile. Il vantaggio sta nell’unicità del sistema e delle abitudini. Il rischio risiede in un modulo che modella i sistemi di IA come asset ordinari, fallendo quindi su classificazione, registrazione e provenienza dei modelli. Un sistema dedicato alla governance dell’IA si giustifica quando l’IA occupa una posizione centrale nel prodotto, quando gli obblighi sono abbastanza specifici da rendere inadeguate le strutture di controllo generiche, oppure quando non esiste nulla di maturo da estendere. Il vantaggio sta in un modello dei dati concepito per il problema. Il costo consiste nel secondo sistema e nel lavoro di integrazione che nessuno apprezza. L’approccio ibrido costituisce l’esito più frequente e il meno discusso. La piattaforma storica resta l’archivio aziendale, mentre un sistema specializzato tratta gli obblighi propri dell’IA e trasmette verso l’alto uno stato consolidato. Funziona quando il confine viene tracciato deliberatamente, e produce due registri concorrenti quando non lo è. Qualunque via scegliate, fissate quel confine prima della trattativa commerciale anziché durante. La nostra pagina dedicata al software di conformità per l’IA espone il nostro approccio alla parte specializzata.

Domande frequenti

Qual è un esempio di software GRC? La categoria comprende diverse conformazioni di prodotto. Le piattaforme GRC aziendali accentrano registri dei rischi, collaudo dei controlli e svolgimento degli audit per grandi organizzazioni regolate. Gli strumenti di automazione della conformità si concentrano sulla raccolta continua di prove a fronte di certificazioni di sicurezza. I sistemi di gestione delle politiche coprono redazione, distribuzione e presa d’atto. I sistemi dedicati alla governance dell’IA modellano i sistemi di IA, la loro classificazione e i loro obblighi. La maggior parte delle organizzazioni ne utilizza più d’uno, sicché il confronto utile riguarda quale sistema tenga l’archivio e quali lo alimentino. GRC e audit informatico indicano la stessa cosa? No, benché la confusione sia frequente perché entrambi guardano ai medesimi controlli. Il GRC è la disciplina operativa continua: definire le politiche, tenere il registro dei rischi, eseguire i controlli e raccogliere prove senza interruzione. L’audit informatico è una valutazione indipendente e periodica sul buon funzionamento di tale disciplina. Un programma GRC ben tenuto rende gli audit meno onerosi, poiché le prove esistono già in forma strutturata. I rilievi dell’audit rientrano poi nel registro dei rischi. La relazione è ciclica, ma i ruoli restano deliberatamente separati, e l’indipendenza ne è la ragione. Jira è uno strumento GRC? Non da solo. Jira traccia attività, e gran parte del lavoro GRC ne comporta: azioni di rimedio, collaudi dei controlli, richieste di prove. Molti team cominciano facendovi transitare la propria attività di conformità. Ciò che manca è il modello dei dati sottostante, ossia oggetti di primo livello per rischi, controlli, obblighi e prove, con le relazioni fra loro. Ticket con etichette ne offrono un’approssimazione finché un esaminatore non chiede quali controlli trattino un dato rischio e dove si trovi la prova. Jira funziona bene accanto a un archivio e male come archivio. Il GRC richiede di saper programmare? In genere non per il lavoro quotidiano. Gli strumenti odierni si configurano tramite interfaccia, e le parti impegnative del mestiere sono analitiche anziché tecniche: classificare correttamente i sistemi, redigere controlli realmente collaudabili, decidere che cosa costituisca prova sufficiente. La programmazione diventa rilevante ai margini, soprattutto per le integrazioni che recuperano automaticamente prove da piattaforme cloud, registri di modelli o sistemi di logging. Quell’automazione rende praticabile il monitoraggio continuo su larga scala, sicché una capacità tecnica nel team resta un vantaggio concreto anche dove non sia richiesta. Meglio un SOC o un GRC? Rispondono a domande diverse e non sono alternativi. Un centro operativo per la sicurezza rileva e tratta le minacce quasi in tempo reale. Il GRC stabilisce che cosa debba essere presidiato, perché, e se i controlli abbiano operato lungo un periodo. Un SOC produce prove e incidenti che un programma GRC utilizza, e un programma GRC fissa le politiche e la propensione al rischio entro cui il SOC opera. Le organizzazioni che li trattano come voci di bilancio concorrenti finiscono con un rilevamento che nessuno ha ricondotto a un obbligo, oppure con obblighi che nulla sorveglia. Gli strumenti GRC coprono il regolamento europeo sull’IA? Lo sostengono sempre più spesso, e tali affermazioni meritano di essere verificate. Chiedete di vedere un inventario dei sistemi di IA con classificazione per sistema e motivazione registrata, prove collegate ad articoli precisi anziché a una famiglia generica di controlli, log macchina conservati anziché attestazioni umane, e una gestione degli incidenti gravi scandita sui termini normativi. Molti prodotti soddisfano il primo punto e si arrestano sui successivi. Un fornitore che rivendichi tale copertura dovrebbe poter percorrere un sistema dalla registrazione fino a un fascicolo leggibile da un esaminatore.

Conclusione

La categoria non ha cambiato nome. Ha cambiato perimetro. Un software GRC si giudicava dal modo in cui trattava processi, fornitori e controlli finanziari; oggi si giudica dalla sua capacità di trattare anche un sistema di IA come oggetto governato di primo livello, dotato di classificazione, insieme di controlli, catena di log e responsabile. Il regolamento ha reso i requisiti insolitamente leggibili. L’articolo 17 elenca ciò che deve essere documentato, l’articolo 12 impone l’esistenza dei log, l’articolo 72 prolunga il monitoraggio dopo il rilascio, e il rinvio delle scadenze significa che la catena di prove deve iniziare ben prima della data sulla quale si sarà misurati. Valutate di conseguenza: non in base al numero di moduli, bensì alla tenuta del percorso che collega l’obbligo al controllo e quindi all’artefatto datato, quando qualcuno dotato di autorità lo percorre. Se state conducendo tale valutazione specificamente per sistemi di IA, la nostra piattaforma di conformità per l’IA è costruita attorno agli obblighi articolo per articolo descritti sopra.