Agent AI dla operacji IT: wewnętrzne zgłoszenia, dostępy, monitoring i dokumentacja

Problem

Wewnętrzne operacje IT nigdy się nie zatrzymują, ale zespół, który je obsługuje, już tak. Analiza Jitbit obejmująca około 1000 firm, regularnie cytowana w branży wsparcia, sytuowała w 2017 roku średni wolumen obsługiwany przez technika na 21 zgłoszeń dziennie, przy średnim czasie rozwiązania wynoszącym 82 godziny. To dane datowane, przedstawione przez własnych autorów jako baza historyczna, a nie aktualny cel, do traktowania jako rząd wielkości, a nie aktualna liczba.

Jeśli chodzi o czas poświęcony na zgłoszenie, Endsight, dostawca zarządzanego wsparcia, podaje średnio 63 minuty na podstawie własnych 10 923 śledzonych użytkowników w ciągu 12 miesięcy. To dane wewnętrzne jednej firmy, niezweryfikowane przez stronę trzecią: do traktowania jako wskazówka, a nie norma branżowa.

Najlepiej udokumentowanym punktem są dostępy. Badanie Wing Security relacjonowane przez The Hacker News w 2024 roku szacuje, że 63% firm ma byłych pracowników zachowujących dostęp do danych organizacji, a 43% do repozytoriów kodu na GitHubie czy GitLabie. Każdy wniosek o dostęp lub cofnięcie zalegający w kolejce wewnętrznych zgłoszeń jest bezpośrednim kandydatem do tego typu statystyki.

To opóźnienie w obsłudze ma drugą konsekwencję, mniej widoczną niż ryzyko bezpieczeństwa: sama kolejka zgłoszeń staje się nieczytelna. Gdy pilne prośby (zablokowany dostęp uniemożliwiający pracę) mieszają się z rutynowymi (pytanie, na które już dziesięć razy odpowiedziano w bazie wiedzy), zespół IT traci tyle samo czasu na segregację, co na rozwiązywanie. Znaczna część tej kolejki nigdy nie powinna dotrzeć do człowieka: to dokładnie ten rodzaj segregacji, który agent czytający istniejącą dokumentację może wchłonąć, zanim zgłoszenie zacznie czekać na swoją kolej.

Co robi agent, krok po kroku

Autonomiczny agent AI dedykowany operacjom IT działa nieprzerwanie, we własnym izolowanym środowisku, i monitoruje kolejkę zgłoszeń, nigdy nie śpiąc.

Zaczyna od kategoryzowania każdego nowego zgłoszenia w Jirze: znane pytanie, wniosek o dostęp, incydent techniczny. Dla już udokumentowanych próśb odpowiada bezpośrednio, cytując procedurę znalezioną w bazie Notion zespołu. Dla wniosku o dostęp do narzędzia lub repozytorium otwiera ustrukturyzowane zgłoszenie ze wszystkimi informacjami niezbędnymi do decyzji, zamiast wykonać je samodzielnie.

Po stronie monitoringu agent śledzi alerty zgłaszane przez Datadog i koreluje je z ostatnimi commitami lub wdrożeniami widocznymi na GitHubie: wzrost opóźnienia następujący tuż po wdrożeniu nie jest traktowany jako izolowany incydent. Gdy korelacja jest wyraźna, otwiera udokumentowane issue na GitHubie, z kontekstem użytecznym dla zespołu technicznego. Każde zablokowane zgłoszenie, każdy krytyczny alert lub każdy oczekujący wniosek o dostęp uruchamia powiadomienie na Slacku dla zespołu IT. Każde działanie, utworzone zgłoszenie, skorelowany alert, wysłana wiadomość, jest rejestrowane w osi czasu agenta, z dokładnym statusem.

Jeden konkretny przykład dobrze ilustruje mechanikę: pracownik otwiera w piątek wieczorem zgłoszenie z prośbą o dostęp do konkretnego repozytorium GitHub, w ramach projektu międzydziałowego. Agent kategoryzuje prośbę, sprawdza, czy jest kompletna (docelowe repozytorium, uzasadnienie, żądany czas trwania), a następnie przygotowuje ustrukturyzowane zgłoszenie gotowe do zatwierdzenia przez odpowiedzialnego z IT już w poniedziałek rano, zamiast pozostawić prośbę śpiącą w ogólnej kolejce, aż ktoś zauważy ją przypadkiem.

Wykorzystywane integracje

