DESAmedia ·

Trumpas atsakymas

Verslo procesų automatizavimas su AI labiausiai atsiperka ten, kur įvestis yra nestruktūruotas tekstas: sąskaitos PDF formatu, laiškai, ilgi dokumentai, netvarkingi duomenys. Kur taisyklę galima užrašyti iš anksto, įprastas kodas yra pigesnis, greitesnis ir nuspėjamas. Patikimiausias modelis abiem atvejais tas pats: AI paruošia pasiūlymą, sistema jį patikrina taisyklėmis, o žmogus patvirtina sprendimus, kurių klaida kainuotų brangiai.

Kada AI automatizacija verslui naudinga, o kada pakanka taisyklių

AI automatizacija verslui šiame straipsnyje reiškia didelius kalbos modelius (angl. large language models, LLM), kurie skaito tekstą ar vaizdą ir grąžina struktūruotą rezultatą: laukus, kategoriją, santrauką ar atsakymo juodraštį. Taisyklėmis pagrįsta automatizacija yra įprastas kodas: „jei siuntėjas yra X, perduoti į Y", „jei suma didesnė nei Z, reikalauti patvirtinimo".

Skirtumas praktinis. Taisyklė kiekvieną kartą duoda tą patį rezultatą ir jos klaidą galima rasti kode. Kalbos modelis susitvarko su formuluotėmis, kurių niekas nenumatė, bet kartais suklysta taip, kad klaida atrodo įtikinamai. Todėl pirmas klausimas prieš kiekvieną projektą: ar galime užrašyti taisyklę?

Užduotis Pakanka taisyklių Prasminga naudoti AI
Sąskaitos iš tiekėjų Duomenys gaunami struktūruotu formatu (XML, API) Gaunami PDF ir skenuoti dokumentai skirtingais maketais
Laiškų skirstymas Kategoriją lemia siuntėjas, tema ar forma Kategoriją lemia laisvai parašytas tekstas
Atsakymai klientams Standartiniai pranešimai apie būseną Klausimai laisva forma, atsakymas priklauso nuo konteksto
Duomenų tikrinimas Formatas, privalomi laukai, sumos Pavadinimų sutapatinimas, dublikatų paieška pagal prasmę
Ataskaitos Skaičiai ir grafikai iš duomenų bazės Ilgų tekstų ar pokalbių santraukos

Dažniausiai geriausias sprendimas yra mišrus. Didžiąją srauto dalį apdoroja taisyklės, o AI tenka tik tie atvejai, kurių taisyklės neatpažįsta.

Rinka juda šia kryptimi. Eurostat duomenimis, 2025 m. bent vieną DI technologiją naudojo 21,3 proc. Lietuvos įmonių, turinčių 10 ir daugiau darbuotojų, o ES vidurkis buvo 19,95 proc. Per metus Lietuvos rodiklis išaugo 12,5 procentinio punkto (2024 m. buvo 8,76 proc.). ES mastu dažniausiai naudota technologija buvo teksto analizė (11,75 proc. įmonių). Įmonės, kurios svarstė DI, bet jo nediegė, kaip pagrindines kliūtis nurodė kompetencijų trūkumą (70,89 proc.), neaiškias teisines pasekmes (52,52 proc.) ir duomenų apsaugos rūpesčius (48,83 proc.). Toliau aptariame visas tris.

1. Dokumentų ir sąskaitų nuskaitymas

Tipinis atvejis: buhalterija ar pirkimų skyrius gauna sąskaitas, važtaraščius ir sutartis PDF formatu arba nuotraukomis. Kalbos modelis perskaito dokumentą ir užpildo iš anksto apibrėžtus laukus: tiekėjas, įmonės kodas, data, eilutės, sumos, PVM.

Galimybės čia realios, bet ribotos. OpenAI savo struktūrizuotų atsakymų (angl. Structured Outputs) funkcijai nurodo, kad modelio atsakymas atitiks pateiktą JSON schemą, t. y. visi laukai bus savo vietose. Tačiau tas pats gamintojas atvirai rašo, kad funkcija neapsaugo nuo visų klaidų: modelis vis tiek gali suklysti pačiose reikšmėse. Kitaip tariant, struktūra garantuojama, bet reikšmių teisingumą tenka tikrinti atskirai.

Todėl po AI nuskaitymo rekomenduojame automatinius patikrinimus:

  • eilučių suma turi sutapti su bendra suma, o PVM turi atitikti tarifą;
  • tiekėjas sutapatinamas su esamu tiekėjų sąrašu pagal įmonės kodą, nes pavadinimai dažnai užrašomi skirtingai;
  • užsakymo numeris turi egzistuoti sistemoje;
  • neįprasta suma ar naujas tiekėjas siunčiami žmogui peržiūrėti.

Dokumentas, praėjęs visus patikrinimus, apdorojamas toliau automatiškai. Neatitikimai ir neaiškūs atvejai patenka į peržiūros eilę, kurioje darbuotojas mato originalą šalia nuskaitytų laukų. Duomenų perdavimas į apskaitos sistemą yra įprasta integracija, kurią aprašome sistemų integracijų ir automatizavimo puslapyje.

