Firefighter AI vs Human: 6:0

Fischio finale su sei mesi di attività SAP Firefighter in un ambiente di produzione reale. Team Human Review: 0. Team AI Agent: 6. Il Team AI non ha vinto perché è stato più veloce della squadra umana. Ha vinto perché ha giocato una partita diversa sullo stesso campo.

Questa serie di articoli illustra quali sono stati questi sei "gol", come il Team AI li ha segnati e perché il punteggio riflette più una colpa di processo e di approccio che errori umani.

I sei "gol" segnati dagli Agenti AI durante la partita descritta in questa serie:

• Gol n. 1. La relazione tra esecutore e revisore della sessione Firefighter (peer review audit)
• Gol n. 2. L'origine dell'attività Firefighter (account tecnici sotto etichette di emergenza)
• Gol n. 3. Esposizione GDPR durante la sessione Firefighter (campo tecnico)
• Gol n. 4. Dati mancanti nella sessione Firefighter approvata (giudizio di approvazione)
• Gol n. 5. Account di emergenza Firefighter utilizzato per modifiche massive
• Gol n. 6. La qualità della revisione della sessione Firefighter (mancato uso di transazioni critiche)

Questo articolo ripercorre i sei "gol" in ordine, poi l'analisi post-partita: come è stato costruito il Team AI, l'architettura a sei livelli che lo sostiene, la disciplina di validazione e le azioni di una settimana che il Team Human può intraprendere per competere sullo stesso campo a partire da lunedì.

Di Filip Nowak, GRC Advisory. I sei segnali descritti in questa serie in tre parti sono stati prodotti da un agente AI GRC nel smartGRC LAB su un estratto anonimizzato di un'effettiva installazione di SAP S/4HANA Firefighter in produzione. Metodologia, euristiche e responsabilità editoriale rimangono in capo al team di consulenza GRC Advisory.

Cos'è e cosa non è questa serie

