AI-agent voor IT-operaties: interne tickets, toegang, monitoring en documentatie

Het probleem

Interne IT-operaties stoppen nooit, maar het team dat ze behandelt wel. Een Jitbit-analyse onder ongeveer 1.000 bedrijven, regelmatig geciteerd in de supportsector, situeerde in 2017 het gemiddelde volume dat een technicus beheert op 21 tickets per dag, met een gemiddelde oplostijd van 82 uur. Dat zijn gedateerde gegevens, door hun eigen auteurs voorgesteld als een historische basis eerder dan een actueel streefcijfer, te behandelen als een orde van grootte en niet als een actueel cijfer.

Over de tijd per ticket noemt Endsight, een aanbieder van managed support, gemiddeld 63 minuten op zijn eigen 10.923 gevolgde gebruikers over 12 maanden. Dat is interne data van één enkel bedrijf, niet door een derde partij geverifieerd: te beschouwen als een indicatie, niet als een sectornorm.

Het meest solide gedocumenteerde punt betreft de toegangen. Een onderzoek van Wing Security, overgenomen door The Hacker News, schat in 2024 dat 63% van de bedrijven oud-werknemers telt die toegang behouden tot organisatiegegevens, en 43% tot codearchieven op GitHub of GitLab. Elk toegangs- of intrekkingsverzoek dat blijft aanslepen in een interne ticketwachtrij, is een directe kandidaat voor dit soort statistiek.

Deze verwerkingstijd heeft een tweede gevolg, minder zichtbaar dan het beveiligingsrisico: de ticketwachtrij zelf wordt onleesbaar. Wanneer dringende verzoeken (een geblokkeerde toegang die werken onmogelijk maakt) zich vermengen met routinevragen (een vraag die al tien keer in de kennisbank beantwoord is), besteedt het IT-team evenveel tijd aan sorteren als aan oplossen. Een groot deel van deze wachtrij zou nooit een mens moeten bereiken: dat is precies het type sortering dat een agent die de bestaande documentatie leest, kan absorberen voordat het ticket op zijn beurt moet wachten.

Wat de agent doet, stap voor stap

Een autonome AI-agent gewijd aan IT-operaties draait continu, in zijn eigen geïsoleerde omgeving, en bewaakt de ticketwachtrij zonder ooit te slapen.

Hij begint met het categoriseren van elk binnenkomend ticket in Jira: al bekende vraag, toegangsverzoek, technisch incident. Voor al gedocumenteerde verzoeken antwoordt hij rechtstreeks, met verwijzing naar de procedure gevonden in de Notion-kennisbank van het team. Voor een toegangsverzoek tot een tool of repository opent hij een gestructureerd ticket met alle informatie die nodig is voor de beslissing, in plaats van het zelf uit te voeren.

Aan de monitoringkant bewaakt de agent de alerts die Datadog rapporteert en koppelt ze aan de recente commits of deployments zichtbaar in GitHub: een latencystijging die kort na een deployment volgt, wordt niet als een op zichzelf staand incident behandeld. Wanneer de correlatie duidelijk is, opent hij een gedocumenteerde GitHub-issue, met de nuttige context voor het technische team. Elk geblokkeerd gebleven ticket, elke kritieke alert of elk wachtend toegangsverzoek activeert een Slack-melding naar het IT-team. Elke actie, aangemaakt ticket, gekoppelde alert, verstuurd bericht, wordt vastgelegd in de tijdlijn van de agent, met de exacte status.

Een concreet voorbeeld illustreert de mechaniek goed: een werknemer opent op een vrijdagavond een ticket om toegang te vragen tot een specifieke GitHub-repository, in het kader van een transversaal project. De agent categoriseert het verzoek, controleert of het volledig is (beoogde repository, motivering, gewenste duur), en bereidt vervolgens een gestructureerd ticket voor dat klaar is om door een IT-verantwoordelijke gevalideerd te worden vanaf maandagochtend, in plaats van het verzoek te laten sluimeren in een generieke wachtrij tot iemand het toevallig opmerkt.

De gebruikte integraties

