LLM-жобаларында деректер құқықтары: іске қосардан бұрын не келісу керек

LLM-жобаларында деректермен қандай мәселе туындайды

Көбінесе мәселе мынада: деректер мен контент туралы сұрақтарды кейінге қалдырады. Команда жедел пилот жинайды: құжаттарды қосады, CRM-ден экспорттарды жүктейді, қолдау чаттарын қосады, логтауды белсендіреді. Ал кімнің бұл материалдарды пайдалануға құқығы бар, олар қайда сақталады және модельдің жауаптары үшін кім жауапты — бұл сұрақтар алғашқы көрсетілімнен кейін, жобаны тоқтату қиын әрі қымбат болғанда ғана шығады.

Осындай жағдай пайда болады, өйткені әркімнің өз «нормасы» бар. IT қауіпсіздік пен қолжетімділік туралы ойлайды, заң бөлімдері лицензиялар мен келісімдерге назар аударады, бизнес пайда мен жылдамдықты талап етеді, мердігер нәтиженің сапасына назар аударады. Ал алдын ала бекітілген ережелер болмаса, барлығы "өздері түсінеді" деп ойлайды, бірақ нақты келісімдер жоқ болады.

Зияндар да нақты: пилот тоқтатылуы немесе эксплуатацияға жіберілмеуі мүмкін, құқық иелері немесе реттеуші талап қояды, сезімтал ақпарат логтар мен промпттар арқылы ағуы ықтимал, ал қате жауаптар ресми түрде қабылдануы мүмкін. Әдетте практикалық шығындар да қосылады: деректерді қайта өңдеу (тазалау, қайта маркалау, қайта баптау, индекс қайта құру) шығындары.

Оқыту мен эксплуатацияға өтерден бұрын бөлек келісу керек: қандай көздер рұқсат етілген, оларды қандай негізде пайдалануға болады, тыйым салынған деректер қайсы, логтар қанша уақыт сақталады және кімде оларға қолжетімділік бар, сондай-ақ нәтижеге кім және қандай жағдайда жауап береді.

Риск әр сценарийге қарай өзгереді. Ішкі чат-бот көбіне құпиялылық пен қолжетімділік шектеулеріне ұшырайды. Клиенттерге арналған сыртқы сервис жария уәделер, авторлық құқықтар және логтар мен шешімнің дәлелдемесіне қатысты қатал талаптарды қосады. Сондықтан "LLM жобаларындағы деректер құқықтары" деген сұрақтарды бірінші интеграциядан бұрын құжатпен жабу тиімді.

Жобаға қандай деректер мен контент кіреді

Ережелерді келісерден бұрын жүйеге өтетін барлық ақпарат қабаттарын атау пайдалы. Командалар көбіне тек құжаттарды ойлайды, бірақ жобаға басқа да контент түрлері қосылады және олардың да иесі мен шектеулері болуы мүмкін.

Жиі төрт топ айрылады.

Біріншісі — оқыту немесе дооқытуға арналған деректер: мәтін жинақтары, кестелер, хат-хабарламалар, разметка, «дұрыс» жауаптардың мысалдары.

Екіншісі — іздеу (RAG) деректері: база знаний, нұсқаулықтар, регламенттер, тикеттер мен мақалалар — модель сұрау жіберген кезде оқитын материалдар.

Үшіншісі — промпттағы деректер: қолданушы қолмен кіргізетін нәрсе (шарт фрагменттері, хаттар, мәтін скриншоттары), сондай-ақ жүйелік ұсыныстар мен шаблондар.

Төртіншісі — модель шығыстары: жауаптар, жинақтамалар, хат жобаcтары, есептер, ұсыныстар, код фрагменттері. Бұл жаңа контент, бірақ онда бастапқы көздердің цитаталары немесе қайта баяндалуы болуы мүмкін.

