De ontbrekende beheersmaatregel begint nadat een agent afwijkt
Organisaties die AI-agents bouwen, investeren terecht in rechten, goedkeuringspoorten, monitoring en auditlogs. Die maatregelen bepalen wat een agent mag doen en helpen achteraf reconstrueren wat er gebeurde. Ze maken de volgende uitvoering alleen niet automatisch veiliger.
Een nieuw voorstel van deelnemers aan de Open Secure AI Alliance maakt dat gat zichtbaar. De Shared AI Findings Exchange, kortweg SAFE, is een conceptkader voor het vertrouwelijk verzamelen van AI-beveiligingsincidenten en bijna-incidenten, het informeren van getroffen partijen en het vertalen van terugkerende fouten naar gedeelde verdedigingsmaatregelen. De Linux Foundation publiceerde het verzoek om commentaar op 4 augustus 2026.
Het voorstel is nog geen definitieve standaard en het is onzeker hoeveel partijen zich zullen aansluiten. Onafhankelijke berichtgeving van Cybersecurity Dive merkt op dat invloedrijke modelaanbieders op dit moment geen lid zijn. Die onzekerheid maakt de operationele les niet zwakker, maar scherper: bedrijven die agents inzetten, kunnen niet wachten tot een extern samenwerkingsverband hun interne leerproces regelt.
Een auditlog is bewijs. Een incidentleerproces is het mechanisme dat bewijs omzet in een veiliger werkproces.
Bijna-incidenten tellen voordat er schade ontstaat
Traditionele incidentafhandeling begint vaak na aantoonbare schade: een datalek, een onbevoegde transactie, uitval of een klantklacht. Agentische systemen geven eerder waarschuwingssignalen die gemakkelijk worden weggewuifd. Een agent probeert een verboden tool aan te roepen en wordt geblokkeerd. Hij stelt een bericht op voor de verkeerde ontvanger, maar een beoordelaar grijpt in. Hij vraagt herhaaldelijk om ruimere rechten. Of hij meldt dat een taak is voltooid terwijl het doelsysteem een onvolledige handeling laat zien.
Geen van deze gebeurtenissen hoeft een datalek te zijn. Ze tonen wel allemaal een verschil tussen het werkproces zoals het is ontworpen en het werkproces zoals de agent het daadwerkelijk uitvoert.
Het SAFE-voorstel neemt bijna-incidenten expliciet mee en laat reviewers naar de hele operationele keten kijken: modelgedrag, instructies, beveiligingen, hulpmiddelen, runtimeomgeving, monitoring, menselijke operatie en afhankelijkheden in de leveringsketen. Het vraagt ook om het bewaren van prompts, traces, tool calls, configuraties, identiteiten, rechten, goedkeuringsmomenten, gewijzigde bestanden en een volledige tijdlijn.
Dat is nuttig, want “het model maakte een fout” is geen oorzaakanalyse. Een afwijking kan ontstaan door verouderde context, een dubbelzinnige methode, te ruime toolrechten, een ontbrekende goedkeuringspoort, zwakke uitzonderingsafhandeling, onvoldoende monitoring of een overdracht zonder eigenaar. Het model is één onderdeel van een operationeel systeem.
Loggen en leren zijn twee verschillende vermogens
Een productie-agent moet een betrouwbare audit trail opleveren buiten zijn eigen verhaal om. De organisatie moet kunnen zien welke context is gebruikt, wat de agent voorstelde, welke hulpmiddelen zijn aangeroepen, welke controles draaiden, wie een handeling goedkeurde en wat er in het doelsysteem veranderde.
Toch kan een groot archief vol traces dezelfde fout klaar laten liggen voor herhaling. Leren vraagt om een besluitproces rondom het bewijs. Iemand moet de gebeurtenis classificeren, het getroffen werkproces bepalen, de mislukte aanname vinden, een correctie kiezen en aantonen dat die correctie werkt.
Het verschil is praktisch:
- Een auditlog beantwoordt: wat gebeurde er tijdens deze uitvoering?
- Een incidentregistratie beantwoordt: wat ging er mis, wat was de impact en wie is eigenaar van de opvolging?
- Een aangepaste beheersmaatregel beantwoordt: wat blokkeert, beperkt of escaleert hetzelfde patroon voortaan?
- Een regressietest beantwoordt: hoe bewijzen we dat de aanpassing blijft werken nadat prompts, modellen, tools of beleid veranderen?
Zonder die laatste twee stappen worden postmortems documentatie in plaats van risicoreductie.
Bouw één incidentproces over data, methoden, tools en governance
AI-incidenten horen niet alleen in een securitywachtrij. Veel afwijkingen zijn operationeel voordat ze een beveiligingsincident worden. Een documentagent kan een verouderde procedure gebruiken. Een serviceagent kan een geldige uitzondering verkeerd routeren. Een finance-agent kan het juiste bewijs verzamelen maar de verkeerde goedkeuringsroute toepassen. Het leerproces heeft daarom de proceseigenaar, de technische eigenaar en waar nodig de risico- of security-eigenaar nodig.
Een werkbare cyclus bestaat uit zes stappen:
- Leg de gebeurtenis vast. Verzamel incidenten en bijna-incidenten uit automatische detectie, menselijke beoordeling, gebruikersmeldingen en vergelijking met de toestand van doelsystemen. Vertrouw er niet op dat de agent zijn eigen fout correct beschrijft.
- Beperk de impact. Pauzeer de getroffen handeling, verklein rechten, schakel een hulpmiddel uit of zet het werkproces terug naar alleen voorbereiden wanneer het risico daarom vraagt.
- Bewaar het bewijs. Houd de exacte context, model- en beveiligingsversies, prompts, tool calls, identiteiten, goedkeuringen, output en uiteindelijke systeemstatus vast. Een screenshot van het eindantwoord is niet genoeg.
- Vind de mislukte aanname. Vraag welke laag de gebeurtenis had moeten voorkomen en waarom dat niet gebeurde. Was de bron leidend? Was de regel uitvoerbaar? Waren de rechten te ruim? Kon een operator de handeling zien en onderbreken?
- Pas een beheersmaatregel aan. Verbeter bronselectie, maak een bedrijfsregel deterministisch, beperk de toolscope, voeg validatie toe, scherp escalatie aan of versterk monitoring. “Zet het nog een keer in de prompt” is bij een fout met grote impact zelden genoeg.
- Voeg een regressietest toe. Reproduceer de gebeurtenis in een gecontroleerde omgeving en bewijs dat het aangepaste werkproces haar blokkeert of veilig afhandelt. Draai die test opnieuw wanneer model, prompt, integratie of beleid verandert.
Zo wordt operationele ervaring onderdeel van de AI Operating Layer in plaats van een map met postmortems.
Gebruik een kleine registratie die tot actie dwingt
Een intern AI-incidentenregister hoeft niet te beginnen als een groot governanceplatform. Start met een vaste registratie die is gekoppeld aan het werkproces en de eigenaar daarvan. Leg minimaal vast:
- het getroffen proces, de agent en de bedrijfseigenaar;
- de waargenomen gebeurtenis en de werkelijke toestand van het doelsysteem;
- of de fout werd geblokkeerd, schade veroorzaakte of een bijna-incident bleef;
- de betrokken data, identiteiten, rechten en hulpmiddelen;
- de gefaalde beheersmaatregel of onbewezen aanname;
- het besluit om de impact te beperken en de eigenaar daarvan;
- de structurele aanpassing, deadline en verantwoordelijke persoon;
- de regressietest en het bewijs dat die slaagt;
- de datum waarop wordt gecontroleerd of het patroon is teruggekeerd.
Koppel ernstcriteria aan bedrijfsimpact: blootstelling van gevoelige data, onomkeerbare handelingen, financiële gevolgen, klantimpact, juridische verplichtingen en het onvermogen om een fout te detecteren of te herstellen. Een vreemd modelantwoord zonder operationeel gevolg verdient niet dezelfde respons als een onbevoegde wijziging in een ERP-systeem.
Meet of de operatie daadwerkelijk veiliger wordt
Alleen incidenten tellen kan misleiden. Meer meldingen kunnen betekenen dat het systeem slechter wordt, maar ook dat medewerkers afwijkingen beter herkennen en rapporteren. Meet daarom de hele opvolgingscyclus.
Bruikbare indicatoren zijn de tijd tot detectie, de tijd tot beheersing, het percentage bijna-incidenten met een benoemde eigenaar, het percentage correcties dat op tijd wordt afgerond, herhaling van bekende foutpatronen en dekking van regressietests voor handelingen met grote impact. Kijk ook waar gebeurtenissen ontstaan. Een cluster rond één integratie, beleidsregel of overdracht is bruikbaarder dan één totaalgetal.
Het doel is niet nul meldingen. Een stille operatie kan ook een onzichtbare operatie zijn. Het doel is minder herhaling, kleinere impact en sneller herstel terwijl de agent meer verantwoordelijkheid krijgt.
Wacht niet op een gedeelde standaard
Het SAFE-voorstel is waardevol omdat het incidenten behandelt als grondstof voor controleerbare beheersmaatregelen, niet als losse reputatieproblemen. Over de voorgestelde externe rapportagetermijnen en governance zal nog worden gediscussieerd. Iedere organisatie moet bovendien haar eigen contractuele en wettelijke meldplichten blijven volgen.
Intern is de richting al duidelijk. Als een agent werkt met documenten, kennis, klantcommunicatie of bedrijfssystemen, heeft de organisatie meer nodig dan preventie en logging. Er is een vaste routine nodig die leert van afwijkingen terwijl de gevolgen nog klein zijn.
Begin bij één live werkproces. Definieer wat als incident en bijna-incident telt. Benoem de eigenaren. Bewaar genoeg bewijs om fouten te reproduceren. Eis dat iedere materiële gebeurtenis eindigt in een bewust geaccepteerd risico of een geteste aanpassing. Zo groeit AI van een indrukwekkende mogelijkheid naar een operatie die door echt gebruik aantoonbaar beter wordt.