Vidinis DI asistentas įmonei: ką jis daro ir kur lūžta

Vidinis DI asistentas yra asistentas darbuotojams, prijungtas prie pačios įmonės sistemų, kuris atsakymus surenka iš jūsų dokumentų, o ne iš bendro modelio žinių. Naudinga jame yra ne modelis, o integracijos. Ir būtent todėl du dalykai, kurių pardavimo skaidrėse nebūna, sprendžia, ar diegimas pavyks: asistentas parodo tai, ką darbuotojas techniškai jau galėjo pasiekti, o ne tai, ką jam buvo skirta matyti, o ES duomenų saugojimas beveik niekada neapima paties modelio skaičiavimo.

Šiame puslapyje abu dalykai išdėstyti su citatomis iš pačių tiekėjų dokumentacijos, perskaitytos 2026 m. rugsėjo 6 d. Ten, kur tiekėjas turi daugiau nei mes, tai pasakyta atvirai, nes palyginimas, kurį skaitytojas gali sugauti, yra bevertis.

Kas yra vidinis DI asistentas

Tai sistema, kuri indeksuoja jūsų dokumentų saugyklą, pokalbių įrankius, CRM, bilietų sistemą ir paštą, o tada į darbuotojo klausimą atsako iš tų šaltinių, nurodydama, iš kurio dokumento kiekviena atsakymo dalis paimta. Rinkoje ji vadinama įvairiai: įmonės paieška, DI asistentas darbuotojams, žinių sluoksnis. Pirkėjo požiūriu tai integracijų projektas, kurio viršuje yra pokalbio langas.

Kodėl tai apskritai perkama, paprastai grindžiama statistika apie tai, kiek laiko darbuotojai praleidžia ieškodami informacijos. Tą statistiką atsekėme iki pirminių dokumentų ir rezultatas nemalonus: garsiausio skaičiaus ataskaitoje, kuriai jis priskiriamas, paprasčiausiai nėra. Tai nereiškia, kad problemos nėra. Tai reiškia, kad pagrindimą verta pasidaryti savo, o ne pasiskolintą.

Pirmas lūžis: asistentas parodo tai, ko darbuotojas neturėjo matyti

Tiekėjų garantija visada skamba vienodai. Glean savo dokumentacijoje rašo: „Glean respects the permissions set in your company's connectors. If you have permission to view a document in Google Drive or a thread in a public Slack channel, it can appear in your results.“ Tai teisinga ir sąžininga. Tik atkreipkite dėmesį, ką ji pažada: tai, ką jūs ir taip galėjote pasiekti, o ne tai, ką jums buvo skirta matyti.

Skirtumas tarp šių dviejų dalykų ir yra visas gedimas. Per plačiai atviras katalogas iki šiol buvo saugus dėl neaiškumo: apie jį niekas nežinojo, todėl niekas jo ir neatidarė. Paieška neaiškumą panaikina per sekundę, o teisių nepakeičia. Tai struktūrinė savybė, o ne vieno tiekėjo aplaidumas.

Microsoft dėl to jau išleido du atskirus valdiklius ir abu vadina laikinais. Pirmasis, Restricted SharePoint Search, apribotas 100 svetainių, apie save sako, kad „isn't a security boundary and doesn't change any permissions on SharePoint sites“, ir kad tai „a short-term solution“, o nuo 2026 m. liepos 31 d. naujai nebeįjungiamas. Antrasis, Restricted Content Discovery, vadinamas „a temporary governance control“, reikalauja SharePoint Advanced Management licencijos šalia Copilot licencijos, o Microsoft prideda įspėjimą, kad per dažnas jo naudojimas „can reduce the amount of content available to organization-wide search and Microsoft Copilot experiences“. Kitaip tariant, valdiklis, kuris jus saugo, tuo pačiu blogina produktą, už kurį mokate.

Tas pats gedimas matomas ir kitų tiekėjų numatytuosiuose nustatymuose:

• Atlassian Rovo indeksuoja visą prijungtą darbo sritį: „We index the entire workspace of the third-party app you connect (for example, the entire Google Drive or the SharePoint workspace)“, o susiaurinti galima tik draudžiamųjų sąrašu ir tik kai kuriems jungikliams. Indeksuoti viską, o paskui atiminėti, yra atvirkštinis mažiausių teisių principas.
• Guru numatytajame modelyje prisijungia kaip vienas naudotojas: „Guru connects as a single user and indexes only what that user can access. Access is controlled entirely within Guru, independent of Source app permissions.“ Šaltinio sistemos teisių užklausos metu iš viso neklausiama. Ir čia verta atkreipti dėmesį į kitą dalyką: Guru rinkodaros puslapyje parašyta besąlygiškai, kad „Permissions are inherited from your existing systems and enforced in real time“, o dokumentacijoje tas paveldėjimas yra tik vienas iš dviejų modelių, veikiantis tik daliai šaltinių ir reikalaujantis, kad šaltinio sistemą prijungtų jos administratorius.
• Dust teises sumuoja: „Permissions are additive. If a person belongs to several groups, they receive the combined permissions granted by those groups.“ Tik sumuojant blogai apibrėžta grupė prieigą tyliai praplečia, o atgal nieko nesusiaurina.

Praktinė išvada Lietuvos vadovui viena: prieigos teisių sutvarkymas yra atskiras projektas, kurį reikia padaryti prieš diegimą, o ne po jo. Tai ne DI darbas, o teisių higienos darbas, ir jis brangiausias tada, kai atidedamas.

Antras lūžis: ES saugojimas neapima skaičiavimo

Rinkoje „duomenų saugojimas ES“ beveik visada reiškia saugojimą ramybės būsenoje. Modelis, kuris jūsų dokumentus perskaito ir parašo atsakymą, yra atskira paslauga, dažnai atskira bendrovė, ir jis dažnai veikia kitur.

Aštriausią sakinį šioje temoje parašė ne kritikas, o pats tiekėjas. Sana subtvarkytojų sąraše apie savo modelių tiekėją rašo: „Routing is dependent on configurations as agreed between the Subscriber and Sana. If no specific agreement has been entered into, default worldwide routing will apply.“ Tai bendrovė savo pačios atitikties dokumente pasakanti, kad be atskiro susitarimo kliento turinys maršrutizuojamas visame pasaulyje.

Ir čia svarbu neperlenkti į kitą pusę. Slack atvejis yra ne toks, kad Slack pasakytų kažką nepalankaus, o toks, kad Slack nesako nieko: jos duomenų saugojimo regiono straipsnyje išvardytos dengiamos kategorijos, o DI kategorijos tarp jų nėra. Teisinga formuluotė yra būtent tokia, o ne „Slack sako, kad DI išeina iš jūsų regiono“. Slack to nesako.

Microsoft pakeitė numatytąjį nustatymą 2026 m. kovo 25 d.

Tai svarbiausias šių metų pokytis šioje srityje, ir didžioji dalis internete esančio turinio jo dar nepasivijo.

Microsoft ES duomenų ribos išimčių registre užrašyta: „To help maintain a consistent Copilot experience during periods of peak demand, Copilot prompts, responses, and grounding data may be processed outside the EU Data Boundary for AI inferencing, including in the United States, Canada, and Australia.“ Mechanizmas vadinamas flex routing, o numatytasis nustatymas yra toks: „Flex routing is on by default for eligible tenants that were created after March 25, 2026.“ Anksčiau sukurtoms organizacijoms liepiama savo nustatymą pasitikrinti Message Center, o tai reiškia, kad ES įmonė savo pačios atsakymo nežino, kol nenueina pažiūrėti.

Paieška ar agentas: trys klausimai, kurie tai atskiria

Šiandien agentu save vadina visi, įskaitant produktus, kurių dokumentuotas elgesys yra „susirask ir atsakyk“. Žodis pirkėjui nieko nepasako. Architektūriškai skirtumas siauresnis ir daug naudingesnis: agentas gali iškviesti rašymo įrankius, keičiančius įrašą sistemoje, ir todėl produktas privalo turėti patvirtinimo žingsnį ir valdiklį jam išjungti.