Жиі ұмытылатын бөлік — метадеректер. Мәтінсіз де олар сезімтал болуы мүмкін: кім сұрады, қашан, қай бөлімнен және қай жүйеден, қандай тақырып бойынша. Мұндай таңбалар арқылы кейде тапсырманың контекстін қалпына келтіруге болады.

Тағы бір қабат — логтар мен телеметрия. Логтар инциденттерді талдау, сапаны жақсарту және «кім не істегенін» дәлелдеуде қажет. Телеметрия жүктеме, қателер, кідірістерді көрсетеді. Мұнда не жазылатынын (толық сұрау немесе тек техникалық белгілер), қайда сақталатынын, кімде қолжетімді екенін, қанша уақыт сақталатынын және қалай жойылатынын алдын ала шешіңіз.

Егер осы деректер картасын іске қосардан бұрын құрастырсаңыз, әрі қарай рұқсаттар, сақтау мерзімдері мен жауапкершілікті талқылау оңайырақ болады.

Рөлдер және жауапкершілік: кім не үшін жауап береді

LLM жобаларында даулы жағдайлар әдетте модельден емес, кім құжаттарға рұқсат бергені және қандай шартта бергені туралы туындайды. Жүктеуді бастамас бұрын рөлдерді жазбаша бекіту керек.

Алдымен бастапқы материалдардың иелерін нақты атаңыз. Бұл тапсырыс беруші (ішкі регламенттер, база знаний), мердігер (өз әдістемелер, промпттар, шаблондар) немесе үшінші тұлғалар (стандарттар, мақалалар, коммерциялық деректер) болуы мүмкін. Егер жинақта үшінші тарап контенті болса, кім рұқсат алатынын және кім растайтын құжаттарды сақтайтынын алдын ала анықтаңыз.

Содан кейін деректерді өңдеу бойынша жауапкершілікті бөліңіз. Қарапайым түрде бұл сұрақтарға жауап беру: қайсысы қандай деректерді пайдалануға болатынын шешеді, кім қолжетімдікті қамтамасыз етеді, егер логта артық ақпарат түскен болса кім жауап береді. Бизнес-нәтиженің иесін бөлек тағайындаңыз: модель жауаптарын кім нұсқау ретінде қабылдайды және кім оларды клиентке немесе қызметкерге жібермес бұрын бекітеді.

Қолжетімділіктің ең аз өкілеттілігін бекіту пайдалы. Мысалы: жаңа көздерді (қалталар, пошта, CRM, ішкі порталдар) кім қоса алады, кімге және қандай негізде қолжетімділік береді, тыйым салынған құжаттар мен деректер түрлерін кім бекіте алады, жауаптардың сапасын кім тексеріп, инциденттерді кім талдайды.

Практикалық схема мынадай болуы мүмкін: қауіпсіздік тек бекітілген көздерге рұқсат береді, заң бөлімі сыртқы материалдарға құқықтарды растайды, IT сақтау мен қолжетімдікті бақылайды, ал процестің иесі (мысалы, HR немесе қолдау қызметі) жауап береді — қай жерде жауаптарды адам тексерусіз қолдануға болады, ал қай жерде міндетті бақылау қажет.

Құжат көздері: не қосуға болады және қандай шарттармен

Жобаға LLM арқылы білім алу көздерінің нақты тізімін бекіту маңызды — бұл сапаға да, құқықтық тәуекелдерге де әсер етеді: негізсіз қосылған көз үшін жауапкершілік көбінесе процестің иесіне түседі.

Көбіне қауіпсіздігі жоғары бастау «ресми» материалдардан келеді: иесі және қолжетімділік ережелері анық болатын ішкі база знаний, бекітілген регламенттер мен нұсқаулықтар, шарт шаблондары, қызмет каталогтары, FAQ, порталдың жабық бөліктері. Қызмет орталығының тикеттері мен өтініштері де пайдалы болуы мүмкін, бірақ оларды жеке деректерден тазалап және қолдану мақсатын айқындап қана қосқан жөн.

