Артық күрделіліксіз LLM үшін Қазақстанда деректерді сақтау

Схема көбіне қай жерде бұзылады

Істен шығу әдетте модельдің өзінен емес, одан бұрын басталады. Команда алғашқы сценарийді тез құрастырып, LLM-ді чатқа, CRM-ге немесе ішкі ботқа қосады да, модельге қолда бардың бәрін жібереді: клиенттің аты, ИИН, телефон нөмірі, мекенжайы, шарт нөмірі және бүкіл диалог. Пилотты тез іске қосу үшін бұл оңай. Кейін сол "уақытша" жол өндірісте қалып қояды.

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

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

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

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

Қарапайым мысал. Клиент банк чатында жазып, несие туралы сұрағымен бірге ИИН жібереді. Бот бүкіл мәтінді алып, модельге жібереді, содан кейін сол мәтінді қосымша журналдарына және провайдер журналына сақтайды. Формалды түрде сервис жұмыс істеп тұр. Ал іс жүзінде жеке деректер бірнеше жерде көшіріліп үлгерді.

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

Ел ішінде нені сақтау керек, ал нені журналға тасымау керек

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

Әдетте төрт санат жеткілікті. Біріншісі - сұрау мәтіні мен жауап мәтіні. Олардың ішінде жиі жеке немесе құпия деректер болады. Екіншісі - метадеректер: модель, қоңырау уақыты, жауап ұзындығы, статус, баға, сервис идентификаторы. Үшіншісі - техникалық оқиғалар: таймауттар, қателер, қайталау әрекеттері, қоңырау маршруты. Төртіншісі - құпиялар мен тіркемелер. Бұларды журналға тасудың қажеті көп жағдайда жоқ.

Сұрау мен жауап мәтіндерін ел ішінде сақтаған дұрыс, егер оларда PII, шарт нөмірі, мекенжай, диагноз немесе басқа да құпия ақпарат болса. Аудит ізі де ел ішінде қалуы керек: кім сұрау жіберді, қай сервиске, қашан, қандай нәтиже шықты және қолжетімділіктің қай ережесі іске қосылды. Метадеректерді ұзағырақ сақтауға болады, бірақ мәтіннің мазмұнынсыз. Есептер үшін көбіне идентификаторлар, токен санағы және қате кодтары жеткілікті. Техникалық журналдарға API токендерін, парольдерді, cookie-ді, шикі файлдарды және сұраудың толық header-лерін жазбаған жөн.

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

Сақтау мерзімі де бір ғана санмен емес, дерек түріне қарай белгіленеді. Егер сұрау мен жауап мәтіні тек сапаны талдау үшін керек болса, оларды, мысалы, 7-30 күн ішінде өшірген дұрыс. Техникалық оқиғаларды 30-90 күн сақтауға болады. Аудит журналдары әдетте ұзағырақ тұрады, өйткені олар арқылы қолжетімділік пен қызметкерлер әрекеттері тексеріледі. Маскаланған агрегаттарды аналитика үшін бұдан да ұзақ сақтауға болады, егер ішкі саясат рұқсат етсе.

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

Қарапайым LLM схемасын қандай блоктардан құрастыруға болады

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

Негізгі блоктар

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

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

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

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

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

Бұл тәжірибеде қалай көрінеді

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

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

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

Сұрау қадам-қадамымен қалай өтеді

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

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

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

Содан соң мәтін тазалау қабаты арқылы өтеді. Осы кезеңде жүйе PII іздейді: ААЖ/ИИН, телефон, ИИН, мекенжай, шарт нөмірі, карта деректері. Табылған өрістерді ол маскалап, немесе [CLIENT_NAME] және [PHONE] сияқты токендермен алмастырады. Модель үшін әдетте осы жеткілікті. Сұраудың мағынасы сақталады, ал жеке деректер әрі қарай кетпейді.

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

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

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

