Pritaikytas DI prieš platformą 2026 m.
Kiekviena vidutinio dydžio Lietuvos įmonė 2026 m. susiduria su tuo pačiu klausimu: pirkti platformą su DI funkcionalumu (Salesforce Einstein, Microsoft Copilot, ServiceNow Now Assist) ar kurti pritaikytą sistemą su domeno specifine logika? Atsakymas, kaip ir dažniausiai, yra mišrus modelis - bet teisingas mišinys priklauso nuo trijų ašių: diferenciacijos, reguliavimo, duomenų vietos. Šis straipsnis pateikia praktinį karkasą sprendimui.
Ašis 1: diferenciacija
Klausimas - ar DI sluoksnis yra jūsų konkurencinis pranašumas, ar foninė funkcija? Jei DI rezultato kokybė tiesiogiai veikia jūsų skirtumą rinkoje (pvz., draudikui - žalų triažo tikslumas, bankui - kreditavimo sprendimo greitis ir tikslumas, advokatų kontorai - sutarčių peržiūros greitis), tai pritaikyta sistema. Jei DI yra tik foninė automatizacija (pvz., el. paštų klasifikavimas, kalendoriaus tvarkymas, susitikimo santraukų generavimas), tai platforma.
Ašis 2: reguliavimas
Klausimas - ar sistema patenka į ES DI akto III priedą arba kitą reguliavimo karkasą (DORA, NIS2, BDAR 22 str.)? Jei taip, platformos garantijos dažnai nepakanka - reguliuotojas reikalauja konkretaus atitikties dokumento, kurį platforma negali pateikti pritaikyta forma. Aukštos rizikos atvejais pritaikyta sistema yra natūralesnis pasirinkimas.
Ašis 3: duomenų vieta
Klausimas - ar jūsų duomenys gali palikti ES debesų regioną? Daugelis didžiausių platformų (Salesforce Einstein, ServiceNow Now Assist, OpenAI ChatGPT Enterprise) turi ES regiono parinktis, bet ne kiekvienai DI funkcijai. Jei reikalingas tik ES regiono apdorojimas (DORA, NIS2, BDAR 9 str. ypatingų kategorijų atvejais), pritaikyta sistema su konkrečiu ES debesų tiekėju yra paprastesnė.
Mišraus modelio anatomija
Praktikoje 2026 m. dauguma vidutinio dydžio įmonių naudoja mišrų modelį: Microsoft Copilot bendrojo darbo automatizavimui (el. paštas, dokumentai, susitikimai), Salesforce Einstein klientų santykių valdymui, pritaikytos sistemos kritiniams reguliuojamiems sluoksniams (kreditavimo sprendimai, žalų triažas, sutarčių peržiūra). Bendros sąnaudos paprastai 30-50 % platformos, 50-70 % pritaikytos sistemos kūrimo.
Tipinės klaidos
Pirmoji klaida - prielaida, kad platforma 'sutaupo' kūrimo laiką. Tiesa - platformos diegimas dažnai užtrunka 6-12 mėnesių dėl integracijų, perkonfigūravimo ir mokymų; pritaikyta sistema su siaura apimtimi - 4-6 mėnesius. Antroji klaida - pritaikytos sistemos kūrimas plačiam horizontaliam atvejui (vidaus pokalbių robotas su 'visa kompanijos žinia'). Trečioji klaida - platformos pasirinkimas dėl 'integracijų ekosistemos' be konkretaus integracijų sąrašo, kurį iš tikrųjų naudosite.
Kaip Impetora padeda priimti sprendimą
Pažinties etape pateikiame trijų ašių vertinimo lentelę kiekvienai DI funkcijai, kurią svarstote. Lentelė rezultatuoja rekomendacija: platforma, pritaikyta sistema arba mišrus. Mes nesiūlome darbų sritims, kurioms platforma yra teisingas atsakymas - tai sąžiningai dokumentuojame. Mūsų darbas yra siauras, reguliuojamas, gilus DI sluoksnis. Likusi dalis paprastai geriau nupirkti.
Lietuviška versija nuolat plečiama. Konkrečiam projektui kvietime pažintiniam pokalbiui arba rašykite info@ainora.lt.