Тест үшін де қосуға болмайтындарды келісіңіз. Тыйым салынған аймаққа жиі қызметкерлердің жеке хат-хабарламалары, жобаланған нұсқалар мен бекітілмеген құжаттар, құқықтары жоқ сыртқы материалдар (соның ішінде пираттық) және дерек шығу тегін дәлелдеу мүмкін емес выгрузкалар кіреді.

Модель ескірген ережелерге негізделіп жауап бермес үшін құжаттың өзектілігін қалай растайтынын алдын ала сипаттаңыз. Минимум — әр құжат түрі үшін «сенімнің бір ұяшығы»: бекіту күні, нұсқаның нөмірі, иесі, қайта қарау мерзімі. Егер бұл белгілер болмаса, құжатты қосу жөн болмас.

Жаңарту ережелері қарапайым және тексерілетін болуы тиіс: кім құжаттарды қосады (ролі көрсетілген, аты емес), кім мазмұн мен құқықтарды тексереді, ревизия қаншалықты жиі жасалады, ескі нұсқалармен не болады және өзгерістер қалай тіркеледі.

Типтік қате — көмектесушіге «нұсқаулық» қалтасын қосады, ал ішінде бір регламенттің екі нұсқасы тұрады. Модель қателесіп қарсы пікір бере бастайды. Бір реестр — көздер мен нұсқалар үшін — көп мәселелерді алдын ала шешеді.

Контентті пайдалану үшін рұқсаттар мен лицензиялар

Құжаттардың қайдан алынғаны ғана емес, сонымен қатар онымен не жасауға рұқсат барын анықтау маңызды. Бір файл адамға оқу үшін заңды болуы мүмкін, бірақ оны индекстеп алу, аудару, қайта өңдеу немесе оқыту үшін пайдалану тыйым салынған болуы мүмкін.

Қай құқықтар әсер етуі мүмкінін тексеріңіз. Көбінесе авторлық құқық (мәтін, схема, сурет), туыстық құқықтар, дерекқорға құқықтар (ұсыныстың құндылығы құрылымы мен жинақта болса), коммерциялық лицензия шарттары. Тіпті ішкі құжат болса да құқықтар мердігерге немесе бұрынғы қызметкерге тиесілі болуы мүмкін.

Пайдалану мақсатын міндетті түрде жазып алыңыз. "ИИ-де пайдалану" деген жалпы мақсап анық емес: іздеу, цитаталау, қайта баяндау, нұсқаулар генерациясы, модельді оқыту, аудару — әрқайсысына бөлек рұқсат керек болуы мүмкін.

Көбіне дау-дамайлар көшірмелерді сақтау (толық немесе кэш), жауаптардағы үзінділерді цитаталау, индексілеу және метадеректерді байыту, аудару мен переформулировка, сондай-ақ дооқыту үшін пайдалану тақырыптарында туындайды (доңғалақ ретінде дооқыту әдетте жеке келісімді талап етеді).

Серіктестер мен вендорлар контентімен арнайы сақ болыңыз. Техникалық құжаттама, оқу материалдары, коммерциялық есептер көбіне тек ішкі оқу үшін рұқсат етілген, бірақ сыртқы сервистерге жүктеуге, қайта өңдеуге немесе пайдаланушыларға ұзақ дәлме-дәл үзінді көрсетуге тыйым салынуы мүмкін. Интеграциялық жоба жүргізіп жатсаңыз, нақты әрекеттер үшін жазбаша рұқсат сұраңыз немесе тек ашық лицензиялы көздерді пайдаланыңыз.

Дауларды болдырмау үшін шектеулерді ТЗ мен келісімшартқа қарапайым тілмен жазып қойған жөн: қандай көздер рұқсат етілген, қандай әрекеттерге рұқсат/тиым салынған, көшірмелер сақталуы мүмкін бе, лицензияларды кім алады, қандай әрекеттер бұзушылық саналады (мысалы, ұзақ цитаталар немесе үшінші тұлғалар деректері негізінде оқыту).

Жеке және құпия деректер: шектеулер мен шаралар

