Mākslīgais intelekts biznesā

Kā izveidot uzņēmuma MI asistentu, kas droši izmanto iekšējos dokumentus?

Praktisks ceļvedis uzņēmuma MI asistenta izveidei: dokumentu meklēšana, piekļuves tiesības, RAG arhitektūra, datu aizsardzība un drošības testēšana.

Kā izveidot uzņēmuma MI asistentu, kas droši izmanto iekšējos dokumentus?

Uzņēmuma dokumentos bieži glabājas liels daudzums vērtīgas informācijas: darba procedūras, līgumu paraugi, produktu apraksti, tehniskās instrukcijas, cenu politika, klientu apkalpošanas vadlīnijas un darbinieku apmācību materiāli.

Problēma sākas brīdī, kad darbiniekam nepieciešamā atbilde jāmeklē desmitiem mapju, e-pasta pielikumu un dažādās viena dokumenta versijās. Meklēšana aizņem laiku, turklāt ne vienmēr ir skaidrs, vai atrastā informācija joprojām ir aktuāla.

Uzņēmuma MI asistents var ļaut darbiniekam uzdot jautājumu dabiskā valodā un saņemt atbildi, kas sagatavota, izmantojot uzņēmuma iekšējos dokumentus.

Piemēram:

  • Kāda ir izdevumu apstiprināšanas kārtība?
  • Kurš līguma paraugs jāizmanto konkrētajam klientam?
  • Kā rīkoties, ja klients vēlas atcelt pasūtījumu?
  • Kādi dokumenti nepieciešami jauna darbinieka pieņemšanai?
  • Kāds ir konkrētā produkta garantijas termiņš?

Tomēr iekšējo dokumentu pievienošana MI sistēmai rada arī būtiskus riskus. Nepareizi izveidots asistents var parādīt konfidenciālu informāciju lietotājam, kuram tā nav paredzēta, izmantot novecojušu dokumenta versiju vai pārliecinoši izveidot atbildi, kurai avotos nav pamatojuma.

Tāpēc droša MI asistenta izveide jāsāk nevis ar dokumentu augšupielādi, bet gan ar skaidru arhitektūru, piekļuves modeli un riska pārvaldības noteikumiem.

Kas ir uzņēmuma MI asistents?

Uzņēmuma MI asistents ir sistēma, kas izmanto valodas modeli, lai palīdzētu darbiniekiem atrast, apkopot un saprast organizācijas informāciju.

Vienkāršākajā variantā asistents:

  1. saņem darbinieka jautājumu;
  2. sameklē atbilstošus fragmentus uzņēmuma dokumentos;
  3. nosūta atrastos fragmentus valodas modelim;
  4. sagatavo atbildi;
  5. parāda izmantotos avotus.

Šādu pieeju bieži sauc par retrieval-augmented generation jeb RAG. Valodas modelis nepaļaujas tikai uz savām vispārīgajām zināšanām, bet atbildes sagatavošanai saņem konkrētus fragmentus no uzņēmuma dokumentiem.

RAG ir piemērots iekšējai zināšanu bāzei, jo dokumentus iespējams papildināt un atjaunināt, nepārmācot visu valodas modeli.

Tomēr RAG pats par sevi nav drošības mehānisms. Ar dokumentu izgūšanu vien nepietiek, lai novērstu promptu injekcijas, neatļautu piekļuvi vai konfidenciālas informācijas noplūdi.

1. Sāciet ar vienu konkrētu lietošanas scenāriju

Pirmajai MI asistenta versijai nevajadzētu mēģināt atbildēt uz pilnīgi visiem uzņēmuma jautājumiem.

Drošāk ir izvēlēties vienu skaidri ierobežotu lietošanas scenāriju, piemēram:

  • personāla procedūru skaidrošanu;
  • iekšējo IT instrukciju meklēšanu;
  • produktu dokumentācijas asistentu;
  • klientu apkalpošanas zināšanu bāzi;
  • kvalitātes vadības dokumentu meklētāju;
  • produktu asistentu pārdošanas komandai.

