Dirbtinio intelekto konsultacijos verslui: ką iš tikrųjų reikia žinoti prieš pradedant

Sąžiningas vadovas apie DI konsultacijas Lietuvos verslui: kodėl dauguma DI projektų nepasiekia rezultato, kaip iš tikrųjų vyksta dirbtinio intelekto diegimas įmonėje ir kaip pasirinkti konsultantą.

Nepatogi tiesa apie DI projektus

„McKinsey" duomenimis, apie 88 % organizacijų bent kažkur naudoja dirbtinį intelektą. Tačiau tik 1 % savo diegimą vadina pilnai išvystytu. Tarp šitų dviejų skaičių slypi dauguma DI konsultacijų verslui rinkoje.

Dažniausia priežastis, kodėl DI projektas neduoda rezultato, nėra technologija. „ChatGPT", „Claude" ar „Copilot" veikia gerai jau šiandien. Problema beveik visada ta pati: niekas įmonėje aiškiai neapibrėžė, kokią konkrečią problemą DI turėtų išspręsti.

Įmonė nusiperka licenzijas, surengia vienus mokymus, o po mėnesio paaiškėja, kad darbuotojai grįžo prie senų įpročių. Arba priešingai: vienas entuziastas komandoje sukuria puikų prototipą, jis parodomas vadovybei, sulaukia pagyrų, o tada tiesiog nueina į stalčių, nes niekas nežinojo, kaip jį integruoti į realų darbą.

Šis straipsnis parašytas ne tam, kad įtikintų jus, jog reikia DI konsultacijų. Jis parašytas tam, kad parodytų, kaip iš tikrųjų atrodo dirbtinio intelekto diegimas įmonėje, kai jis pavyksta, ir kur dažniausiai lūžta, kai nepavyksta. Jei po jo nuspręsite, kad jums to nereikia arba galite tai padaryti patys, tai irgi bus geras rezultatas.

Kas iš tikrųjų yra DI konsultacijos, o kas ne

Terminas „DI konsultacijos" per pastaruosius metus tapo tiek plačiai naudojamas, kad prarado prasmę. Verta atskirti tris dalykus, kurie nuolat susipainioja.

Įrankiai. „ChatGPT" prenumerata darbuotojui nėra DI strategija. Tai tiesiog licenzija. Ji gali padidinti individualų produktyvumą, bet pati savaime nekeičia, kaip veikia organizacija. Dauguma įmonių šioje stadijoje ir sustoja: turi įrankius, neturi plano. Po kelių mėnesių paaiškėja, kad kiekvienas darbuotojas įrankį naudoja skirtingai, niekas nesidalina, kas veikia geriausiai, o organizacija kaip visuma nė kiek nepriartėjo prie sistemingo DI panaudojimo.

Agentai. DI agentas jau yra kažkas kito: sistema, kuriai duodate tikslą, o ji pati suplanuoja žingsnius, naudoja jūsų duomenis ir įrankius, ir įvykdo užduotį iki rezultato. Tai galingiau nei paprastas įrankis, bet reikalauja aiškiai aprašyto proceso, kad veiktų teisingai. Skirtumas nuo pokalbių roboto paprastas: robotas atsako į klausimą pagal iš anksto numatytą scenarijų, o agentas pats nusprendžia, kokių veiksmų imtis, kad pasiektų nurodytą tikslą.

Strategija. Tai lygmuo, kuriame dirba tikros DI konsultacijos verslui: kur konkrečiai jūsų organizacijoje dirbtinis intelektas sukurtų realią vertę, kokia tvarka tai daryti, kokių rizikų vengti ir kaip išmatuoti, ar tai iš tikrųjų veikia. Be šio lygmens, įrankiai ir agentai lieka pavieniais eksperimentais, o ne sistemingu pokyčiu.

