Жасырын дерексіз ИИ-ассистент үшін қолжетімділікті бөлу

Қауіп қай жерде пайда болады

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

Әдетте бұл былай көрінеді:

• пайдаланушы сұрақ қояды;
• іздеу ұқсас үзінділерді табады;
• модель оларды контекстке алады;
• қосымша құқықты тым кеш тексереді.

Ашық нұсқаулықтар үшін бұл онша қорқынышты емес. Ал келісімшарттар, HR-файлдар, өтініштер тарихы, медициналық деректер және ішкі регламенттер үшін мұндай тәртіп қауіпті. Интерфейс кейін бас тарту көрсетсе де, модель беруге болмайтын мәтінді оқып үлгереді.

Неге шығаруына тыйым салу жеткіліксіз

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

Пайдаланушы бүкіл файлды алмаса да, "келісу лимиті қандай?" немесе "айыппұл тармағы қалай жазылған?" сияқты бір сәтті сұрақ артық деректі ашып беруі мүмкін.

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

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

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

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

Қандай құқықтарды бөлу керек

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

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

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

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

Жиі ұмытылатын төртінші тексеріс бар - сессиядағы контекстті сақтау. Пайдаланушының құқықтары тек сұраныстың жанында емес, диалог тарихының жанында да болуы керек. Әйтпесе қызметкер сатып алу бөлімінің құқықтарымен чатты ашып, кейін мердігер рөліне ауысады да, бұрынғы сессия әлі де табылған үзінділерді араластыра береді.

Тәжірибеде кемінде төрт бөлек ережені ұстаған дұрыс:

• құжатты индексте іздеуге бола ма;
• нақты үзіндіні оқуға бола ма;
• оны сөзбе-сөз келтіруге не ашуға бола ма;
• осы контексті ағымдағы сессияда сақтауға бола ма.

Әр операцияның өз check-і болады. Іздеуді біреуі, үзінділерді таңдауды екіншісі, жауап генерациясын үшіншісі, сессия жадысын төртіншісі тексереді. Иә, код сәл күрделене түседі. Бірақ кейін бот "тек қысқаша баяндап берді" деген жабық құжатқа қатысты инцидентті талдауға тура келмейді.

Қадамдап тексеруді қалай құру керек

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

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

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

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

Жұмыс істейтін схема әдетте былай көрінеді:

1. Сұранысты қабылдап, оны нақты пайдаланушы мен сессиямен байланыстыру.
2. IAM, HR жүйесі немесе ішкі рөлдер каталогынан ағымдағы құқықтарды алу.
3. Құжаттарды қолжетімділік атрибуттары бойынша іздеуге дейін және іздеу кезінде сүзу.
4. Әр табылған үзіндіні модельдің промптына жіберер алдында тексеру.
5. Шешімді сақтау: не сұралды, не рұқсат етілді, не тыйым салынды және не үшін.

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

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

Даулы жағдайлар үшін аудит-лог керек. Пайдаланушыны, оның құқықтарын, табылған құжаттар тізімін, рұқсат етілген үзінділер жиынтығын және әр бұғатталған бөлік үшін бас тарту себебін жазыңыз. Егер модельдерге сұраныс AI Router арқылы өтсе, мұндай жазбаларды PII маскалауымен және кілт шектеулерімен бірге ұстау ыңғайлы. Бірақ шлюздің өзі ACL-ды алмастырмайды: білім базасына қолжетімділікті тексеру мәтін модель контекстіне түсердің алдында да орындалуы тиіс.

Модельге жабық мәтінді қайта айтқызбау жолы

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

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

Модельге не беру керек

Модельге жіберер алдында қысқа тазалау жасаған жөн:

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

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

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

Өз сөзімен қайта айтуға жасалатын әрекеттерді де бөлек жабу керек. Көп команда тек тура цитатаны тыйып, қайта жазуды ұмытады. Нәтижесінде модель абзацты көшірмейді, бірақ оны дерлік сөзбе-сөз қайта баяндайды. Жүйелік ережелерде ашық жазған дұрыс: егер үзінді жабық болса, оны келтірме, қайта айтпа, қорытып берме және соның негізінде қорытынды жасама.