Si tratta di uno studio dei pattern presenti nei dati, suddiviso in tre parti per facilitarne la lettura. Analizza un dataset di attività SAP Firefighter anonimizzato e di scala produttiva e descrive sei categorie di segnali di controllo visibili quando i dati vengono esaminati a livello di sessioni Firefighter incrociate, invece che una singola attività Firefighter alla volta (l'approccio tradizionale). Non è un report di audit pubblico. Non è la descrizione delle debolezze di un'organizzazione specifica. Non è un'affermazione secondo cui l'AI sostituisce i revisori umani.

Quello che sostiene è: che la revisione Firefighter classica sessione per sessione non è progettata per portare alla luce pattern trasversali tra sessioni, utenti e origini; che tali pattern sono quantificabili nei dati di produzione di scala ordinaria; e che un agente AI GRC dotato della giusta architettura può estrarre questi pattern in modo abbastanza affidabile da consentire ai revisori umani di validarli e agire. Ogni segnale è stato verificato, sui dati sottostanti, da un consulente senior di sicurezza GRC responsabile prima di apparire in questa serie.

L'agente rileva i pattern. L'umano decide se il pattern è rilevante per l'audit.

Il confronto

Due modi di leggere una sessione Firefighter. La revisione basata sulla sessione chiede: questa singola sessione era legittima? È la domanda a cui ogni revisione classica di audit Firefighter è strutturata per rispondere. Il revisore Firefighter apre la sessione, legge la motivazione della prenotazione, esamina il log delle transazioni, controlla la presenza di anomalie evidenti, firma. Questo è il playbook del Team Human.

L'analisi AI basata sui pattern è iniziata come tipica revisione umana ma in più pone domande più profonde: la disposizione di sessioni, utenti, origini, transazioni, stati di audit e baseline storiche genera un pattern di rischio? Ciò richiede di incrociare domini di dati che la revisione basata sulla sessione non porta alla luce insieme: grafi relazionali tra richiedenti e approvatori, distribuzioni per host di origine tra gli account, contenuto di tipo regex del testo di intestazione dei documenti contabili, configurazione dei parametri di sistema che governano la registrazione dei documenti di modifica, rapporti di concentrazione per attività per utente, distribuzioni del tempo di permanenza per classe di rischio delle transazioni. Questo è il playbook del Team AI.

Stessi dati. Stesso campo di gioco. Due playbook diversi. I segnali descritti in questa serie sono visibili solo quando si pongono domande più numerose e di tipo diverso. I dati per rispondere a queste domande esistono in tabelle che ogni ambiente SAP e GRC già conserva. L'intuizione della revisione AI non esiste nella revisione classica di sessione. Almeno non fino ad ora. È questa l'asimmetria che ha trasformato la partita in una vittoria AI con il punteggio di 6 a 0.

Le condizioni della partita

Sei mesi di osservazione continuativa su un ambiente di produzione SAP S/4HANA con più codici società. Quasi 600 prenotazioni Firefighter su 11 account di emergenza, 39 utenti finali univoci. Circa 2,55 milioni di voci di Security Audit Log. Circa 352.000 modifiche di dati anagrafici. Oltre 201.000 documenti contabili. Circa 14.000 voci di audit log SAP al giorno.

Per essere espliciti sull'origine dei dati: il dataset è costituito da dati reali di produzione estratti da un'effettiva installazione di SAP S/4HANA Firefighter, non da un ambiente sintetico o di test. I riferimenti al "nostro LAB" indicano l'ambiente analitico in cui l'agente AI GRC ha elaborato l'estratto anonimizzato, non l'origine dei dati. Identificatori specifici, nomi di account, struttura di Paese e intervalli di date esatti sono stati anonimizzati; gli ordini di grandezza e i pattern strutturali rimangono invariati.

Il contesto del volume è importante per le circa 600 sessioni Firefighter in questo dataset. Con il tipico tasso di campionamento del 5-10%, i revisori di log Firefighter più qualificati e impegnati esaminano in dettaglio forse da 30 a 60 sessioni - dedicando un'enorme quantità di tempo e sforzo all'attività, cercando di trovare pattern di comportamenti scorretti all'interno di ciascuna sessione Firefighter. Le altre 530 e più ricevono un clic di "accetta". Campionare al 5-10% non è una scelta di processo: è un vincolo di risorse. Con un campione di dimensioni maggiori, la popolazione oggetto di audit dovrebbe espandersi di un ordine di grandezza, e i controlli che giustificavano il mantenimento ristretto del campione (indipendenza, responsabilità, integrità della traccia di audit) non reggerebbero.

Nessun revisore che lavora sessione per sessione avrebbe mai potuto individuare i primi due pattern descritti di seguito: emergono solo quando si elabora l'intero dataset. La matematica e la struttura della revisione non lo consentono. La revisione non era stata progettata per porre la domanda. Questo è il campo su cui ha giocato il Team Human.

Il dataset ha mostrato 115 sessioni in sei mesi, all'incirca una sessione accettata su quattro, approvate da un revisore che era a sua volta tra gli operatori Firefighter più assidui. Sia il richiedente sia l'approvatore appartenevano allo stesso team operativo nella maggior parte dei casi. Ogni singola approvazione, presa isolatamente, appare difendibile. Il pattern emerge solo calcolando il grafo utente-revisore su tutte le sessioni accettate e identificando gli anelli chiusi.

Perché ciò è importante: un revisore che esegue l'audit della sessione di un collega di squadra opera con incentivi diversi rispetto a chi esegue l'audit della sessione di uno sconosciuto. La fiducia è più rapida del contestare. Mettere in discussione la sessione di un collega comporta due costi che il revisore non può assorbire facilmente. Primo, attrito all'interno del team che deve continuare a lavorare insieme. Secondo, l'aspettativa ragionevole che la stessa ispezione "dettagliata" si ripresenti la volta successiva in cui la propria sessione sarà in coda. Il contestare va in salita. L'accettare va in discesa. La via di minor resistenza è firmare e proseguire.

Ogni singola approvazione appare comunque difendibile. Il processo è stato seguito. Il richiedente è autorizzato a prenotare. Il revisore è autorizzato a chiudere. La traccia è pulita. In superficie, una persona lavora e un'altra verifica, il che sembra controllo. Il rischio sistemico vive solo nell'aggregato, dove le persone più in grado di sottoporre a scrutinio il lavoro reciproco sono anche quelle con il minor incentivo a farlo. Questo quadro non è visibile in nessun record di singola sessione.

Come l'AI ha segnato questo gol: ha smesso di guardare i record delle singole sessioni e ha iniziato a guardare la rete sottostante. L'agente ha costruito un modello relazionale dell'intero ciclo di audit. Ogni richiedente come nodo. Ogni approvatore come nodo. Ogni sessione accettata come arco direzionale dal richiedente all'approvatore. Con quel grafo in memoria operativa, individuare gli anelli chiusi in cui gli utenti assidui approvano le sessioni reciproche è una singola query, non una scansione di 481 record. L'agente AI ha inoltre incrociato il grafo con due livelli contestuali che il flusso di lavoro manuale tiene in strumenti separati: la matrice delle autorizzazioni che indica chi può approvare e la baseline di attività per utente che identifica la popolazione degli utenti assidui. Il pattern è emerso in pochi secondi perché l'agente guardava la struttura della rete, non i singoli record. Questa è la mossa che ha portato al gol. Una revisione Firefighter di qualità e l'audit indipendente dell'attività durante la sessione Firefighter sono il fondamento di questo controllo. Nessuna revisione di qualità = nessun controllo per questo rischio è in atto.

Perché il playbook basato sulla sessione del Team Human non ha potuto eguagliare ciò: le voci di log esistono all'interno della revisione, ma nessuna vista all'interno del flusso di lavoro consente al revisore di aggregarle per host di origine tra gli account. Aggregare quella classificazione per account e confrontare il rapporto con una baseline per account di emergenza rispetto a quelli tecnici richiede il catalogo dei ruoli e un'euristica su quale proporzione suggerisce un uso tecnico. Nessuno dei due fa parte della checklist per singola sessione. Il revisore ha i dati. Non ha la lente. Richiede anche che il revisore pensi al di là della checklist immediata e si ponga una domanda di tipo diverso: non solo "questa singola sessione era giustificata?", ma "quale pattern emerge quando queste sessioni sono confrontate tra account, host e tipi di account?". È un passaggio analitico più profondo di quanto il flusso di lavoro standard incoraggi. Va detto, in tutta onestà, che questo tipo di compito è particolarmente difficile per un revisore umano perché implica leggere lunghi log di revisione per ore, spesso contenenti voci ripetitive e a basso valore informativo. Il lavoro richiede tempo, è monotono e mentalmente stancante. Oltre un certo punto, l'attenzione cala naturalmente, ed è facile non cogliere pattern sottili. Un revisore può elaborare correttamente ciascuna singola voce e tuttavia non notare il segnale più ampio nascosto in molte sessioni simili. In altre parole, la limitazione non è che il revisore non abbia accesso alle prove. La limitazione è che le prove sono sepolte all'interno di un flusso di lavoro Firefighter ottimizzato per la validazione di singole sessioni, non per il rilevamento di pattern tra account. I dati ci sono, ma il processo di revisione non rende visibile il pattern rilevante.

Il dataset ha mostrato che il 53,7% di tutte le voci di Security Audit Log delle sessioni Firefighter, circa 1,37 milioni di righe, ha avuto origine su hostname di server. Si tratta di automazione che gira sotto account etichettati come accesso di emergenza, non di lavoro umano in emergenza. Tre degli undici account Firefighter mostravano una distribuzione di host di origine dominata dal traffico server, indicando che funzionano come account tecnici de facto. La raccomandazione strutturale: sostituire questi tre account con account tecnici con ambito ristretto secondo il pattern Z_BC_*.

A livello di singola sessione, nessuna sessione rivela questo pattern. Ogni sessione mostra una prenotazione, un elenco di transazioni e un verdetto di audit. Il fatto che le transazioni all'interno della sessione abbiano avuto origine su un hostname di server piuttosto che sulla workstation del richiedente è sepolto in una colonna che il flusso di audit non raggruppa mai. Un revisore che apre la sessione vede attività che sembra legittima: transazioni che corrispondono all'ambito del ruolo, una finestra temporale ragionevole, un log pulito. L'anomalia strutturale non appare a livello di sessione. È visibile solo classificando le voci di log per host di origine e aggregando il risultato per account. Quella classificazione non è nella vista per singola sessione.

Come l'AI ha segnato questo gol: ha smesso di leggere l'audit log come un elenco di eventi di sessione e ha iniziato a leggerlo come un dataset dimensionale. L'agente ha calcolato la distribuzione degli host di origine su tutti i 2,55 milioni di voci di log, suddivisa per account Firefighter. In pochi secondi ha ottenuto una tabella di undici account, ciascuno con un rapporto tra attività su host server e su workstation. Poi ha incrociato quella tabella con due elementi che il flusso di lavoro manuale tiene in posizioni separate: il catalogo dei ruoli (quale account è di quale tipo) e l'euristica del settore SAP (più del cinquanta percento di attività su host server equivale a un carico di lavoro da account di servizio, non da accesso di emergenza). Tre account Firefighter si sono distinti per comportamento da account tecnici travestiti. L'agente ha poi prodotto la raccomandazione strutturale: riclassificare questi tre account secondo il pattern Z_BC_* con ambito ristretto, non "dire al revisore di guardare con più attenzione la prossima volta". Questa è la mossa che ha portato al gol.

Perché il playbook basato sulla sessione del Team Human non ha potuto eguagliare ciò: le voci di log esistono all'interno della revisione, ma nessuna vista all'interno del flusso di lavoro consente al revisore di aggregarle per host di origine tra gli account. Aggregare quella classificazione per account e confrontare il rapporto con una baseline per account di emergenza rispetto a quelli tecnici richiede il catalogo dei ruoli e un'euristica su quale proporzione suggerisce un uso tecnico. Nessuno dei due fa parte della checklist per singola sessione. Il revisore ha i dati. Non ha la lente.

La revisione del dataset da parte dell'agente AI ha mostrato 19 documenti contabili registrati in cui il campo testo di intestazione BKPF conteneva indirizzi email di clienti su provider di posta consumer. Il testo di intestazione su un documento finanziario è progettato per riferimenti di sistema: ID di fattura, chiavi di correlazione interna, puntatori della catena di documenti. La presenza di dati di contatto dei clienti in tale campo è una preoccupazione GDPR. I dati personali si trovano ora in un campo di sistema che non ha una propria politica di retention, non è registrato nei Registri delle attività di trattamento dell'organizzazione come repository di PII ed è regolarmente esportato nei flussi di reportistica standard, comprese le sottomissioni di audit e le condivisioni di dati con i partner.

Cosa è effettivamente rotto: BKPF-BKTXT è ufficialmente classificato come "campo di riferimento tecnico" nell'inventario dei dati. Quella classificazione significa che le richieste DSAR (GDPR Art. 15) lo saltano, le richieste di cancellazione (Art. 17) lo saltano, le politiche di retention lo saltano e le regole di pseudonimizzazione nelle esportazioni di dati lo saltano. Diciannove indirizzi email di clienti sono ora incorporati in un record contabile di oltre 5 anni che nessuno analizza alla ricerca di dati personali, in un campo che nessuno guarda quando onora i diritti sui dati di un cliente. L'organizzazione non è in grado di dimostrare la conformità con il GDPR Art. 5, 15, 17 o 30 per questa classe di dati, e non sa di non poterlo fare.

Perché la revisione Firefighter per sessione non ha rilevato ciò: quando un revisore apre una sessione Firefighter ed esamina i documenti registrati, vede il testo di intestazione come una stringa. Anche se nota mentalmente che una voce sembra un contatto cliente, la checklist di audit per la revisione di sessione Firefighter non ha alcuna voce che dica "se vedi una stringa di forma PII in BKPF-BKTXT, solleva un rilievo di controllo". Il revisore non ha alcuna azione di follow-up definita. Il campo è classificato come riferimento tecnico, quindi qualsiasi cosa appaia lì è trattata per default come un riferimento tecnico. Gli umani non hanno identificato questo come un problema non per disattenzione, ma perché il protocollo di revisione non assegna la scansione di conformità GDPR allo step di audit Firefighter, e perché la consapevolezza che queste informazioni non dovrebbero essere divulgate nei documenti registrati è conoscenza propria del consulente GDPR, non parte della formazione standard del revisore Firefighter.

Come l'AI ha segnato questo gol: ha eseguito una scansione del contenuto basata sui pattern che la revisione Firefighter manuale non include. L'agente ha preso l'intero insieme dei valori BKPF-BKTXT dei documenti registrati durante sessioni Firefighter, decine di migliaia di stringhe, e ha applicato una libreria di pattern regex che copriva indirizzi email, numeri di telefono, numeri di identificazione e altri formati di dati personali. In pochi secondi ha segnalato 19 documenti. Poi ha applicato un'euristica del consulente GRC che la checklist standard non codifica: quando i dati personali appaiono in campi non registrati come repository PII, portarli in evidenza come gap di controllo e collegarli alla sessione Firefighter che li ha registrati. L'agente ha poi collegato il rilievo agli articoli GDPR 5 (minimizzazione dei dati), 15 (diritto di accesso), 17 (diritto alla cancellazione) e 30 (registri delle attività di trattamento), producendo non solo diciannove documenti ma una dichiarazione di controllo difendibile che un revisore interno può portare al DPO. Questa è la mossa che ha portato al gol. La gestione delle PII sotto Firefighter è un'area di controllo che le operazioni conformi al GDPR devono gestire in modo dimostrabile. Nessuna scansione mirata dei campi a testo libero significa nessuna evidenza che questo controllo sia operativo.

Perché il Team Human non ha potuto segnare contro questo: nessun revisore umano che esamina le sessioni Firefighter una alla volta esegue una corrispondenza regex per pattern di PII sul campo testo di intestazione BKPF, e la revisione per sessione mostra singole stringhe ma non le aggrega per la scansione. L'euristica che dice "quando i dati personali appaiono in campi designati per i riferimenti di sistema, portali in evidenza come gap di controllo" fa parte della prassi del consulente GRC senior mappata su specifici articoli del GDPR, non della checklist di audit Firefighter standard. Il revisore ha le stringhe davanti a sé. Non ha lo scanner, la libreria di pattern PII o la mappatura degli articoli GDPR che renderebbe le stringhe azionabili come rilievo di conformità.

Il dataset ha mostrato che per circa 297.000 modifiche di materiale anagrafico effettuate dall'utente Firefighter con il volume più elevato, il campo dei dettagli nelle voci dei documenti di modifica CDPOS era vuoto. Non parziale. Non corrotto. Vuoto. L'interpretazione standard di questo gap è che le operazioni massive sui dati non producono documenti di modifica a livello di campo e che pertanto la verifica a livello di dettaglio è impossibile a posteriori.

Cosa è effettivamente rotto: i framework ITGC (SOX, ISO 27001 A.12.4) richiedono che le modifiche ai dati che determinano gli esiti finanziari siano tracciabili a livello di campo. 297.000 modifiche registrate come "impossibile verificare" non sono un gap parziale; sono un fallimento completo del controllo delle modifiche a livello di campo sul più grande blocco singolo di attività di dati anagrafici del ciclo. Un revisore non può concludere l'efficacia operativa su un controllo in cui 297.000 voci di valutazione restituiscono "impossibile verificare". Tuttavia la revisione per sessione tratta ciascuna voce come una limitazione nota, la nota di lavoro rimane "impossibile verificare" e il rilievo cumulativo non viene mai sollevato a livello di piattaforma.

L'interpretazione più profonda, emersa in un passaggio di feedback dell'analisi, è che non si tratta di un problema di comportamento di logging a livello utente. È un problema di configurazione dei parametri di sistema a livello di piattaforma. Il parametro SAP che governa la cattura dei documenti di modifica a livello di campo per gli aggiornamenti massivi MM02 e LSMW molto probabilmente non è abilitato nell'ambiente. La correzione non è "dire ai revisori di esaminare con più attenzione". La correzione è nella configurazione SAP. Nessuno se ne è accorto o l'ha richiesto, perché chiederlo renderebbe più difficile un compito di revisione già impossibile. In condizioni in cui 300.000 voci si trovano in coda, la qualità della revisione cala per il solo volume. Anche lavorando 24 ore su 24, 7 giorni su 7, la verifica non può essere completata. È difficile aspettarsi che qualcuno chieda che vengano catturati ancora più dati. È più facile "accettare" la revisione con il gap e far avanzare la sessione successiva.

Come l'AI ha segnato questo gol: ha riformulato il problema con l'aiuto di un passaggio di feedback. Al primo passaggio sul dataset, l'agente ha segnalato il campo dei dettagli vuoto come gap di verifica, la stessa interpretazione a cui sarebbe arrivato un revisore umano. In un passaggio successivo, con il livello euristico arricchito da una correzione del consulente GRC, l'agente ha posto una domanda diversa: se il gap è strutturale (si ripete su 297.000 modifiche di un utente), quale impostazione a livello di piattaforma controlla la cattura dei documenti di modifica a livello di campo per le operazioni massive MM02 e LSMW? Ha incrociato i parametri di configurazione SAP Basis, che la revisione Firefighter manuale non include nella sua checklist, e ha identificato che il parametro pertinente molto probabilmente non è abilitato. L'agente ha poi collegato il rilievo ai requisiti di logging di SOX ITGC e ISO 27001 A.12.4, producendo non solo una nota a livello di sessione ma un rilievo di controllo a livello di piattaforma che l'audit interno può indirizzare al team Basis per la remediation. Questa è la mossa che ha portato al gol. L'audit Firefighter non può dimostrare l'efficacia operativa dei controlli sulle modifiche massive dei dati senza che la cattura a livello di campo sia abilitata. Nessuna configurazione significa nessuna evidenza di audit, e quindi nessun controllo difendibile.

Perché il Team Human non ha potuto segnare contro questo: i revisori avevano registrato il campo dei dettagli vuoto nelle loro note di lavoro come "impossibile verificare" su molte sessioni. Correlare quell'osservazione con il parametro di configurazione SAP che controlla la registrazione di audit a livello di campo richiede sia competenza SAP Basis sia un inquadramento di controllo di audit. Entrambi risiedono nel livello delle euristiche del consulente, non nella checklist del revisore per singola sessione. Il revisore ha il sintomo davanti a sé. Non ha la conoscenza Basis più l'inquadramento per convertire "non posso verificare" in "la scelta di configurazione è il gap di controllo, ed ecco il parametro".

La correzione non è "dire ai revisori di esaminare con più attenzione". La correzione è nella configurazione di sistema.

Il dataset ha mostrato che un profilo utente rappresentava il 36% di tutte le voci Firefighter del Security Audit Log, l'85% di tutte le modifiche Firefighter ai dati anagrafici (299.017 record) e il 99,8% di tutti i documenti contabili registrati durante sessioni Firefighter (201.413 su 201.840). Tre misure indipendenti dell'attività Firefighter, tutte che puntano allo stesso profilo. La matematica non è sottile.

Cosa è effettivamente rotto: Firefighter è per definizione un accesso di emergenza. Eccezionale. A tempo limitato. Basato sulla prenotazione. Se un profilo esegue il 99,8% di tutta l'attività contabile Firefighter in una finestra di sei mesi, l'accesso non è di emergenza per quel profilo. È accesso elevato permanente travestito. Il controllo compensativo costruito sull'assunzione "Firefighter equivale a eccezione" smette di essere un controllo nel momento in cui Firefighter equivale a routine. Le limitazioni SoD nel ruolo normale dell'utente non si applicano più al carico di lavoro effettivo, perché il carico di lavoro effettivo passa per il percorso Firefighter. L'audit SOX e ITGC tratta "accesso di emergenza utilizzato per operazioni di routine" come una deficienza di controllo automatica. L'ISO 27001 A.9.2.5 (Revisione dei diritti di accesso utente) richiede che gli account privilegiati siano rivisti rispetto al fabbisogno effettivo. Un profilo che genera il 99,8% dei documenti contabili sotto Firefighter ha chiaramente bisogno di un accesso stabile, non di un accesso di emergenza, ma il processo di revisione non ha alcun meccanismo per convertire tale fabbisogno in una decisione di provisioning di un ruolo stabile.

Il pattern di lavoro in sé corrisponde alla firma di un'interfaccia batch, non a quella di un power user umano. Volume elevato su centinaia di migliaia di transazioni. Codici di transazione ripetitivi entro un ambito ristretto. Nessun clic esplorativo. Nessuna voce di fallimento di transazione. Finestre di esecuzione prevedibili. O un umano sta eseguendo manualmente più di 200.000 transazioni, il che è fisicamente impossibile, oppure una qualche forma di automazione gira sotto questa credenziale umana tramite l'accesso Firefighter. Entrambe le interpretazioni sono gap di controllo. L'organizzazione o non sa di stare eseguendo automazione batch tramite l'accesso di emergenza, oppure lo sa e ha accettato che l'accesso di emergenza sia il percorso operativo quotidiano per uno dei suoi utenti più attivi.

Perché questa concentrazione non è mai stata sollevata: nessuno l'ha progettata. Si è accumulata negli anni, mese dopo mese. Al primo anno questo utente ha svolto forse il 30% del lavoro sui dati anagrafici perché era il più esperto. Al secondo anno il 50% perché i membri più nuovi del team si affidavano a lui. Al terzo anno l'85% perché ormai nessun altro ricordava come si facesse. Quando qualcuno guarda all'aggregato dei sei mesi, la concentrazione è una dipendenza da singolo punto travestita da competenza. Il team etichetta questa persona come un contributore senior insostituibile. La popolazione di audit la etichetta come un utente assiduo, correttamente revisionato. Il processo di revisione Firefighter non ha alcuna metrica chiamata "tua quota del volume di ciclo", e nessun segnale che dica che questa concentrazione è matematicamente incoerente con un profilo da power user umano. La deriva è invisibile in qualsiasi singolo ciclo di revisione, e l'inquadramento sociale del tipo "lui o lei è il nostro esperto di dati anagrafici" la protegge dal venire messa in discussione.

Come l'AI ha segnato questo gol: ha calcolato i rapporti di concentrazione su molteplici dimensioni dell'attività Firefighter (voci di log per utente, modifiche anagrafiche per utente, documenti contabili per utente), e ha confrontato la distribuzione risultante con una libreria di firme operative. In pochi secondi ha ottenuto una classifica che collocava questo singolo profilo al 36%, 85% e 99,8% sulle tre misure. Poi ha applicato un'euristica del consulente GRC che la revisione Firefighter manuale non codifica: quando la distribuzione di un singolo profilo corrisponde alla firma di un'interfaccia batch (volume elevato, gamma di transazioni ristretta, cadenza ripetibile, tasso di fallimento prossimo allo zero, finestre prevedibili), riclassificarlo come candidato ad account di servizio, non come utente assiduo. L'agente ha prodotto la raccomandazione strutturale: costruire un ruolo tecnico stabile con ambito ristretto Z_BTC_* e migrare questo carico di lavoro completamente fuori da Firefighter. Ha collegato il rilievo a SOX ITGC (l'accesso di emergenza usato per operazioni di routine è una deficienza), ISO 27001 A.9.2.5 (revisione degli accessi privilegiati) e ISO 22301 (continuità operativa, dato che la dipendenza da una singola persona per il 99,8% della produzione contabile è un rischio di continuità documentato). Questa è la mossa che ha portato al gol. Tre framework di controllo puntano alla stessa correzione: togliere questo carico di lavoro da Firefighter, metterlo su un ruolo tecnico stabile, ripristinare Firefighter come percorso di eccezione.