Painiava tarp šių trijų lygmenų yra dažniausia priežastis, kodėl DI projektų biudžetai ir lūkesčiai neatitinka vienas kito. Vadovybė, kalbėdama apie „DI strategiją", dažnai iš tikrųjų turi omenyje tik įrankių pirkimą. IT komanda, kalbėdama apie „DI diegimą", dažnai turi omenyje vieną konkretų agentą, o ne visos organizacijos požiūrio pokytį. Kai šie du supratimai nesutampa, projektas atrodo nesėkmingas net tada, kai techniškai viskas veikia, nes buvo tikimasi kitokio rezultato nei tas, kuris buvo iš tikrųjų suplanuotas.

Gera DI konsultacija retai prasideda nuo technologijos. Ji prasideda nuo klausimo: kur jūsų organizacijoje laikas ir pinigai šiandien nuteka į rankinį, pasikartojantį darbą, kurį galima būtų automatizuoti nesukeliant papildomos rizikos. Tik atsakius į šį klausimą verta svarstyti, ar reikia įrankio, agento, ar platesnės strategijos.

Keturios problemos, dėl kurių į mus kreipiasi įmonės

Per pastaruosius metus dirbant su Lietuvos verslu, kartojasi keturi scenarijai. Jie retai skamba kaip „norime įdiegti DI". Dažniau jie skamba taip.

„Nežinome, kas iš tikrųjų vyksta." Vadovai įtaria, kad darbuotojai jau naudoja DI įrankius darbe, bet neturi aiškaus vaizdo, kiek ir kaip. Tai vadinamas šešėlinis DI: kai kiekvienas darbuotojas individualiai sprendžia, kaip pasitelkti dirbtinį intelektą, o organizacija iš to nesimoko ir nesupranta, kur kyla realios rizikos. Kaip rašė mūsų bendraįkūrėjas Gediminas Buivydas Delfi skiltyje, didžiausia rizika šiandien yra ne tai, kad darbuotojai naudoja DI, o tai, kad vadovybė nežino, kaip jie tai daro. Praktikoje tai reiškia, kad rinkodaros specialistas per „ChatGPT" asmeninę paskyrą apdoroja klientų duomenis, buhalteris DI įrankiui perduoda sąskaitų informaciją, o teisininkas prašo DI apibendrinti sutartį su konfidencialiomis sąlygomis. Nė vienas iš jų nedaro nieko blogo sąmoningai, tiesiog niekas jiems nepasakė, kur yra riba.

„Nežinome, nuo ko pradėti." Vadovybė supranta, kad dirbtinis intelektas verslui gali duoti realios naudos, bet turi dešimtis idėjų ir nė vieno aiškaus prioriteto. Rezultatas: arba nieko nedaroma, nes per daug galimybių, arba imamasi pirmos idėjos, kuri pasitaiko po ranka, nebūtinai tos, kuri duotų didžiausią grąžą. Dažnai tai atrodo taip: vienas susirinkimas nusprendžia bandyti chatbot'ą klientų aptarnavimui, kitas savaitę vėliau nusprendžia, kad svarbiau automatizuoti ataskaitas, o po mėnesio abu projektai vis dar „planavimo stadijoje", nes niekas jų neišdėstė prioriteto tvarka pagal realią grąžą ir įgyvendinimo sudėtingumą.

„Turėjome puikų prototipą, bet jis niekur nenuėjo." Vienas iš dažniausių scenarijų. Komandos entuziastas ar IT specialistas per savaitgalį sukuria veikiantį DI sprendimą. Jis parodomas, sulaukia pritarimo, o tada užstringa, nes niekas neapskaičiavo, ko reikia, kad jis veiktų su realiais duomenimis, realia apkrova ir realiais darbuotojais kasdien. Prototipas, veikiantis su dešimt testinių įrašų, ir sistema, veikianti su dešimt tūkstančių realių klientų įrašų kasdien, yra du visiškai skirtingi inžineriniai uždaviniai. Būtent čia dažniausiai ir sustoja vidiniai bandymai: idėja buvo teisinga, bet trūko plano, kaip ją perkelti iš demonstracijos į kasdienį darbą.

