AI-agent til IT-drift: interne tickets, adgange, monitorering og dokumentation

Problemet

Den interne IT-drift stopper aldrig, men det gør teamet, der håndterer den. En Jitbit-analyse af omkring 1.000 virksomheder, ofte citeret i supportbranchen, satte i 2017 en teknikers gennemsnitlige volumen til 21 tickets om dagen, med en gennemsnitlig løsningstid på 82 timer. Det er forældede data, af forfatterne selv præsenteret som et historisk grundlag snarere end et aktuelt mål, og bør behandles som en størrelsesorden, ikke som et opdateret tal.

Om tidsforbruget pr. ticket angiver Endsight, en managed support-udbyder, 63 minutter i gennemsnit på sine egne 10.923 fulgte brugere over 12 måneder. Det er interne data fra en enkelt virksomhed, ikke tredjepartsverificeret: bør betragtes som en indikation, ikke som en branchenorm.

Det bedst dokumenterede punkt angår adgange. En undersøgelse fra Wing Security, gengivet af The Hacker News i 2024, anslår, at 63 procent af virksomhederne har tidligere medarbejdere, der stadig har adgang til organisationens data, og 43 procent til kodedepoter på GitHub eller GitLab. Enhver adgangs- eller tilbagekaldelsesanmodning, der trækker ud i en kø af interne tickets, er en direkte kandidat til denne slags statistik.

Denne behandlingsforsinkelse har en anden konsekvens, mindre synlig end sikkerhedsrisikoen: selve ticketkøen bliver ulæselig. Når hastende anmodninger (en blokeret adgang, der forhindrer en i at arbejde) blandes med rutinemæssige anmodninger (et spørgsmål der allerede er besvaret ti gange i vidensbasen), bruger IT-teamet lige så meget tid på at sortere som på at løse. En stor del af denne kø burde aldrig nå et menneske: det er præcis den type sortering, en agent der læser den eksisterende dokumentation kan absorbere, før ticketen venter på sin tur.

Hvad agenten gør, trin for trin

En autonom AI-agent dedikeret til IT-drift kører kontinuerligt, i sit eget isolerede miljø, og overvåger ticketkøen uden nogensinde at sove.

Den starter med at kategorisere hver indkommende ticket i Jira: allerede kendt spørgsmål, adgangsanmodning, teknisk hændelse. For allerede dokumenterede anmodninger svarer den direkte med henvisning til proceduren fundet i teamets Notion-base. For en anmodning om adgang til et værktøj eller depot opretter den en struktureret ticket med alle de oplysninger, der er nødvendige for beslutningen, i stedet for selv at udføre den.

På monitoreringssiden overvåger agenten alarmer fra Datadog og korrelerer dem med nylige commits eller udrulninger synlige i GitHub: en latensstigning, der følger tæt efter en udrulning, behandles ikke som en isoleret hændelse. Når korrelationen er klar, opretter den en dokumenteret GitHub-issue, med den relevante kontekst for det tekniske team. Enhver ticket der forbliver blokeret, enhver kritisk alarm eller enhver ventende adgangsanmodning udløser en Slack-notifikation til IT-teamet. Hver handling, oprettet ticket, korreleret alarm, sendt besked, logges i agentens tidslinje, med præcis status.

Et konkret eksempel illustrerer mekanikken godt: en medarbejder opretter en ticket en fredag aften for at anmode om adgang til et bestemt GitHub-depot, som led i et tværgående projekt. Agenten kategoriserer anmodningen, tjekker at den er fuldstændig (pågældende depot, begrundelse, ønsket varighed) og forbereder derefter en struktureret ticket, klar til at blive godkendt af en IT-ansvarlig mandag morgen, i stedet for at lade anmodningen ligge i en generisk kø, indtil nogen tilfældigvis bemærker den.

Integrationerne i spil