Perché il Team Human non ha potuto segnare contro questo: ogni sessione aperta da questo utente, revisionata isolatamente, sembra lavoro operativo legittimo. Le transazioni corrispondono all'ambito del ruolo. Le motivazioni di prenotazione fanno riferimento a ticket reali. Il verdetto di audit è "accetta". Nulla in nessuna singola sessione rivela che la stessa persona è responsabile del 99,8% di tutti i documenti contabili Firefighter nel dataset. I rapporti di concentrazione sono una proprietà dell'intero dataset, non di una singola sessione. Il log della sessione non riporta "il tuo contributo all'aggregato di ciclo è del 99,8%". Anche quando i revisori sanno intuitivamente che questa persona è "sempre su Firefighter", quantificare quell'intuizione richiede di calcolare metriche di quota per utente su molteplici dimensioni di attività e confrontare il risultato con una libreria di firme di interfacce batch. Nessuna delle due fa parte della revisione per singola sessione. Il revisore vede il volume. Non vede il rapporto di concentrazione, e non ha la libreria di pattern per distinguere il volume da utente assiduo da quello a forma di automazione.

La correzione non è "rivedere con più attenzione l'utente assiduo". La correzione è riconoscere il carico di lavoro da interfaccia batch per quello che è e rimuoverlo del tutto da Firefighter.

