AI u IT podršci: Brže i efikasnije rešavanje problema

U izvornom Positive tekstu iz marta 2025. pitanje je bilo jednostavno: kako veštačka inteligencija može da ubrza IT podršku bez gubitka kvaliteta usluge? Odgovor se zasniva na pet oblasti — automatizaciji rutinskih zadataka, ranijem prepoznavanju problema, prilagođavanju odgovora korisniku, povezivanju postojećih IT sistema i racionalnijem korišćenju resursa. Danas je jednako važno razumeti granice tih mogućnosti i ulogu stručnjaka.

Urednička napomena (oktobar 2026): Ovo je obnovljeno i prošireno izdanje Positive članka „AI u IT podršci: Brže i efikasnije rešavanje problema“, objavljenog 12. marta 2025. Originalnih pet tema i njihovi osnovni primeri sačuvani su po smislu. Dodatni koraci implementacije, bezbednosna ograničenja i predlozi za merenje rezultata predstavljaju novu uredničku dopunu, a ne podatke iz izvorne objave.

Šta zapravo znači AI u IT podršci

IT podrška nije samo odgovaranje na poruke. Ona obuhvata prijem zahteva, prepoznavanje uzroka, proveru pristupa, dijagnostiku uređaja i aplikacija, praćenje incidenata, komunikaciju sa zaposlenima i dokumentovanje rešenja. Ako se svaki korak obavlja ručno, isti problemi se ponavljaju, a stručnjaci gube vreme na pretragu prethodnih slučajeva.

AI može da bude pomoćni sloj koji prepoznaje obrazac zahteva, pronalazi relevantno uputstvo i predlaže sledeći korak. To ne znači da samostalno zna šta se dešava u svakoj mreži. Rezultat zavisi od kvaliteta dokumentacije, dostupnih podataka, ovlašćenja i integracije sa stvarnim alatima. Najbolji početak je zato konkretan proces, a ne opšta tvrdnja da će chatbot rešiti svaku poteškoću.

1. Automatizacija rutinskih zadataka

Prva oblast iz originalnog članka jesu zadaci koji se stalno ponavljaju. Zaposleni često traže uputstvo za prijavu na nalog, informacije o podešavanju pošte, status zahteva ili pomoć pri korišćenju standardne aplikacije. AI asistent može da odgovori na osnovu odobrene baze znanja, postavi dopunsko pitanje i pripremi tiket za odgovarajući tim.

Resetovanje lozinke je dobar primer granice između odgovora i izvršavanja radnje. Sistem može da objasni zvaničan postupak, ali promena pristupnih podataka mora da ide kroz proveru identiteta i odobren tok. Slično tome, automatsko otklanjanje poznate greške treba da se pokrene samo kada su uslovi provereni i kada postoji mogućnost zaustavljanja ili vraćanja izmene.

Dobit nije samo brzina prvog odgovora. Važnije je da korisnik dobije konzistentnu informaciju, da se zahtev pravilno evidentira i da IT stručnjak preuzme složen slučaj sa već prikupljenim osnovnim podacima.

2. Prediktivna analitika i prevencija problema

Druga tema izvornog teksta jeste otkrivanje problema pre ozbiljnijeg prekida rada. Serveri, mrežni uređaji, aplikacije i sistemi za čuvanje podataka proizvode logove i telemetriju. Kada se takvi zapisi prikupljaju dosledno, analitički modeli mogu da ukažu na neobično ponašanje: ponavljane greške, promene opterećenja ili obrazac koji prethodi poznatom incidentu.

Međutim, anomalija nije isto što i potvrđen kvar. Nagli rast aktivnosti može da bude posledica legitimnog posla, a ne napada ili greške. Zato je potrebno povezati signal sa kontekstom: promenama konfiguracije, planiranim radovima, korisničkim prijavama i drugim indikatorima. Dobra praksa je da AI predloži prioritet i objašnjenje, a da tim proveri uzrok pre intervencije.

