Federale AI-incidentrichtlijn Zet Bewijs Centraal

De eerste vraag nadat een AI-agent iets doet wat niemand hem heeft opgedragen, is niet “wie is er schuldig.” Het is “wat kun je bewijzen?” De meeste organisaties kunnen daar geen helder antwoord op geven, en de nieuwste federale richtlijn voor AI-incidentrespons is precies op die zwakte gebouwd.

NIST, de NSA en CISA brachten op 16 oktober 2026 gezamenlijk het document Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation uit, zoals gerapporteerd door ComplexDiscovery. Het bevat 10 vrijwillige praktijken verdeeld over vijf fasen (voorbereiden, detecteren, reageren, herstellen en rapporteren) en bouwt voort op de NIST CSF 2.0 en NIST SP 800-61 Revisie 3. De auteurs zijn het Center for Advancing Innovation and Standards for Super Intelligence van NIST, het Super Intelligence Security Center van de NSA en CISA. De primaire doelgroep is de kleine groep laboratoria die zeer geavanceerde modellen traint en evalueert.

Als je verantwoordelijk bent voor security of compliance bij een organisatie die AI-agents inzet in plaats van frontier-modellen bouwt, is het verleidelijk om dit als “iemand anders’ probleem” te zien. Dat zou een vergissing zijn. Het document is kort, algemeen en expliciet vrijwillig, en stelt dat de praktijken ook kunnen gelden voor organisaties die deze agents inzetten. Belangrijker nog: de vragen die het stelt (wat deed de agent, wat raakte hij aan, kun je het reconstrueren, heeft je schoonmaakactie het bewijs vernietigd) zijn exact de vragen die je toezichthouders, verzekeraars en advocaten zullen stellen na je eerste agent-incident.

Belangrijkste Inzichten

1. Bewijs wordt als een control beschouwd.

De richtlijn vraagt organisaties om modelgewichten, tussentijdse checkpoints, tool-calls, afgewezen acties en de status van de omgeving te bewaren zodat een incident onderzocht en gereproduceerd kan worden.

2. De richtlijn is vrijwillig en algemeen.

Er staat een disclaimer in dat het informatief is en geen compliance- of juridisch advies, dus het certificeert niets en is voor niemand bindend.

3. Retentie en volgorde blijven open.

Het document stelt geen bewaartermijn vast en vereist niet expliciet dat het vastleggen van bewijs afgerond moet zijn voordat een gecompromitteerde omgeving wordt herbouwd.

4. Inzetters krijgen dezelfde bewijs-vragen.

Een organisatie die agents inzet op gevoelige data krijgt hetzelfde reconstructieprobleem, ook al is het document geschreven voor frontier-ontwikkelaars.

5. De praktische stap is toegang op het data-niveau te beheren.

Beperk wat een agent kan bereiken en registreer elke toegang in één audittrail: dat maakt de rest van de richtlijn uitvoerbaar.

Wat de Richtlijn Werkelijk Zegt

Begin bij de definitie, want die bepaalt alles. De hoofdtekst staat op NIST’s site en CISA host een kopie van de bron. Het document beschrijft een “control incident” als een situatie waarin een AI-agent significante niet-geïnstrueerde acties onderneemt die het beleid, de controls of het menselijke toezicht ondermijnen die zijn taak definiëren. Niet-geïnstrueerd is hier belangrijk. Volgens de interpretatie van ComplexDiscovery worden acties veroorzaakt door prompt-injectie of een backdoormodel als geïnstrueerd beschouwd, dus die vallen buiten de primaire definitie. Dat is een smallere blik dan de meeste securityteams in het bedrijfsleven hanteren, en het is goed om te weten voordat je de richtlijn op je eigen risicoregister projecteert.

Het tweede concept is de bijna-misser. De richtlijn definieert dit als een gebeurtenis die geen incident werd, maar wel een redelijk voorzienbaar of dreigend risico vormde om dat te worden, en behandelt bijna-missers als mogelijke triggers voor snelle respons. Iedereen die in de luchtvaart of zorgprocessen heeft gewerkt, herkent de logica. De gebeurtenis die bijna plaatsvond, is goedkoop om te onderzoeken en duur om te negeren. In een standaard securityprogramma is een bijna-misser een ticket dat gesloten wordt omdat er niets misging.

