Obdelava dokumentov z AI: klasifikacija, ekstrakcija, preverjanje

Kaj je obdelava dokumentov z AI in zakaj je pomembna#

Obdelava dokumentov z AI je proces, pri katerem sistem samodejno prepozna vrsto dokumenta, iz njega izlušči relevantne podatke in preveri, ali so ti podatki pravilni in popolni, preden vstopijo v poslovni sistem. Sestavljajo ga trije koraki: klasifikacija, ekstrakcija in preverjanje. V praksi to pomeni, da se pogodbe, računi, dobavnice, vloge, obrazci ali korespondenca ne prepisujejo ročno, temveč jih sistem razvrsti po vrsti, prebere ključne podatke in jih pred vnosom v ERP, CRM ali dokumentni sistem preveri glede na pravila, ki jih določi naročnik.

Za podjetja z več kot milijon evrov prihodkov dokumenti praviloma ne krožijo po enem oddelku, temveč gredo skozi nabavo, računovodstvo, pravno službo, kadrovsko službo ali proizvodnjo. Vsak oddelek dokument obravnava po svojih pravilih in ga vnaša v svoj sistem. Kadar ta pot poteka ročno, nastajajo zamude, podvajanje vnosa in tveganje napak pri prepisovanju. AI obdelava dokumentov ne nadomesti presoje ljudi, temveč prevzame ponavljajoče se branje in vnašanje, ljudje pa se posvetijo preverjanju izjem in odločanju o vsebini.

Epix pri tovrstnih projektih razvija programske rešitve, ki nad internimi podatki, dokumentacijo in poslovnimi procesi uporabljajo umetno inteligenco – med drugim v projektu Kwizmo, kjer smo razvili rešitev z AI agenti, semantičnim iskanjem (RAG), obdelavo dokumentov in integracijami v obstoječe sisteme. Tovrstne projekte gradimo znotraj Epixa in naše specialistične partnerske mreže, kjer po potrebi sestavimo ekipo AI in podatkovnih strokovnjakov, arhitektov integracij ter poslovnih analitikov, prilagojeno obsegu posameznega projekta.

V nadaljevanju pojasnjujemo, kaj mora naročnik določiti pred začetkom projekta obdelave dokumentov z AI: kako se dokumenti razvrščajo, kateri podatki se iz njih izluščijo, kako se preverjajo pred vnosom v poslovne sisteme, kako se rešitev poveže z obstoječim ERP, CRM ali dokumentnim sistemom ter kako je urejena varnost podatkov, testiranje in podpora po uvedbi.

Klasifikacija dokumentov – kaj je treba določiti#

Klasifikacija je prvi korak obdelave dokumentov z AI in pomeni, da sistem dokument najprej razvrsti v ustrezno kategorijo, še preden iz njega karkoli prebere. Brez jasno določenih kategorij sistem ne ve, po katerih pravilih naj podatke pozneje izlušči in preveri. Zato je prva naloga pri vsakem projektu popis vrst dokumentov, ki v podjetje prihajajo ali iz njega izhajajo, in določitev, po katerih merilih se med seboj razlikujejo – po vsebini, izvoru, obliki ali namenu uporabe v nadaljnjem procesu.

Način, kako je klasifikacija zastavljena, vpliva na to, kako natančno bo sistem pozneje ločil med podobnimi dokumenti, na primer med različnimi tipi pogodb ali med računom in dobropisom. Če so kategorije preveč splošne, se poveča delež dokumentov, ki jih mora pregledati človek. Če so preveč podrobne, se poveča število izjem, ki jih je treba ročno urejati. Pravo razmerje se določi glede na to, kako se bodo podatki iz posamezne kategorije pozneje uporabili v poslovnem procesu.

Popis kategorij in pravil ni enkratno opravilo. Ko se v poslovanje vključijo novi tipi pogodb, obrazcev ali dobaviteljev, je treba klasifikacijska pravila dopolniti, sicer sistem nove dokumente uvršča napačno ali jih označuje kot izjeme. Zato v projekt klasifikacije vključimo mehanizem za dodajanje novih kategorij in za spremljanje deleža dokumentov, ki jih sistem ne uspe zanesljivo razvrstiti, saj ta delež pokaže, kje je treba pravila dopolniti ali dodatno usposobiti model.