Katram scenārijam jānosaka:

  • kas drīkst izmantot asistentu;
  • kuri dokumenti tam ir pieejami;
  • uz kādiem jautājumiem tas drīkst atbildēt;
  • kādus datus tas nedrīkst apstrādāt;
  • vai atbildi drīkst izmantot bez cilvēka pārbaudes;
  • kā tiks mērīta atbilžu kvalitāte.

Ja projekta robežas nav skaidri noteiktas, dokumentu apjoms, piekļuves tiesības un drošības prasības ātri var kļūt nekontrolējamas.

2. Inventarizējiet un klasificējiet dokumentus

Pirms dokumentu savienošanas ar MI asistentu jāizveido datu avotu uzskaite.

Dokumentus vēlams sadalīt vismaz trīs kategorijās.

Publiska informācija

Materiāli, kurus uzņēmums varētu publicēt arī savā mājaslapā:

  • produktu apraksti;
  • publiskas instrukcijas;
  • biežāk uzdotie jautājumi;
  • mārketinga materiāli.

Iekšējai lietošanai paredzēta informācija

Dokumenti, kuri paredzēti darbiniekiem, bet kuru izpaušana parasti neradītu kritisku kaitējumu:

  • darba procedūras;
  • iekšējās instrukcijas;
  • apmācību materiāli;
  • projektu darba veidnes.

Konfidenciāla informācija

Dokumenti, kuriem nepieciešama stingra piekļuves kontrole:

  • klientu dati;
  • līgumi;
  • cenu veidošanas modeļi;
  • finanšu informācija;
  • personāla dokumenti;
  • komercnoslēpumi;
  • drošības procedūras.

Sākotnējā pilotprojektā vēlams izmantot tikai pirmās divas kategorijas.

Īpašu kategoriju personas datus, sensitīvu personāla informāciju un kritiskas piekļuves instrukcijas nevajadzētu pievienot bez datu aizsardzības un informācijas drošības speciālistu izvērtējuma.

GDPR paredz nolūka ierobežojuma, datu minimizācijas, glabāšanas ierobežojuma, integritātes un konfidencialitātes principus. Tas nozīmē, ka uzņēmumam jāspēj pamatot, kāpēc konkrēti personas dati MI asistentam ir nepieciešami un cik ilgi tie tiks glabāti.

3. Neizmantojiet valodas modeli kā dokumentu noliktavu

Drošā arhitektūrā dokumenti parasti netiek vienkārši ievietoti valodas modelī uz nenoteiktu laiku.

Tā vietā tie tiek glabāti kontrolētā uzņēmuma krātuvē, dokumentu vadības sistēmā vai meklēšanas infrastruktūrā.

Kad lietotājs uzdod jautājumu, sistēma atrod tikai dažus atbilstošākos fragmentus un nosūta tos modelim atbildes sagatavošanai.

Tipiska arhitektūra ietver:

  • dokumentu avotus;
  • dokumentu apstrādes un indeksēšanas procesu;
  • piekļuves tiesību metadatus;
  • meklēšanas vai vektoru datubāzi;
  • valodas modeli;
  • atbilžu avotu norādes;
  • audita žurnālus.

Šāda pieeja ļauj dokumentu izdzēst, aizstāt vai atjaunināt, nepārveidojot visu sistēmu.

Tā arī palīdz kontrolēt, kāda informācija tiek nosūtīta ārējam modeļa pakalpojuma sniedzējam.

4. Saglabājiet dokumentu sākotnējās piekļuves tiesības

Viena no būtiskākajām kļūdām ir visu dokumentu ievietošana vienā kopīgā zināšanu bāzē bez piekļuves ierobežojumiem.

Ja darbinieks nedrīkst atvērt dokumentu uzņēmuma failu sistēmā, viņš nedrīkst saņemt tā saturu arī ar MI asistenta palīdzību.

Katram dokumentam jāsaglabā metadati, piemēram:

  • nodaļa;
  • dokumenta īpašnieks;
  • konfidencialitātes līmenis;
  • atļautās lietotāju grupas;
  • valsts vai juridiskā vienība;
  • dokumenta derīguma termiņš;
  • versijas numurs.

Pirms dokumentu meklēšanas sistēmai jāidentificē lietotājs un jāfiltrē saturs atbilstoši viņa tiesībām.