De vijf fasen zijn herkenbaar voor iedereen die ooit een incident response plan heeft uitgevoerd. Voorbereiden omvat technische beveiligingen, beperkte agentrechten, shutdownmechanismen en getraind personeel. Detecteren omvat monitoring van systemen, interfaces en netwerken, niet alleen het model. Reageren omvat afbakening, indamming en het bewaren van bewijs. Herstellen omvat het verifiëren dat de indamming werkte voordat een agent opnieuw wordt gestart, inclusief het bevestigen dat monitoring, logging, toegangsbeperkingen en shutdownmechanismen functioneren. Rapporteren omvat het informeren van betrokken partijen, voldoen aan toepasselijke meldingsvereisten en vrijwillig delen met de overheid en, waar passend, het publiek.

De control-taal zal ook vertrouwd aanvoelen. De richtlijn stelt dat agents alleen toegang mogen hebben tot de informatie, systemen en tools die hun taak vereist, en CPO Magazine voegt single-use infrastructuur en beperkingen op communicatie tussen agents toe aan de lijst van logische controls. Niets hiervan is exotisch. Het is least privilege, tijdelijke omgevingen en segmentatie toegepast op een nieuw soort actor. Wat nieuw is, is de onderliggende aanname: de actor kan zich gedragen op manieren die de operator niet bedoelde, dus de omgeving eromheen moet zo zijn ontworpen dat het hem kan indammen en onthouden wat hij deed.

Waarom Bewijsbewaring het Zwaartepunt Is

Van de 10 praktijken heeft de bewijspraktijk de meeste operationele impact voor een compliance-leider. De fase Reageren vraagt om het bewaren van modelgewichten en de trainings-, evaluatie- en inzetomgevingen, voor zover nodig om een incident te onderzoeken. Volgens de details van ComplexDiscovery omvat dat tussentijdse checkpoints, tijdstempels, sandbox- en netwerklogs, afgewezen acties en tool-calls, en de configuratie die nodig is om te reconstrueren wat er is gebeurd. Ook worden logbestanden beschreven die bestand zijn tegen manipulatie, met betrouwbare tijdstempels voor agent-trajecten, tool-calls, gebruikersinteracties, omgevingsstatussen en security-control beslissingen.

Lees die lijst zoals een auditor dat zou doen. Het is een beschrijving van een bewijsrecord, geen verlanglijstje voor monitoring. De term “afgewezen acties” verdient extra aandacht, want de meeste loggingprogramma’s registreren alleen wat er is gebeurd en zeggen niets over wat de agent probeerde te doen maar werd tegengehouden. Juist in die tweede categorie bevindt zich vaak de bijna-misser.

Hetzelfde principe geldt voor je eigen inzet, zelfs als je nooit modelgewichten aanraakt. De equivalente artefacten voor een organisatie zijn de prompts en instructies die een agent kreeg, de identiteit waaronder hij handelde, de bestanden en records die hij opende, de tools die hij gebruikte en de beleidsbeslissingen die elke stap toestonden of weigerden. Als die verspreid zijn over vijf verschillende systemen met vijf verschillende bewaartermijnen, wordt reconstructie een forensisch project in plaats van een query. Een goed ingerichte audit log die menselijke en agent-activiteiten op één plek vastlegt, maakt het verschil tussen die twee uitkomsten.

Er is een punt over vertrouwen dat verloren gaat in de technische details. Bewijs is alleen nuttig als iemand anders erop kan vertrouwen. Daarom benadrukt de richtlijn manipulatiebestendigheid en betrouwbare tijdstempels, en hoort de term chronologische documentatie thuis in het gesprek. Een logbestand dat je eigen beheerders kunnen aanpassen, is een logbestand dat de tegenpartij in twijfel zal trekken.

De Gaten die een CISO of CCO Moet Zien