Prediktivni pristup posebno ima smisla kada organizacija već ima uređeno praćenje sistema. Bez pouzdanih logova, istorije incidenata i vlasnika procesa, algoritam ne može nadomestiti nedostajuću operativnu disciplinu.

3. Personalizovana podrška korisnicima

Treća oblast je prilagođavanje podrške konkretnom korisniku. Nije isto kada problem prijavi novi zaposleni koji prvi put koristi aplikaciju i kada isti simptom prijavi administrator sa iskustvom. Dobro organizovan sistem može da ponudi različit nivo objašnjenja, relevantne procedure i korake primerene ovlašćenjima.

Istorija tiketa pomaže da se prepozna da li se zahtev ponavlja i koje je rešenje ranije uspelo. Ali pristup tim informacijama mora da bude ograničen. Asistent ne sme da otkrije tuđe podatke, lozinke, poverljive dokumente ili informacije iz drugih odeljenja samo zato što su dostupne u zajedničkoj bazi.

Personalizacija zato treba da znači precizniju pomoć, a ne neograničeno prikupljanje podataka. Korisnik treba da zna kada razgovara sa AI sistemom, šta se evidentira i kako može da zatraži čoveka.

4. Integracija sa postojećim IT sistemima

Četvrti stub originalnog članka je povezivanje AI alata sa postojećom infrastrukturom. Bez integracije, asistent može da daje opšta uputstva. Sa kontrolisanom integracijom u ITSM ili ticketing sistem može da proveri status zahteva, dodeli kategoriju, predloži odgovornog izvršioca ili sažme dosadašnju komunikaciju.

U praksi treba jasno razdvojiti tri nivoa ovlašćenja: čitanje odobrenih informacija, pripremu predloga i izvršavanje promene. Čitanje statusa tiketa obično nosi drugačiji rizik od isključivanja naloga, izmene mrežne konfiguracije ili brisanja zapisa. Za radnje sa većim posledicama potrebni su ljudska potvrda, evidencija i mogućnost revizije.

Važno je i da postojeći sistemi ostanu izvor istine. AI ne bi trebalo da izmisli status incidenta niti da korisniku obeća završetak posla ako u ticketing sistemu takva potvrda ne postoji.

5. Operativni troškovi i raspodela vremena

Peti deo originalnog teksta bavi se troškovima. Automatizacija može da smanji broj ponovljenih ručnih koraka, ali sama instalacija AI alata ne garantuje uštedu. U trošak treba uključiti licenciranje, integracije, održavanje baze znanja, nadzor, obuku i vreme potrebno za ispravljanje pogrešnih odgovora.

Korisnije je pitati koliko se vremena oslobađa za posao veće vrednosti. Ako stručnjak više ne mora svakodnevno da prepisuje iste procedure, može da se posveti trajnom uklanjanju uzroka incidenata, bezbednosti ili unapređenju infrastrukture. Ako automatizacija samo proizvodi dodatne tikete i zbunjuje korisnike, operativni rezultat može biti negativan.

Zato se ekonomski efekat meri u konkretnom procesu, uz poređenje stanja pre i posle pilot-projekta. Broj poruka koje je chatbot poslao nije dovoljan pokazatelj uspeha.

Bezbednost, privatnost i ljudska kontrola

AI podrška često radi sa osetljivim informacijama: imenima korisnika, sadržajem tiketa, tehničkim logovima, internim adresama i opisima bezbednosnih incidenata. Pre uključivanja modela treba odrediti koje podatke sme da primi, gde se obrađuju, koliko se čuvaju i ko ima pravo pristupa. Posebnu pažnju zahtevaju lozinke, tajni ključevi, podaci o klijentima i dokumentacija koja otkriva strukturu sistema.

Odgovori modela nisu dokaz da je postupak bezbedan ili tačan. Potrebni su proverljivi izvori, jasno označena nesigurnost i eskalacija čoveku. Za promene naloga, pristupa ili infrastrukture treba primenjivati princip najmanjih privilegija i beležiti svaku izvršenu radnju.