Šī filtrēšana jāveic pirms fragmentu nosūtīšanas valodas modelim, nevis tikai pēc atbildes sagatavošanas.

Nulles uzticēšanās jeb zero trust pieeja balstās uz konkrētu resursu aizsardzību un katra piekļuves pieprasījuma pārbaudi. Lietotājs netiek automātiski uzskatīts par uzticamu tikai tāpēc, ka atrodas uzņēmuma tīklā.

Praksē drošs risinājums var izmantot:

  • vienoto pierakstīšanos;
  • daudzfaktoru autentifikāciju;
  • lomu vai atribūtu piekļuves kontroli;
  • minimālo nepieciešamo tiesību principu;
  • regulāru lietotāju tiesību pārskatīšanu;
  • tūlītēju piekļuves slēgšanu pēc darba attiecību beigām.

5. Kontrolējiet dokumentu pievienošanas procesu

Arī pats dokuments var kļūt par uzbrukuma avotu.

Ļaunprātīgs vai neuzmanīgi sagatavots fails var saturēt instrukcijas, kas mēģina mainīt MI asistenta uzvedību. Piemēram, dokumentā var būt paslēpts norādījums ignorēt sistēmas noteikumus, atklāt citu dokumentu saturu vai izpildīt neatļautu darbību.

Šādu risku sauc par netiešu promptu injekciju.

Dokumentu pievienošanas procesā vēlams:

  • atļaut tikai noteiktus failu formātus;
  • pārbaudīt failus pret ļaunprogrammatūru;
  • ierobežot maksimālo faila izmēru;
  • reģistrēt dokumenta augšupielādētāju;
  • pārbaudīt dokumenta īpašnieku;
  • kontrolēt ārējās saites;
  • saglabāt dokumenta izcelsmi;
  • nepieļaut automātisku neuzticamu ārējo failu importu;
  • nodalīt lietotāju augšupielādētos failus no apstiprinātās zināšanu bāzes.

Īpaši svarīgi ir precīzi noteikt, kuri darbinieki drīkst pievienot dokumentus, kas automātiski kļūs pieejami citiem lietotājiem.

6. Pārvaldiet dokumentu versijas un aktualitāti

MI asistenta atbilde var būt tehniski pareiza, bet biznesam nederīga, ja tā balstīta novecojušā dokumentā.

Katram avotam vēlams saglabāt:

  • dokumenta izveides datumu;
  • pēdējo izmaiņu datumu;
  • spēkā stāšanās datumu;
  • atbildīgo personu;
  • dokumenta statusu;
  • saiti uz aizstājošo dokumentu;
  • nākamās pārskatīšanas termiņu.

Sistēmai pēc noklusējuma jāizvēlas jaunākā apstiprinātā dokumenta versija.

Arhivētus dokumentus var saglabāt juridiskām vai vēsturiskām vajadzībām, taču tiem nevajadzētu automātiski piedalīties ikdienas atbilžu sagatavošanā.

Atbildē lietotājam vēlams parādīt ne tikai dokumenta nosaukumu, bet arī versiju un datumu.

7. Pieprasiet avotus katrai būtiskai atbildei

Drošs uzņēmuma MI asistents nedrīkst radīt iespaidu, ka tas vienmēr zina vienīgo pareizo atbildi.

Atbildē vēlams parādīt:

  • izmantotā dokumenta nosaukumu;
  • konkrēto sadaļu;
  • dokumenta versiju;
  • saiti uz oriģinālo avotu;
  • brīdinājumu, ja informācija nav pietiekama.

Sistēmas instrukcijās jānosaka, ka asistents:

  • atbild tikai no atļautajiem avotiem;
  • neizdomā trūkstošu informāciju;
  • skaidri norāda nenoteiktību;
  • iesaka sazināties ar atbildīgo personu, ja avoti ir pretrunīgi;
  • neatbild, ja lietotājam nav piekļuves nepieciešamajam dokumentam.

Avotu parādīšana nenovērš visas kļūdas, taču ļauj darbiniekam ātri pārbaudīt atbildes precizitāti un aktualitāti.

8. Izvērtējiet modeļa un pakalpojuma sniedzēja noteikumus

