Mniej sortowania w service desku IT, więcej czasu na zgłoszenia, które wymagają ludzi

Service desk codziennie obsługuje te same sprawy: hasła, VPN, drukarki, skrzynki pocztowe, oprogramowanie i uprawnienia. Każde zgłoszenie trzeba przeczytać, posortować, często trafia do niewłaściwego zespołu, a potem odpowiada się na nie artykułem, który ktoś musi najpierw znaleźć. AI przejmuje czytanie, sortowanie i pierwszy szkic. Twój zespół zajmuje się zgłoszeniami, które wymagają człowieka, a druga linia wsparcia dostaje zgłoszenia, w których jest już wszystko, czego potrzebuje.

Działy IT zaczęły późno, ale nadrabiają. W badaniu Bitkom z 2026 roku wśród firm zatrudniających co najmniej 20 osób 9% firm korzystających z AI używa jej w dziale IT, wobec 2% w badaniu Bitkom z 2025 roku, co jest najszybszym względnym wzrostem spośród wszystkich obszarów. Dostawcy usług IT są dalej: w badaniu Kaseya i Foundry z 2025 roku wśród integratorów, dostawców usług zarządzanych i firm usługowych IT w regionie DACH obsługa zgłoszeń i helpdesk była najbardziej zaawansowanym zastosowaniem AI, z AI korzysta tam 58,4%. Oba badania obejmują inne grupy, więc tych liczb nie można porównywać wprost.

• Zgłoszenia od razu trafiają do właściwego zespołu, zamiast krążyć między zespołami.
• Powtarzające się sprawy dostają odpowiedź z bazy wiedzy, z linkiem do artykułu.
• Druga linia dostaje zgłoszenia z urządzeniem, komunikatem błędu i krokami, które już wypróbowano.
• Dyżurni inżynierowie znajdują runbook, ostatnie zmiany i podobne incydenty w jednym miejscu.
• Efekt widzisz we własnych liczbach: godziny na zgłoszenie i przekierowane zgłoszenia, zmierzone przed i po.

Agent wykonuje pracę przygotowawczą przy każdym zgłoszeniu i przekazuje wynik człowiekowi. Sam krok przypisywania jest sprawdzony. W 2020 roku produktion.de informował, że firma IT BTC, korzystając z SAP Service Ticket Intelligence, osiągnęła na produkcji trafność około 80% dla grup roboczych i 90% dla priorytetu, i wskazał problem, który za tym stał: pracę z „veralteten oder fehlerbehafteten Ticketinformationen”, czyli nieaktualnymi lub błędnymi informacjami w zgłoszeniach. Ten system powstał przed dzisiejszymi dużymi modelami językowymi (LLM), czyli modelami stojącymi za narzędziami takimi jak ChatGPT. LLM dodają szkice odpowiedzi, dopytywanie i wyszukiwanie w runbookach i właśnie tę część budujemy.

• Klasyfikacja i przypisanie: kategoria, priorytet i grupa obsługi, a duplikaty są łączone z otwartym incydentem, do którego należą.
• Szkice odpowiedzi na powtarzające się sprawy, takie jak VPN, drukarki, skrzynki pocztowe i oprogramowanie, oparte na artykułach bazy wiedzy i rozwiązanych zgłoszeniach, z linkami do źródeł, żeby zespół mógł je sprawdzić.
• Dopytanie o brakujące informacje, takie jak nazwa urządzenia, dokładny komunikat błędu czy zrzut ekranu, zanim zgłoszenie trafi do drugiej linii.
• Wnioski o hasła i dostęp: agent sprawdza wniosek względem katalogu ról, przygotowuje zmianę i wysyła ją do właściwej osoby zatwierdzającej. Hasła resetuje się przez istniejący portal samoobsługowy z uwierzytelnianiem wieloskładnikowym.
• Asystent runbooków dla utrzymania IT: przy alercie albo incydencie znajduje pasujący runbook, ostatnie zmiany i podobne wcześniejsze incydenty, wykonuje zatwierdzone przez ciebie kontrole tylko do odczytu i proponuje kolejne kroki.
• Utrzymanie bazy wiedzy: po rozwiązaniu zgłoszenia szkic artykułu do przeglądu oraz lista artykułów, po których zgłoszenia są ponownie otwierane.