Een vrijwillig document van circa 14 pagina’s kan niet elk operationeel vraagstuk oplossen, en de commentaren eromheen zijn daar snel duidelijk over. Vier gaten springen eruit voor een security- of compliance-leider.

Geen bewaartermijn

De richtlijn zegt bewijs te bewaren zolang nodig voor onderzoek, maar noemt geen periode. Voor een frontier-lab is dat misschien logisch, want de hoeveelheid gewichten en checkpoints is enorm en het juiste antwoord hangt af van het incident. Voor een gereguleerde organisatie blijft er een gat. Je bewaartermijn voor AI-agentrecords wordt bepaald door sectorspecifieke regels, contractvoorwaarden en procesrisico’s, niet door dit document. Als je agentlogs elke 30 dagen worden overschreven en een toezichthouder vraagt naar een gebeurtenis van 90 dagen geleden, helpt de richtlijn je niet.

Vastleggen versus herbouwen

De fase Herstellen omvat herbouwen vanaf geverifieerde baselines en het intrekken van toegangsrechten die tijdens een incident zijn gebruikt. De fase Reageren omvat het bewaren van bewijs. Die twee instructies kunnen botsen. Als een team een gecompromitteerde omgeving herbouwt voordat het bewijs is vastgelegd en gehasht, vernietigt de herbouw het record. Het document stelt dat de praktijken gelden gedurende de hele levenscyclus, maar specificeert de volgorde niet, en de analyse van ComplexDiscovery suggereert dat het veiligste patroon is om eerst een snapshot en hash te maken voor je herbouwt. Zet die volgorde in je draaiboek in heldere taal. Het midden van een incident is een slecht moment om te ontdekken dat twee goede praktijken elkaar bijten.

Rechtszaken worden niet genoemd

Het document gaat niet in op juridische bewaarplichten. Dat is begrijpelijk gezien de doelgroep, maar betekent dat de bedrijfsjurist de ontbrekende laag moet toevoegen. Zodra een agent-incident een redelijke kans op een rechtszaak creëert, wordt bewaren geen goede gewoonte meer, maar een juridische plicht. Je eDiscovery-proces moet weten dat agenttranscripten, tool-call logs en beleidsbeslissingen vindbare records zijn, en moet ze kunnen bevriezen zonder de agentvloot stil te leggen.

Bijna-missers scoren is moeilijker dan ze benoemen

De richtlijn vraagt om ernstscores en behandelt bijna-missers als triggers. Geen van beide is eenvoudig. Ernstscoring voor een agent die bijna een gevoelig bestand naar de verkeerde bestemming stuurde, vereist een rubric die je team vooraf heeft afgesproken. Zonder zo’n rubric wordt de eerste bijna-misser een discussie over of het telt. De praktische oplossing is om nu een korte ernstschaal te kiezen, met voorbeelden uit je eigen agentgebruik, en daar een tabletop-oefening mee te doen.

In de commentaren is ook opgemerkt dat monitoringtools hun eigen kwetsbaarheden kunnen introduceren en dat het überhaupt lastig is een rogue agent-incident te herkennen. Dat zijn terechte waarschuwingen. Het zijn ook redenen om de richtlijn als een startchecklist te behandelen, niet als een compleet programma.

Waarom Inzetters Dezelfde Vragen Krijgen

Frontier-labs en organisaties zitten op verschillende plekken op de risicocurve, maar het faalpatroon lijkt op elkaar. Een agent krijgt een doel, een set toegangsrechten en toegang tot data. Iets in de taak, de omgeving of het modelgedrag zorgt ervoor dat hij buiten zijn opdracht handelt. Iemand moet dan aan een bestuur, toezichthouder of klant uitleggen wat er is gebeurd.