2. Laiškų klasifikavimas ir maršrutizavimas

Bendru adresu gaunami laiškai: užklausos, skundai, sąskaitos, darbo pasiūlymai, reklama. Kalbos modelis priskiria kategoriją, nustato skubumą, ištraukia užsakymo numerį ir nukreipia laišką atsakingam žmogui ar skyriui.

Pirmiausia verta išsemti taisykles. Sąskaitos nuo žinomų tiekėjų, automatiniai pranešimai ir formų užklausos atpažįstami be AI. Modeliui lieka laisva forma parašyti laiškai.

Svarbiausias projektavimo sprendimas yra kategorija „neaišku". Modelis, priverstas pasirinkti vieną iš penkių kategorijų, pasirinks, net jei nė viena netinka. Leidus atsakyti „neaišku", tokie laiškai patenka į bendrą eilę, o ne į netinkamą skyrių. Tikslumą verta išmatuoti prieš paleidimą: paimti kelis šimtus jau surūšiuotų laiškų, palyginti modelio sprendimus su žmonių sprendimais ir tik tada nuspręsti, kurias kategorijas galima skirstyti automatiškai.

3. Atsakymų juodraščiai klientų aptarnavime

Čia kalbos modelis parengia atsakymo juodraštį pagal kliento klausimą, užsakymo duomenis ir įmonės žinių bazę: taisykles, kainoraščius, ankstesnius atsakymus. Tokia architektūra vadinama RAG (angl. retrieval-augmented generation): sistema pirmiausia suranda susijusius dokumentus, o modelis atsakymą rašo remdamasis jais, ne vien savo bendromis žiniomis.

Kai juodraštį peržiūri ir išsiunčia darbuotojas, jis yra darbo įrankis, o atsakomybė už atsakymą lieka žmogui. Kai klientas bendrauja tiesiogiai su pokalbių robotu, taikomos kitos taisyklės. Pagal ES dirbtinio intelekto aktą (Reglamentas (ES) 2024/1689) sistemos, tiesiogiai sąveikaujančios su žmonėmis, turi būti sukurtos taip, kad žmogus būtų informuotas, jog bendrauja su DI sistema, nebent tai akivaizdu iš konteksto. Didžioji akto dalis taikoma nuo 2026 m. rugpjūčio 2 d.

Praktiškai pradėti rekomenduojame nuo juodraščių. Jie iš karto sutaupo laiko, o darbuotojų pataisymai parodo, kuriose temose modelis klysta. Tik tada galima spręsti, kuriuos klausimų tipus verta patikėti savarankiškam atsakymui. Jei reikia sistemos, kuri ne tik rašo, bet ir atlieka veiksmus, pavyzdžiui, patikrina užsakymo būseną ar sukuria grąžinimo užklausą, tai jau yra AI agentas. Apie tokių agentų ribas ir leidimus rašome AI agentų kūrimo puslapyje.

4. Ilgų tekstų ir pokalbių santraukos

Santraukos yra viena saugiausių AI panaudojimo sričių, nes žmogus rezultatą vis tiek skaito. Tipiniai atvejai: pirkimo dokumentų ar sutarčių apžvalga, susitikimų įrašų santraukos, kliento istorijos CRM sistemoje sutraukimas į kelias eilutes prieš skambutį.

Ribos dvi. Pirma, santrauka gali praleisti svarbią detalę, pavyzdžiui, baudos sąlygą sutartyje. Todėl santrauka turėtų nurodyti, iš kurios dokumento vietos paimtas kiekvienas teiginys, kad svarbius punktus būtų galima patikrinti originale. Antra, pokalbių įrašai ir kliento istorija yra asmens duomenys. Juos tvarkant galioja Bendrasis duomenų apsaugos reglamentas (BDAR): reikia teisinio pagrindo, o modelio tiekėjas tampa duomenų tvarkytoju. BDAR 28 straipsnis reikalauja rinktis tik tokius tvarkytojus, kurie užtikrina tinkamas technines ir organizacines priemones, ir sudaryti su jais sutartį.

Duomenų vieta taip pat valdoma. Pavyzdžiui, OpenAI nuo 2025 m. vasario siūlo API projektus su Europos duomenų rezidencija: tokiuose projektuose užklausos apdorojamos regione, nesaugant užklausų ir atsakymų. Gamintojas taip pat nurodo, kad pagal nutylėjimą API duomenys modeliams mokyti nenaudojami. Panašias galimybes siūlo ir kiti tiekėjai, tačiau sąlygas verta patikrinti konkrečioje sutartyje ir duomenų tvarkymo priede.

5. Duomenų tvarkymas prieš migraciją

Keičiant CRM ar verslo valdymo sistemą, seni duomenys retai būna tvarkingi: tas pats klientas įvestas tris kartus skirtingai, adresai viename lauke, produktų kategorijos keitėsi kelis kartus. Rankinis valymas užtrunka savaites.