Każda decyzja, która zmienia dostęp, systemy albo to, co usłyszy użytkownik, zostaje u ludzi. Agent przygotowuje, twój zespół zatwierdza.

• Odpowiedzi dla użytkowników: twój zespół wysyła, poprawia albo odrzuca każdy szkic. Automatyczne odpowiedzi dla wskazanych kategorii o niskim ryzyku pojawiają się dopiero wtedy, gdy zmierzona jakość to uzasadnia i ty tak zdecydujesz.
• Uprawnienia: przełożony albo właściciel danych zatwierdza każdą rolę lub grupę. Agent tylko przygotowuje zmianę w Active Directory albo Entra ID, a wprowadza ją twój proces zarządzania tożsamością.
• Hasła: agent nigdy nie widzi, nie ustawia ani nie wysyła hasła. Czat, który resetuje hasła, to otwarte drzwi dla socjotechniki, dlatego resety zostają w portalu samoobsługowym albo u osoby, która weryfikuje tożsamość.
• Zmiany na produkcji: domyślnie asystent runbooków wykonuje tylko kontrole do odczytu. Każde polecenie, które zmienia system, wymaga zgody wskazanego inżyniera i przechodzi przez twój proces zarządzania zmianą.
• Incydenty bezpieczeństwa, poważne awarie i wszystko, co dotyczy danych osobowych konkretnej osoby, trafia od razu do ludzi, bez szkicu odpowiedzi.

Łączymy agenta przez interfejs z systemem zgłoszeń, którego używasz, na przykład ServiceNow, Jira Service Management, TOPdesk albo SAP Service Cloud, oraz z bazą wiedzy w Confluence albo SharePoint. Monitoring, CMDB i katalog użytkowników dochodzą tam, gdzie zadanie ich wymaga. Niczego nie migrujemy. Praca nadal jest zapisywana w systemie zgłoszeń.

• Narzędzia z jednym zadaniem każde: odczytać zgłoszenie, ustawić kategorię, dodać notatkę wewnętrzną, zaproponować członkostwo w grupie. Każde działa na własnym koncie serwisowym z najmniejszymi potrzebnymi uprawnieniami. Tam, gdzie to pasuje, używamy MCP, standardu, przez który agent uzyskuje dostęp do systemu z własnymi uprawnieniami.
• Zgłoszenia traktujemy jako niezaufane dane wejściowe. Tekst w zgłoszeniu nie może zmienić tego, co agent może zrobić, a wewnętrzne procedury administracyjne nigdy nie trafiają do odpowiedzi dla użytkowników.
• Hosting na twoim własnym koncie w chmurze w regionie UE albo na własnych serwerach z modelem open-weight, czyli modelem, którego wagi możesz uruchomić samodzielnie. Zgłoszenia, wiedza i logi zostają w twoim środowisku.
• Jedna bramka LLM, czyli jeden kontrolowany punkt dostępu do wszystkich modeli z kluczami, budżetami i logami, dzięki czemu widzisz koszt obsługi jednego zgłoszenia.
• Kupić czy zbudować: kilka pakietów ITSM sprzedaje własne funkcje AI. Jeśli twój pakiet obsługuje klasyfikację i szkice odpowiedzi na twoich danych, a jego hosting spełnia twoje zasady, zacznij od niego, a my możemy go przetestować na twoich zgłoszeniach. Własna budowa opłaca się, gdy odpowiedzi wymagają źródeł spoza systemu zgłoszeń, takich jak SharePoint, udziały plików, monitoring czy CMDB, gdy dane muszą zostać na własnych serwerach albo gdy jedna sprawa przechodzi przez kilka systemów i łańcuch zatwierdzeń.