Onderzoeksresultaten suggereren dat de meeste organisaties daar niet klaar voor zijn. Het 2026 State of AI Governance-rapport van Schellman, gebaseerd op 525 Amerikaanse professionals bij bedrijven met 500 of meer medewerkers, vond dat slechts 22 procent drempels heeft gedefinieerd voor wanneer een mens het werk van een agent moet beoordelen, volgens het Schellman 2026 State of AI Governance whitepaper. Zo’n drempel is een voorwaarde voor een bijna-misserprogramma. Als niemand heeft vastgelegd wat een agent zelfstandig mag doen, kan niemand zeggen wanneer hij over de grens gaat.

Hetzelfde beeld geldt voor audits. Grant Thornton’s 2026 AI Impact Survey onder 950 senior organisatieleiders vond dat 78 procent weinig vertrouwen heeft dat ze binnen 90 dagen een onafhankelijke AI-governance-audit zouden doorstaan, zoals gerapporteerd op de Grant Thornton survey page. Auditors vragen niet of je een beleid hebt. Ze vragen om het bewijs. De federale richtlijn is in feite een verklaring van drie instanties over hoe een geloofwaardig bewijsrecord eruitziet als de actor een AI-agent is.

Verantwoordelijkheid is de derde rode draad. Een enquête onder executives en technische leiders door Gravitee, samengevat in het State of AI Agent Security 2026 report, vond dat slechts circa 7 procent een benoemd persoon heeft die verantwoordelijk is voor agentgedrag. Het cijfer is zelfgerapporteerd door een leverancier en moet richtinggevend worden gelezen, maar de richting is duidelijk. Wanneer een incident plaatsvindt, heeft de incidentcommander een tegenhanger nodig aan de businesszijde die eigenaar is van het doel en de rechten van de agent.

Geen van deze drie bronnen mat de federale richtlijn, en geen ervan bewijst dat organisaties zullen falen bij een AI-incident. Samen suggereren ze dat de voorwaarden voor een goede respons (gedefinieerde drempels, auditklare records, benoemde eigenaren) bij de meeste organisaties ontbreken. Dat is de echte waarde van de richtlijn voor een inzetter: het biedt een neutraal extern referentiepunt als je om budget vraagt.

De Richtlijn Vertalen naar een Werkend Programma

Je hoeft niet alle 10 praktijken te implementeren om er voordeel van te hebben. Een verstandige aanpak is om de vijf fasen te vertalen naar beslissingen die je team dit kwartaal kan nemen.

Voorbereiden door de actor en impactzone te definiëren

Begin met een inventarisatie. Maak een lijst van elke AI-agent in productie of pilot, de identiteit die hij gebruikt, de data die hij kan bereiken en de persoon die eigenaar is. Pas dan least privilege toe, wat de richtlijn expliciet noemt. Een agent die klantoverzichten opstelt, heeft geen schrijfrechten nodig op het contractenarchief. Sterke access controls op de data zelf, niet alleen op de applicatie waar de agent in draait, voorkomen dat een ontsporende agent een data-exposure incident veroorzaakt.

Hier horen ook zero trust security-principes bij. Behandel de agent als een actor die bij elk verzoek moet worden geverifieerd, beperkt tot de taak en standaard geen toegang krijgt. De oproep van de richtlijn tot shutdownmechanismen hoort hier ook bij. Als je de toegang van een agent niet binnen enkele minuten kunt intrekken, heb je geen shutdownmechanisme maar een hoop.

Detecteren door naar de data te kijken, niet alleen het model

De richtlijn stelt dat monitoring systemen, software-interfaces en netwerken moet omvatten, niet alleen het model. Voor de meeste organisaties is data-toegang het nuttigste signaal. Welke bestanden heeft deze agent geopend, hoeveel, uit welke bronnen, en past dat patroon bij zijn doel? Door die gebeurtenissen naar je SIEM te sturen, krijgt het security operations team iets concreets om op te alarmeren, en voorkom je dat je een aparte monitoringstack bouwt voor agents die niemand beheert.

Reageren door eerst vast te leggen, dan pas in te dammen en te herbouwen