Čia gerai veikia padalinta schema. Formato dalykus (telefono numerius, datas, įmonių kodus, el. pašto adresus) tvarko įprastas kodas: tai pigiau ir tiksliau. Kalbos modelis naudojamas ten, kur reikia suprasti prasmę: pasiūlyti, kurie įrašai yra dublikatai, išskaidyti laisvai įvestą adresą į laukus, priskirti seną kategoriją naujai struktūrai. Visi pasiūlymai pateikiami peržiūrai paketais, o patvirtinti pakeitimai įrašomi su nuoroda į pradinį įrašą, kad bet kurį sprendimą būtų galima atšaukti.

Toks darbas paprastai yra dalis platesnio projekto, pavyzdžiui, CRM sistemos kūrimo, kai seni duomenys perkeliami į naują struktūrą.

Kodėl žmogaus patvirtinimo žingsnis būtinas

Pirmoji priežastis yra teisinė. BDAR 22 straipsnis suteikia žmogui teisę, kad jam nebūtų taikomas tik automatizuotu duomenų tvarkymu grindžiamas sprendimas, dėl kurio jam kyla teisinės pasekmės arba kuris panašiu būdu daro didelį poveikį. Kai toks sprendimas grindžiamas sutartimi ar aiškiu sutikimu, duomenų valdytojas turi užtikrinti bent teisę reikalauti žmogaus įsikišimo, pareikšti savo nuomonę ir ginčyti sprendimą.

DI aktas kai kurias sritis priskiria didelės rizikos kategorijai. Tarp jų yra DI sistemos, naudojamos darbuotojų atrankai, pavyzdžiui, darbo prašymams filtruoti ir kandidatams vertinti. Tokioms sistemoms taikomi papildomi reikalavimai, įskaitant žmogaus priežiūrą. 2026 m. liepos 27 d. įsigaliojęs Reglamentas (ES) 2026/1744 šių reikalavimų taikymą atidėjo: savarankiškoms didelės rizikos sistemoms iki 2027 m. gruodžio 2 d., o į reguliuojamus gaminius įdiegtoms iki 2028 m. rugpjūčio 2 d. Tas pats reglamentas pakeitė DI raštingumo nuostatą: tiekėjai ir diegėjai turi imtis priemonių, kurios padeda ugdyti darbuotojų DI raštingumą.

Antroji priežastis yra praktinė. Kalbos modelio klaida dažnai atrodo kaip teisingas atsakymas: tvarkinga suma, įtikinamas sakinys, logiška kategorija. Taisyklių klaidos dažniausiai matomos iš karto, pavyzdžiui, kaip tuščias laukas ar klaidos pranešimas, o modelio klaidą tenka ieškoti. Žmogaus patvirtinimas kritiniuose taškuose yra paprasčiausias būdas tokias klaidas sustabdyti, kol jos nepasiekė kliento ar apskaitos.

Patvirtinimas nebūtinai reiškia, kad žmogus peržiūri viską. Dažniausiai pakanka jam parodyti tai, kas neatitiko patikrinimų, ir periodiškai atrinktus automatiškai apdorotus įrašus kokybei stebėti.

Kiek kainuoja klaida ir kaip ją riboti

Automatizavimo lygį rekomenduojame rinktis pagal tai, kiek kainuotų klaida. Neteisingai priskirtas laiškas kainuoja kelias minutes. Neteisinga suma apskaitoje kainuoja taisymą ir galimus mokestinius klausimus. Neteisingas atsakymas klientui apie sutarties sąlygas gali kainuoti ginčą.

Praktinės priemonės klaidoms riboti:

  • Automatinis vykdymas tik po patikrinimų. Automatiškai vykdomi tik veiksmai, kurių rezultatas praėjo patikrinimus taisyklėmis. Visa kita patenka į peržiūros eilę.
  • Mažiausi leidimai. AI komponentas gauna tik tuos duomenis ir veiksmus, kurių reikia užduočiai. Santraukas rašanti sistema neturi galėti keisti užsakymų.
  • Veiksmų žurnalas. Kiekvienas AI pasiūlymas, patikrinimo rezultatas ir žmogaus sprendimas įrašomas, kad klaidą būtų galima atsekti ir pataisyti.
  • Tikslumo matavimas. Prieš paleidimą ir periodiškai po jo AI rezultatai lyginami su žmonių sprendimais. Pakeitus modelio versiją, matavimas kartojamas.
  • Atsarginis kelias. Jei modelio tiekėjo paslauga neveikia, procesas grįžta į rankinę eilę ir nesustoja.

Nuo pradžios verta įvertinti ir veikimo kaštus: kiekviena užklausa modeliui kainuoja pagal apdorotą teksto kiekį, todėl dideliems srautams pigiau pirma atfiltruoti tai, ką tvarko taisyklės.

Ką daryti toliau

Jei norite įvertinti, kuriuos jūsų procesus verta automatizuoti taisyklėmis, o kuriems tinka AI, pradėkite nuo vieno proceso aprašymo: kas ateina į jį, kas išeina ir kiek kainuoja klaida. Kaip tokius projektus sudarome ir kur dedame patikrinimus, aprašėme sistemų integracijų ir automatizavimo puslapyje.

Šaltiniai