Za določitev kategorij in pravil je odgovoren naročnik, saj pozna vsebino in namen dokumentov v svojem poslovanju, medtem ko izvajalec poskrbi, da se ta pravila prevedejo v delujoč sistem. Pri večjih projektih to uskladimo s projektnim vodjo, ki določi, kdo na strani naročnika potrjuje kategorije in kdo je odgovoren za spremembe pravil po uvedbi rešitve v produkcijo.

• vrste dokumentov, ki jih sistem obravnava, in njihovo pričakovano razmerje po obsegu
• kanale, po katerih dokumenti prihajajo (e-pošta, skeniranje, portal, sistemski prenos)
• jezike, v katerih so dokumenti napisani
• stopnjo standardiziranosti oblike (enotni obrazci ali poljubne priloge)
• pravila za mejne primere, ki jih sistem ne zna zanesljivo razvrstiti
• oddelke ali sisteme, h katerim se posamezna kategorija dokumentov usmeri naprej

Ekstrakcija podatkov iz dokumentov#

Ekstrakcija je korak, pri katerem sistem iz že razvrščenega dokumenta izlušči konkretne podatke – zneske, datume, davčne številke, postavke, imena strank ali šifre izdelkov – in jih zapiše v strukturirano obliko, primerno za nadaljnjo obdelavo. Pri tem je odvisno, ali gre za standardizirane obrazce z vedno enako postavitvijo polj ali za poljubno oblikovane dokumente, kot so pogodbe ali dopisi, kjer je treba podatek najti glede na pomen besedila, ne glede na položaj na strani.

Katera polja je treba izluščiti in v kakšni natančnosti, določa to, kam bodo podatki pozneje šli. Če se ekstrahirani podatki vnašajo neposredno v ERP ali CRM, morajo ustrezati obstoječim poljem in formatom teh sistemov, sicer pride do napak pri uvozu ali podvajanja zapisov. Zato pred začetkom ekstrakcije skupaj z naročnikom pripravimo seznam ciljnih polj, njihov format in sistem, v katerega se podatek vnese, ter določimo, kaj se zgodi, če polja na dokumentu ni ali je nečitljivo.

Sistem ob vsakem izluščenem podatku izračuna tudi, kako zanesljiv je ta rezultat. Kadar zanesljivost pade pod dogovorjeni prag, se dokument ne vnese samodejno, temveč se uvrsti v vrsto za ročni pregled. Kje postaviti ta prag, je odločitev naročnika in je odvisna od tega, kako drago bi bilo popravljati napačen vnos v primerjavi s časom, ki ga zaposleni porabi za ročni pregled. Pri finančnih in pogodbenih podatkih je prag praviloma postavljen strože kot pri splošnih evidenčnih podatkih.

Ekstrakcijo gradimo z rešitvami, ki vključujejo obdelavo naravnega jezika in prepoznavanje besedila iz skeniranih dokumentov, znotraj Epixa in naše specialistične partnerske mreže, kjer imamo dostop do kadra z izkušnjami na področjih, kot so bančništvo, zavarovalništvo, javni sektor in zdravstvo – panog, kjer je obseg dokumentacije, ki jo je treba obdelati, običajno največji.

• seznam polj, ki jih je treba izluščiti iz posameznega tipa dokumenta
• pričakovan format vsakega polja (na primer datum, znesek, šifra)
• ciljni sistem, v katerega se podatek vnese (ERP, CRM, dokumentni sistem)
• prag zaupanja, pod katerim sistem podatek označi za ročni pregled
• način obravnave manjkajočih ali nečitljivih podatkov
• povezavo med izluščenimi podatki in obstoječimi zapisi (na primer stranko ali naročilom)

Preverjanje in validacija podatkov#

Preverjanje je zadnji korak, preden podatki iz dokumenta postanejo del poslovnega zapisa. Sistem izluščene podatke primerja s pravili, ki jih določi naročnik – na primer, ali se znesek na računu ujema z zneskom v naročilu, ali je davčna številka veljavne oblike, ali datum ne leži v prihodnosti in ali je dokument že bil obdelan. Šele ko podatek prestane ta preverjanja, se samodejno zapiše v ERP, CRM ali dokumentni sistem, sicer se dokument vrne v pregled.

