IA nella GRC: citare non significa verificare

Un agente IA legge una policy di sicurezza, trova un paragrafo pertinente e segna un requisito come soddisfatto. La sua spiegazione sembra plausibile e include un link alla fonte. Ma quale modifica al requisito o alle evidenze cambierebbe quel giudizio?

La ricerca recente su governance, rischio e compliance (GRC) rende questa domanda inevitabile. Un modello può dare la risposta giusta per il motivo sbagliato, citare una fonte autentica riferita al sistema sbagliato o confondere una policy scritta con un controllo efficace. In Secani consideriamo tutto questo una sfida di progettazione del prodotto: il collegamento tra requisito, osservazione e decisione deve essere aperto all’ispezione.

Verificare se il giudizio dipende dalla regola

Il preprint Verdict Without the Rule mantiene fisso un caso mentre elimina, sostituisce o nega la regola che lo disciplina. Su cinque modelli eseguiti in locale e 20 ambiti, l’eliminazione della regola ha cambiato il giudizio in media solo nel 5,3 per cento dei casi. Un giudizio invariato non è automaticamente sbagliato: regole diverse possono portare allo stesso esito. Ma una risposta corretta, da sola, non può dimostrare che il sistema abbia usato la regola fornita.

Servono quindi coppie di casi revisionate, non solo benchmark a risposta singola. Se un requisito di revisione degli accessi passa da trimestrale a mensile mentre i log disponibili restano gli stessi, la valutazione potrebbe dover cambiare. Riformulare lo stesso requisito senza modificarne il significato dovrebbe invece lasciare stabile la valutazione. Entrambe le reazioni contano.

Separare la copertura delle policy dalla prova operativa

PACE separa il recupero dei passaggi pertinenti delle policy dalla valutazione del fatto che coprano un requisito di sicurezza in modo completo, parziale o per nulla. I risultati riportati riguardano la copertura documentale, non il fatto che le misure descritte funzionino nella pratica. Una policy può imporre l’autenticazione a più fattori per gli accessi privilegiati senza dimostrare quali account siano tecnicamente protetti o quali eccezioni esistano.

ReCon documenta un errore ancora più semplice: in alcuni esempi i modelli trattano il testo del requisito incluso nel prompt come se fosse un’evidenza dell’azienda. Requisiti e registrazioni aziendali devono quindi avere identità distinte nel modello dei dati. Una citazione deve rimandare al passaggio che supporta effettivamente l’affermazione.

Questa distinzione rende le risultanze utilizzabili. «La policy esiste, ma mancano evidenze tecniche per tre account privilegiati» indica a un consulente che cosa approfondire. «Parzialmente conforme» no.

Verificare la relazione, non solo la fonte

La pipeline descritta in From Legacy Documentation to OSCAL estrae asset dalle descrizioni dei sistemi e usa threat intelligence strutturata per produrre artefatti di compliance. La sua analisi degli errori mostra perché una fonte reale può comunque supportare una conclusione sbagliata: se un asset viene estratto in modo errato, le interrogazioni successive possono restituire vulnerabilità autentiche relative a un altro prodotto.

La revisione umana ha il massimo valore proprio in questi collegamenti ad alto impatto: una versione di prodotto, un confine di sistema, una sede o un’assegnazione di controllo da cui dipendono molte risultanze successive. Un suggerimento estratto deve restare distinguibile da un elemento d’inventario confermato. Quando un collegamento fondamentale viene corretto, le valutazioni derivate devono essere tracciabili.

Dare alle evidenze un perimetro e una finestra temporale

Compliance-as-Code for AI-Driven Identity Systems propone «contratti sulle evidenze» che specificano tipi di evidenze richiesti, mappature, campi, release e periodi di osservazione. Il suo prototipo usa workflow di identità sintetici, per cui lo studio è un esempio architetturale più che una validazione su larga scala in contesti aziendali.

Un report di test di marzo non dimostra automaticamente che un controllo funzioni ancora dopo una modifica di sistema a settembre. Un’esportazione della configurazione di una controllata non stabilisce lo stato di un’altra. Le evidenze richiedono un soggetto, un’origine, un periodo e un’affermazione supportata. Se un’integrazione smette di fornire dati aggiornati, lo stato attuale è non dimostrato; ciò è diverso da un malfunzionamento del controllo accertato.

Rendere ripetibili le verifiche concordate

Ontological Knowledge Blocks descrive una rappresentazione intermedia strutturata di obblighi definiti da esperti, compilata in regole di validazione eseguibili. L’interpretazione normativa resta una responsabilità umana. Un altro preprint sulla valutazione del rischio associa artefatti tecnici osservabili a esiti ordinali tramite regole versionate e verifica formalmente alcune proprietà di coerenza. Nessuno dei due studi stabilisce un motore di compliance universale né probabilità di incidente calibrate empiricamente.

Il principio utile è distinguere l’interpretazione dall’esecuzione ripetibile. Un agente può proporre criteri a partire da una policy. Una volta approvati dagli esperti, verifiche come un campo mancante, un periodo di osservazione scaduto o una soglia superata non dovrebbero richiedere una nuova interpretazione del modello a ogni esecuzione. Un giudizio deve registrare la versione del requisito, le versioni delle evidenze e la logica applicata.

Riaprire le decisioni quando cambiano le loro premesse

La compliance continua non impone di riaprire ogni controllo dopo ogni modifica a un documento. Richiede di sapere quali conclusioni dipendono dalle informazioni cambiate. Un titolo corretto può non avere alcun effetto. Una nuova eccezione per gli accessi privilegiati può incidere su diversi framework.

La decisione storica deve restare intatta: all’epoca poteva essere giustificata. Ma non deve sopravvivere indefinitamente come affermazione attuale dopo che le sue premesse sono cambiate. Relazioni esplicite e versionate consentono ai consulenti di concentrarsi sulle valutazioni che richiedono davvero un nuovo esame.

Questi articoli non dimostrano che la GRC possa essere completamente autonoma. Diversi sono preprint o valutazioni di prototipi circoscritti. Indicano però uno standard utile per Secani: gli agenti devono preparare le informazioni, proporre mappature, spiegare le lacune e aiutare i consulenti a raggiungere più rapidamente decisioni difendibili.

Uno stato verde è un output. Il prodotto è il collegamento tracciabile tra requisito, realtà e decisione.