Zaposleni pita interni AI alat da li kupac ima pravo na povraćaj avansa. Dobija uverljiv odgovor i naziv ugovora. Pre nego što ga prosledi finansijama, treba da otvori konkretan dokument, proveri potpisanu verziju i pronađe odredbu koja zaista podržava zaključak. AI interna baza znanja treba da olakša tu proveru, ne da je zameni.
Ovaj tekst predlaže postupak za firmu koja želi da pretražuje sopstvene ugovore i procedure. Nije pregled novih zakonskih obaveza niti tvrdnja da je svaka interna AI pretraga posebno regulisana. Prvo pitanje glasi: može li zaposleni da utvrdi odakle odgovor potiče i sme li taj izvor uopšte da vidi?
Počnite od ograničene zbirke, ne od celog diska
Za početno testiranje izaberite jednu oblast, na primer odobrene procedure za prijem reklamacija. Odredite osobu koja potvrđuje koja verzija važi. Iz zbirke izdvojite radne beleške, stare obrasce i nacrte koji nisu odobreni. Velika količina dokumenata nije sama po sebi dobar razlog za njihovo uključivanje.
Uz svaki izvor vodite naziv, vlasnika dokumenta, datum odobrenja, oznaku verzije i krug korisnika. Korisno je dodati i status: važi, zamenjen ili namenjen samo za istorijsku proveru. Sačuvajte original na mestu sa kog se može otvoriti bez oslanjanja na AI prepričavanje.
Kod ugovora nemojte pretpostavljati da je najnoviji datum fajla ujedno datum merodavne verzije. Potpisani ugovor i kasniji nepotpisani nacrt moraju se razlikovati. Postupak opisan u tekstu o AI poređenju verzija ugovora pomaže da poređenje izmena ne postane pogrešno odobrenje dokumenta.
Tražite izvor koji zaposleni može da proveri
U testnom zadatku zahtevajte da odgovor sadrži naziv dokumenta, oznaku verzije i član ili odeljak na koji se oslanja. Ako odgovor objedinjuje više izvora, neka ih razdvoji. Dobro je predvideti i odgovor da u dostupnoj zbirci nema dovoljno podataka.
Prisustvo linka nije dovoljno. Otvorite navedeni odeljak i proverite da li govori o istom kupcu, istom poslu i istom pitanju. Ugovor o jednoj vrsti usluge ne treba koristiti kao pravilo za sve odnose firme. Izuzetak u aneksu može biti važniji od opšte procedure.
NIST profil rizika generativne AI razmatra stvaranje netačnih sadržaja i rizike po integritet informacija. To je stručni okvir, ne zakon Srbije. Za ovu primenu praktična posledica je jednostavna: uverljiv stil odgovora ne služi kao dokaz njegove tačnosti.
Isti princip važi kada u zbirku uključite sudske odluke. Broj predmeta i sažetak ne zamenjuju izvornu odluku, što je detaljnije objašnjeno u tekstu o proveri AI pretrage sudske prakse.
Razdvojite pravo pristupa od tehničke mogućnosti pretrage
Pre uključivanja ugovora sa podacima zaposlenih ili klijenata proverite svrhu i pravni osnov obrade. Načela ograničenja svrhe, minimizacije i tačnosti podataka, kao i pravni osnovi, uređeni su članovima 5 i 12 Zakona o zaštiti podataka o ličnosti Srbije. Postojanje dokumenta u firmi samo po sebi ne rešava te provere.
Ako dobavljač alata obrađuje podatke u ime firme kao obrađivač, proverite uređenje odnosa prema članu 45. Za mere bezbednosti relevantan je član 50, prema riziku obrade. Konkretne uloge i tokove podataka treba utvrditi pre izbora ugovorne dokumentacije.
U praktičnom testu napravite naloge sa različitim ovlašćenjima. Zaposleni koji ne sme da otvori kadrovski dosije ne bi trebalo da kroz AI odgovor dobije njegov sadržaj. Proverite i rezultate pretrage, sažetke, izvoze i istoriju razgovora, ne samo prikaz izvornog fajla.
Posebno tražite odgovore dobavljača o čuvanju podataka, podizvođačima, lokacijama obrade, brisanju i korišćenju unosa za druge svrhe. Ako smanjujete količinu podataka pre unosa, pogledajte i proveru anonimizacije dokumenata. Samo uklanjanje imena ne rešava svaki rizik identifikacije.
Testirajte pogrešne i nepotpune odgovore pre puštanja u rad
Pripremite nekoliko pitanja na koja već imate proverene odgovore. Dodajte pitanje za koje u zbirci nema odgovora, dva dokumenta sa suprotnim pravilima i primer sa ukinutom procedurom. To su predloženi testovi kvaliteta, ne propisani broj provera.
Za svaki pokušaj zabeležite pitanje, nalog, navedene izvore i ocenu pregledatelja. Nemojte meriti samo koliko brzo je odgovor stigao. Proverite da li je alat prepoznao nedostatak informacije i da li je korisnika uputio na odgovornu osobu.
Koristan zamišljeni primer: opšta procedura kaže da je za popust potrebno odobrenje direktora, dok ugovor sa određenim kupcem sadrži već ugovoren rabat. Zadatak nije da AI sam odluči koja isplata sledi, već da pokaže oba izvora i mesto neslaganja. Nadležna osoba zatim proverava njihov odnos.
Ako alat pogreši, odvojite mogući uzrok: zastareo izvor, pogrešno ovlašćenje, loše postavljeno pitanje ili zaključak koji izvor ne podržava. Svaki traži drugačiju popravku. Samo preformulisanje upita neće rešiti neuređenu dokumentaciju.
Odredite ko odobrava odgovor za poslovnu upotrebu
Za orijentacionu pretragu dovoljno je da zaposleni dobije put do dokumenta. Za odluku o isplati, odbijanju zahteva kupca ili promeni ugovorne obaveze predvidite imenovanog pregledatelja. Sačuvajte izvor na koji se konačna odluka oslanja, datum provere i odobrenu verziju odgovora.
Odredite i postupak kada izvor bude povučen ili zamenjen: ko ažurira zbirku, ko proverava pretragu i kako se prijavljuje pogrešan odgovor. Interno uputstvo treba da kaže kome zaposleni prosleđuje neslaganje, umesto da od njega očekuje da nagađa.
Pre nabavke ili šireg uvođenja pripremite paket za pravnu i poslovnu proveru sistema: spisak izvora, grupe korisnika, opis toka podataka i predlog ugovora sa dobavljačem. Ako tražite savet o konkretnom sistemu, pošaljite taj paket na pregled pre odobrenja pristupa stvarnim dokumentima. Na toj osnovi može se razgovarati o stvarnom riziku i odgovornosti, umesto o obećanju da alat „zna sve o firmi".