Ең аз жұмыс істейтін маршрут мынадай:

1. Қосымша сұрауды қабылдап, request_id береді.
2. Қолжетімділік модулі рөлді, кілтті және лимиттерді тексереді.
3. Қорғаныс қабаты PII-ді тауып, маскалайды.
4. Шлюз тазаланған мәтінді модельге жібереді.
5. Жүйе жауапты, белгілерді және аудит оқиғаларын сақтайды.

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

Деректерді модельге дейін қалай маскалау керек

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

Әдетте күнделікті бизнес-ағындарда жиі кездесетін нәрседен бастайды: аты-жөні, ИИН, телефон, мекенжай, карта нөмірі. Бұл артық дерек тасу қаупін айтарлықтай азайтып, prompt-қа керек емес ақпараттың түсуіне жол бермейді.

Нақты мәндердің орнына түсінікті маркерлер қойыңыз: [CLIENT_NAME], [IIN], [PHONE], [ADDRESS], [CARD]. Модель көп жағдайда түпнұсқа дерексіз-ақ дұрыс жауап бере алады, егер сұраудың мағынасы сақталса.

Мысалы, "Клиент Айжан Сарсенова с ИИН 990101300123 просит сменить адрес доставки на Алматы, Абая 10" деген сөйлемді "Клиент [CLIENT_NAME] с ИИН [IIN] просит сменить адрес доставки на [ADDRESS]" деп өзгерткен дұрыс. Санаттау, қысқа жауап, өтінімді бағыттау немесе хаттың қара нұсқасы үшін бұл әдетте жеткілікті.

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

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

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

Тәжірибеде бұл модель шақыруына дейінгі бөлек қадам сияқты көрінеді: сервис PII-ді табады, мәндерді алмастырады, ауыстыру картасын жабық қоймаға жазады және содан кейін ғана мәтінді әрі қарай жібереді. Егер AI Router сияқты шлюз қолданылса, маскалау логикасын бәрібір сұрауды API-ге жібермей тұрып орындаған дұрыс, ал қайта қалпына келтіруді тек ішкі сенімді аймақта жасаған жөн.

Аудит журналдарын және қолжетімділікті қалай жүргізу керек

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

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

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

Журналдардың өзімен жасалатын әрекеттердің ізін бөлек сақтаңыз. Бірі - модельді шақыру. Екіншісі - журналды оқу, CSV экспорттау, хат алмасуды қарау, кілт лимитін өзгерту. Бұл оқиғалар да жазылуы керек: кім ашты, нені шығарды, қай кезең үшін, қай IP-ден және қай рөл бойынша. Ағып кету көбіне модель арқылы емес, журналдарға тым ыңғайлы қолжетімділік арқылы болады.

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

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

Егер мұндай ережелер үшін бірегей контур керек болса, AI Router осы сценарийге сай келеді: онда бір OpenAI-мен үйлесімді endpoint, теңгемен ай сайынғы B2B шот-фактуралау және аудит журналдары, PII маскалау, кілт деңгейіндегі лимиттер сияқты жергілікті бақылау құралдары бар. Бірақ ондай шлюз болса да, қолжетімділік архитектурасы мен сақтау мерзімін бәрібір компания ішінде белгілеу керек.

Контакт-орталыққа арналған қарапайым мысал

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

Одан кейін жүйе LLM-ге тазаланған мәтінді және қысқа нұсқаулықты жібереді: 3-4 сөйлемдік қысқа жауап беру, сабырлы тонды сақтау және оператор орындай алмайтын нәрсені уәде етпеу. Модель жеке деректерді көрмейді, бірақ бәрібір іске көмектеседі: шағымның мәнін қысқаша айтып береді, жауаптың қара нұсқасын ұсынады және қажетті тонды ұстайды.

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

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

