Toen ik Ai-agents op mijn systemen liet meekijken, verwachtte ik het probleem aan de verkeerde kant. Ik was bang dat ze een echt incident zouden missen. Wat er in de praktijk gebeurde was het omgekeerde: ze zagen overal incidenten. Honderden geblokkeerde toegangspogingen, geheugenalarmen, mislukte verbindingen. Voor een agent die net is losgelaten ziet een druk systeem eruit als een systeem onder vuur.

Het punt is dat de meeste van die alarmerende signalen helemaal geen alarm verdienen. Ze horen bij normaal gedrag. En het verschil kennen tussen “dit is een aanval” en “dit is gewoon dinsdag” is precies het werk. In dit stuk deel ik een paar concrete gevallen waarin mijn automatisering vals alarm sloeg, en de regels die ik daaruit destilleerde om agents te leren wanneer ze wel en niet aan de bel moeten trekken.

Geval één: honderden “aanvallen” die browsertabs waren#

Het klassieke voorbeeld. Op een ochtend meldde de bewaking een golf van geblokkeerde toegangspogingen. Tientallen per minuut, allemaal geweigerd. Op papier: een brute-force-aanval, iemand die probeert binnen te komen.

De werkelijkheid was saaier en leerzamer. Ik had kort daarvoor een inlogdienst herstart. Daardoor waren alle actieve sessies ongeldig geworden. En her en der stonden nog browsertabs open, van mezelf, die op de achtergrond netjes elke paar seconden probeerden opnieuw verbinding te maken. Elke poging werd geweigerd, want de sessie was verlopen. Elke weigering zag eruit als een aanval. Maar het waren mijn eigen vergeten tabbladen die beleefd bleven aankloppen.

Het onderscheid dat hier telt: een echte aanval komt van buiten, van onbekende bronnen, en houdt aan of neemt toe. Deze “aanval” kwam van binnen, van bekende adressen, en verdween vanzelf zodra ik die tabs sloot of opnieuw inlogde. Een agent die dat onderscheid niet maakt, stuurt je in paniek achter een spook aan.

Geval twee: het geheugenalarm dat een opstart was#

Tweede geval, zelfde soort verwarring. De bewaking sloeg alarm: geheugengebruik torenhoog, bijna vol. Dat klinkt urgent, en soms is het dat ook.

Maar deze piek kwam vlak na het herstarten van een zware dienst. Sommige software grijpt bij de start een flinke hap geheugen om vervolgens rustig terug te zakken. En dat was precies wat er gebeurde: binnen een paar minuten was het geheugengebruik weer normaal, helemaal vanzelf, zonder dat ik iets deed. Het was geen crisis, het was een opwarming.

De les: een momentopname zegt weinig. Een enkele hoge meting tijdens een opstart is iets heel anders dan een meting die blijft stijgen en niet meer zakt. Het gaat om de beweging, niet om de foto. Kijk of iets terugkomt naar normaal, of dat het blijft doorstijgen. Dat verschil bepaalt of je te maken hebt met warmdraaien of met een echt probleem.

Geval drie: één hik is geen incident#

Het derde geval is bijna te simpel om te noemen, en juist daarom belangrijk. Een verbinding mislukte een keer, werd automatisch opnieuw geprobeerd, en slaagde. Klaar. Voor een nerveuze agent is die ene mislukking een reden voor een melding. Voor een volwassen systeem is het ruis.

Vrijwel alle software probeert dingen automatisch opnieuw. Netwerken haperen, een dienst is heel even bezig, een verbinding valt weg en komt terug. Als je elke individuele hik als incident behandelt, meld je de hele dag door. De regel die ik hier hanteer: één mislukking die zichzelf herstelt, is geen incident. Pas als iets structureel of herhaald faalt, wordt het interessant.

De criteria die ik expliciet heb opgeschreven#