LLM жобаларында жиі туындайтын мәселе — модель қандай мәліметті көре алады, ал қайсысы әрқашан жасырылуы тиіс. Бұл заң мен ішкі ережелерді сақтау және жауаптар, логтар немесе чат тарихы арқылы деректердің ағуын азайту үшін маңызды.

Алдымен сіздің ұйымыңызда қандай категориялар жеке және сезімтал саналатынын бекітіңіз. Әдетте бұл ФИО, ИИН, телефон нөмірлері, мекенжайлар, email, қызметкер мен клиент деректері, медициналық мәліметтер, жалақы. Құпия сауда деректері — келісімдегі баға, тендерлік шарттар, ішкі қаржылық есептер, қауіпсіздік схемалары, парольдер мен кілттер.

Келесі принцип — минимизация: модельге жауап үшін қажет емес нәрсені көрсетпеңіз. Қандай деректер әрдайым LLM-ге жіберілмеуі тиіс — алдын ала анықтаңыз. Әдетте тыйым салынған тізімге тіркелгі деректері (парольдер, токендер, API кілттер), толық идентификаторлар (ИИН, құжат нөмірлері, банк реквизиттері), рұқсатсыз хат мазмұны мен почта, денсаулық туралы деректер, тәртіптік жазбалар, келісімдер мен сатып алу шарттары сияқты заттар кіреді.

Деректерсіз жұмыс істей алмайтын жағдайларда анонимизация мен маскирлеуді қолданыңыз. Қай жерде бұл жасалатынын (сұрау жіберерден бұрын, индексация кезiнде, жауап шығарғанда) және маскирлеудің сапасын кім тексеретінін алдын ала шешіңіз. Әдетте бұл дерек иесі мен ІБ/комплаенс бірігіп бекітеді, өйткені «жартылай жабылды» дегені контексттен қалпына келуі мүмкін.

Рөлдерге негізделген қолжетімдіктер сұрақтарды ғана емес, сұрау жіберу мүмкіндігін де шектейді. Мысалы, қолдау қызметінің қызметкері типтік инциденттер бойынша сұрай алады, бірақ нақты келісімшарттың бөлшектерін немесе әріптестің жеке деректерін ала алмайды.

Пайдаланушыларға арналған ережелерді қарапайым тыйымдармен және мысалдармен жазған жөн: «Сұрауға ИИН, паспорт нөмірлері, реквизиттер мен парольдерді енгізуге болмайды». Жанында: «Мәселені идентификаторсыз сипаттауға немесе ішкі өтініш нөмірін пайдалануға болады». Бұл кездейсоқ артық ақпарат жіберу қаупін азайтады және модель кейде жауап бермей тұрғанының себебін түсіндіреді.

Логтар, сақтау және қолжетімділік: не жазып, қанша уақыт сақтау

LLM жобасындағы логтар көбіне даулардың басты себебі болады: не жазылғаны, қайда жатқаны, кім қарағаны және жоюға бола ма. Алдын ала келісілмесе, қауіпсіздік талаптары бұзылып немесе инциденттерді талдау үшін қажетті деректер жоғалуы мүмкін.

Бастапқыда қандай оқиғалар лог саналатынын анықтаңыз. Операциялық логтарды (жүйенің жұмысы үшін) және өнімдік логтарды (сапа үшін) бөліп алған ыңғайлы. Қолайлы жиынға әдетте енгізіледі: қолданушы промпты (толық не маскіленген түрде), модель жауаптары және қолданушы көрген финал мәтін, пайдаланылған көздердің атаулары мен нұсқалары (фрагменттер тек рұқсат болса ғана), сапа белгілері (оператор бағасы, шағымдар, шешім табылу деңгейі), қателер мен техникалық оқиғалар.

Содан кейін сақтау мерзімдерін бекітіңіз: минимум және максимум. Минимум инцидентті тергеу және не болғанын растау үшін қажет. Максимум ішкі ережелер, келісімдер және регулятор талаптарына байланысты. Жиі тәжірибе — мәтін бар логтар үшін қысқа мерзім, ал обезличенная статистика үшін ұзақ сақтау.