Ovakav pristup je usklađen sa opštim načelima upravljanja AI rizicima i dobrog upravljanja sistemskim zapisima: najpre definišemo odgovornost, zatim merimo pouzdanost i tek onda širimo automatizaciju.

Kako izgleda prvi pilot-projekat

Dobar pilot ne mora da obuhvati celu kompaniju. Izaberite jednu grupu čestih, relativno niskorizičnih zahteva: uputstva za VPN, standardne aplikacije ili pitanja o statusu tiketa. Prikupite odobrene procedure, označite njihove vlasnike i datum poslednje provere. Definišite kome se zahtev prosleđuje kada nema sigurnog odgovora.

Sledeći korak je testiranje na stvarnim, ali odgovarajuće zaštićenim primerima. Proverite da li asistent razume različite formulacije istog problema, da li citira tačno uputstvo, da li odbija neovlašćene radnje i da li pravilno otvara ili dopunjava tiket. Uključite i primere za koje namerno nema odgovora.

Tek kada tim potvrdi kvalitet, omogućite ograničen pristup korisnicima. Zadržite jednostavan način da se korisnik obrati osobi i dokumentujte situacije u kojima AI nije pomogao.

Koje pokazatelje treba pratiti

Za procenu koristi pratite vreme do prvog korisnog odgovora, vreme do konačnog rešenja, broj zahteva rešenih bez dodatne intervencije i učestalost ponovnog otvaranja tiketa. Važni su i zadovoljstvo korisnika, tačnost predloženih procedura, broj pogrešnih eskalacija i vreme koje stručnjaci troše na proveru AI izlaza.

Pokazatelje tumačite zajedno. Kratak prvi odgovor ne vredi mnogo ako korisnik zatim čeka danima ili mora ponovo da objašnjava problem. Visok procenat automatizovanih odgovora takođe nije uspeh ako se rešavaju samo laka pitanja, dok se složeni incidenti pogoršavaju.

Odredite početnu vrednost svakog pokazatelja pre pilota. Posle nekoliko nedelja uporedite iste tipove zahteva i zabeležite promene u obimu posla. Tako se odluka o širenju sistema zasniva na dokazima, a ne na utisku.

Kada AI nije pravo rešenje

Neki incidenti zahtevaju neposrednu intervenciju: prekid ključnog poslovnog sistema, sumnju na kompromitovan nalog, gubitak podataka ili problem koji utiče na bezbednost. AI može da pomogne u prikupljanju činjenica i usmeravanju, ali ne sme da uspori kontakt sa odgovornim timom.

Ako dokumentacija nije ažurna, ako su procedure protivrečne ili niko nije zadužen za održavanje baze znanja, najpre treba rešiti taj problem. Automatizacija lošeg procesa često samo brže širi lošu informaciju. Isto važi kada organizacija nema način da proveri izlaz modela ili da evidentira njegove postupke.

Pravo pitanje nije koliko zadataka AI može da preuzme, već koji zadaci mogu da se ubrzaju uz prihvatljiv rizik i jasnu odgovornost.

Zaključak: brža podrška počinje uređenim procesom

Izvorni Positive članak izdvojio je pet praktičnih mogućnosti: rutinsku automatizaciju, predviđanje problema, personalizovanu pomoć, integraciju sa IT alatima i bolje korišćenje resursa. Te mogućnosti ostaju relevantne, ali daju rezultat tek kada su povezane sa kvalitetnom dokumentacijom, jasnim ovlašćenjima i stručnim nadzorom.

Najbolja AI IT podrška ne skriva čoveka iza interfejsa. Ona korisniku skraćuje put do tačne informacije, timu daje bolji kontekst i omogućava da se složeni problemi rešavaju pažljivije. Za kompaniju je to prilika da gradi pouzdaniju podršku — korak po korak, uz merljive rezultate i kontrolu rizika.