Il dataset ha mostrato nove sessioni che hanno eseguito la transazione F110 (esecuzione pagamenti, che genera ordini di pagamento bancari reali che fanno uscire il denaro dall'azienda lo stesso giorno). Sei di quelle nove erano ancora nello stato PENDING di audit settimane o mesi dopo la chiusura della sessione. In questo dataset, il pattern F110 si è concentrato attorno a un profilo finance. Totale esecuzioni F110 sulle nove sessioni: 23. Numero di quelle 23 revisionate in modo indipendente al momento dell'analisi: zero. Nel dataset più ampio, il tempo di permanenza in PENDING delle transazioni ad alto rischio ha superato quello delle transazioni a basso rischio, l'inverso di ciò che una politica di audit intenderebbe.

Cosa è effettivamente rotto: F110 è la transazione SAP che genera ordini di pagamento bancari reali. Ogni esecuzione autorizza un pagamento in uscita che lascia il conto aziendale nella stessa giornata lavorativa. I framework ITGC (SOX, COBIT) classificano l'autorizzazione dei pagamenti come un controllo primario. L'ISO 27001 A.9.4.4 affronta esplicitamente il controllo sui programmi di utilità privilegiata, e F110 ne è un esempio da manuale. Ventitré esecuzioni F110 con zero revisioni indipendenti significano che il principio dei quattro occhi attorno ai pagamenti in uscita non è operativo. Il controllo sulla carta dice "le sessioni F110 richiedono una revisione indipendente tempestiva". Il controllo nella pratica dice "le sessioni F110 restano in PENDING più a lungo delle sessioni di routine perché nessuno si propone come secondo paio d'occhi su un pagamento bancario reale".

Perché la revisione Firefighter per sessione ha lasciato le sessioni ad alto rischio in attesa più a lungo: è un paradosso di avversione al rischio. Il costo mentale di chiudere una sessione F110 è asimmetrico. Una revisione F110 chiusa erroneamente lega il nome del revisore a un pagamento bancario reale che non sarebbe dovuto avvenire. Una revisione F110 rinviata non comporta alcun costo visibile. La risposta individuale razionale, data quell'asimmetria, è rinviare finché "avrò tempo per farlo come si deve". Ma ogni revisore fa lo stesso calcolo, nello stesso giorno, sullo stesso tipo di sessione. Il comportamento di coorte produce un SLA invertito senza che nessuno della coorte lo intenda. Si aggiunga la verità operativa per cui le sessioni F110 richiedono più tempo per essere revisionate perché l'analisi è più pesante (più transazioni, più importi, più riferimenti a fatture da controllare), così che si attardano. E la coda non rende visibile l'effetto coorte a nessun singolo revisore.

Come l'AI ha segnato questo gol: ha correlato la classe di rischio della transazione con la durata dello stato di revisione su tutto l'arretrato. L'agente ha costruito una distribuzione dei "giorni in PENDING" segmentata per la transazione con il rischio più elevato all'interno della sessione (F110, SE38, SU01, SM30, tutti codici notoriamente ad alto rischio), e l'ha confrontata con la distribuzione delle sessioni di routine. Il risultato è stata l'inversione: le sessioni ad alto rischio hanno mediamente un tempo di permanenza più lungo di quelle a basso rischio. Poi l'agente ha applicato un'euristica del consulente GRC che la checklist manuale non codifica: le transazioni ad alto rischio devono avere uno SLA in PENDING più breve, non più lungo. L'agente ha prodotto la raccomandazione strutturale: aggiungere un campo di classe di rischio di transazione all'ordinamento della coda di revisione Firefighter, escalation automatica delle sessioni contenenti codici ad alto rischio verso un percorso di revisione a quattro occhi con uno SLA definito, instradarle fuori dalla coda PENDING predefinita e riportare separatamente la conformità agli SLA. Ha collegato il rilievo a SOX ITGC (controllo dell'autorizzazione dei pagamenti), ISO 27001 A.9.4.4 (programmi di utilità privilegiata) e al principio dei quattro occhi. Questa è la mossa che ha portato al gol. Pagamenti bancari eseguiti sotto Firefighter senza revisione indipendente tempestiva sono esattamente il fallimento di controllo che gli auditor cercano in una valutazione esterna. Nessun instradamento per classe di rischio significa che F110 sta nella stessa coda di F-04, e l'attività a maggior rischio riceve il minor tempo.

Perché il Team Human non ha potuto segnare contro questo: ogni sessione viene revisionata quando un revisore la apre. La coda di revisione non comunica al revisore se questa sessione sia più o meno critica per il tempo rispetto ad altre in coda, né quale sia il pattern di SLA a livello di coorte. La distribuzione del tempo di permanenza non è visibile dentro alcuna sessione, è una proprietà della coda, e la coda non la rende visibile. Anche quando un singolo revisore sa che le sessioni F110 tendono ad attendere troppo a lungo, non ha alcun segnale quantitativo per fare escalation e nessun meccanismo per instradare la coda F110 in modo diverso dalla coda di routine.

La correzione non è "dire ai revisori di chiudere le sessioni F110 più velocemente". La correzione è instradarle fuori dalla coda predefinita verso un percorso a quattro occhi con uno SLA definito.

Sei gol segnati. Prima di passare all'analisi post-partita su come è stato effettivamente costruito il Team AI, vale la pena essere espliciti su ciò che l'agente deliberatamente non ha portato alla luce.

I gol che il Team AI non ha segnato

Vale la pena evidenziare ciò che l'agente non ha portato alla luce. Non ha segnalato nessuna singola sessione come fraudolenta. Il dataset non conteneva alcuna evidenza di malintenzionati. Non ha inventato rilievi di conformità che non esistevano. Non ha proposto remediation che il livello delle policy non supporta. Non ha, nonostante girasse su un modello pienamente in grado di allucinare, allucinato transazioni, numeri di documento o attività utente. I numeri in questa serie compaiono perché l'agente li ha contati direttamente da CDPOS, BKPF e tabelle simili, non perché li ha stimati.

Questa è la risposta pratica all'obiezione standard all'uso dell'AI in contesti di audit. L'allucinazione accade quando a un modello viene chiesto di ragionare su qualcosa per cui non ha dati verificabili.

L'agente in questo esperimento aveva dati verificabili per tutto ciò che ha detto. Il livello delle euristiche gli ha indicato cosa cercare. Il livello degli strumenti gli ha permesso di estrarre conteggi verificati dalla piattaforma sottostante. Il livello di feedback delle esecuzioni precedenti ha corretto le sue distorsioni. Ciò che l'agente non poteva ancorare ai dati, non l'ha portato alla luce.

Questo non è lo stesso di una garanzia di assenza di allucinazioni. È una garanzia di verificabilità: ogni conteggio che l'agente ha effettivamente portato alla luce è riproducibile rieseguendo la stessa query sulle stesse tabelle.

Il modello è la parte più piccola di un agente AI in audit. È l'architettura attorno ad esso che determina se l'output è difendibile.

Come si allena il Team AI: metodologia e validazione

Il livello delle euristiche su cui l'agente ragiona è stato scritto da consulenti GRC senior con oltre 15 anni di esperienza in audit SAP, sottoposto a peer review rispetto al materiale formativo di audit dell'azienda e versionato. Ogni euristica deve fare riferimento a una motivazione di controllo di audit documentata prima di essere committata nella libreria di ragionamento dell'agente. Le euristiche non si aggiungono iterando i prompt; si aggiungono con lo stesso processo con cui una società di consulenza scriverebbe un nuovo controllo interno.

Ogni segnale prodotto dall'agente è stato revisionato da un consulente GRC umano prima di apparire in questa serie. Due segnali candidati emersi da passaggi di analisi precedenti sono stati respinti in revisione: uno era un falso positivo basato su dati incompleti del catalogo dei ruoli (l'agente stava lavorando con uno snapshot non aggiornato precedente a una ridefinizione SoD ordinaria), e uno era un'anomalia reale che non aveva implicazioni rilevanti per l'audit e avrebbe prodotto rumore anziché segnale. I sei segnali pubblicati hanno tutti superato quella revisione umana.

Il tasso di falsi positivi su tutti i passaggi di analisi si è attestato attorno all'8%. All'incirca uno su dodici elementi segnalati dall'agente è stato respinto dal revisore umano come basato su contesto incompleto o come anomalia benigna. Il punteggio di confidenza dell'agente correla con l'accettazione del revisore, ma non sostituisce la revisione. Ogni segnale di questa serie è stato verificato, sui dati sottostanti, da un consulente GRC responsabile. Nessun segnale è presentato come definitivo senza tale firma umana.

La divisione del lavoro è il principio. L'agente rileva pattern su una scala e tra domini di dati che la revisione umana non può raggiungere: rilevamento di pattern su 600 sessioni, calcolo di rapporti su 2,55 milioni di voci di log, incrocio tra più domini di dati. L'umano decide se il pattern è rilevante per l'audit, se l'inquadramento è corretto e se è pubblicabile come affermazione di controllo. Nessuno dei due sostituisce l'altro.

Come si schiera il Team AI: l'architettura a sei livelli

Un livello di strumenti: ogni funzione della piattaforma GRC esposta come API ben tipizzata che l'agente può chiamare senza allucinarne gli argomenti. Ogni azione delimitata, controllata nei tipi e reversibile.

Un livello di policy: regole Firefighter, ruleset SoD, classi di rischio delle transazioni, template di commento di audit, regole di instradamento a quattro occhi. Tutto in un formato strutturato che l'agente interroga, anziché testo libero che il modello deve interpretare.

Un livello di contesto storico: ogni verdetto di audit passato con il relativo commento, ogni motivazione di prenotazione con il relativo esito, indicizzati e interrogabili.

Un livello di euristiche: il know-how del consulente GRC sulle anomalie reali rispetto agli outlier benigni. Il livello più difficile da costruire, perché gli autori sono consulenti senior, non ingegneri di LLM.

Un livello di feedback: correzioni dalle esecuzioni precedenti che aggiustano la distorsione dell'agente nel passaggio successivo.

E sopra a tutto, uno step di verifica deterministica che rielabora ogni conteggio prodotto dall'agente, in modo che l'output sia riproducibile end-to-end a richiesta.

Questo è ciò che significa AI in una piattaforma GRC come categoria di prodotto. Non un riquadro ChatGPT aggiunto alla UI. Le stesse funzioni di audit che la piattaforma già possiede, esposte come strumenti dell'agente, situate sotto livelli di logica di business-audit e di contesto storico che vincolano strutturalmente l'allucinazione e rendono verificabile ogni affermazione dell'agente.

La piattaforma GRC di un altro vendor (SAP GRC, altri in questa classe) potrebbe costruire la stessa architettura. Nella nostra implementazione, queste capacità sono fornite tramite il modulo smartAccess di smartGRC. L'architettura è indipendente dalla piattaforma.

La disciplina di mantenere l'agente ancorato a dati verificabili, anziché aggirare il problema delle allucinazioni con il marketing, è ciò che definirà i prossimi cinque anni del SAP GRC.

Come il Team Human rientra in partita

Misurate il vostro campo

I segnali sono riproducibili. Vivono in dati che la vostra organizzazione possiede già, in tabelle che la vostra piattaforma GRC già interroga. Le seguenti domande possono trovare risposta sul vostro dataset Firefighter con lo stesso livello di strumenti utilizzato dall'agente in questo esperimento: tabelle dei documenti di modifica, intestazioni dei documenti contabili, voci di audit log, storico delle prenotazioni, cataloghi dei ruoli. Per il segnale della relazione: di tutte le sessioni Firefighter accettate nel vostro ultimo ciclo, quale frazione è stata approvata da un membro del vostro decile superiore di utenti assidui?

Per il segnale della relazione (Gol n. 1): costruite un grafo direzionale delle prenotazioni Firefighter in cui ogni richiedente è un nodo, ogni approvatore è un nodo, e ogni sessione accettata è un arco dal richiedente all'approvatore. Quale frazione delle sessioni accettate forma anelli chiusi in cui gli utenti Firefighter assidui si approvano a vicenda le sessioni?

Per il segnale dell'origine dell'attività: per ogni account Firefighter, qual è il rapporto tra voci di audit log che hanno origine su hostname di server rispetto a workstation utente? Quali account superano la soglia che suggerisce un carico di lavoro da account di servizio?

Per il segnale del posizionamento dei dati: una ricerca regex sul testo di intestazione BKPF degli ultimi sei mesi. Quanti documenti contengono indirizzi email o altri formati di dati personali?

Per il segnale della completezza del logging: il parametro di sistema SAP che controlla la cattura dei documenti di modifica a livello di campo per le operazioni massive MM02 e LSMW è abilitato nel vostro ambiente?

Per il segnale della concentrazione: per ogni profilo utente Firefighter, qual è la sua quota dei documenti contabili totali e delle modifiche ai dati anagrafici?

Per il segnale di priorità di revisione (Gol n. 6): nella vostra attuale coda PENDING, qual è la distribuzione del tempo di permanenza delle sessioni contenenti F110, SE38, SU01 o SM30 rispetto al tempo di permanenza delle sessioni di routine?

Ciascuna di queste query è un compito di una settimana per un analista SAP/GRC competente. I pattern che emergeranno, se ce ne sono, non saranno gli stessi numeri di questa serie. Ambienti diversi producono distribuzioni diverse. Le domande sono le stesse.

Tre azioni di una settimana

I segnali si traducono in azioni concrete di una settimana per ruoli diversi nell'operatività GRC, indipendenti da qualsiasi programma strutturale di cambiamento pluriennale.

Un CISO dovrebbe commissionare un audit sull'origine dell'attività sugli account Firefighter della propria organizzazione. Una query di un giorno sul Security Audit Log produrrà lo stesso tipo di percentuale del Gol 2, o una differente. Se il numero è alto, alcuni account di emergenza potrebbero operare come account tecnici travestiti.

Un GRC Manager dovrebbe aggiungere un campo di classe di rischio della transazione all'ordinamento della coda PENDING del flusso di audit, mappando il Gol 6 a una modifica di configurazione della coda di revisione anziché a un progetto. La policy Firefighter che avete scritto classifica già F110 come ad alto rischio; il flusso di lavoro deve leggere quella classificazione.

Un revisore interno dovrebbe richiedere al team SAP Basis la conferma se il parametro di documento di modifica a livello di campo (Gol 4) sia abilitato nell'ambiente, e trattare la risposta come un rilievo di valutazione di controllo in entrambi i casi.

Ciascuna di queste è un'azione di una settimana, non un programma pluriennale.

La partita più ampia

La domanda non è se mettere l'AI nel GRC. La domanda è se le piattaforme GRC esporranno le loro funzioni di audit come strumenti per agenti, come dieci anni fa le hanno esposte come UI umane, e se le euristiche che i consulenti GRC portano in testa verranno codificate in un livello di contesto su cui un agente possa ragionare in modo coerente. I primi vendor a farlo, con la disciplina di mantenere l'agente ancorato a dati verificabili anziché aggirare il problema delle allucinazioni con il marketing, definiranno l'aspetto dei prossimi cinque anni del SAP GRC.

Se il vostro ciclo di audit troverà questi pattern prima che compaiano nel report di un auditor esterno dipende interamente dagli strumenti che date alle persone responsabili di trovarli. I segnali di questa serie sono stati il primo deliverable dell'agente. Le correzioni strutturali a cui puntano sono ora un problema che spetta a tutti risolvere.

A proposito di questa serie. Il dataset analizzato in questo articolo proviene da un'effettiva installazione di SAP S/4HANA Firefighter in produzione; l'analisi è stata condotta dal smartGRC LAB di GRC Advisory su un estratto anonimizzato di quei dati. L'articolo non nomina, identifica né attribuisce l'analisi ad alcuna organizzazione specifica. Se gestite SAP Firefighter su larga scala e volete discutere l'esecuzione di un'analisi analoga sui vostri dati, i contatti e una preview UX live si trovano su smartgrc.eu. Questa è l'edizione consolidata della serie in tre parti precedentemente pubblicata come Parte 1, 2 e 3.