Қайда сақтаймыз

Маңызды сұрақ: логтар ұйымның контурында қалады ма әлде сыртқы жүйелерге (бұлтты мониторинг, қателерді трекинг, аналитика сервистері) жіберіле ме. Бұл келісімдерге, қолжетімділікке және трансшекаралық деректер тасымалына әсер етеді. Қайдан оқылған фрагменттер сақтала ма және қандай түрде сақталатынын да айқындаңыз.

Кім қарайды және қалай жоямыз

Қандай рөлдерге нақты қолжетімділік қажет екенін анықтаңыз (қолдау, қауіпсіздік, өнім иелері) және қарауды аудиттеу механизмін енгізіңіз. Қол жеткізу журналын жүргізу және қарауды тұрақты тексеру пайдалы.

Жою процесін де сипаттаңыз: кім бастайды (қолданушы, ІБ, заңгер), кім растайды, қандай мерзімдер және жойылғанын қалай дәлелдейсіз (акт, жүйеде жазба, талап нөмірі).

Алдын ала келісу: қадам бойынша тәртіп

Деректер, қолжетімдіктер мен логтар туралы мәселелер соңғы сәтте шықпас үшін келісімдерді бірінші пилотқа дейін жазып алған жөн. Қарапайым сөзбен — не қосамыз, кім рұқсат берді, қайда сақтаймыз, кім жауапты.

Келісу тәртібі

Сценарийлерден бастаңыз. Бір көмекші қызметкерлер үшін анықтамалық, клиенттік бөлімге хаттың черновикін құрастыру немесе техподдержка құралы болуы мүмкін. Сценарийге байланысты деректер, тәуекелдер және қолжетімділік өзгереді.

Содан соң мына қадамдармен жүріңіз:

• Сценарийлер мен қолданушылар тізімін сипаттау: рөлдер, қолжетімділік, тыйымдар (мысалы, бос өріске персонал деректерін енгізуге болмайды).
• Деректер мен көздер реестрін жасау: база знаний, файлдар, пошта, тикеттер. Әрқайсысына иесін және келісім контактіні көрсету.
• Контент құқықтары мен лицензияларын тексеру: не іздеуге индексіленетінін, не цитаталанатынын, не оқытуға қолданылатынын, не сақталмайтынын анықтау.
• Логирование және сақтау саясатын келісу: не жазамыз, сақтау мерзімі, кімде қолжетімділік, қалай жоямыз.
• Қателерге жауапкершілік пен эскалация тәртібін анықтау: қайсысы көзді блоктайды, кім промпттарды түзетеді, кім пайдаланушыларға жауап береді.

Одан кейін қолданушыларға арналған ережелер мен оқыту жоспарын бекітіңіз. Әдетте бір бет жеткілікті: сұрауды қалай құрастыру, не енгізуге болмайтыны, жауапты қалай тексеру және қайда қателер туралы хабарлау.

Қысқа мысал

Ішкі база знанийге арналған қолдау көмекшісін іске қосуды елестетіңіз. Егер компанияда 24/7 қолдау мен жүйелік интеграция болса, инструкциялар, инфрақұрылым схемалары және инцидент өтініштері контекстке қосыла ма және логтар қалай қорғалатынын алдын ала шешкен маңызды. Бір қате қолжетімділік немесе тым егжей-тегжейлі логтар пайдалы құралды дерек ағынына айналдыра алады.

Дайындық белгісі қарапайым: әр көз бойынша кім рұқсат берді, қандай шартта, қайда сақталады және модель қателескенде не істеу керек — бәрі анық болса, жоба дайын саналады.

Мысал сценарий: ішкі база знанийге көмекші