1. Ar yra atskiras, atskirai valdomų teisių rašymo paviršius? Atlassian tai išskiria komponentais: „Knowledge: the data the agent can reference“ ir „Skills: actions that your agent is allowed to take, such as draft a Confluence page or send Slack messages“. Grynoje paieškos sistemoje antrojo objekto tiesiog nėra.

2. Ar yra planuotojas, kuris pats renkasi žingsnius? Jei sistema visada eina tuo pačiu keliu „susirask, tada parašyk“, tai paieška su gražiu langu.

3. Kas gali išjungti žmogaus patvirtinimą? Glean administratoriaus dokumentacijoje: „When tools are enabled to run without user confirmation, Glean automatically executes the tool based on AI-predicted values and might update the system of record“, o „Admins determine which tools are allowed to run without confirmation“ ir „End users must grant consent“. Atlassian priduria: „Without automations and setup from an admin, agents can't work autonomously.“

Tiekėjas, kuris į rašymo klausimą aiškiai neatsako, pardavinėja paiešką. Tai nėra blogai, jei jums to ir reikia. Blogai yra mokėti agento kainą už paieškos produktą.

Ką tiekėjai iš tikrųjų pažada

Antrą ir trečią stulpelį skaitykite kaip du atskirus atsakymus. Šešiose iš devynių eilučių jie skiriasi.

Šeši klausimai tiekėjui, raštu

Kiekvieną iš jų apgalvojęs tiekėjas atsako vienu sakiniu, ir į kiekvieną bent vienas šios apžvalgos tiekėjas atsako kliento nenaudai. Būtent todėl jie ir verti klausimo.

Klauskite raštu, o ne pokalbyje. Rašytinis atsakymas yra tas, kuris nukeliauja į duomenų tvarkymo sutartį ir kurį galima padėti prieš duomenų apsaugos pareigūną. Ką tie patys tiekėjai daro su duomenimis pagal paskyros tipą, surašėme atskirai puslapyje ar DI tiekėjas mokosi iš jūsų duomenų.

Kur šiame paveiksle esame mes, įskaitant tai, ko neturime

Statome ES aplinkoje, ir tikslesnė šio sakinio versija yra siauresnė už rinkodarinę, todėl štai tikslesnė. Duomenys tvarkomi ir saugomi serveriuose Europos Sąjungos viduje. Kai paslaugą teikiant dalyvauja subtvarkytojas, bet koks perdavimas už ES ar EEE ribų vyksta su BDAR reikalaujamomis apsaugos priemonėmis, o patys subtvarkytojai įvardyti mūsų privatumo politikoje, o ne rinkodaros puslapyje. Tik ES vykdomas apdorojimas galimas pagal atskirą prašymą tiems diegimams, kuriems to reikia. Ko nesakome, nes tai neatlaikytų to paties patikrinimo, kurį šiame puslapyje taikome visiems kitiems, yra kad jokie duomenys niekada jokiomis aplinkybėmis neišeina iš ES.

Ko neturime, tokiame puslapyje svarbu ne mažiau. Ainora neturi jokio SOC 2 ataskaitos ir jokio ISO sertifikato. Glean, Sana, Notion, Slack, Atlassian, Microsoft ir Google turi ir SOC 2, ir ISO 27001, keli iš jų dar ir ISO 42001, o Dust deklaruoja SOC 2 Type II. Tai jų kredencialai, ne mūsų, ir infrastruktūros tiekėjo sertifikatas taip pat yra jo, o ne mūsų. Jei jūsų pirkimo procesui reikia tiekėjo SOC 2 ataskaitos, mes jos neturime ką duoti, ir tai geriau sužinoti iš palyginimo puslapio nei trečią vertinimo savaitę. Veikimo laiką skelbiame, nes jis tikras: 99,9 proc.

Kainos mūsų individualios ir derinamos kiekvienam projektui atskirai, o ne skelbiamos. Skaidrumo prasme tai ta pati kategorija kaip Glean ir Guru, ir tai atsilikimas nuo Dust, Notion, Slack, Microsoft ir Google. Tai ne pasigyrimas, o tiesiog teisingas lentelės langelis.

Kaip visa tai atrodo praktikoje, aprašėme puslapyje DI komandos narys įmonėje, o vieno tiekėjo pjūviai surinkti tiekėjų kataloge.