Een nieuwe golf AI-modellen is in korte tijd vanuit de hoek van onderzoek naar praktisch gebruik gesprongen. Waar klassieke modellen vooral tekst genereren, maken AI beslismodellen het mogelijk om direct een uitkomst te kiezen op basis van vaste, getype vragen. Voor een AI-SOC (Security Operations Center) is dat aantrekkelijk: triage kan sneller, consistenter én beter controleerbaar worden.
Toch is het belangrijk om de hype te plaatsen. Het echte verschil ontstaat niet door “slimme” output alleen, maar door de manier waarop je de context en het bewijs verzamelt vóórdat je een model een beslissing laat nemen.
Wat zijn AI beslismodellen precies?
AI beslismodellen zijn ontworpen om geen tekst te schrijven, maar om een keuze of oordeel terug te geven. Je levert daarbij een set state-informatie en een vooraf gedefinieerde reeks vragen (met vaste typen). Het model retourneert vervolgens bijvoorbeeld een ja/nee, een score of een keuze, vaak gekoppeld aan een kans of mate van zekerheid.
Dit is anders dan generatieve AI die uitleg produceert. Het voordeel voor security is dat de uitkomst vaak strikt binnen een bepaald schema valt: ideaal voor automatisering, logging en auditbaarheid.
Waarom AI-SOC’s hier enthousiast van worden
In een SOC draait het in de kern om een veelvoorkomende vraag: is dit alert benigne ruis of een echte incidentmelding? AI beslismodellen passen goed omdat ze drie eigenschappen meenemen die je kunt vertalen naar concrete triage-regels.
1) Automatiseren met drempels
Omdat de output een numerieke waarde en/of een gekalibreerde kans bevat, kun je die koppelen aan beleid. Denk aan: sluit een alert automatisch wanneer de kans dat het benigne is zeer hoog is, of eskaleer wanneer de kans op een incident boven een andere grens uitkomt. Alles daartussenin kan naar een analist voor menselijke beoordeling.
Dat maakt het beleid niet alleen sneller, maar ook consistenter. Je kunt bovendien onderscheid maken tussen acties die “onomkeerbaar” zijn versus acties die later nog te corrigeren zijn.
2) Kosten worden minder een bottleneck
De aantrekkingskracht zit ook in schaal. In de bron wordt genoemd dat één van de genoemde systemen zeer snel reageert en dat de prijs per hoeveelheid input relatief laag kan uitvallen. Daardoor wordt het eenvoudiger om niet alleen de “top” alerts te analyseren, maar een groter deel van de stroom—zelfs wanneer je duizenden alerts per dag verwerkt.
Voor veel teams is dit precies de frictie die automation tegenhoudt: je wilt wel automatiseren, maar je kunt niet op elk niveau dezelfde investering doen. Met beslismodellen verschuift die balans.
3) Elke beslissing wordt een record
Omdat de uitkomst gestructureerd is en binnen een vast antwoordveld blijft, kun je elke triagebeslissing loggen. Je kunt dan achteraf controleren wat het model voorspelde en dat vergelijken met wat er werkelijk gebeurde.
Dat is vaak eenvoudiger te auditen dan een vrije tekstverklaring, omdat je met een vast outputformaat direct kunt meten en terugkoppelen.
Let op: “geen hallucinaties” betekent niet “altijd gelijk”
Leveranciers benadrukken vaak dat deze modellen niet “hallucineren” in de zin dat ze altijd een correct gestructureerd antwoordschema teruggeven. Maar dat zegt niets over de juistheid van het oordeel.
Een goed gevormde output kan dus nog steeds een verkeerde conclusie zijn. Daarom blijft het van belang om te beoordelen wanneer het model betrouwbaar is en welke inputs het met voldoende context krijgt.
Gekalibreerde kans is nuttig—maar alleen binnen de juiste context
Een centrale nuance uit de bron: kalibratie is geen magie, maar een statistische belofte. Wanneer een model bijvoorbeeld zegt “90%”, dan betekent dat: over een specifieke soort inputs die op jouw case lijken, klopt het ongeveer 90% van de tijd.
Het probleem is dat het model de wereld buiten je invoer niet automatisch “kent”. Als je het model voedt met informatie als een alerttitel en een severity-veld, dan is de kalibratie vooral afgestemd op alerts met vergelijkbare kenmerken—niet op de echte situatie op hosts of gebruikers.
Daarom is “garbage in, garbage out” nog steeds de kern. Slechte of onvolledige input maakt zelfs een goed gekalibreerd model minder waardevol.
Waarom evidence en context het verschil maken
Forensisch denken helpt om te voorkomen dat je alleen op metadata stuurt. In de bron wordt dat vergeleken met een misdaadonderzoek: een generiek verhaal klinkt plausibel, maar echte bewijzen (DNA, vingers, verklaringen) wijzen naar de juiste verdachte.
In security is evidence niet exotisch, maar vooral lastig om automatisch te verzamelen bij elke alert. Toch is dat precies waar een betrouwbare triage pijplijn begint.
Wat “normaal” betekent verschilt per organisatie
Naast forensische sporen heb je de vraag: is dit binnen onze organisatie normaal? Met name bij identity-gerelateerde alerts ontstaat vaak ruis. Voorbeelden uit de bron: veel identity alerts worden als waarschijnlijk benigne geclassificeerd, terwijl echte incidenten bij bepaalde subtypen (zoals “impossible travel”) relatief zeldzaam zijn.
Een model kan bovendien niet uit zichzelf weten dat een bepaalde gebruiker altijd vanaf een land of regio inlogt, of dat een specifieke detectie regelmatig afgaat bij release-momenten. Dat soort kennis zit meestal in de hoofden van ervaren analisten.
Omdat assets, accounts en tooling veranderen, moet die organisatorische context continu worden bijgewerkt. Een eenmalige “snapshot” bij onboarding wordt snel verouderd.
Een forensische aanpak voor alerttriage (van bewijs naar oordeel)
In plaats van eerst te beslissen op basis van de alert zelf, is het idee: verzamel eerst bewijs en laat daarna het beslismodellayer de laatste stap nemen. In de bron wordt een dergelijke aanpak concreet gemaakt met meerdere onderdelen.
Code-level vergelijkingen
Er wordt beschreven dat een systeem binair code in het geheugen vergelijkt met bekende patronen van vertrouwde en kwaadwillende code. Dat kan zowel bekende malware vangen als nieuw gedrag dat hergebruik van bestaande code bevat.
Live memory forensics waar nodig
Wanneer een alert te weinig evidence heeft—of wanneer signalen wijzen op fileless aanvallen of code-injectie—kan een Endpoint Scanner geactiveerd worden. Die verzamelt informatie zoals processtructuren, executables die in geheugen geladen zijn, memory dumps bij vermoedelijke injectie en bestanden die gekoppeld zijn aan geplande taken of autoruns.
Detonation en netwerk-onderzoek
Verdachte bestanden worden in een sandbox uitgevoerd, waarna URL’s, domeinen en IP’s worden onderzocht. Zo wordt de uiteindelijke verdict gebaseerd op observeerbaar gedrag in plaats van alleen op de alertomschrijving.
Organizational memory
Daarnaast wordt “organizational memory” genoemd als antwoord op de vraag wat normaal is binnen een specifieke omgeving. Dat omvat onder meer procedurele kennis (hoe het team onderzoekt en welke detecties men direct afhandelt) en declaratieve kennis (assets, gebruikerspatronen en hoe SIEM-velden zijn ingericht). Cruciaal is dat die kennis bijgeschaald wordt op basis van uitkomsten uit eerdere cases.
Wat dit oplevert: minder escalaties en snellere triage
De bron beschrijft dat met deze aanpak een groot aantal alerts kan worden onderzocht, ongeacht severity-niveau. Slechts een klein deel hoeft naar een menselijke analist, terwijl de accuratesse hoog blijft en de mediane triagetijd kort kan zijn.
Ook het kostenverhaal wordt benadrukt: veel analyse kan deterministisch en forensisch zijn, wat doorgaans goedkoper is dan het inzetten van een groot model op elke alert. Beslismodellen brengen dan juist “economics” naar de decision stap.
Waar zou je je engineering-tijd aan besteden?
Als je zelf een pipeline bouwt (of bestaande automation wilt verbeteren), dan komt uit de bron een duidelijke prioriteitenlijst naar voren.
- Verzamel evidence vóórdat je beslist met processtructuren, detonationresultaten en live memory-inhoud.
- Laat severity niet bepalen wat je onderzoekt. Als beslismodellen goedkoop zijn, is er minder reden om lage severity standaard weg te laten.
- Behandel organisatorische kennis als een systeem: leer, refresh en meet doorlopend wat “normaal” is.
- Meet kalibratie in je eigen omgeving door geautomatiseerde verdicts aan uitkomsten te koppelen en drift te bewaken.
Met die bouwstenen wordt de rol van AI beslismodellen logisch: ze maken de laatste stap snel, goedkoop en auditbaar—maar ze worden alleen betrouwbaar als de input en context kloppen.
Handige vervolgstappen en gerelateerde aandachtspunten
Wil je ook weten hoe je beter omgaat met AI-gedrag en bewijs in security workflows? Bekijk dan bijvoorbeeld dit artikel over hoe AI-modellen toegang tot data kunnen misbruiken: AI-modellen misbruiken toegang tot data. Voor het proces van het omzetten van losse meldingen naar actie kan dit ook relevant zijn: van losse meldingen naar actie.
Conclusie
AI beslismodellen zijn een sterke ontwikkeling voor AI-SOC’s omdat ze gestructureerde beslissingen met scores of kansuitkomsten leveren. Dat maakt automatiseren met drempels mogelijk, verlaagt de kosten van triage op schaal en maakt elke stap beter te loggen en te auditen.
Maar de kern blijft: een betrouwbaar oordeel vraagt om de juiste evidence en een continue update van wat in jouw organisatie “normaal” is. Zodra je die context goed op orde hebt, wordt de decision layer echt een versneller—niet een nieuw risico.
Bron: https://thehackernews.com/2026/10/ai-decision-models-and-their-impact-on.html