Katera pravila preverjanja veljajo, je odvisno od tega, kako kritičen je podatek za nadaljnje poslovanje. Pri finančnih dokumentih, kot so računi ali plačilni nalogi, so pravila praviloma strožja in vključujejo navzkrižno preverjanje z drugimi zapisi, medtem ko je pri interni korespondenci dovolj osnovno preverjanje oblike. Naročnik skupaj z izvajalcem določi, katera pravila so obvezna, katera zgolj opozorilna in kdo je odgovoren za dokončno potrditev, kadar sistem podatka ne more samodejno potrditi.

AI preverjanje ne pomeni, da sistem sam odloča o vsebini dokumenta, temveč da človeku pripravi odločitev v obliki jasno označenih odstopanj. Taka rešitev deluje kot podpora pri odločanju: zaposlenemu pokaže, kateri podatek odstopa od pričakovanega in zakaj, namesto da bi moral vsak dokument v celoti pregledati sam. Odgovornost za končno potrditev ostane pri zaposlenem oziroma pri postopku, ki ga za to določi naročnik.

Za dokumente, ki so pomembni z vidika revizije ali skladnosti, je treba določiti tudi, kako se beleži, kdo je podatek preveril, spremenil ali potrdil, in kako dolgo se ta sled hrani. To je še posebej pomembno v javnem sektorju in reguliranih panogah, kjer mora biti mogoče kadar koli izslediti, kako je posamezen podatek prišel v sistem in kdo je zanj odgovoren.

Povezava z obstoječimi sistemi: ERP, CRM, DMS, ECM#

Obdelava dokumentov z AI ni samostojna aplikacija, temveč se mora povezati z že delujočimi sistemi, v katerih podjetje vodi svoje poslovanje. Pred začetkom projekta je treba določiti, s katerimi sistemi se mora rešitev povezati – najpogosteje z ERP za finance in nabavo, s CRM za podatke o strankah ter z dokumentnimi (DMS) ali arhivskimi (ECM) sistemi, kjer se dokumenti trajno hranijo. Povezave gradimo prek API-jev, kar pomeni, da mora biti znano, kateri podatki in v kakšni obliki so prek teh vmesnikov dostopni.

Kakovost in obseg obstoječih API-jev neposredno vplivata na to, koliko dela zahteva integracija. Če ciljni sistem že ponuja API za vnos zapisov, se ekstrahirani podatki lahko vnašajo skoraj neposredno. Če takega vmesnika ni ali je omejen, je treba predvideti dodaten korak, ki podatke pripravi v obliki, primerni za uvoz, ali pa se z izvajalcem ciljnega sistema uskladiti, kako naj poteka izmenjava. To je treba razjasniti pred oceno obsega projekta, ne med njegovo izvedbo.

Pri podjetjih, ki že imajo delno zgrajeno rešitev za obdelavo dokumentov ali nedokončan projekt integracije, lahko obstoječ sistem prevzamemo po pregledu izvorne kode, arhitekture, infrastrukture in podatkov. Na podlagi tega pregleda ocenimo, kateri deli se lahko obdržijo, kateri je treba prilagoditi in kateri je smiselno zgraditi na novo, namesto da bi projekt začeli od začetka brez razloga.

Izvorna koda in podatki so v vsakem primeru last naročnika. Dokumentacija, dostopi in gesla so del primopredaje ob zaključku projekta ali posameznega sklopa, tako da naročnik ni odvisen od enega izvajalca za nadaljnje spremembe ali morebiten prehod k drugemu ponudniku podpore.

Varnost podatkov in skladnost#

Dokumenti, ki jih obdeluje AI sistem, pogosto vsebujejo osebne, finančne ali poslovno občutljive podatke, zato je varnost vprašanje, ki ga je treba urediti pred uvedbo, ne po njej. To pomeni določiti, kdo ima dostop do posameznih vrst dokumentov, kako so podatki zavarovani med prenosom in shranjevanjem ter kako se sistem odziva na poskus nepooblaščenega dostopa. Zahteve so strožje v javnem sektorju in reguliranih panogah, kjer morajo biti izpolnjene tudi zahteve glede varstva osebnih podatkov (GDPR).