„ES DI aktas jau čia, o mes neturime jokios politikos." Nuo 2025 metų vasario galioja pareiga užtikrinti darbuotojų DI raštingumą, o priežiūra Lietuvoje realiai įsijungia nuo 2026 rugpjūčio. Įmonės, kurios jau duoda darbuotojams DI įrankius, bet neturi jokios aiškios dirbtinio intelekto politikos įmonei, atsiduria pozicijoje, kur rizika auga greičiau nei jos supratimas apie ją. Dažnai tai pastebima tik tada, kai klientas ar partneris paklausia, kaip įmonė užtikrina duomenų saugumą naudodama DI, o atsakymo tiesiog nėra.

Šios keturios problemos turi vieną bendrą bruožą: nė viena jų neišsprendžiama nusipirkus dar vieną DI įrankį. Joms reikia sistemingo požiūrio.

Kaip iš tikrųjų vyksta DI diegimas: S.E.A. metodas

Mūsų darbo pagrindas yra S.E.A. metodas: Strategija, Eksperimentavimas, Adaptacija. Tai ne rinkodaros terminas, o realus 30 dienų DI planas, kurio kiekvienas etapas turi konkretų tikslą ir konkrečią riziką, jei jo nepavyksta atlikti gerai.

Strategija (pirmoji savaitė). Šiame etape nustatome, kur jūsų organizacijoje dirbtinis intelektas sukurtų didžiausią vertę, ir, kas ne mažiau svarbu, kur jo geriau nenaudoti. Peržiūrime realius procesus, duomenis ir komandos gebėjimus, o ne bendrą rinkos statistiką. Kalbame su žmonėmis, kurie realiai atlieka darbą, ne tik su vadovybe, nes būtent jie žino, kur laikas iš tikrųjų dingsta. Dažniausia klaida šiame etape: praleisti jį ir iš karto šokti prie sprendimo, kuris atrodo įdomus, bet neišsprendžia realios problemos. Rezultatas: keli konkretūs kandidatai automatizavimui, sudėlioti pagal potencialią grąžą ir įgyvendinimo sudėtingumą.

Eksperimentavimas (antra ir trečia savaitės). Prioritetinės idėjos testuojamos su jūsų realiais duomenimis, ne demonstracine aplinka. Būtent čia paaiškėja, ar idėja, kuri gerai skambėjo susirinkime, iš tikrųjų veikia praktikoje: ar duomenys pakankamai švarūs, ar procesas pakankamai stabilus, ar rezultatas pakankamai tikslus, kad juo būtų galima pasitikėti. Dažniausia klaida šiame etape: testuoti per daug idėjų vienu metu ir taip niekada negauti aiškaus atsakymo nė dėl vienos, arba testuoti su „gražiais" pavyzdiniais duomenimis, kurie nerodo, kaip sprendimas elgsis su realia, netvarkinga informacija.

Adaptacija (ketvirta savaitė). Patikrinta idėja įgyvendinama kaip veikiantis sprendimas, o komanda paruošiama juo naudotis kasdien. Šis etapas dažnai nuvertinamas: technologija gali veikti puikiai, bet jei komanda nesupranta, kaip ir kada ją naudoti, sprendimas lieka nenaudojamas, net jei techniškai jis pilnai veikiantis. Dažniausia klaida šiame etape: laikyti projektą baigtu, kai sistema paleista, o ne kai ji tampa įprasta darbo dalimi, su aiškiu atsakingu asmeniu ir suprantamu būdu pranešti apie problemas, jei jos atsiras.

Rezultatas po 30 dienų nėra pažadas, kad viskas taps automatizuota. Tai patikrintas veiksmų planas, pagrįstas jūsų pačių duomenimis, o ne bendromis prielaidomis apie tai, ką DI „turėtų" sugebėti. Kai kuriais atvejais sąžiningas rezultatas būna ir toks: konkreti idėja, kuri atrodė perspektyvi, po testavimo pasirodo neduodanti pakankamos grąžos, palyginti su įgyvendinimo sudėtingumu. Tai irgi vertingas rezultatas, nes sutaupo mėnesius, kurie priešingu atveju būtų investuoti be aiškaus atsakymo.

Kas iš tikrųjų lemia projekto apimtį

Sąžiningas atsakymas į klausimą, kiek tai kainuoja, yra toks: priklauso. Ne todėl, kad vengiame atsakyti, o todėl, kad du iš pažiūros panašūs projektai gali skirtis kelis kartus pagal keturis dalykus.