Przed startem system przechodzi test akceptacyjny na zestawie twoich wcześniejszych zgłoszeń, dla których znana jest właściwa kategoria, zespół i odpowiedź. Wyniki podajemy dla każdej kategorii osobno, żebyś widział, gdzie system jest niezawodny, a gdzie nie.

Po starcie mierzymy na twoich zgłoszeniach to, co jest dla ciebie ważne, przed i po: godziny na zgłoszenie, odsetek przekierowanych zgłoszeń, odsetek ponownie otwartych i czas do pierwszej odpowiedzi. Te same testy uruchamiamy ponownie po każdej zmianie modelu, promptu albo bazy wiedzy. Dostajesz runbooki do obsługi samego agenta i albo twój zespół przejmuje go razem z kodem i testami, albo my go utrzymujemy.

• Przypisanie: odsetek zgłoszeń z poprawną kategorią, priorytetem i zespołem w porównaniu z tym, jak twój service desk przypisuje je dziś.
• Odpowiedzi: poprawna treść, źródło, które ją potwierdza, i brak informacji tylko do użytku wewnętrznego w odpowiedziach dla użytkowników.
• Bezpieczeństwo: wrogie zgłoszenia, które próbują wydawać agentowi polecenia, prośby o reset hasła przez czat i wnioski o dostęp bez osoby zatwierdzającej. Oczekiwany wynik to odmowa albo przekazanie człowiekowi.
• Tryb cienia: potem agent pracuje równolegle z twoim service deskiem na prawdziwych zgłoszeniach, jego propozycje są zapisywane, ale nie wdrażane, a my porównujemy je z tym, co zrobił zespół.

Zgłoszenia zawierają dane osobowe: nazwiska, urządzenia, lokalizacje, a czasem szczegóły, których ludzie woleliby nie ujawniać. Wszystko jest przetwarzane w twoim środowisku, a ty decydujesz, co jest przechowywane i jak długo, z pomocą inspektora ochrony danych i prawników. Ta sekcja opisuje stronę techniczną i nie jest poradą prawną.

Rada zakładowa ma tu znaczenie dla dwóch grup: pracowników service desku i wszystkich, którzy otwierają zgłoszenia. Poradnik Bitkom o AI i współdecydowaniu z 2026 roku wskazuje, że § 87 ust. 1 pkt 6 BetrVG ma zastosowanie, gdy system obiektywnie nadaje się do monitorowania wydajności lub zachowania, niezależnie od intencji. System, który mógłby raportować zgłoszenia na pracownika albo czas obsługi na osobę w service desku, się do tego kwalifikuje. Projektujemy tak, żeby tego uniknąć: bez raportów na osobę, z pseudonimizowanymi identyfikatorami w logach, uzgodnionym okresem przechowywania i krótką kartą systemu, którą rada zakładowa może przeczytać.

Asystent wsparcia IT nie należy do zastosowań wysokiego ryzyka wymienionych w załączniku III AI Act, takich jak rekrutacja czy ocena zdolności kredytowej. Obowiązek przejrzystości z art. 50 obowiązuje od 2 sierpnia 2026 roku: ludzie muszą wiedzieć, że rozmawiają z systemem AI, więc czat o tym informuje.

Zacznij od jednego strumienia zgłoszeń, który jest częsty, powtarzalny i niskiego ryzyka, na przykład prośby o oprogramowanie albo wnioski o dostęp dla standardowych ról. To daje jasny punkt wyjścia i efekt, który widać.

• Wyeksportuj zestaw wcześniejszych zgłoszeń z tego strumienia z kategorią, zespołem i ostateczną odpowiedzią, jaką każde otrzymało.
• Zmierz punkt wyjścia: godziny na zgłoszenie, przekierowane zgłoszenia i odsetek ponownie otwartych.
• Uzgodnij punkty zatwierdzania i logowanie z działem bezpieczeństwa IT, inspektorem ochrony danych i radą zakładową przed pierwszym testem.
• Przeprowadź test akceptacyjny, potem tryb cienia, a potem szkice odpowiedzi zatwierdzane przez zespół.