Jira forbliver referencekøen for interne tickets. Agenten søger anmodninger der (search_issues), tjekker detaljer (get_issue) og kan oprette en ny struktureret issue, alt efter de handlinger dens grant dækker.

GitHub bruges til at korrelere en teknisk alarm med en kodeændring: liste over nylige commits (list_commits), detaljer om en pull request (get_pull_request), og oprettelse af en dokumenteret issue (create_issue), når korrelationen er etableret.

Datadog leverer det rå overvågningssignal, som agenten tjekker uden nogensinde at erstatte selve monitoreringsværktøjet. Notion huser procedurerne og runbooks, agenten slår op i, før den besvarer en anmodning, og Slack bærer notifikationerne til IT-teamet i realtid.

Det, der stadig er op til mennesket

Agenten forbereder og advarer, den udfører aldrig selv en ændring af adgang eller infrastruktur på eget initiativ. Reelt at tildele eller tilbagekalde en adgang forbliver en menneskelig handling: agenten opretter den dokumenterede anmodning i Jira, en person fra IT udfører den og lukker den.

Den reelle kritikalitet af en tvetydig alarm, en der ikke svarer til nogen identificerbar nylig udrulning, afgøres af et menneske, før nogen eskalering ud over en Slack-notifikation. At beslutte og gennemføre en kode- eller infrastrukturrettelse forbliver, ikke overraskende, et ingeniørarbejde. Og som for enhver Atako-agent skal en administrator tildele og justere grants på Jira, GitHub og Datadog, handling for handling, med et omfang på læsning eller læsning og skrivning defineret eksplicit.

Denne grænse gælder også for agenten selv: støder den på en situation, der falder uden for det, dens forretningskontekst dækker, en usædvanlig licensfornyelse, en adgangsanmodning til et udokumenteret system, tvinger den ikke et omtrentligt svar frem. Den notificerer IT-teamet og lader ticketen forblive åben til menneskelig behandling, i stedet for at gætte en procedure, der ikke findes i dens vidensbase.

Målbart resultat

Den mest direkte gevinst er reduktionen af dødtiden mellem en tickets eller alarms ankomst og dens første behandling. En agent, der kører døgnet rundt, kan kategorisere en ticket åbnet en søndag aften og forberede den tilsvarende adgangsanmodning, før teamet ankommer mandag, i stedet for at lade anmodningen vente i køen.

Den anden gevinst rammer direkte det problem, Wing Security dokumenterer: ved systematisk at oprette en tilbagekaldelsesticket, så snart en fratrædelse meldes, reducerer agenten tiden mellem den udløsende begivenhed og IT's handling, hvilket begrænser det tidsrum, hvor en adgang unødigt forbliver aktiv, et tidsrum der uden løbende overvågning kan strække sig over uger eller endda måneder ifølge de ovenfor nævnte observationer.

Hver oprettet ticket, hver korreleret alarm, hver sendt besked forbliver tilgængelig i Atakos audit trail, eksporterbar til CSV for IT-teamet med op til 50.000 linjer. Denne fulde sporbarhed letter også interne sikkerhedsrevisioner: at finde ud af, hvem der anmodede om en adgang, hvornår, og på hvilket grundlag anmodningen blev formaliseret, kræver ikke længere, at man genskaber et forløb fra flere forskellige værktøjer.

En IT-agent hører under Standard-planen, 20 euro om måneden pr. slot, med 1.000 credits inkluderet hver måned til at dække modelkald. Antallet af behandlede tickets eller medarbejdere, der interagerer med agenten, har ingen indflydelse på denne pris, kun antallet af samtidigt aktive agenter tæller. Et lille IT-team kan derfor køre en enkelt agent på alle sine interne tickets, monitoreringsalarmer og adgangsanmodninger, uden at skulle mangedoble slots for at dække hver strøm separat, hvilket holder omkostningen forudsigelig, selv når agentens omfang gradvist udvides til nye værktøjer eller nye interne teams over tid.