Pirms uzņēmuma dokumentu nosūtīšanas ārējam MI pakalpojumam jānoskaidro:

  • vai ievades dati tiek izmantoti modeļa apmācībai;
  • cik ilgi tiek glabāti pieprasījumi un atbildes;
  • kurā reģionā dati tiek apstrādāti;
  • kādi apakšapstrādātāji ir iesaistīti;
  • vai pieejams datu apstrādes līgums;
  • vai iespējams konfigurēt datu glabāšanas termiņu;
  • kā notiek datu dzēšana;
  • vai dati tiek šifrēti pārraidē un glabāšanā;
  • vai pieejami drošības audita apliecinājumi;
  • kā tiek ziņots par drošības incidentiem.

Šie nosacījumi jāpārbauda līgumā un tehniskajā dokumentācijā, nevis jāpieņem, balstoties tikai uz mārketinga materiāliem.

Personas datu izmantošana MI risinājumu izstrādē un ieviešanā jāvērtē katrā gadījumā atsevišķi.

9. Sāciet ar tikai lasīšanas režīmu

Iekšējo dokumentu asistenta pirmajai versijai vēlams ļaut tikai:

  • meklēt;
  • apkopot;
  • salīdzināt;
  • paskaidrot;
  • sagatavot melnrakstus.

Tam nevajadzētu automātiski:

  • mainīt dokumentus;
  • nosūtīt e-pastus;
  • apstiprināt maksājumus;
  • mainīt klientu datus;
  • parakstīt līgumus;
  • dzēst failus;
  • izveidot lietotāju kontus.

Ja asistents vēlāk saņem piekļuvi uzņēmuma rīkiem, katrai darbībai jābūt skaidri ierobežotai, reģistrētai un pārbaudāmai.

Augsta riska darbībām nepieciešams cilvēka apstiprinājums.

Pārmērīga autonomija rodas brīdī, kad MI sistēmai tiek piešķirtas plašākas tiesības vai funkcijas, nekā nepieciešams tās konkrētajam uzdevumam.

10. Izveidojiet testus pirms sistēmas palaišanas

Pirms asistenta nodošanas darbiniekiem nepieciešami gan kvalitātes, gan drošības testi.

Atbilžu kvalitātes testi

Sagatavojiet 50–100 reālus jautājumus un pārbaudiet:

  • vai atrasts pareizais dokuments;
  • vai atbilde atbilst avotam;
  • vai norādīta pareizā dokumenta versija;
  • vai nav pievienota izdomāta informācija;
  • vai atbilde ir saprotama.

Piekļuves kontroles testi

Izveidojiet dažādu lomu lietotājus un pārbaudiet:

  • vai pārdošanas darbinieks nevar atrast personāla dokumentus;
  • vai ārpakalpojuma lietotājs neredz iekšējos finanšu datus;
  • vai bijušā darbinieka piekļuve tiek slēgta;
  • vai dokumenta nosaukums netiek atklāts bez atļaujas;
  • vai fragments no neatļauta dokumenta nenonāk atbildē.

Uzbrukumu testi

Mēģiniet sistēmu apzināti maldināt:

  • lūdziet ignorēt drošības noteikumus;
  • pieprasiet citam lietotājam paredzētu informāciju;
  • augšupielādējiet dokumentu ar slēptām instrukcijām;
  • uzdodiet jautājumu, uz kuru dokumentos nav atbildes;
  • mēģiniet panākt sistēmas instrukciju atklāšanu.

Ģeneratīvā MI riski jāpārvalda visā sistēmas dzīves ciklā, ietverot pārvaldību, mērīšanu, testēšanu un regulāru risku pārskatīšanu.

Praktisks ieviešanas plāns

1. posms: definējiet mērķi

Izvēlieties vienu nodaļu, vienu dokumentu grupu un vienu konkrētu lietošanas scenāriju.

2. posms: sakārtojiet dokumentus

Noņemiet dublikātus, arhivējiet novecojušās versijas un piešķiriet dokumentiem atbildīgos īpašniekus.

3. posms: izveidojiet piekļuves modeli