Jira blijft de referentiewachtrij voor interne tickets. De agent zoekt er de verzoeken (search_issues), raadpleegt het detail (get_issue) en kan een nieuwe gestructureerde issue aanmaken, volgens de acties die door zijn grant worden gedekt.

GitHub dient om een technische alert aan een codewijziging te koppelen: lijst van recente commits (list_commits), detail van een pull request (get_pull_request), en het aanmaken van een gedocumenteerde issue (create_issue) wanneer de correlatie is vastgesteld.

Datadog levert het ruwe bewakingssignaal, dat de agent raadpleegt zonder ooit de monitoringtool zelf te vervangen. Notion host de procedures en runbooks die de agent raadpleegt voordat hij een verzoek beantwoordt, en Slack draagt de meldingen naar het IT-team in realtime.

Wat bij de mens blijft

De agent bereidt voor en waarschuwt, hij voert nooit op eigen initiatief een wijziging van toegang of infrastructuur uit. Een toegang daadwerkelijk toekennen of intrekken blijft een menselijke handeling: de agent opent het gedocumenteerde verzoek in Jira, iemand van IT voert het uit en sluit het af.

De werkelijke kritiekheid van een dubbelzinnige alert, die niet overeenkomt met een identificeerbare recente deployment, wordt door een mens beoordeeld vóór elke escalatie voorbij een Slack-melding. Het beslissen en toepassen van een code- of infrastructuurcorrectie blijft, niet verrassend, ingenieurswerk. En zoals bij elke Atako-agent moet een beheerder de grants op Jira, GitHub en Datadog toekennen en aanpassen, actie per actie, met een expliciet gedefinieerde reikwijdte van lezen of lezen en schrijven.

Deze grens geldt ook voor de agent zelf: als hij een situatie tegenkomt die buiten zijn zakelijke context valt, een ongebruikelijke licentievernieuwing, een toegangsverzoek tot een niet-gedocumenteerd systeem, forceert hij geen bij benadering antwoord. Hij meldt het IT-team en laat het ticket open voor menselijke behandeling, in plaats van een procedure te gokken die niet in zijn kennisbank bestaat.

Meetbaar resultaat

Het meest directe voordeel is de vermindering van de dode tijd tussen de aankomst van een ticket of alert en de eerste behandeling ervan. Een agent die 24 uur per dag draait, kan een ticket geopend op een zondagavond categoriseren en het overeenkomstige toegangsverzoek voorbereiden vóór de aankomst van het team op maandag, in plaats van het verzoek in de wachtrij te laten wachten.

Het tweede voordeel raakt rechtstreeks het door Wing Security gedocumenteerde probleem: door het openen van een intrekkingsticket te systematiseren zodra een vertrek wordt gesignaleerd, vermindert de agent de vertraging tussen de triggergebeurtenis en de IT-actie, wat het venster beperkt waarin een toegang onnodig actief blijft, een venster dat zonder continue bewaking, volgens de eerder aangehaalde vaststellingen, weken of zelfs maanden kan aanslepen.

Elk geopend ticket, elke gekoppelde alert, elk verstuurd bericht blijft raadpleegbaar in de audit trail van Atako, exporteerbaar als CSV voor het IT-team tot 50.000 regels. Deze volledige traceerbaarheid vergemakkelijkt ook interne beveiligingsaudits: terugvinden wie een toegang heeft aangevraagd, wanneer, en op welke basis het verzoek is geformaliseerd, vereist niet langer het reconstrueren van een chronologie op basis van meerdere verschillende tools.

Een IT-agent valt onder het Standard-plan, 20 euro per maand per slot, met 1.000 credits per maand inbegrepen om de modelaanroepen te dekken. Het aantal behandelde tickets of medewerkers dat met de agent interageert, heeft geen enkele impact op deze prijs, alleen het aantal gelijktijdig actieve agents telt. Een klein IT-team kan zo een enkele agent laten draaien op al zijn interne tickets, monitoringalerts en toegangsverzoeken, zonder de slots te moeten vermenigvuldigen om elke stroom afzonderlijk te dekken, wat de kost voorspelbaar houdt zelfs wanneer het werkterrein van de agent geleidelijk uitbreidt naar nieuwe tools of nieuwe interne teams in de loop van de maanden.