Kokybė. Jei jūsų duomenys išsibarstę po penkias skirtingas sistemas, kurios tarpusavyje nesikalba, pirmasis darbas yra ne DI, o duomenų sutvarkymas. Tai neretai užima daugiau laiko nei pats DI sprendimas. Įmonė, kurios klientų duomenys tvarkingai sukaupti vienoje CRM sistemoje, pradės nuo visai kitokio taško nei įmonė, kurios ta pati informacija išbarstyta po el. pašto dėžutes, „Excel" failus ir keturias skirtingas programas.

Proceso aiškumas. DI agentas gali automatizuoti tik tai, ką jūs patys sugebate aiškiai aprašyti žingsnis po žingsnio. Jei procesas šiandien egzistuoja tik vieno patyrusio darbuotojo galvoje, pirmiausia jį reikia išgryninti į aiškius žingsnius, o tai kartais atskleidžia, kad pats procesas turi nenuoseklumų, kuriuos vertėtų sutvarkyti dar prieš automatizuojant.

Integracijos gylis. Sprendimas, kuris veikia atskirai, sukuriamas greičiau nei sprendimas, kuris turi susijungti su jūsų CRM, apskaitos sistema ir el. paštu vienu metu. Kiekviena papildoma integracija yra papildomas darbas ir papildoma vieta, kur kažkas gali sugesti, todėl vertė tarp „atskiro įrankio" ir „pilnai integruoto agento" gali skirtis kelis kartus.

Atitikties našta. Projektas, kuriame apdorojami klientų asmens duomenys ar sudaromi sprendimai, turintys teisinių pasekmių, reikalauja daugiau atsargumo nei vidinis produktyvumo įrankis. ES DI akto ir BDAR reikalavimai čia nėra formalumas, o realus darbo apimties veiksnys: reikia numatyti, kaip sprendimas bus paaiškinamas, kaip bus fiksuojami veiksmai ir kaip žmogus galės peržiūrėti ar pakeisti DI sprendimą, kai to prireiks.

Būtent dėl šių keturių kintamųjų nematysite kainoraščio mūsų svetainėje. Bet kokia fiksuota kaina, paskelbta be konteksto, arba būtų neatsakingai maža, arba dirbtinai išpūsta, priklausomai nuo to, kuris scenarijus jums iš tikrųjų taikomas. Vietoj to pradedame nuo nemokamo 30 minučių pokalbio, kurio metu kartu peržiūrime šiuos keturis veiksnius ir jūs išeinate su aiškiu supratimu, ko iš tikrųjų reikėtų jūsų atveju, net jei tuo metu nuspręsite dirbti su kitu partneriu arba patys.

Reguliavimas: kas galioja nepriklausomai nuo to, ką pasirenkate

Nesvarbu, ar dirbsite su konsultantais, ar patys, kelios pareigos jums galioja jau dabar, ir jos negalioja tik didelėms korporacijoms.

ES DI akto 4 straipsnis įpareigoja organizacijas užtikrinti darbuotojų DI raštingumą, jei jos naudoja DI įrankius darbe. Ši pareiga galioja nuo 2025 m. vasario, o jos priežiūra Lietuvoje pavesta Ryšių reguliavimo tarnybai (RRT) ir realiai įsijungia nuo 2026 m. rugpjūčio. Praktiškai tai reiškia, kad jei jūsų komanda naudoja bet kokį DI įrankį, nuo „Copilot" iki paprasčiausio „ChatGPT", jums jau dabar reikalinga aiški politika, kaip tai daroma saugiai.

Jei tvarkomi asmens duomenys, taikomas BDAR, o didžioji dalis verslo DI naudojimo atvejų patenka į ribotos arba minimalios rizikos kategoriją, kuriai keliami skaidrumo, o ne draudimo reikalavimai. Tai reiškia, pavyzdžiui, kad klientas turi žinoti, kai bendrauja su DI, o ne su žmogumi, ir kad tam tikri sprendimai, darantys įtaką asmeniui, turi turėti galimybę būti peržiūrėti žmogaus.