Leg de volgorde vastleggen-voor-herbouwen vast in het draaiboek. Maak een snapshot van de omgeving, exporteer de logs, hash ze, registreer wie ze heeft behandeld, en trek daarna pas toegangsrechten in en herbouw. Koppel dit aan je risicobeoordeling zodat het team weet welke agents een volledige forensische vastlegging vereisen en welke een lichtere aanpak. Niet elk incident verdient dezelfde diepgang, maar de keuze moet vooraf worden gemaakt, niet tijdens het incident.

Herstellen door het herstel te bewijzen voor herstart

De richtlijn vraagt teams te bevestigen dat monitoring, logging, toegangsbeperkingen en shutdownmechanismen werken voordat een agent opnieuw wordt gestart. Maak hiervan een gedocumenteerde checklist met een benoemde goedkeurder. Dit is de stap die onder druk van de business vaak wordt overgeslagen, omdat de agent een live proces ondersteunt en iedereen hem terug wil. Een ondertekende verificatiestap is goedkope verzekering.

Rapporteren door vooraf te bepalen wie wat hoort, en wanneer

Rapporteren is volgens de richtlijn vrijwillig, behalve wat de wet al vereist, dus de organisatie moet bepalen welke verplichtingen gelden. Sectorspecifieke regels, contractbepalingen en meldingsplichten blijven leidend. Bepaal vooraf wie klanten te woord staat, wie toezichthouders aanspreekt en wie beslist of er gedeeld wordt met CISA of een branchegroep. Stem dit af met de Govern-functie in NIST CSF 2.0, die verwacht dat leiderschap eigenaar is van de cybersecuritystrategie en verantwoordelijkheid, niet dat het wordt gedelegeerd aan het SOC.

Waar Data-Layer Governance Past

Het zou overdreven zijn te zeggen dat een enkel product aan deze richtlijn voldoet. Het certificeert niets, en geen leverancier kan claimen compliant te zijn. Wat een organisatie wel kan doen, is kijken naar het bewijs dat de richtlijn vraagt en nagaan welk deel daarvan consequent uit één bron kan worden geleverd.

Kiteworks secure data exchange benadert dit vanuit het data-niveau. In plaats van te vertrouwen op elke applicatie of agent-framework om eigen gedrag te loggen, past het platform beleid toe waar gevoelige inhoud zich bevindt en registreert elke toegang in één set auditlogs. De data policy engine beoordeelt wie of wat iets vraagt, wat er wordt gevraagd en of het beleid dat toestaat. De Secure MCP Server brengt AI-assistenten en agents die via MCP verbinden onder datzelfde beleid, zodat de toegang van een agent tot gevoelige inhoud aan dezelfde regels voldoet en hetzelfde type record achterlaat als die van een menselijke gebruiker.

Dat ontwerp weerspiegelt twee thema’s uit de richtlijn zonder te claimen eraan te voldoen. Agenttoegang beperken tot wat een taak vereist is een beleidsbeslissing die wordt afgedwongen op het toegangspunt. Een bruikbaar bewijsrecord van agentactiviteit is een bijproduct van diezelfde handhaving, omdat de toestaan- en weigeren-beslissingen worden gelogd waar de inhoud zich bevindt. Het resultaat is een bewijstraject dat een CCO aan een auditor kan overhandigen en een CISO kan raadplegen tijdens een incident, opgebouwd vanuit de governance-laag in plaats van achteraf gereconstrueerd.

Deze aanpak heeft grenzen die duidelijk benoemd moeten worden. Data-layer controls bewaren geen modelgewichten, trainingsomgevingen of de interne redeneringen van een model dat je zelf draait. Ze beantwoorden de vraag waar de meeste organisaties daadwerkelijk mee te maken krijgen: wat deed een agent met de gevoelige inhoud waartoe hij toegang had? Organisaties die zelf modellen trainen of fine-tunen, zullen extra vastleggingsmechanismen voor die artefacten nodig hebben.

Dezelfde governance geldt voor menselijke en agenttoegang. Agents als aparte klasse met een apart regelboek behandelen, creëert het tweelagenprobleem dat audits vaak blootleggen. Eén AI data governance-aanpak, waarbij de regels aan de data hangen en de actor simpelweg een andere identiteit is die geverifieerd moet worden, is makkelijker uit te leggen en te verdedigen.