Razvojno, testno in produkcijsko okolje pri projektih obdelave dokumentov ločimo, v testnem okolju pa ne uporabljamo pravih osebnih podatkov, temveč nadomestne testne zapise. Tako preverjanje delovanja klasifikacije, ekstrakcije in validacije ne izpostavlja resničnih dokumentov strank ali zaposlenih nepotrebnemu tveganju, hkrati pa je mogoče sistem temeljito preizkusiti, preden začne obdelovati prave dokumente.

Za projekte, kjer je varnost ključna zahteva, znotraj Epixa in naše specialistične partnerske mreže sestavimo ekipo z znanjem s področja varnostne arhitekture, upravljanja identitet in dostopov (IAM) ter odkrivanja ranljivosti, tako da je varnost vgrajena v rešitev od začetka, ne dodana naknadno. To je še posebej pomembno pri dokumentih iz bančništva, zavarovalništva ali javnega sektorja, kjer je nadzor nad dostopom del zakonske obveznosti, ne le dobre prakse.

• pravice dostopa do posameznih vrst dokumentov glede na vlogo zaposlenega
• način zaščite podatkov med prenosom in shranjevanjem
• ločitev razvojnega, testnega in produkcijskega okolja
• beleženje sledi, kdo je dokument obdelal, preveril ali spremenil
• postopek odziva, če pride do poskusa nepooblaščenega dostopa
• uskladitev z zahtevami varstva osebnih podatkov (GDPR)

Testiranje in zagotavljanje kakovosti#

Preden gre rešitev za obdelavo dokumentov v produkcijo, mora skozi testiranje, ki preveri, ali klasifikacija, ekstrakcija in validacija delujejo pravilno na realističnem, a ne resničnem naboru dokumentov. Testiranje vključuje pripravo testnih scenarijev za tipične in mejne primere dokumentov, ročno preverjanje rezultatov ter avtomatizirano testiranje, ki se ponovi ob vsaki spremembi sistema, da se preveri, ali sprememba ni pokvarila že delujoče funkcionalnosti.

Obseg testiranja se določi glede na to, kako kritični so podatki, ki jih sistem obdeluje. Pri dokumentih, ki vplivajo na plačila, pogodbene obveznosti ali zakonske roke, je smiselno vključiti tudi neodvisen QA, ločen od razvojne ekipe, ki rezultate preveri z vidika naročnika, ne izvajalca. Pri manj kritičnih dokumentih zadostuje ožji nabor testnih scenarijev in redno spremljanje deleža pravilno obdelanih dokumentov po uvedbi.

Merila prevzemnega testiranja se dogovorijo pred začetkom razvoja, ne šele ob zaključku projekta, saj le tako naročnik vnaprej ve, po čem bo presojal, ali je rešitev pripravljena za produkcijo. To vključuje dogovor o tem, kateri delež pravilno obdelanih dokumentov je sprejemljiv in kako se obravnavajo dokumenti, ki jih sistem ne zna zanesljivo obdelati.

• pripravo testnih scenarijev za tipične in mejne primere dokumentov
• ročno preverjanje rezultatov klasifikacije, ekstrakcije in validacije
• avtomatizirano testiranje, ki se ponovi ob vsaki spremembi sistema
• testiranje povezav z ERP, CRM ali dokumentnim sistemom prek API-jev
• regresijsko testiranje, da sprememba ne pokvari obstoječe funkcionalnosti
• prevzemno testiranje po vnaprej dogovorjenih merilih pred prevzemom v produkcijo

Vzdrževanje, podpora in odzivni časi po uvedbi#

Po uvedbi rešitve za obdelavo dokumentov se pojavljajo nove vrste dokumentov, spreminjajo se predloge obrazcev in včasih pride do napak, ki jih med testiranjem ni bilo mogoče predvideti. Zato je treba pred zaključkom projekta določiti, kdo skrbi za nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema, in po kakšnih pravilih se prijave obravnavajo. To se uredi s pogodbo o podpori, ki opredeljuje razrede prijav in način njihove obravnave.

