RPA, darbo eigų automatizavimas ir dirbtinio intelekto agentai: ką reiškia kiekvienas terminas
Trys žodžiai, kuriuos pasiūlymuose vartoja kaip tris kainų lygius vienai paslaugai, yra trys skirtingi mechanizmai. Kuo kiekvienas skiriasi, ką gauna pirkėjas ir kodėl skirtumas dabar yra ir teisinis.
Trys žodžiai, kuriuos pasiūlymuose vartoja kaip tris kainų lygius vienai paslaugai, yra trys skirtingi mechanizmai. Kuo kiekvienas skiriasi, ką gauna pirkėjas ir kodėl skirtumas dabar yra ir teisinis.
Trys žodžiai pasiūlyme neretai atsiranda taip, tarsi tai būtų trys kainų lygiai vienai ir tai pačiai paslaugai: robotizuotas procesų automatizavimas, darbo eigų automatizavimas ir dirbtinio intelekto agentai. Pirkėjui susidaro įspūdis, kad reikia rinktis vieną iš trijų produktų, ir paprastai pasirenkamas brangiausias, nes skamba moderniau.
Iš tikrųjų tai trys skirtingi mechanizmai, kurie sprendžia skirtingas problemas, ir didžioji dalis tikrų užduočių reikalauja būtent to, kuris kainuoja mažiausiai. Šis straipsnis nelygina įrankių ir nerekomenduoja platformos; jis paaiškina, kuo kiekvienas mechanizmas techniškai skiriasi, ką pirkėjas kiekvienu atveju gauna ir kodėl būtent šis skirtumas per pastaruosius dvejus metus tapo ir teisiniu klausimu.
Trys mechanizmai, kurie atsako į tris skirtingus klausimus
Paprasčiausias būdas juos laikyti atskirai — paklausti, kaip kiekvienas žino, ką jam daryti. Robotizuotas procesų automatizavimas kartoja veiksmus, kuriuos žmogus jam parodė; darbo eigų automatizavimas seka keliu, kurį kažkas nupiešė; dirbtinio intelekto agentas kelią nustato pats, darydamas išvadą iš tikslo, kuris jam buvo duotas. Iš šio vieno skirtumo išplaukia beveik viskas kita, įskaitant kainą, trapumą ir tai, kas nutinka, kai situacija netikėta. Mechanizmas, kuris kartoja, netikėtoje situacijoje sustoja; mechanizmas, kuris seka nupieštu keliu, nueina klaidų atšaka, jei tokia numatyta; mechanizmas, kuris daro išvadą, sugalvoja ką nors naujo, ir būtent todėl jam reikia priežiūros, kurios kitiems dviem nereikia.
Verta tai išbandyti su viena konkrečia užduotimi, kuri beveik kiekvienoje įmonėje atrodo taip pat: iš pašto atėjusią sąskaitą reikia įtraukti į apskaitos sistemą. Robotizuotas procesų automatizavimas šį darbą spręstų atidarydamas pašto programą, atsisiųsdamas priedą, atidarydamas apskaitos langą ir užpildydamas laukus būtent ta seka, kuria tai darytų darbuotojas. Darbo eiga tai spręstų gaudama dokumentą per sąsają ir iškviesdama apskaitos sistemos sąsają su paruoštais laukais, visai neatidarydama nė vieno lango. Agentas tai spręstų gaudamas užduotį „įtraukite šią sąskaitą į apskaitą“ ir pats spręsdamas, kuriuos įrankius jam iškviesti ir ką daryti, jei ko nors trūksta.
Visi trys variantai šią užduotį gali atlikti, ir būtent tai klaidina: skirtumas pasirodo ne tada, kai viskas tvarkoje, o tada, kai tiekėjas pakeičia sąskaitos formą, kai sistemoje atsiranda naujas privalomas laukas arba kai ta pati prekė pavadinta dvejopai, ir būtent šie atvejai sudaro didžiąją dalį tikro darbo.
Robotizuotas procesų automatizavimas kartoja veiksmus ekrane
Robotizuotas procesų automatizavimas, kasdien vadinamas angliška santrumpa RPA, yra programinis robotas, kuris veikia būtent tose pačiose sąsajose, kuriose dirba žmogus: atidaro langą, spusteli, įklijuoja lauką, paspaudžia išsaugojimą. Sistemos, su kuriomis jis dirba, lieka visiškai nepakitusios, ir būtent tai yra ir jo pagrindinis pranašumas, ir pagrindinis silpnumas. Pranašumas tas, kad RPA susidoroja su programomis, kurios neturi jokios sąsajos duomenims keistis ir kurių niekas nebeperprojektuos, todėl tai dažnai vienintelis kelias prie senų apskaitos ar šakinių sistemų. Silpnumas tas, kad robotas mato ekraną, o ne duomenis, todėl bet koks pakeitimas ekrane — perkeltas mygtukas, naujas laukas, kita atnaujinimo versija — sustabdo darbą, ir priežiūra tampa nuolatine sąnauda, o ne vienkartine.
Pirkėjas čia gauna roboto licenciją, jo vykdymo aplinką ir valdymo įrankį, proceso aprašą ir žurnalą su atliktais veiksmais. Verta žinoti, kad pačioje srityje šis pavadinimas laikomas nevykusiu: tai, ką RPA automatizuoja, paprastai yra atskira užduotis, ne visas procesas, ir būtent šis neatitikimas tarp pavadinimo ir turinio sukuria dalį pirkėjų lūkesčių, kurie vėliau neišsipildo.
Dar vienas požymis, kuris RPA projektuose neretai nustebina, yra tas, kad robotas dirba su tuo pačiu prieigos lygiu, kokį turi žmogus, kurio veiksmus jis kartoja. Tai reiškia, kad robotui reikia savo naudotojo kiekvienoje sistemoje, kad šio naudotojo teisės turi būti apgalvotos taip pat kaip bet kurio kito, ir kad roboto veiksmai sistemos žurnale atrodo kaip žmogaus veiksmai, jei tik jis neturi atskiros paskyros. Įmonėse, kuriose apie tai nepagalvota, vėliau sunku atsakyti į paprastą klausimą, kas konkretų įrašą padarė.
Darbo eigų automatizavimas jungia sistemas, o ne ekranus
Darbo eigų automatizavimas dirba vienu sluoksniu giliau: jis kalba ne su ekranu, o su pačiomis sistemomis, naudodamas jų programinės įrangos sąsajas. Darbo eiga yra iš anksto nupieštas žingsnių grafas — įvykis paleidžia grandinę, grandinė iškviečia veiksmus kitose sistemose, ir tarp jų gali būti ir žingsnis, kuriame žmogus ką nors patvirtina. Kadangi duomenų mainai vyksta per sąsają, o ne per vaizdą, sistemos išvaizdos pakeitimai šio mechanizmo neveikia, ir tai pagrindinė priežastis, kodėl ten, kur sąsaja prieinama, tai beveik visada atsparesnis ir pigiau prižiūrimas pasirinkimas nei ekrano kartojimas. Trūkumas akivaizdus: jei sistema sąsajos neturi arba ji neprieinama Jūsų licencijos lygiu, šis kelias paprasčiausiai neegzistuoja.
Pirkėjas čia gauna pačią darbo eigą, prieigos duomenis, vykdymo žurnalą ir klaidų atšaką, ir būtent pastarasis yra tai, pagal ką verta vertinti pasiūlymą, nes darbo eiga be klaidų apdorojimo veikia tik tol, kol viskas tvarkoje. Lietuvių kalboje šiam mechanizmui yra savas žodis: darbo eiga yra nusistovėjęs terminas, todėl angliško žodžio skliaustuose čia nereikia.
Žodis, kuris čia praverčia ir kurį verta vartoti tiksliai, yra programinis robotas: tai programa, kuri imituoja žmogaus veiksmus sąsajoje, ir tai nėra joks fizinis robotas. Šis skirtumas lietuvių kalboje svarbesnis nei anglų, nes žodis „robotas“ kasdienėje kalboje reiškia įrenginį, ir būtent iš šio nesusipratimo kyla dalis klausimų apie tai, ką robotas „mato“ ir ką jis „supranta“, nors nieko jis nesupranta: kartoja tai, kas jam buvo parodyta.
Dirbtinio intelekto agentas kelią nustato pats
Agentas nuo abiejų ankstesnių skiriasi tuo, kad jam neduodamas kelias, o tikslas, ir kelią jis pasirenka pats, iškviesdamas įrankius, kurie jam prieinami — paiešką, duomenų bazę, sistemos sąsają, kitą modelį. Būtent darbas su įrankiais yra tas požymis, kuris agentą skiria nuo pokalbių roboto: pokalbių robotas atsako, agentas daro. Iš to išplaukia, kad agentas susidoroja su užduotimis, kuriose žingsnių seka iš anksto nežinoma, ir kartu tai vienintelis iš trijų mechanizmų, kurio rezultatas nėra visiškai nuspėjamas. Du identiški paleidimai gali pasirinkti skirtingus kelius, ir tai reiškia, kad reikia ir priežiūros, ir aiškiai nustatytų ribų tam, ką agentas gali daryti pats ir kur jam reikia sustoti ir klausti žmogaus.
Praktiniame darbe tai neretai reiškia, kad agentas yra tinkamas mechanizmas ten, kur įvesties duomenys nestruktūrizuoti ir įvairūs, bet netinkamas ten, kur užduotis griežtai nustatyta ir kartojasi šimtus kartų per dieną. Antruoju atveju darbo eiga ir pigesnė, ir saugesnė, o agento naudojimas ten yra pinigų leidimas už nenuspėjamumą, kurio niekam nereikėjo.
Agento atveju pirkėjas gauna ką kita nei abiem kitais atvejais, ir pasiūlymuose tai neretai apskritai neaprašyta. Be paties agento reikia įrankių, kuriuos jis gali iškviesti, ribų tam, ką jis gali daryti be patvirtinimo, žurnalo su tuo, ką jis kiekvienu paleidimu padarė, ir būdo jį sustabdyti. Pasiūlymas, kuriame yra tik modelis ir užklausa, aprašo demonstraciją, ne darbo įrankį.
Yra ir vienas sąnaudų skirtumas, kurio projektų planuose neretai pritrūksta: darbo eigos vykdymas kainuoja beveik nieko, nes tai keli iškvietimai, o RPA sąnaudos daugiausia yra licencija ir priežiūra. Kiekvienas agento paleidimas savo ruožtu kainuoja pagal modelio naudojimą, ir ši sąnauda auga kartu su apimtimi, todėl mechanizmas, kuris bandyme atrodė pigus, šimtais paleidimų per dieną gali pasirodyti brangiausias iš trijų.
Kur baigiasi automatizavimas ir prasideda dirbtinis intelektas
Ši riba pastaraisiais metais tapo teisiniu klausimu, nes Europos Sąjungos dirbtinio intelekto reglamentas savo pareigas sieja būtent su dirbtinio intelekto sistemos apibrėžtimi. Reglamento 3 straipsnio 1 punktas ją apibūdina kaip sistemą, kuri daro išvadą, kaip iš gautos įvesties generuoti išvedinį — predikciją, turinį, rekomendaciją ar sprendimą, ir lygiai tiek pat svarbu tai, kas lieka už ribos. Reglamento konstatuojamosiose dalyse tiesiogiai pasakyta, kad sistemos, kurios veikia tik pagal žmonių nustatytas taisykles, kad automatiškai vykdytų operacijas, šios apibrėžties neatitinka, o Europos Komisijos gairės tai kartoja dar konkrečiau, įvardydamos gebėjimą daryti išvadas kaip nepakeičiamą savybę ir iš anksto nustatytų instrukcijų vykdymą kaip tokį, kuris į apibrėžtį neįeina.
Tą pačią ribą lietuviškai nubrėžia ir pats reglamento tekstas: sistemos, grindžiamos tik fizinių asmenų nustatytomis taisyklėmis, kad automatiškai vykdytų operacijas, dirbtinio intelekto sistemos apibrėžties neatitinka. Tai paties reglamento formuluotė, ne atskiras nacionalinis įstatymas, tačiau tai aiškiausia lietuviška šio skirtumo išraiška. Praktinė reikšmė tiesioginė: RPA robotas, kuris perkelia duomenis tarp dviejų langų, ir darbo eiga, kuri iškviečia sąsają pagal nupieštą kelią, dirbtinio intelekto reglamento pareigų nesukuria. Agentas, kuris daro išvadą, jas gali sukurti, ir būtent todėl pavadinimų maišymas pasiūlyme nėra vien stiliaus klausimas.
Ką pirkėjas kiekvienu atveju gauna
Pasiūlymus lyginti lengviau, jei žiūrima ne į pavadinimą, o į tai, kas po darbo pabaigos lieka įmonėje. Robotizuoto procesų automatizavimo atveju lieka licencija, vykdymo aplinka, valdymo įrankis, proceso aprašas ir žurnalas su atliktais veiksmais, ir iš viso to svarbiausias yra proceso aprašas, nes būtent jis pasako, ką robotas daro, kai kažkas neatitinka laukto.
Darbo eigos atveju lieka pati darbo eiga, prieigos duomenys prie kiekvienos sujungtos sistemos, vykdymo žurnalas ir klaidų atšaka, ir čia verta atkreipti dėmesį į tai, kam priklauso prieigos duomenys ir kur darbo eiga veikia. Jei ji veikia tiekėjo paskyroje su tiekėjo raktais, tada santykių nutraukimas reiškia ir darbo nutrūkimą, ir tai lengviau sutvarkyti sutarties sudarymo metu nei vėliau.
Agento atveju be viso ankstesnio lieka ir atsakomybė už tai, ką jis padarė, ir būtent todėl žurnalas ten nėra techninė smulkmena, o pati esmė. Jei negalima pasakyti, kodėl agentas konkrečiu atveju elgėsi taip, kaip elgėsi, tada negalima ir atsakyti klientui, kuris klausia, kodėl jo paraiška buvo išnagrinėta būtent taip.
Kurie terminai jau prasidėjo
Kadangi reglamento reikalavimai įsigalioja palaipsniui, verta žinoti, kas jau galioja šiandien ir kas dar ne. Pareiga informuoti žmogų, kad jis sąveikauja su dirbtinio intelekto sistema, taikoma nuo 2026 metų rugpjūčio 2 dienos, ir ji apima klientams matomą dirbtinio intelekto agentą arba pokalbių robotą Jūsų svetainėje, ir jei toks įdiegtas, tai klausimas, kurį reikia išspręsti dabar, o ne ateityje.
Didelės rizikos reikalavimai, kurie taikomi tokioms sritims kaip personalo atranka ir užimtumo sprendimai, pradedami taikyti 2027 metų gruodžio 2 dieną, ir ši data neseniai buvo perkelta, todėl dalyje straipsnių vis dar stovi ankstesni metai, o draudžiama praktika ir pati sistemos apibrėžtis galioja jau dabar.
Nepriklausomai nuo dirbtinio intelekto reglamento lieka galioti ir duomenų apsaugos reikalavimas dėl sprendimų, kurie priimami tik automatizuotai ir sukelia teisines pasekmes arba panašiu būdu daro didelį poveikį žmogui. Šis reikalavimas nepriklauso nuo to, ar mechanizmas yra agentas, ar paprasta darbo eiga: svarbu tai, ar sprendimą apie žmogų priima mašina viena pati.
Verta ir suprasti, kodėl ši riba nubrėžta būtent per gebėjimą daryti išvadas, o ne per sudėtingumą. Programa gali būti labai sudėtinga ir vis tiek nebūti dirbtinio intelekto sistema, jei kiekvieną jos žingsnį nustatė žmogus, ir atvirkščiai — visai nedidelis sprendimas, kuris naudoja modelį, kad nuspręstų, ką daryti, apibrėžtį atitinka. Tai reiškia, kad atsakymo į klausimą apie pareigas neduoda nei projekto biudžetas, nei eilučių skaičius, o tik tai, kaip priimamas sprendimas dėl kito veiksmo.
Praktikoje šie terminai dažniausiai taikomi vienam konkrečiam dalykui, kurį daugelis įmonių jau turi: pokalbių robotui arba asistentui svetainėje. Jei jis matomas klientui ir grindžiamas kalbos modeliu, tada pareiga pasakyti, kad pašnekovas nėra žmogus, jau galioja, ir praktiškai ją įvykdo aiškus užrašas sąsajoje, ne pastraipa privatumo politikoje. Jei tai paprastas taisyklių medis su iš anksto parašytais atsakymais, tada tai nėra dirbtinio intelekto sistema ir ši pareiga neatsiranda, tačiau skirtumą verta užfiksuoti raštu, nes po metų niekas nebeatsimins, kaip tai buvo padaryta.
Kodėl pavadinimai rinkoje maišosi
Šiai painiavai yra ir visai objektyvi priežastis, ir tai nėra vien rinkodara: įrankiai, kurie anksčiau darė vieną dalyką, dabar daro kelis: platformos, kurios prasidėjo kaip darbo eigų įrankiai, dabar siūlo ir agento žingsnį, o įmonės, kurios pardavinėjo robotizuotą procesų automatizavimą, dabar tuos pačius produktus aprašo kaip tokius, kurie veikia patys.
Tai reiškia, kad pagal produkto pavadinimą mechanizmo daugiau nustatyti negalima, ir vienintelis saugus klausimas pasiūlymui yra, kaip konkrečiame sprendime nustatomas veiksmų kelias: ar jį įrašo žmogus, ar jį nupiešia kaip grafą, ar jį kiekvienu paleidimu pasirenka modelis. Atsakymas į šį vieną klausimą pasako ir kainą, ir trapumą, ir tai, ar reglamento pareigos apskritai gali atsirasti.
Yra ir žodžių, su kuriais lietuvių kalboje reikia būti atidiems: santrumpą RPA tekste niekada neverta dėti vieną, be pilnos formos pirmą kartą paminint. Taip pat pasitaikanti forma robotikos procesų automatizavimas yra klaida: robotika yra fiziniai robotai, o čia kalbama apie programinę įrangą.
Antroji vieta, kur pavadinimai maišosi, yra pats žodžio „automatizavimas“ vartojimas: lietuvių kalboje juo žymimas ir pramoninių procesų valdymas, ir biuro darbo automatizavimas, ir tai dvi visiškai skirtingos rinkos su skirtingais tiekėjais. Jei ieškote pasiūlymo, verta pasakyti, kuri iš abiejų turima omenyje, nes priešingu atveju dalis gautų pasiūlymų bus iš visai kitos šakos.
Trys teiginiai, kurie pasiūlymuose neteisingi
Pirmasis yra tas, kad robotizuotas procesų automatizavimas esąs dirbtinis intelektas, ir tai nėra vien terminijos klausimas, nes iš to išplaukia pareigos: sistema, kuri vykdo žmogaus parašytus žingsnius, dirbtinio intelekto sistemos apibrėžties neatitinka, ir pasiūlymas, kuris robotą vadina dirbtiniu intelektu, arba parduoda brangiau, nei reikia, arba kelia nerimą, kuris nėra pagrįstas. Antrasis yra tas, kad agentas esąs paprasčiausiai gudresnis pokalbių robotas, ir skirtumas ne gudrume, o veiksme: pokalbių robotas generuoja atsakymą, agentas iškviečia įrankius ir keičia būseną kitose sistemose, ir būtent todėl agentui reikia ribų, kurių pokalbių robotui nereikia. Įmonė, kuri to neskiria, neretai agentui duoda prieigą, apie kurią niekas nėra pagalvojęs.
Trečiasis yra tas, kad pasirinkimas tarp šių trijų esąs pasirinkimas tarp trijų tiekėjų. Iš tikrųjų vienas ir tas pats įrankis dažnai gali visus tris: platformos, kurios prasidėjo kaip darbo eigų įrankiai, dabar siūlo ir agento žingsnį, ir tai reiškia, kad klausimas nėra, ką nupirkti, o kaip konkrečiame sprendime nustatomas veiksmų kelias.
Kaip pasirinkti mechanizmą konkrečiam darbui
Pasirinkimas praktikoje trumpas, jei klausimai užduodami teisinga seka: pirmiausia išsiaiškinkite, ar dalyvaujančios sistemos turi programinės įrangos sąsają, nes jei ji yra, darbo eiga beveik visada bus atsparesnė ir pigiau prižiūrima nei ekrano kartojimas, ir toliau klausimas jau ne apie mechanizmą, o apie apimtį. Jei sąsajos nėra ir sistemos keisti negalima, tada robotizuotas procesų automatizavimas yra tinkamas įrankis, tačiau atmerktomis akimis: biudžete turi būti priežiūra, ir projekte turi būti atsakingasis, kuris robotą pataiso, kai ekranas pasikeičia. Jei įvesties duomenys nestruktūrizuoti, kiekvienas atvejis skiriasi ir žingsnių sekos iš anksto parašyti neįmanoma, tik tada verta žiūrėti agento kryptimi, ir tada reikia žinoti, kur jis sustoja ir kas jį prižiūri.
Dažniausiai pasitaikantis praktinis sprendimas yra mišrus: darbo eiga valdo grandinę ir atlieka visus numatomus žingsnius, bet vienoje konkretioje vietoje ji iškviečia modelį, kad apdorotų nestruktūrizuotą įvestį, ir rezultatą grąžina atgal į grandinę. Tai sujungia nuspėjamumą su lankstumu būtent ten, kur jo reikia, ir tai taip pat pigiausias iš variantų, kurie apskritai veikia.
Yra dar vienas praktinis sumetimas, kuris pasirinkimą neretai nulemia labiau nei technika: kiekvienas iš trijų mechanizmų reikalauja kitokio prižiūrėtojo: darbo eigą gali prižiūrėti žmogus, kuris supranta sistemų sąsajas, robotui reikia kažko, kas išmano būtent tą įrankį ir ekranus, su kuriais jis dirba, o agentui papildomai reikia kažko, kas reguliariai žiūri, ką jis iš tikrųjų daro. Jei įmonėje tokio žmogaus nėra ir neplanuojama pirkti priežiūros, tada pasirinkimas tarp mechanizmų turi prasidėti nuo to, kurį iš jų realiai pavyks prižiūrėti.
Verta įvardyti ir tą klaidą, kuri šiame pasirinkime kainuoja brangiausiai, ir tai nėra mechanizmo pasirinkimas, o seka. Įmonės neretai pirma pasirenka įrankį, tada ieško, ką juo automatizuoti, ir tik tada supranta, kad procesas, kurį norėjo automatizuoti, dar neaprašytas. Teisinga seka yra priešinga: pirma aprašomas darbas su jo išimtimis, tada išsiaiškinama, ar sistemos turi sąsajas, ir tik tada pasirenkamas mechanizmas, nes šiuo momentu pasirinkimas paprastai akivaizdus ir užima penkias minutes. Lygiai taip pat dažnai pasitaiko priešinga kraštutinybė, kurioje įmonė laukia, kol viskas bus sutvarkyta, ir nepradeda nieko. Čia praverčia prisiminti, kad darbo eigą galima pastatyti ir vienai nedidelei atkarpai ir išplėsti vėliau, ir kad būtent pirmoji baigta atkarpa paprastai parodo, kur iš tikrųjų yra spūstis, gerokai tiksliau nei bet koks išankstinis vertinimas.
Verta ir pasakyti, kad mechanizmo keitimas vėliau nėra katastrofa, jei pats procesas aprašytas. Įmonės neretai bijo neteisingo pasirinkimo taip, tarsi jis būtų negrįžtamas, bet praktikoje didžiausia vertė projekte yra būtent proceso aprašas su jo išimtimis, ir jis lieka tinkamas nepriklausomai nuo to, ar jį vykdo robotas, darbo eiga ar agentas. Pakeisti vykdytoją tada, kai aprašas jau sutvarkytas, yra gerokai pigiau nei rašyti aprašą iš naujo.
Ką paklausti tiekėjo
Jei pasiūlymas jau ant stalo, tada keturių klausimų paprastai pakanka, kad būtų suprasta, kas jame iš tikrųjų siūloma, nepriklausomai nuo to, kokie žodžiai yra antraštėje. Pirmasis yra apie tai, kas sprendžia kitą žingsnį: įrašytas skriptas, nupieštas grafas ar modelis vykdymo metu, ir būtent šis atsakymas įvardija mechanizmą tiksliau nei bet koks produkto pavadinimas antraštėje.
Antrasis yra tai, kas nutinka, kai kažkas neatitinka laukto, ir čia verta prašyti konkretaus pavyzdžio, ne bendro teiginio apie patikimumą. Trečiasis yra tai, kam priklauso prieigos duomenys ir kur sprendimas veikia, nes nuo to priklauso, ar darbas tęsiasi, jei santykiai su tiekėju baigiasi. Ketvirtasis yra tai, kiek kainuoja priežiūra per metus ir kas būtent už ją gaunama, nes būtent priežiūra yra ta sąnauda, kuri pasiūlymuose dažniausiai visai nenurodyta.
Jei į kurį nors iš šių klausimų atsakymas neaiškus, tai dar nereiškia, kad pasiūlymas blogas — tai reiškia, kad apie šią dalį dar nepagalvota, ir susitarti dėl to gerokai pigiau prieš sutartį nei po pirmo sustojimo.
Tinka ir priešingas sąrašas, būtent klausimai, kurie nieko nenulemia, nors juos užduoda dažnai. Kokio dydžio įmones tiekėjas aptarnavo, kiek metų jis dirba rinkoje ir kiek procesų jis automatizavo, pasako apie patirtį, bet nieko nepasako apie tai, ar konkretus mechanizmas tinka konkrečiai užduočiai. Taip pat mažai praverčia klausimas, kurią platformą tiekėjas naudoja, nes viena ir ta pati platforma šiandien gali veikti visais trimis mechanizmais, ir atsakymas į šį klausimą Jums nieko nepasako apie sprendimo trapumą ar priežiūros sąnaudas.
Galiausiai verta prašyti, kad tiekėjas parodytų vieną jau veikiantį pavyzdį ir papasakotų, kas jame sugedo nuo įdiegimo ir kodėl. Atsakymas į šį klausimą apie tiekėjo darbo kokybę pasako daugiau nei bet koks atsiliepimų sąrašas, nes genda viskas, kas veikia pakankamai ilgai, ir svarbu tai, kaip greitai tai pastebėjo ir sutaisė.
Sąžininga pasakyti ir savo poziciją, nes ji paaiškina, kodėl šis straipsnis parašytas būtent taip. Mes neparduodame robotizuoto procesų automatizavimo licencijų ir nesame jokios tokios platformos partneriai, todėl mums nėra intereso, kad Jūs pasirinktumėte brangiausią mechanizmą.
Mūsų darbas yra verslo procesų automatizavimas su darbo eigomis ir sąsajomis tarp sistemų, kurias Jūs jau turite, įskaitant tą mišrų variantą, kuriame grandinę valdo darbo eiga, o modelį iškviečia tik viename nestruktūrizuotame žingsnyje, ir atskirai dirbtinio intelekto sprendimai ten, kur užduotis tikrai reikalauja daryti išvadą. Jei Jums šiuo metu yra pasiūlymas, kuriame šie žodžiai sumaišyti, arba paprasčiausiai neaišku, kuris mechanizmas tinka Jūsų užduočiai, atsiųskite mums aprašymą: dažnai atsakymas yra, kad pakanka vienos jungties, ir tai pigiausias atsakymas, kokį galima gauti.
Dažniausiai užduodami klausimai.
Kuo RPA skiriasi nuo darbo eigų automatizavimo?
Tuo, kur jis dirba. Robotizuotas procesų automatizavimas veikia ekrane: programinis robotas atidaro langus, spusteli ir kopijuoja laukus lygiai taip pat kaip žmogus, ir sistemos lieka nepakitusios. Darbo eigų automatizavimas dirba vienu sluoksniu giliau, naudodamas sistemų programinės įrangos sąsajas, todėl pakeitimai ekrane jo neveikia. Praktikoje tai reiškia, kad ten, kur sąsaja prieinama, darbo eiga beveik visada atsparesnė ir pigiau prižiūrima, o RPA yra tinkamas įrankis senoms sistemoms, kurios sąsajos neturi ir kurių niekas nebeperprojektuos.
Ar RPA yra dirbtinis intelektas?
Ne. Dirbtinio intelekto reglamento 3 straipsnio 1 punktas dirbtinio intelekto sistemą apibūdina kaip tokią, kuri daro išvadą, kaip generuoti išvedinį, o reglamento konstatuojamosios dalys tiesiogiai nustato, kad sistemos, kurios veikia tik pagal žmonių nustatytas taisykles, šios apibrėžties neatitinka. Tą pačią ribą lietuviškai nubrėžia ir pats reglamento tekstas: sistemos, grindžiamos tik fizinių asmenų nustatytomis taisyklėmis, kad automatiškai vykdytų operacijas, dirbtinio intelekto sistemos apibrėžties neatitinka. Praktiškai tai reiškia, kad robotas, kuris perkelia duomenis tarp dviejų langų, reglamento pareigų nesukuria.
Kuo dirbtinio intelekto agentas skiriasi nuo pokalbių roboto?
Veikimu. Pokalbių robotas atsako į klausimą, o agentas gauna tikslą ir pats pasirenka kelią, iškviesdamas įrankius, kurie jam prieinami: paiešką, duomenų bazę ar kitos sistemos sąsają. Būtent įrankių naudojimas yra tas požymis, kuris šiuos du skiria. Iš to išplaukia ir pagrindinės praktinės pasekmės: agento rezultatas nėra visiškai nuspėjamas, nes du identiški paleidimai gali pasirinkti skirtingus kelius, todėl jam reikia priežiūros ir aiškiai nustatytų ribų.
Kurie dirbtinio intelekto reglamento reikalavimai jau galioja?
Pareiga informuoti žmogų, kad jis sąveikauja su dirbtinio intelekto sistema, taikoma nuo 2026 metų rugpjūčio 2 dienos, todėl klientams matomas dirbtinio intelekto agentas arba pokalbių robotas svetainėje yra klausimas, kurį spręsti reikia jau dabar. Draudžiama praktika ir pati sistemos apibrėžtis taip pat galioja. Didelės rizikos reikalavimai tokiose srityse kaip personalo atranka pradedami taikyti 2027 metų gruodžio 2 dieną, ir ši data neseniai buvo perkelta, todėl dalyje straipsnių vis dar stovi ankstesni metai. Nepriklausomai nuo šio reglamento lieka galioti duomenų apsaugos reikalavimas dėl sprendimų, kurie grindžiami tik automatizuotu duomenų tvarkymu ir dėl kurių kyla teisinės pasekmės arba kurie panašiu būdu daro didelį poveikį žmogui — abi sąlygos galioja kartu, ne kiekviena atskirai.
Kaip suprasti, kuris mechanizmas tinka mano užduočiai?
Jei dalyvaujančios sistemos turi programinės įrangos sąsają, darbo eiga beveik visada bus teisingas pasirinkimas. Jei sąsajos nėra ir sistemos keisti negalima, tinka robotizuotas procesų automatizavimas, bet biudžete reikia numatyti priežiūrą, nes robotas sustoja kartu su pakeitimais ekrane. Dirbtinio intelekto agentas svarstytinas tik tada, jei įvesties duomenys nestruktūrizuoti ir žingsnių sekos iš anksto parašyti neįmanoma. Dažniausias praktinis sprendimas yra mišrus: darbo eiga valdo grandinę ir vienoje vietoje iškviečia modelį nestruktūrizuotai įvesčiai apdoroti.
Mažiau rankinio darbo: sąskaitos faktūros, dokumentai ir duomenų mainai tarp CRM, ERP ir apskaitos vyksta savaime. Pirmieji rezultatai — per 4–12 savaičių.
Daugiau straipsniai.