Егер сізде RAG қабаты немесе AI Router сияқты шлюз болса да, мағына өзгермейді. Құқықты тексеру мәтін модель контекстіне түсердің алдында жүруі тиіс. Сонда модельде кездейсоқ беріп қоюы мүмкін материал болмайды.

Жұмыс чатындағы мысал

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

Сатылым бөлімінің менеджері: "Осы тоқсанда қолдау қызметі қызметкерлерінің бонусы қандай?" деп жазады. Ассистент төлемдер кестесі, грейдтерге қатысты шарттар және есептеу мысалдары бар HR-құжатты табады. Іздеу дұрыс жұмыс істеді, бірақ менеджер рөлі бұл файлға қолжетімділік бермейді.

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

Бір сұрақ, екі түрлі жауап

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

Мысалы: "Басқа бөлімнің бонусы рөлге, грейдке және жоспардың орындалуына байланысты. Нақты сомалар мен шарттар HR мен бөлім басшысына қолжетімді". Мұндай жауап көмектеседі, бірақ жабық егжей-тегжейді ашпайды.

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

HR үшін жауап басқаша болады: "Support мамандарының Middle деңгейінде бонус KPI 90%-дан жоғары орындалса, жалақының 15%-ын құрайды. Senior үшін бөлек шкала қолданылады". Мұнда сандарға рұқсат, өйткені оқу құқығы расталған.

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

Көп команда бір жерден қателеседі: құжаттарды іздеу экранында сүзеді, бірақ модельге кететін контексті сүзбейді. Сонда ассистент файлды тікелей көрсетпейді, бірақ бәрібір оның мазмұнын қайта айтып береді. Жұмыс чатында бұл әсіресе жағымсыз ағып кету, өйткені сырттай бәрі сыпайы әрі пайдалы көрінеді.

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

Командалар көбіне қай жерде қателеседі

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

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

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

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

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

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

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

Кемінде мына үш нәрсені тексеріңіз:

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

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

Іске қосар алдындағы жылдам тексеріс

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

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

Қысқа тексеріс

Релиз алдында әдетте бес тармақ жеткілікті:

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

Бір сұрақты әртүрлі рөлдерден қою әлсіз жерді бес минутта-ақ ашып береді. Мысалы, менеджер мен бухгалтер: "Наурыздағы келісімшарт бойынша клиентке қандай жеңілдік бекітілді?" деп сұрайды. Бухгалтер санды және негізін көре алады. Қажетті рұқсаты жоқ менеджер "Келісімшарттың егжей-тегжейін көрсете алмаймын" сияқты бейтарап жауап алуы тиіс. Егер бас тартуда сома, фамилия немесе тұжырымның бір бөлігі көрініп қалса, тексеріс сәтсіз.

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

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

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

Кейін не істеу керек

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

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

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

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

• жабық үзіндіні толық немесе бөліп-бөліп береді;
• оқу құқығы жоқ кезде құжаттың мағынасын қайта айтады;
• егер бұл өрістер де жабық болса, файлдың атауын, нөмірін немесе авторын ашады;
• чат тарихы, кеш немесе басқа сөзбен қойылған сұрақ арқылы тыйымды айналып өтеді.

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

Егер команда LLM сұраныстарын AI Router арқылы airouter.kz-де жүргізіп жүрсе, жақын жерде модельдерді бағыттау, аудит логтары, PII маскалау және кілт бойынша шектеулерді ұстау ыңғайлы. Бұл инциденттерді талдауды жеңілдетіп, бақылауды стек бөліктеріне шашыратып жібермеуге көмектеседі. Бірақ негізгі қағида өзгермейді: мәтінге қолжетімділік құжат немесе үзінді модельге түспей тұрып тексеріледі.

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