Vertinant nacionalinį kontekstą, verta stebėti ir Ekonomikos ir inovacijų ministerijos (EIMIN) iniciatyvas bei Lietuvos dirbtinio intelekto strategiją, kurios formuoja tiek reikalavimus, tiek finansavimo galimybes. Šis reguliacinis sluoksnis keičiasi greičiau, nei dauguma įmonių spėja sekti, todėl vertą periodiškai grįžti prie savo DI politikos ir ją atnaujinti, o ne parengti vieną kartą ir pamiršti.

Praktinis pirmas žingsnis, kurį galite žengti šiandien, nemokamai: DI politikos generatorius per kelias minutes sugeneruoja jūsų įmonei pritaikytą dirbtinio intelekto politiką, atitinkančią ES DI akto ir BDAR reikalavimus. Tai nepakeičia teisininko sudėtingesniais atvejais, bet duoda tvirtą pagrindą pradėti, o dažnai ir aiškiai parodo, kur jūsų dabartinė praktika jau turi spragų.

Kaip pasirinkti DI konsultantą

Rinka pilna žmonių, vadinančių save DI ekspertais po vieno savaitgalio su „ChatGPT". Per pastaruosius metus konsultantų, siūlančių DI paslaugas, skaičius Lietuvoje išaugo greičiau nei realios patirties turinčių specialistų skaičius. Kelios praktinės gairės, kaip atskirti.

Ar jie rodo konkrečius atvejus, ne bendrus pažadus? Bet kas gali pasakyti, kad DI „transformuos jūsų verslą". Verta ieškoti konsultantų, kurie gali parodyti konkrečius, patikrinamus pavyzdžius: kokia problema, koks sprendimas, kokia reali rizika buvo įvertinta. Jei atsakymas į „parodykite konkretų atvejį" yra bendra frazė apie „inovacijas" ir „skaitmeninę transformaciją", tai signalas.

Ar jie publikuoja savo vardu? Konsultantas, kuris viešai rašo apie DI temas savo tikruoju vardu, atiduoda savo profesinę reputaciją į viešumą. Tai skiriasi nuo anoniminės agentūros, kurios niekas negali patikrinti. Verta pasidomėti, ar konsultantas turi patikrinamą profesinę istoriją, ne tik gerai suprojektuotą svetainę.

Ar jie kalba apie riziką, ne tik apie naudą? Kiekvienas DI projektas turi ir gerąją, ir rizikingą pusę: duomenų saugumą, teisinę atitiktį, priklausomybę nuo vieno tiekėjo, galimybę, kad sprendimas duos klaidingą rezultatą. Konsultantas, kuris apie tai nekalba pirmas, arba nesupranta srities, arba nenori jūsų sustabdyti prieš pradedant prastą projektą, nes tai neapsimoka jo verslui.

Ar jie gali pasakyti „ne"? Geriausias signalas: konsultantas, pasiruošęs pasakyti, kad jūsų idėja neduos grąžos, arba kad jums iš viso nereikia DI sprendimo tam tikrai problemai spręsti, kurią galima išspręsti paprasčiau. Jei kiekvienas pasiūlymas baigiasi „taip, tai puikiai tinka", verta suabejoti, ar jums iš tikrųjų duodamas patarimas, ar tiesiog parduodamos valandos.

Šie keturi kriterijai neišskiria konkretaus vardo. Jie tiesiog padeda per pirmą pokalbį suprasti, ar priešais jus žmogus, kuris iš tikrųjų daro šį darbą, ar žmogus, kuris tiesiog seka rinkos tendenciją.

Nuo ko pradėti šiandien

Jei norite pradėti savarankiškai, trys žingsniai, kuriuos galite atlikti dar šią savaitę:

Jei norite peržiūrėti savo konkretų atvejį su kažkuo, kas tai daro kasdien, rezervuokite nemokamą 30 minučių pokalbį. Per jį pereisime jūsų procesus ir sąžiningai pasakysime, ar ir kur DI iš tikrųjų sukurtų vertę, net jei atsakymas bus, kad dar ne laikas.