Jira pozostaje referencyjną kolejką wewnętrznych zgłoszeń. Agent wyszukuje tam prośby (search_issues), sprawdza szczegóły (get_issue) i może utworzyć nowe, ustrukturyzowane issue, zgodnie z działaniami objętymi jego grantem.

GitHub służy do korelowania alertu technicznego ze zmianą kodu: lista ostatnich commitów (list_commits), szczegóły pull requestu (get_pull_request) i utworzenie udokumentowanego issue (create_issue), gdy korelacja zostanie ustalona.

Datadog dostarcza surowy sygnał nadzoru, który agent sprawdza, nigdy nie zastępując samego narzędzia monitoringu. Notion hostuje procedury i runbooki, które agent sprawdza przed odpowiedzią na prośbę, a Slack przekazuje powiadomienia zespołowi IT w czasie rzeczywistym.

Co zostaje po stronie człowieka

Agent przygotowuje i alarmuje, nigdy sam z własnej inicjatywy nie wykonuje zmiany dostępu lub infrastruktury. Faktyczne przyznanie lub cofnięcie dostępu pozostaje działaniem ludzkim: agent otwiera udokumentowany wniosek w Jirze, osoba z IT go wykonuje i zamyka.

Rzeczywistą krytyczność niejednoznacznego alertu, takiego, który nie odpowiada żadnemu możliwemu do zidentyfikowania ostatniemu wdrożeniu, rozstrzyga człowiek przed jakąkolwiek eskalacją wykraczającą poza powiadomienie na Slacku. Decyzja o poprawce kodu lub infrastruktury i jej wdrożenie pozostaje, bez zaskoczenia, pracą inżyniera. I jak w przypadku każdego agenta Atako, administrator musi przyznać i dostosować granty na Jira, GitHub i Datadog, działanie po działaniu, z jawnie określonym zakresem odczytu lub odczytu i zapisu.

Ta granica dotyczy też samego agenta: jeśli trafi na sytuację wykraczającą poza to, co obejmuje jego kontekst biznesowy, nietypowe odnowienie licencji, wniosek o dostęp do nieudokumentowanego systemu, nie wymusza przybliżonej odpowiedzi. Powiadamia zespół IT i zostawia zgłoszenie otwarte do ludzkiej obsługi, zamiast zgadywać procedurę, której nie ma w jego bazie wiedzy.

Wynik mierzalny

Najbardziej bezpośrednią korzyścią jest skrócenie martwego czasu między pojawieniem się zgłoszenia lub alertu a jego pierwszą obsługą. Agent działający 24 godziny na dobę może skategoryzować zgłoszenie otwarte w niedzielny wieczór i przygotować odpowiadający mu wniosek o dostęp przed przyjściem zespołu w poniedziałek, zamiast pozostawić prośbę czekającą w kolejce.

Druga korzyść dotyka bezpośrednio problemu udokumentowanego przez Wing Security: systematyzując otwieranie zgłoszenia o cofnięcie dostępu, gdy tylko zgłoszone zostanie odejście, agent skraca czas między zdarzeniem wyzwalającym a działaniem IT, co ogranicza okno, w którym dostęp pozostaje niepotrzebnie aktywny, okno, które bez nieprzerwanego nadzoru może rozciągać się na tygodnie, a nawet miesiące, według wspomnianych wyżej danych.

Każde otwarte zgłoszenie, każdy skorelowany alert, każda wysłana wiadomość pozostają dostępne w audit trail Atako, eksportowalnym do CSV dla zespołu IT do 50 000 wierszy. Ta pełna identyfikowalność ułatwia też wewnętrzne audyty bezpieczeństwa: odtworzenie, kto poprosił o dostęp, kiedy i na jakiej podstawie prośba została sformalizowana, nie wymaga już rekonstruowania chronologii na podstawie kilku różnych narzędzi.

Agent IT mieści się w planie Standard, 20 euro miesięcznie za slot, z 1000 kredytami wliczonymi każdego miesiąca na pokrycie wywołań modelu. Liczba obsłużonych zgłoszeń czy współpracowników wchodzących w interakcję z agentem nie ma żadnego wpływu na tę cenę, liczy się wyłącznie liczba jednocześnie aktywnych agentów. Mały zespół IT może więc uruchomić jednego agenta dla wszystkich swoich wewnętrznych zgłoszeń, alertów monitoringu i wniosków o dostęp, bez konieczności mnożenia slotów dla każdego strumienia osobno, co utrzymuje przewidywalny koszt nawet gdy zakres agenta stopniowo rozszerza się na nowe narzędzia lub nowe zespoły wewnętrzne w kolejnych miesiącach.