Het patroon achter deze drie gevallen is dat “vals alarm of echt” geen kwestie van onderbuik mag zijn. Ik heb de criteria letterlijk in de instructies van mijn agents gezet, zodat het oordeel elke keer hetzelfde is:

  • Intern of extern? Komt het signaal van bekende, eigen bronnen, of van onbekende partijen buiten? Eigen browsertabs die aankloppen zijn iets anders dan een onbekend adres dat blijft proberen.
  • Voorbijgaand of aanhoudend? Zakt het vanzelf terug naar normaal binnen een paar minuten, of blijft het staan of stijgen? Een piek die verdwijnt is warmdraaien; een piek die aanhoudt is een probleem.
  • Eenmalig of herhaald? Herstelt iets zichzelf na één poging, of blijft het falen? Een enkele hik is geen incident, een monotoon stijgende foutstroom wel.

Met die drie vragen valt het overgrote deel van de valse alarmen vanzelf weg, en dat zonder dat een echt incident door de mazen glipt.

De stopregel: drie keer vals is zelf een signaal#

Er zit nog een laag onder. Wat doe je als een bepaald soort alarm keer op keer vals blijkt? Dan is de melding niet het probleem meer, dan is de regel het probleem. Ik heb daarom een harde stopconditie ingebouwd: gaat eenzelfde alarm binnen 24 uur drie keer vals af, dan is dat het signaal dat de regel bijgesteld moet worden. Niet nóg een melding, maar de detectieregel zelf onder handen nemen.

Dit is belangrijker dan het klinkt, want zonder zo’n stopregel raak je gewend aan valse alarmen. En gewenning is precies hoe je het echte alarm mist: je hebt geleerd om weg te klikken. Drie keer vals betekent niet “negeer voortaan”, het betekent “repareer de regel”.

De uitzondering die je nooit als vals mag afdoen#

Tot slot de belangrijkste nuance, want je kunt met al dit filteren te ver doorschieten. Er is één situatie die je nooit, maar dan ook nooit als vals alarm mag bestempelen: als een dienst intern prima lijkt te werken maar van buitenaf onbereikbaar is voor je klanten.

Ik ben er zelf ingetrapt. Een agent zag dat een dienst intern netjes reageerde, concludeerde “dit is een vals alarm” en zweeg. Ondertussen was diezelfde dienst voor de buitenwereld urenlang onbereikbaar. Voor de klant was er wél een storing, een langdurige zelfs, en die werd weggefilterd als ruis.

De regel die ik daaruit trok: “intern in orde maar publiek onbereikbaar” is per definitie een echte storing, geen vals alarm. Wat de klant ervaart is de waarheid, niet wat je systeem intern van zichzelf vindt.

Wat betekent dit voor jouw bedrijf?#

Zodra je iets laat bewaken, of dat nu een Ai-agent is of een simpele monitoringtool, kom je in de spanning tussen te veel en te weinig alarm terecht. Te veel en je negeert alles; te weinig en je mist het echte probleem. De uitweg is niet gevoel, maar expliciete criteria.

Drie dingen om mee te nemen:

  1. Schrijf op wat een echt incident is. Intern of extern, voorbijgaand of aanhoudend, eenmalig of herhaald. Wie die vragen vooraf beantwoordt, laat de automatisering consistent oordelen in plaats van te schrikken van elk piekje.
  2. Bouw een stopregel tegen herhaald vals alarm. Als iets keer op keer vals blijkt, repareer je de regel, niet je humeur. Anders leer je jezelf aan om te negeren.
  3. Laat de klantervaring altijd winnen. Wat de buitenwereld ziet, telt zwaarder dan wat je systeem intern van zichzelf denkt. “Intern in orde” mag nooit een echte storing wegpoetsen.

Wil je uitzoeken waar in jouw bedrijf de bewaking te veel schreeuwt of juist te vaak zwijgt? Bekijk mijn gratis downloads of neem via de consulting-pagina contact op.