Банк немесе университет бірінші деңгей қолдауға арналған LLM-қолдаушы іске қосып жатыр деп ойлаңыз. Ол колл-центр қызметкерлеріне немесе студенттерге форманы қайдан табуға, өтінішті қалай рәсімдеуге, ақаулыққа не істеуге және мерзімдер мен тәртіптерге жауап береді.

Жиі қате модельде емес, деректермен жұмыс шарттары алдын ала айтылмағанында болады: қандай құжаттарды қосуға болады, кім рұқсат береді, логтар мен жұмыс іздері қайда сақталады.

Практикада қандай көрініс береді

Команда ішкі материалдардан «білім витриналарын» жинайды: база знаний мен FAQ, регламенттер мен нұсқаулықтар, жауап шаблондары. Көбіне өтініштер архиві (тикеттер, хаттар, чаттар) мысалдар үшін қосылады және сыртқы мердігерлерден келетін құжаттар да қосылады.

Риск бірден пайда болады. Өтініш архивінде жиі жеке деректер бар, олар промптқа немесе логтарға түсуі мүмкін. Ал нұсқаулықтар кейде үшінші тарап жазған және құқықтары шектелген, тіпті файл ортақ қалтада тұрса да.

Не көмектеседі

Интеграцияға дейін ережелер: бекітілген көздер тізімі (не қосуға және не қоспауға болады), сезімтал өрістерді маскілеу, рөлдер бойынша бөлініс (кім жауаптарды көреді, кім әкімшілік етеді, кім логтарды қарайды) және сақтау мерзімі.

Жоба құжаттарында ең аз талаптарды бекітіңіз: рұқсат етілген көздер мен дерек иелері, жеке және құпия деректерге маскілеу талаптары, логирование ережелері (не жазылады, кімде қолжетімділік, сақтау мерзімі және жою тәртібі), авторлық құқық бойынша шағымдарды өңдеу тәртібі және жауапкершілік (қай жерде адам тексеруі қажет және қай жерде жауапқа сенуге болмайды).

Осындай тар ережелер пилот дайын болғанда апта бойынша болатын дауларды жиі үнемдейді.

Типтік қателер мен тұзақтар

Ең жиі кездесетін мәселе — пилотты «аяқ астынан» іске қосу. Қолда бар нәрсені қосады, кейін қандай да бір құжатты пайдалануға болмайтыны, дерек иесі жоқтығы және жауапкершілік белгіленбегені анықталады.

Тұзақтардың бірі — көздер реестрінің жоқтығы. Қай базалар, қалталар, пошта жәшіктері мен сыртқы ресурстар қосылғанын жазбасаңыз, заңдылықты дәлелдеуіңіз де, даулы көзді жылдам өшіруіңіз де мүмкін емес. Әр деректер жинағы үшін иесін тағайындау маңызды: кім рұқсат береді, кім жаңартуларды енгізеді, кім жариялауды алып тастайды.

Тағы бір қате — барлық промпттар мен жауаптарды «қойып қою». Сақтау мерзімі мен қолжетімділігі жоқ логтар сезімтал деректер қоймасына айналуы мүмкін. Бір ғана сұрау жеке деректерді кіргізсе, бүкіл ұйым үшін тәуекел туады.

Сондай-ақ оқыту мен эксплуатацияны араластыру жиі кездеседі. Тесттік орта мен өндірістік контур үшін ережелер әртүрлі болуы тиіс: не жүктеуге болады, қайда сақтау керек, кім нәтижені көреді, диалогтарды дооқытуға пайдалануға болады ма — бұл бөлек анықталуы тиіс.

Жоба қауіпті бағытта бара жатқанын көрсететін сигналдар:

• Ауызша келісімдер қағазда бекітілмеген.
• Логтарды сақтау мерзімі және қолжетімділік үшін жауапты белгіленбеген.
• Бірдей контент тест пен продқа араласып кеткен.
• Жаңа көзді кім бекітетіні анықталмаған.
• Қате немесе зиянды жауап болғанда не істеу керектігі жазылмаған.