Супервизор кейін түсінікті әрекет тізбегін көреді. Мысалы, оператор Айжан диалогты 14:03-те ашты, жүйе ИИН-ді, телефонды және шарт нөмірін жасырды, модель жауаптың қара нұсқасын қайтарды, ал оператор финалдық мәтінді 14:05-те жіберді. Даулы жағдайларды, аудитті және қолжетімділікті бақылау үшін осының өзі жеткілікті.

Жиі қателер

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

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

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

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

Егер схема бастапқыда сәтсіз жиналса, ол бірден көрінеді:

• журналдарда диалогтардың толық мәтіні бар;
• нақты сұрауды қай сервис жібергенін ешкім білмейді;
• маскалау модель шақыруынан кейін тұр;
• тест және өндірістік трафик бір кілтпен өтеді;
• клиентке берілген жауапта мәтінді ЖИ жасағаны туралы белгі жоқ.

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

Команда OpenAI-мен үйлесімді шлюз арқылы жұмыс істеп, тек base_url ауыстырса да, бұл қателер жоғалып кетпейді. Қарапайым схема көбіне жақсырақ: шақыруға дейін маскалау, журналдарды бөлу, жеке кілттер және шығудағы түсінікті белгілеу.

Іске қоспас бұрын қысқа тексеру тізімі

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

Мынау ең аз тексеріс жиыны:

1. Әр шақырудың өз request_id-і бар, ал оның жанында иесі - сұрау оның атынан шыққан сервис, команда немесе қызметкер сақталады.
2. Жеке деректер модельге жібермей тұрып маскаланады. Аты-жөн, телефон, ИИН, мекенжай және шарт нөмірлері токендермен алмастырылады, ал түсіндірмесі ел ішінде бөлек сақталады.
3. Аудит журналдары үшін сақтау мерзімі мен түсінікті құрылым алдын ала белгіленеді: жүйені кім шақырды, қашан болды, қай маршрут таңдалды, маскалаудың қай ережесі іске қосылды және жауап пайдаланушыға көрсетілді ме.
4. Рөлдер мен лимиттер іске қосуға дейін дайын болады. Қолжетімділік журналы бөлек тексеріледі: журналды кім қарады және ережелерді кім өзгертті.
5. Команда регламент бойынша деректерді қолмен ойлап таппай өшіре алады: жазбаны request_id бойынша табу, жұмыс қоймаларындағы байланысты деректерді жою және заң мен ішкі бақылау талап ететін ізді ғана қалдыру.

Егер жергілікті немесе гибридті шлюз қолданылса, бұл схеманың бір бөлігін жинау жеңілдейді. Мысалы, AI Router-да деректерді Қазақстан ішінде қалдырып, қолданыстағы SDK-лерді қайта жазбай-ақ бір үйлесімді endpoint арқылы шақыру жүргізуге болады. Бірақ деректермен, қолжетімділікпен және журналдармен жұмыс істеу реті бәрібір алдын ала жазылуы керек.

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

Әрі қарай не істеу керек

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

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

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

1. Қазіргі сұрау жолын бір схемаға түсіру.
2. Қандай деректер ел ішінде қалуы керек, ал қайсысын мүлде сақтамауға болатынын белгілеу.
3. Барлық LLM шақыруларын бір API-ге жинап, журнал саясаты, PII маскалау және лимиттер бірдей жұмыс істеуін қамтамасыз ету.
4. Пилотты нақты журналдарда өткізіп, жауап сапасын ғана емес, аудитте нақты не қалғанын тексеру.

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

Егер бір провайдерге байланбайтын үйлесімді API шлюзі керек болса, airouter.kz хостымен AI Router-ды қарауға болады. Ол тек base_url-ды ауыстыруға мүмкіндік береді, бір OpenAI-мен үйлесімді endpoint ұсынады және деректер мен аудитті Қазақстан ішінде ұстауы маңызды командаларға сай келеді. Пилот үшін бұл бірнеше шашыраңқы сервистен өз контурыңызды жинаудан оңайырақ болады.

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