Prijave po uvedbi razvrstimo v razrede glede na to, kako vplivajo na poslovanje. Izpad pomeni, da sistem ali ključni del ne deluje, in ima najvišjo prednost. Motnja pomeni, da sistem deluje, posamezna funkcija pa ne. Napaka je manjša težava brez vpliva na poslovanje, zahteva pa je sprememba ali nadgradnja, ki jo je treba oceniti in uskladiti. Za vsak razred se odzivni čas dogovori v pogodbi glede na kritičnost sistema za naročnika.

Kateri razred SLA podjetje potrebuje, je odvisno od tega, kako odvisno je vsakodnevno poslovanje od pravilnega delovanja obdelave dokumentov. Pri procesih, kjer zamuda pomeni zamujen zakonski rok ali ustavljeno proizvodnjo, je smiselno imeti dogovorjene stroge odzivne čase za izpade. Pri manj kritičnih procesih zadostuje osnovna podpora z obravnavo napak v rednih ciklih nadgradenj.

• Razred 1 – izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 – motnja: sistem deluje, posamezna funkcija ne, obravnava po dogovorjeni prednosti
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Razred 4 – zahteva: sprememba ali nadgradnja, obseg se oceni in termin uskladi

Kako poteka sodelovanje z izvajalcem#

Projekt obdelave dokumentov z AI lahko naročnik prepusti izvajalcu v celoti ali pa izvajalca vključi le za posamezen sklop, na primer samo za ekstrakcijo podatkov, medtem ko klasifikacijo in vnos v ERP že ima urejena interno. Katera možnost je smiselna, je odvisno od tega, koliko je od te odločitve odvisnih obstoječih sistemov in koliko internega znanja o teh sistemih podjetje že ima. To je treba razjasniti na začetku, saj vpliva na to, kako se projekt razdeli na sklope.

Pri večjih projektih, ki vključujejo več oddelkov in več sistemov, določimo projektnega vodjo, odgovornosti posameznih ekip, roke za posamezne sklope ter način komunikacije in poročanja med izvajalcem in naročnikom. To je pomembno predvsem takrat, kadar imajo posamezni oddelki – na primer nabava, računovodstvo in pravna služba – različna pričakovanja do iste rešitve, ki jih je treba uskladiti, preden se začne razvoj.

Znotraj Epixa in naše specialistične partnerske mreže za tovrstne projekte sestavimo ekipo glede na potrebe posameznega projekta – od AI in podatkovnih strokovnjakov, poslovnih analitikov in arhitektov integracij do QA inženirjev, ki skrbijo za testiranje pred uvedbo. Epix posluje od leta 2020, v Sloveniji, Srbiji in ZDA, doslej pa smo skupaj s partnersko mrežo izvedli več kot 950 projektov na različnih področjih, med njimi tudi projekte, ki vključujejo AI obdelavo podatkov in dokumentov.

Kaj vpliva na obseg in ceno projekta#

Cene za projekte obdelave dokumentov z AI se razlikujejo glede na obseg dela, zato je ne navajamo vnaprej brez pregleda zahtev. Namesto tega se pri vsakem projektu najprej določi, kaj obseg dela dejansko vključuje: koliko vrst dokumentov je treba obravnavati, s koliko obstoječimi sistemi se mora rešitev povezati, kakšne so zahteve glede varnosti in koliko podatkov je treba morebiti prenesti iz obstoječega, delno zgrajenega sistema.

Pred oceno obsega praviloma predlagamo krajšo analizo, ki celoten projekt razčleni na sklope, tako da je vsak sklop mogoče oceniti in izvajati ločeno – na primer ločeno klasifikacijo, ločeno integracijo z ERP in ločeno postavitev pravil za preverjanje. Tak pristop naročniku omogoča, da se odloči, kateri sklop izvede najprej in kateri morda kasneje, namesto da bi moral vnaprej potrditi celoten projekt naenkrat.

Šele na podlagi te razčlenitve je mogoče oceniti, koliko dela posamezen sklop zahteva in v kakšnem vrstnem redu jih izvesti, ne da bi naročnik prevzel tveganje, da se obseg med izvedbo bistveno spremeni brez jasnega razloga.

• obseg funkcionalnosti in število uporabniških vlog v rešitvi
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• količina in stanje podatkov, ki jih je treba prenesti
• zahteve glede varnosti, revizijske sledi in skladnosti
• obseg testiranja in ali je potreben neodvisen QA
• raven podpore po uvedbi in dogovorjeni odzivni časi