Мысал: ішкі база помощью көмекшіге қызметтік нұсқаулар мен хат шаблондарына қолжеткізу сұрайды. Егер жауапкершілік пен шекара жазылмаса, қызметкерлер ұсыныстарды көшіріп алып, қате жағдайда кім көздерді шектеуі және тексеруді кім орнатуы керектігі анықталмайды.

Іске қоспас бұрын қысқа чек-лист

LLM-ге деректерді қосып, алғашқы нәтижелерді қолданушыларға көрсетпес бұрын қысқа тексеруден өтіңіз.

Біріншіден, жобаның деректер шекаралары анық болуы керек: рұқсат етілген көздер тізімі және тыйым салынған категориялар тізімі. Екіншіден, контент құқықтары сіздің сценарийіңізге нақты тексерілуі тиіс. Құжатты оқу бір нәрсе, оны цитаталау, қысқаша шығару, модельді оқыту немесе сыртқы провайдерге беру — мүлдем басқа.

Бастапқы ұйымдық ережелердің минималды жинағын келістіріңіз:

• жаңа көздерді қосу мен промпттарды өзгертуге кім рұқсат береді;
• кім қандай деңгейде құжаттарды, модель жауаптарын және логтарды көреді;
• қандай логтар жазылады, қанша уақыт сақталады және қалай жойылады;
• ағымдық ағып кету немесе шағым болса не істейміз: жауап мерзімдері, кім тексеріп, кім хабарлайды;
• қай жерде адамның тексеруі қажет және қай жерде жауапқа сенуге болмайтыны.

Практикалық тұрғыдан инцидентті қарау тәртібі бар-жоғын тексеріңіз. Егер модель ескі бұйрыққа сілтеме жасаса немесе ішкі құжаттан артық мәлімет ашып қойса, кім қолжетімділікті тоқтатады, кім көзді жаңартады және шешім қалай тіркелетінін білу керек.

Келесі қадамдар: талқылаудан енгізуге көшу

Тәуекелдер мен күтілімдерді талқылап болған соң, шешімдерді нақты іске асыруға аударыңыз: кім деректерге рұқсат береді, не пайдалануға болады, қайда жұмыс істейді және логтарға не жазылады. Осылайша келісімдер ауызша емес, эксплуатация ережелеріне айналады.

Практикалық қадамдар жиыны келесідей:

• Жұмыс тобы жинаңыз: бизнес, ІБ, заң бөлімі, IT және дерек иелері.
• Пилот мақсатын және шекараны бекітіңіз: қандай міндеттер шешіледі, қандай міндеттер кірмейді.
• Бастау үшін 1–2 құжат көзін бекітіп, олардың құқықтары мен лицензияларын тексеріңіз.
• Қосымша деректер жинамау үшін логтар мен қолжетімдікті баптап, сақтау мерзімін анықтаңыз.
• Шектеулі аудиторияда пилот іске қосып, нәтижелерді кім қабылдайтынын белгілеңіз.

Келесі екі қысқа құжат пайдалы болады. Біріншісі — деректер мен ережелер матрицасы: деректер түрі, иесі, қайда сақталады, кім қарайды, модельге не жіберуге болады, не тыйым етілген және өтініш бойынша қалай жойылады. Екіншісі — эксплуатация регламенті: көздер қалай жаңартылады, промпттарды кім өзгерте алады, инциденттер қалай өңделеді және дау тудыратын жауаптарда не істеу керек.

Егер жобаны қатаң контурда (мемлекеттік немесе қаржылық) орналастыру керек болса, сақтау мен қолжетімдікті бақылау талаптарына сәйкес инфрақұрылымды алдын ала жоспарлаған дұрыс. Мұндай жағдайларда жүйелік интеграторды тарту ыңғайлы — мысалы, GSE.kz (gse.kz) өндірісші және интегратор ретінде серверлерді жеткізеді және 24/7 қолдау көрсетеді, бұл нақты процестерде қолжетімділік пен эксплуатация режимін сақтау үшін маңызды болуы мүмкін.