Maskinhastighet knäcker granskning i efterhand
De flesta SAP-team granskar privilegierade konton, servicekonton och tekniska konton på samma sätt som de alltid har gjort: exportera en logg, öppna den i ett kalkylark och läs. Kanske månadsvis. Kanske efter en incident. När revisorn frågar.
AI förändrar skalan på det jobbet. Agenter och skript pratar nu direkt med SAP - OData-anrop, RFC-läsningar, GUI-automatisering - körande under servicekonton, ofta över natten, med hundratals händelser per minut. Det mesta är precis vad man kan förvänta sig. Ett upptäcktsskript läser tabellstrukturer; ett övervakat konto kör sina rutinjobb.
Problemet är resten. Den enda läsningen som rörde en känslig tabell. Den enda åtgärden utanför kontots normala mönster. I en logg med tusentals händelser är den enskilda posten osynlig för det mänskliga ögat - och när en manuell granskning hittar den är spåret veckor gammalt.
Det finns ett andra problem under detta: ansvarstillskrivning. När en agent körs under en persons konto är revisorns första fråga inte ”läs eller skriv?” - det är ”vem är ansvarig för den sessionen?”. En personlig användare som kör ett skript suddar ut ansvarsfördelning (SoD) och kopplar varje fel till någon som aldrig faktiskt skrev något.
Att förbjuda det får det inte att sluta
Det finns ett lockande svar på allt detta: släpp inte in AI eller skript i SAP alls. Det fungerar inte. Människor automatiserar redan de delar av sitt jobb som de tycker minst om - den manuella exporten, kopieringen till Excel, samma fem klick hundra gånger om dagen. Stäng den sanktionerade vägen så tar de den osanktionerade: en personlig användare, ett lokalt skript, ett verktyg på en laptop som IT aldrig ser.
Så valet var aldrig AI i SAP - ja eller nej. Det är övervakad eller skugga. Ett generellt förbud tar inte bort risken; det tar bort er synlighet över den och pressar aktiviteten till exakt de personliga konton som suddar ut ansvarstillskrivningen mest.
Och det blir enklare, inte svårare. Att aktivera SAP GUI Scripting är en enda profilparameter (sapgui/user_scripting = TRUE); en liten COM-brygga låter en assistent styra en aktiv SAP-session; och praktiker publicerar redan agenter som öppnar en transaktion, läser ett ALV-rutnät och producerar en Excel-analys på ett par minuter.
Det blir också inbyggt. SAP:s egen Joule-assistent bäddas nu in i SAP GUI for Windows, med frontend-åtgärder som läser den aktuella skärmen och kör GUI-skript direkt - AI som driver SAP-transaktioner som en leverantörsstödd funktion, inte en workaround. Kapaciteten är på väg, oavsett om era kontroller är redo eller inte.
En fungerande agent, i en enkel textprompt
Detta är inte teoretiskt. En praktiker pekar en assistent mot en aktiv SAP-session över COM och skriver något nära vanlig engelska: lista anslutningarna, öppna felmonitorn, läs meddelandena, bygg mig ett Excel-ark med de sannolika åtgärderna. Två minuter senare finns ett rangordnat kalkylark - meddelandeklass, antal, allvarlighetsgrad, transaktionen där varje ska åtgärdas - för en migreringskörning med fjortontusen bokföringsfel som skulle ha kostat en konsult en eftermiddag. Människor publicerar öppet dessa genomgångar, med installationsstegen bifogade.
Idag är de flesta av dessa agenter medvetet försiktiga: skrivskyddade, körande under personens egen session och behörigheter, inga bokföringar. Men läs de ärliga tekniska anteckningarna som följer med dem och riktningen är tydlig. Primitivorna - navigera, läsa ett fält, tolka ett rutnät, upptäcka en skärm - driver redan de flesta rapporttransaktioner. Det som fortfarande saknas (systemspecifika fält-ID:n, sidindelning i rutnät, bokföringsflöden över flera skärmar) är brister i tillförlitlighet, inte i avsikt. Nästa version vill ha djupare skärmupptäckt och så småningom skrivning tillbaka.
Det är punkten där kontrollfrågan slutar vara valfri - och, praktiskt nog, där ”endast läsning” idag ger er ett lugnt fönster att sätta kontot, policyn och bevisen på plats innan skrivning tillbaka anländer.
Granska undantagen, inte loggen
Lösningen är inte mer granskning. Det är mindre - riktad mot det som faktiskt spelar roll.
Istället för att läsa allt ett konto gjort och bedöma det i efterhand definierar ni i förväg vad kontot får göra. Systemet visar sedan enbart den aktivitet som hamnar utanför den linjen. Granskning slutar vara arkeologi rad för rad och blir hantering av undantag: fem saker att titta på, inte fem tusen.
Övervakade konton och en levande policy
smartGRC bevakar privilegierade konton, servicekonton och AI-konton mot en policy - en vitlista och en svartlista av transaktioner, avgränsade till ett konto eller en uppsättning konton. När något hamnar utanför policyn kör processen sig själv:
Vitlista
Transaktioner som uttryckligen är tillåtna för kontot. Vitlistad aktivitet passerar tyst - inget granskningsbrus, ingen larmtrötthet.
Aktivitet utanför listan
Allt som inte finns på vitlistan (och allt som finns på svartlistan) utlöser ett undantag i samma stund det sker.
Ägaren notifieras
Ansvarig ägare får undantaget i realtid - inte veckor senare från en rå export.
Motivera eller vitlista
Ägaren förklarar vad som hände, eller lägger till transaktionen som en ny, versionshanterad regel. Varje undantag blir dokumenterad historik eller en snävare policy.
Arbetsflödet ovan översätts direkt till hur smartGRC hanterar en aktiv SAP-session. Diagrammet nedan visar vad som händer vid varje transaktion som AI-agenten kör - från det inledande anropet, genom policykontrollen, till de tre sätten en åtgärd utanför listan kan lösas på. Den streckade gröna slingan tillbaka till policyn är nyckeldetaljen: varje beslut ägaren fattar lär gränsen, så morgondagens granskning är mindre än dagens.
Varje undantag slutar som dokumenterad historik eller en snävare policy. Regeluppsättningen blir mer precis varje gång den används.
Läs från vänster till höger: AI-agenten anropar en transaktion, smartGRC kontrollerar den mot policyn i realtid och låter den antingen passera tyst eller utlöser ett undantag i samma stund det ses. Det undantaget landar hos ägaren - inte nästa vecka, inte i en månadsrapport. Därifrån finns tre utfall: vitlista (transaktionen var legitim och ansluter till reglerna nästa gång), motivera (en engångsföreteelse, förklarad och dokumenterad för revisionsspåret), eller blockera (kontot får inte köra detta igen förrän någon godkänner). Samma gränssnitt, samma bevis, oavsett hur ägaren beslutar.
Det fjärde steget är det som ackumuleras. Gränsen ni upprätthåller är aldrig ett inaktuellt dokument - det är en regeluppsättning som blir mer precis varje gång den används. Och den körs i två lägen som täcker hela bilden:
Vad passerar, vad flaggas
Ta ett servicekonto som används av en AI-agent för att utforska och rapportera SAP-data. Samma konto, samma etikett ”endast läsning” - och tre mycket olika utfall, avgjorda av policyn, inte av granskarens minne:
De vitlistade läsningarna når aldrig en människa. Undantagen landar hos ägaren samma dag - motivera, eller lägg till som regel. Poster på svartlistan stoppas helt. Granskaren ser en handfull poster, inte de tusen som var korrekta.
Lätt att missa, dyrt att förklara
Var och en av dessa ser oansenlig ut i en rå logg, mitt bland hundratals harmlösa läsningar. Det är precis därför de behöver dyka upp på egen hand.
Vad som händer. En agent läser RFC-destinationer medan den ”bara utforskar systemet”.
Varför det spelar roll. RFCDES kan innehålla lagrade anslutningsuppgifter. Massläsning av den är ett väsentligt fynd för en revisor även när ingenting skrivs - och i en rå logg ser det identiskt ut med de harmlösa metadataläsningarna runt omkring. Ingen upptäcker det förrän någon börjar leta, och då är det en incident, inte en anteckning.
Vad som händer. Ett servicekonto bokför 500 dokument på två minuter - del av en pipeline som ”bearbetar det i ett annat system och skriver tillbaka”.
Varför det spelar roll. Volym och hastighet är den AI-specifika signalen. En människa kan inte bokföra 500 poster på två minuter, så själva mönstret är den röda flaggan - och skrivning tillbaka är där en berättelse om ”endast läsning” tyst blir en skapare av finansiella transaktioner. Fångas det i realtid är det en fråga till ägaren; fångas det vid revision är det ett avstämningsproblem.
Vad som händer. En agent för ”endast läsning” behöver SAP GUI Scripting växlat från att läsa skärmen till att aktivt driva den.
Varför det spelar roll. ”Läs GUI:t” och ”operera GUI:t” är olika kontrolltillstånd. Att växla till aktiv scripting är en ITGC-förändring som öppnar makrostyrning av varje transaktion användaren kan nå. En agent som tyst kräver det har korsat från läs till styrning - och den gränsen är en som en revisor kommer att be er bevisa att ni upprätthåll.
En gräns som systemet upprätthåller - med en ägare, ett undantag i realtid och ett fullständigt spår för revisorn - är det. Det är skillnaden mellan att ha en AI-användningspolicy och att kunna bevisa att den håller.
Övervaka en AI-agent på det sätt smartGRC gör det
Vitlista och svartlista per konto. Undantag till ägaren i realtid. Ett spår som revisorn accepterar. Se arbetsflödet i smartGRC:s livedemo.
Relaterad läsning
Intelligent SoD-rapportering
Hur AI förvandlar SAP-åtkomstrisk till bevis av revisionsklass. Från 4 000 flaggor till en försvarbar kortlista.
Firefighter AI mot människa 6:0
Sex månaders firefighter-data från produktions-SAP S/4HANA. Sex kontrollsignaler som klassisk granskning missar.
30 AI-agenter för SAP
Hela katalogen - Decision Co-pilot, Anomaly Detection, Firefighter Review och 27 till.