Een 90-Dagenplan voor Security- en Compliance-Leiders

Richtlijnen zonder deadline blijven vaak liggen. Hier is een volgorde die binnen een kwartaal past en geen nieuw budget vereist om te starten.

Binnen de eerste 30 dagen: stel de agentinventaris op en wijs voor elke agent een eigenaar aan. Bevestig welke identiteiten agents gebruiken en of die identiteiten beperkt zijn tot hun taak. Controleer de bewaartermijnen van elk systeem dat agentactiviteit registreert en noteer de kortste. Dat getal is je feitelijke bewaartermijn, ongeacht je beleid.

In dagen 31 tot 60: definieer een korte ernstschaal voor agentincidenten en bijna-missers, met drie of vier voorbeelden uit je eigen praktijk. Leg de volgorde vastleggen-voor-herbouwen vast in het incidentdraaiboek en betrek juridische zaken zodat juridische bewaarplichten agenttranscripten en tool-call logs omvatten. Bepaal wie een agent mag uitschakelen en test of dat lukt.

In dagen 61 tot 90: voer een tabletop-oefening uit rond een bijna-misser. Kies een scenario waarin een agent inhoud ophaalt die hij niet mocht hebben, of een actie probeert die door beleid wordt geblokkeerd. Doorloop met het team detectie, bewijsvastlegging, afbakening en rapportage. Meet de tijd, noteer wat ontbrak en breng de gaten naar de volgende risicocommissievergadering samen met de onderzoeksresultaten hierboven. Als de oefening aantoont dat je niet kunt reconstrueren wat de agent deed, heb je je budgetonderbouwing.

Houd de toon van de oefening praktisch. Het doel is niet om schuldigen aan te wijzen, maar om vooraf te leren welke records er zijn, wie ze kan bereiken en hoe lang reconstructie duurt. Teams die dit eenmaal hebben gedaan, merken dat het eerste uur van een incident de tweede keer veel beter verloopt.

Wat Nu in de Gaten Houden

Drie ontwikkelingen verdienen aandacht. De eerste is of de richtlijn uitgroeit tot meer dan zijn korte, algemene vorm. Commentatoren hebben al gewezen op het ontbreken van bewaartermijnadvies en de beperkte aandacht voor inzetters; een toekomstige versie kan beide adresseren. De tweede is hoe sectorspecifieke toezichthouders en auditors eruit putten. Vrijwillige federale praktijken worden vaak de benchmark waar beoordelaars naar grijpen als er nog geen standaard is, of dat nu de bedoeling is of niet. De derde is hoe verzekeraars reageren. Als verzekeraars gaan vragen of je agent-bewijs bewaart, wordt de richtlijn van optioneel naar verwacht, zonder dat er een regel is geschreven.

Behandel het document voorlopig als wat het is: een geloofwaardige schets van drie instanties van hoe een verdedigbaar AI-incidentrecord eruitziet. Het vertelt je niet wat je moet kopen of welke bewaartermijn je moet kiezen. Het vertelt je wel welke vragen je zult krijgen, en geeft je tijd om de antwoorden voor te bereiden.

Zie Hoe Beheerde AI-Toegang Werkt in de Praktijk

Wil je zien hoe Kiteworks secure data exchange beleid afdwingt op agent- en menselijke toegang tot gevoelige inhoud en elke toegang in één audittrail vastlegt? Plan vandaag nog een demo op maat.

Aanvullende Bronnen

• Blog Post
  Zero‑Trust Strategieën voor Betaalbare AI-Privacybescherming
• Blog Post
  Hoe 77% van de Organisaties Faalt bij AI-gegevensbeveiliging
• eBook
  AI Governance Gap: Waarom 91% van Kleine Bedrijven Russisch Roulette Speelt met Gegevensbeveiliging in 2025
• Blog Post
  Er is Geen “–dangerously-skip-permissions” voor Jouw Data
• Blog Post
  Toezichthouders Willen Geen AI-beleid Meer Zien. Ze Willen Bewijs dat Het Werkt.