Nosakiet, kuras lietotāju grupas drīkst meklēt katrā dokumentu kategorijā.

4. posms: izstrādājiet pilotversiju

Sāciet ar tikai lasīšanas režīmu, ierobežotu lietotāju skaitu un zema riska dokumentiem.

5. posms: testējiet

Pārbaudiet atbilžu precizitāti, datu noplūdes risku, promptu injekcijas un piekļuves kontroli.

6. posms: ieviesiet uzraudzību

Reģistrējiet kļūdas, lietotāju atsauksmes, izmantotos avotus un drošības incidentus.

7. posms: paplašiniet pakāpeniski

Ja pilotprojekts ir veiksmīgs, pievienojiet nākamo dokumentu grupu vai nodaļu, atkārtoti veicot riska novērtējumu.

Biežākās kļūdas

Visu dokumentu pievienošana vienlaikus

Tas palielina datu noplūdes, novecojušas informācijas un piekļuves kļūdu risku.

Paļaušanās tikai uz sistēmas instrukciju

Teksta norādījums “neatklāj konfidenciālu informāciju” nevar aizstāt tehnisku piekļuves kontroli.

Dokumentu tiesību zaudēšana indeksēšanas laikā

Ja meklēšanas datubāzē netiek saglabātas sākotnējās atļaujas, asistents var apiet uzņēmuma failu sistēmas ierobežojumus.

Avotu neparādīšana

Bez dokumenta saites darbinieks nevar pārbaudīt, vai atbilde ir pareiza un aktuāla.

Pārāk plašu darbību tiesību piešķiršana

Asistentam nevajadzētu saņemt iespēju mainīt uzņēmuma sistēmas tikai tāpēc, ka tehniski tas ir iespējams.

Droša MI asistenta kontrolsaraksts

Pirms sistēmas palaišanas pārbaudiet:

  • Vai definēts konkrēts lietošanas scenārijs?
  • Vai izveidota dokumentu un datu avotu uzskaite?
  • Vai dokumentiem piešķirti konfidencialitātes līmeņi?
  • Vai personas dati tiek izmantoti tikai pamatotā apjomā?
  • Vai saglabātas dokumentu sākotnējās piekļuves tiesības?
  • Vai lietotāji tiek droši autentificēti?
  • Vai meklēšana tiek filtrēta pirms datu nosūtīšanas modelim?
  • Vai dokumentiem ir īpašnieki un versiju kontrole?
  • Vai atbildēs tiek rādīti avoti?
  • Vai asistents spēj atteikties no nepamatotas atbildes?
  • Vai pirmajai versijai nav nevajadzīgu darbību tiesību?
  • Vai pārbaudīti pakalpojuma sniedzēja datu izmantošanas noteikumi?
  • Vai veikti piekļuves un promptu injekcijas testi?
  • Vai tiek uzturēti audita žurnāli?
  • Vai noteikta incidentu un kļūdu ziņošanas kārtība?

Secinājums

Drošs uzņēmuma MI asistents nav tikai tērzēšanas logs, kuram pievienoti daži dokumenti.

Tas ir pilnvērtīgs informācijas sistēmas risinājums ar lietotāju identitātes pārbaudi, dokumentu klasifikāciju, piekļuves kontroli, versiju pārvaldību, audita žurnāliem un regulāru testēšanu.

Drošākā pieeja ir:

  • sākt ar vienu konkrētu lietošanas scenāriju;
  • izmantot zema riska un sakārtotus dokumentus;
  • saglabāt dokumentu sākotnējās piekļuves tiesības;
  • izgūt tikai konkrētajam lietotājam atļautu informāciju;
  • katrai būtiskai atbildei parādīt avotu;
  • nepiešķirt asistentam nevajadzīgu autonomiju;
  • pārbaudīt personas datu apstrādes pamatojumu;
  • veikt kvalitātes un drošības testus;
  • paplašināt sistēmu pakāpeniski.

MI asistenta vērtība nav tikai ātrāka dokumentu meklēšana.

Pareizi izveidota sistēma palīdz saglabāt uzņēmuma zināšanas, vienādot darba procesu izpildi un samazināt laiku, ko darbinieki pavada, meklējot nepieciešamo informāciju.