Otázka, ktorú pri AI v ITSM stojí klásť, nie je, či ide o „budúcnosť“ — ale ktoré časti skutočne obstoja na živom service desku a ktoré sa rozpadnú v momente, keď sa dotknú reálnych tiketov. Rok nasadzovania LLM funkcií do GLPI prostredí priniesol pomerne jasný obraz a odpovede sú menej dramatické ako demá.
Čo dnes funguje
Použitia, ktoré si zarábajú na seba, sú úzko vymedzené, asistenčné a ponechávajú človeka v rozhodovaní:
- Kategorizácia tiketov. Z voľného popisu vie LLM navrhnúť kategóriu, urgenciu a SLA. Hodnota nie je v tom, že nahradí triagera — je v tom, že používateľ pri zadávaní tiketu nemusí vyberať z 40‑položkového dropdownu. Zlé odhady sa opravia pri triage a postupom času vidieť, ktoré kategórie sa akceptujú a ktoré sa prepisujú. To je užitočný podklad na vylepšenie samotnej taxonómie.
- Vyhľadanie podobných tiketov. „Za posledných šesť mesiacov sa vyskytli tri tikety s podobným popisom; dva boli vyriešené reštartom print spooleru.“ Ide o embeddingy nad GLPI históriou, nie o generovanie, a funguje to dobre práve preto, že je o čo sa oprieť. Agent si môže prekliknúť cez konkrétne riešenie.
- Drafty odpovedí z KB. Keď sa tiket zhoduje s článkom v knowledge base, LLM pripraví návrh odpovede s odkazom na správny článok. Agent upraví a odošle. Toto je zďaleka najvýnosnejšie použitie, ktoré sme nasadili — premení „hľadaj, skopíruj, uprav, pošli“ na „uprav, pošli,“ a KB sa zlepšuje samo, pretože zlyhané drafty odhaľujú medzery v článkoch.
- Sumarizácia dlhých tiketov. Tiket s 30 aktualizáciami naprieč troma týždňami sa zhrnie do krátkeho súhrnu pre ďalšieho riešiteľa. Obzvlášť užitočné pri incidentoch, ktoré sa odovzdávajú medzi smenami alebo eskalujú na L2 — náklady na prečítanie celého vlákna človekom sú veľmi reálne.
- Validácia pred odoslaním. Samoobslužný formulár prejde draft popisu cez LLM, ktoré skontroluje chýbajúce informácie („spomenuli ste server, ale nepomenovali ho,“ „napísali ste ‚pomalé' — v porovnaní s čím?“) a vypýta si ich ešte pred vytvorením tiketu. Oveľa lacnejšie než ping‑pong po zaradení do fronty.
Nič z toho nenahrádza ľudí. Odkrojí to minúty z opakujúcej sa práce, ktorá agentom potichu ujedala čas.
Čo je stále len demo
Niektoré použitia vyzerajú skvele na plátne a v produkcii sa rozpadnú:
- Autonómne riešenie tiketov. „Bot uzavrie rutinné tikety od začiatku do konca.“ Funguje len v úzko definovanom, dobre známom rozsahu — napríklad reset hesla proti jedinému identity provideru. Mimo toho rozsahu je zlyhanie také, že bot sebavedome označí tiket ako vyriešený bez toho, aby ho skutočne vyriešil — a to ničí dôveru používateľov rýchlejšie, ako by to dokázal aj pomalý ľudský agent.
- Predikcia incidentov bez dát. AIOps dashboardy, ktoré tvrdia, že „predikujú výpadky,“ potrebujú mesiace čistej telemetrie, označenú históriu incidentov a metriky korelované so známymi zlyhaniami. Väčšina prostredí to nemá. Dashboardy vyzerajú pôsobivo a nepredikujú nič.
- Nahradenie L2 a L3. LLM nevie debugovať problém v TCP stacku, vystopovať flappingujúcu BGP session ani zrekonštruovať pokazenú databázovú migráciu. Vie zhrnúť, čo sa stalo. Riešenie stále pochádza od človeka, ktorý systému rozumie.
- Generatívne chatboty nad neoverenou KB. Ak je knowledge base zastaraná alebo neúplná, bot vyplní medzery plynulými nezmyslami. Používatelia to buď spozorujú a prestanú botu veriť, alebo to neuvidia a posunú zlú informáciu ďalej. Obe možnosti sú horšie ako žiadny bot.
Ako to zapadá do GLPI
GLPI nie je AI‑native, ale potrebné háky tam sú. Webhooky a REST API sa spúšťajú pri životných udalostiach tiketu — vytvorenie, aktualizácia, zmena stavu — a to stačí na zavolanie externej LLM služby a zápis výsledku späť do vlastných polí. Praktická podoba, akú najčastejšie nasadzujeme:
- Prichádzajúci tiket prejde krokom Cascade workflowu, ktorý POSTuje na interný LLM endpoint pre kategorizáciu a vyhľadanie podobných tiketov, a návrhy zapíše do vlastných polí tiketu.
- Agenti vidia návrhy v UI tiketu. Prijmú, prepíšu alebo ignorujú.
- Prijaté návrhy plnia evaluačný log, ktorý používame na ladenie promptu a meranie presnosti v čase.
Nič z toho nevyžaduje vendor AI feature. Stačí LLM, ktorému dôverujete, API, ktoré viete zavolať, a nejaký rozumný objem workflow plumbingu. Naše LLM integrácie zvyčajne začínajú práve takto a rastú podľa toho, ktoré použitie si prvý týždeň udrží používateľov.
Poctivé obmedzenia
Niekoľko obmedzení, ktoré treba pomenovať nahlas:
- Ochrana dát. Posielanie obsahu tiketu do tretej LLM služby znamená posielať všetko, čo v popisoch tiketov skončí — heslá, ktoré používatelia zadali „aby to bolo jednoduchšie,“ interné hostnames, osobné údaje. V regulovaných prostrediach je jedinou prijateľnou voľbou self‑hosted alebo on‑prem inferencia. A tá výrazne mení nákladový model.
- Evaluácia je nosná. Bez merania, či LLM naozaj zlepšuje výsledky, budete potichu posielať zlé návrhy celé mesiace. Spätnoväzbovú slučku postavte skôr ako samotnú funkciu.
- Cena za tiket. Hosted inferencia je za jedno volanie lacná, ale pri objemoch service desku sa to sčítava. Počítajte s tým a vypínajte funkcie, pri ktorých ROI nesedí.
- Halucinácie zostávajú riziko. Aj pri dobre podložených úlohách si model občas niečo vymyslí s plnou sebaistotou. Každý výstup, ktorý sa dostane k používateľovi alebo agentovi bez úpravy — drafty odpovedí, automatické návrhy — potrebuje kontrolný krok alebo veľmi prísne podklady.
Kde začať
Začnite tam, kde zlá odpoveď nič nestojí a správna odpoveď šetrí čas. Drafty odpovedí z KB pre opakujúce sa otázky a vyhľadanie podobných tiketov cez embeddingy sú dve najmenej rizikové prvé nasadenia. Zmerajte, či ich agenti používajú aj po dvoch týždňoch. Ak áno, rozširujte. Ak nie, funkcia si na seba nezarába — nerolujte ju ďalej len preto, že demo vyzeralo dobre.