Firma je proverila AI alat za izdvajanje ugovornih obaveza i počela da ga koristi. Dobavljač zatim promeni model. Ekran izgleda isto, zaposleni daju isto uputstvo, ali novi odgovor više ne označava da jedan rok zavisi od prijema obaveštenja. Ovo je ilustrativan primer, ne opis konkretnog incidenta. Pokazuje zašto posle promene nije dovoljno proveriti samo da li alat radi.

Praktičan pristup je da se nova i prethodno prihvaćena verzija uporede na istom kontrolnom skupu zadataka. Firma unapred određuje šta je neprihvatljiva greška, ko proverava rezultat i ko odobrava nastavak upotrebe. Takva provera je preporuka za upravljanje poslovnim rizikom, a ne tvrdnja da svaki korisnik AI alata u Srbiji ima jednu univerzalnu zakonsku obavezu testiranja.

Prvo utvrdite šta je zaista promenjeno

Promena naziva modela nije jedini povod za proveru. Isti poslovni zadatak može dobiti drugačiji rezultat kada se promeni sistemsko uputstvo, način pretrage dokumenata, obrada skenova ili spisak izvora kojima alat pristupa. Zato evidencija promene treba da obuhvati ceo tok rada, ne samo oznaku modela.

Od dobavljača tražite dostupne podatke o datumu promene, zahvaćenim funkcijama i mogućnosti zadržavanja prethodne verzije. Ako alat ne otkriva tačnu verziju, zabeležite i to ograničenje. Ne upisujte u zapisnik podatak koji tehnički ne možete potvrditi.

Za proces koji odgovara na pitanja iz internih akata proverite i da li su dokumenti i dozvole pristupa ostali isti. Postupak opisan u tekstu o AI internoj bazi znanja i proveri izvora odgovora pomaže da se razdvoje greška modela i pogrešan ili nedostupan izvor.

Napravite kontrolni skup koji liči na stvarni posao

Kontrolni skup ne čine samo kratki, uredni dokumenti sa očiglednim odgovorom. Uključite zadatke koji predstavljaju uobičajen posao, ali i situacije u kojima greška može promeniti poslovnu odluku: aneks koji menja osnovni ugovor, nedostajući prilog, dve slične firme ili odredbu sa izuzetkom.

Za svaki slučaj unapred pripremite očekivani rezultat i mesto u dokumentu na kojem se on zasniva. Kada pouzdan odgovor nije moguć, ispravan rezultat može biti „nema dovoljno podataka". Model ne treba nagraditi za uverljivu pretpostavku.

Na primer, test za izdvajanje rokova može sadržati sledeće provere:

  • Da li je izdvojen događaj od kojeg rok počinje da teče?
  • Da li je razlikovan osnovni ugovor od važećeg aneksa?
  • Da li je jasno označeno da datum prijema obaveštenja nije dostavljen?
  • Da li rezultat navodi konkretan izvor, umesto samostalno izračunatog datuma bez osnova?

Za pripremu takvih slučajeva može poslužiti vodič o AI evidenciji ugovornih rokova. Ovde ne proveravate samo pojedinačan rok, već da li promenjena verzija i dalje ispunjava prethodno prihvaćene kriterijume.

Uporedite rezultate pod istim uslovima

Sačuvajte kontrolne dokumente, tačno uputstvo i postavke koje su dostupne korisniku. Staru i novu verziju, kada je to moguće, pokrenite nad istim materijalom. Ako stara više nije dostupna, poređenje ograničite na ranije sačuvane rezultate i izričito navedite da potpuno ponavljanje nije bilo moguće.

Nemojte ocenjivati samo stil. Razdvojite činjeničnu tačnost, pokrivenost zadatka, proverljivost izvora i pridržavanje ograničenja. Odgovor može biti lepše napisan, a da izostavlja ugovorni izuzetak koji je važan za odluku. Kod AI poređenja verzija ugovora posebno proverite da li model i dalje razlikuje jezičku izmenu od promene prava i obaveza.

Jedno uspešno pokretanje nije dovoljno da se opiše doslednost. Za važne slučajeve preporučljivo je ponoviti test i proveriti da li se nalaz menja. Broj ponavljanja i obim uzorka firma određuje prema riziku i raspoloživim sredstvima, bez izmišljanja univerzalnog obaveznog minimuma.

Odredite greške koje zaustavljaju upotrebu

Ukupan procenat uspešnosti može sakriti kritičan propust. Unapred odvojite sitnu grešku u formatu od izmišljenog iznosa, pogrešnog ugovarača ili otkrivanja sadržaja koji korisniku nije namenjen. Odličan prosek ne treba da poništi razlog zbog kojeg je konkretan proces neprihvatljiv.

Praktičan interni zapis za svaki test sadrži oznaku slučaja, očekivani nalaz, stvarni rezultat, težinu greške i ime osobe koja je proverila izvor. Trošak i brzina mogu biti dodatni kriterijumi, ali ne zamena za tačnost. Sačuvajte i neuspešne rezultate, jer su važni za razumevanje odluke.

Koristite sintetičke ili primereno pripremljene dokumente kad god se njima može proveriti ista funkcija. Ako razmatrate stvarne poslovne spise, najpre proverite ugovorne uslove, dozvoljene podatke i pristup. Uslove promene usluge, obaveštavanja i izlaska razmotrite zajedno sa ugovorom sa AI dobavljačem, a ne tek kada test pokaže problem.

Odobrenje vežite za određenu namenu

Odluka ne mora biti samo „odobreno" ili „zabranjeno". Nova verzija može biti prihvatljiva za interni sažetak, a neprihvatljiva za pripremu dopisa koji bez dodatne kontrole odlazi poslovnom partneru. Zapišite dozvoljenu namenu, potrebnu ljudsku proveru, ograničenja i uslove za ponovno preispitivanje.

Predložena dokumentacija obuhvata opis promene, rezultate testova, otvorena pitanja i obrazloženu odluku odgovorne osobe. To nije potvrda potpune pravne usklađenosti niti garancija budućih rezultata. Konkretne obaveze zavise od namene, sektora, podataka i ugovornog odnosa. Ovaj tekst ne izvodi zaključak o primeni prava EU ili AI Act-a na određenu firmu.

Šta pripremiti za razgovor sa dobavljačem ili pravnikom

Ponesite opis poslovnog zadatka, ranije prihvaćene kriterijume, obaveštenje o promeni i nekoliko uporedivih rezultata. Navedite i šta firma gubi ako upotrebu privremeno ograniči. Tako se tehničko pitanje pretvara u odluku o prihvatanju promene, kontroli troškova i ugovornim mogućnostima.

Metodološki oslonac je zvanična dokumentacija proizvođača Claude o razvoju evaluacionih testova, koja polazi od konkretnih kriterijuma uspeha i provere zadatka. To je tehnička smernica proizvođača, ne pravni propis niti potvrda da je njegov proizvod odgovarajući za određenu pravnu namenu.