Модельді шақырмай тұрып PII-ді маскалау: қай жерде және қалай жасау керек

Неге PII-ді модельге сол күйінде жіберуге болмайды

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

Мәселе тек модельді шақырумен шектелмейді. Шикі мәтін жиі бірден бірнеше жерде қалып қояды:

• қолданба логтарында
• чат немесе тикет тарихында
• сұрау кэшінде
• трассировка мен APM-де
• debug-дамптарда

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

Тәуекел команда модельдер мен провайдерлерді ауыстырғанда одан сайын өседі. Бүгін сұрау бір сервиске кетеді, ертең — басқа сервиске. Әзірлеушілер көбіне тек base_url-ды ауыстырып, сол бірдей промптты жібере салады. Бұл ыңғайлы, бірақ деректердің маршруты өзгереді. Әртүрлі провайдерлердің сақтау ережелері, өңдеу аймақтары және қызметтік логтар жиыны да әртүрлі. Егер сіз параллель A/B-тесттер жүргізсеңіз, тәуекел нүктелері одан да көбейеді.

Пилот та құтқармайды. Дәл сынақ кезеңінде командалар жиі фильтрлерді өшіреді, көбірек лог жазады және әріптестерінен сапаны тексеру үшін "нақты кейстерді" салуды сұрайды. Сөйтіп тест ортаға шын ИИН, адрес пен телефон түседі. Кейін пилот жұмыс сервисіне айналады, ал шикі деректер чаттарға, ноутбуктерге және мониторинг жүйелеріне тарап үлгереді.

Тағы бір тыныш проблема бар: PII деректерге өте тез жабысып қалады, кейін оны алып тастау қиын болады. Егер оператор модельге "Айгерим Садыкова, ИИН 030101..." деген сияқты фраза жіберсе, ол деректер модель жауабында, әрі қарай жіберілген әңгімеде және сапаны бағалауға арналған қолмен белгілеуде де көрінуі мүмкін.

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

Сіздің ағыныңызда PII деп нені санау керек

PII көбіне "жеке деректер" деген белгісі бар бір ғана өрісте жатпайды. Әдетте ол өтініш формасына, қолдау чаттарына, хаттарға, PDF-ке, құжат сканына және OCR-дан кейінгі мәтінге шашырап кетеді. Егер тек аты, телефоны және email іздесеңіз, тәуекелдің бір бөлігін міндетті түрде өткізіп аласыз.

Алдымен барлық нақты кіріс көздерін жинаңыз: формалар, чат, пошта, CRM-нен алынған мәліметтер, скандар, дауыстық транскрипциялар және OCR нәтижелері. Сосын модель қай бөлікті тұтас көреді, ал қай бөлік промптқа бөлшектеп түседі — соны ажыратыңыз. Осындай жаттығудан кейін сезімтал өрістер тізімі әдетте едәуір ұлғаяды.

Деректерді екі топқа бөлу ыңғайлы:

• Тікелей идентификаторлар: аты-жөні, ИИН, телефон нөмірі, email, нақты адрес, паспорт нөмірі, клиенттің ішкі ID-і.
• Жанама идентификаторлар: тапсырыс нөмірі, лауазым, қала, жұмыс орны, жұмысқа кірген күні, сирек шағым, филиал нөмірі.

Жанама өрістерді жиі бағаламайды. Жеке-жеке олар зиянсыз сияқты көрінуі мүмкін. Бірақ "Қостанайдағы бас бухгалтер, 184533 тапсырысы, 12 мамырдағы қабылдау" деген сөйлем-ақ бір нақты адамға меңзеуі мүмкін.

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

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

Қазақстан үшін ИИН-ді алғашқы күннен-ақ ережеге қосқан дұрыс. Бұл сирек жағдай емес және бірнеше клиентке ғана тән бөлек тармақ емес. ИИН анкета, хат, келісімшарт, скан және чатта жиі кездеседі, көбіне аты-жөні мен телефонның жанында тұрады.

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

Ағынның қай жеріне редакттеуді қою керек

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

Әдетте бұл үшін ең жақсы қабат — кіріс API немесе шлюз, агентті маршруттауға дейін және кез келген өңдеу басталмай тұрып. Мәтін келеді, сервис PII-ді табады, фрагменттерді [EMAIL_1] немесе [PHONE_1] сияқты белгілерге ауыстырады, содан кейін ғана сұрауды әрі қарай жібереді.

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

1. Сұрауды қабылдай салысымен мәтінде, метадеректерде және қызметтік өрістерде сезімтал деректерді бөліп алыңыз.
2. Табылған мәндерді түсінікті токендерге ауыстырыңыз: [NAME_1], [PHONE_1], [IIN_1]. Бір фрагмент сұрау ішінде әрдайым бір ғана токен алуы керек.
3. Сәйкестік кестесін промпттан бөлек сақтаңыз, бірақ ол шынымен керек болса ғана. Оны request_id-ке байлап, қысқа уақытқа ұстаған дұрыс.
4. Логтарға, кэшке, агентке және модельге тек тазартылған мәтінді жіберіңіз.
5. Модель жауабынан кейін өрістерді тек рұқсат етілген жерлерге және қатаң ережелермен ғана қайтарыңыз.

Соңғы қадам жиі бұзылады. Команда модель жауабын алып, [NAME_1]-ді кез келген жерге жай ғана бастапқы атымен ауыстырып жібереді. Бұл қауіпті. Модель токенді жаңа контекске көшіруі мүмкін: мысалы, [PHONE_1]-ді операторға арналған ескертпеге немесе артық абзацқа салып жіберуі мүмкін. Бұған дейін рұқсат етілген өрістердің тізімін анықтап қойған дұрыс, мысалы greeting, contact_block немесе contract_number. Егер токен осы тізімнен тыс жерге түссе, оны маскаланған күйде қалдырып, жауапты тексеруге жіберіңіз.

Сол ереже файлдарға да қатысты. PDF, скан, құжат фотосы және OCR-дан кейінгі дауыстық транскрипциялар көбіне кәдімгі чаттан да көп сезімтал дерек ұстайды. Файлдар үшін фильтрсіз бөлек жол болмауы керек: алдымен мәтінді шығару, содан кейін тазалау, тек содан кейін ғана индекстеу, қысқаша мазмұндау немесе модель шақыру.

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

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

Процестің жетілгенінің жақсы белгісі қарапайым: промпт, кэш және модель жауабы жеке деректерсіз өмір сүреді, ал кері подстановка тек соңында және тек ережемен орындалады.

Маскадан кейін мағынаны қалай жоғалтпау керек

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

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

Тек жалпы "жауап сапасына" қарау жеткіліксіз. Кемі бес нәрсені тексеріңіз:

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

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

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

Сондықтан кезең-кезеңмен тест жасаған жақсы. Алдымен тек атты ауыстырыңыз. Сосын тек соманы. Кейін тек құжаттарды. Одан соң тек адрессті. Сонда нақты қай нәрсе жауапты бұзып тұрғаны тез көрінеді.

Кішкентай мысал: шағымда "14 наурыздағы келісімшарт бойынша қате есептелген 12 500 теңгені алып тастаңыз" деген фраза бар. Егер сіз соманы да, датаны да бірдей [REDACTED] токеніне ауыстырсаңыз, модель оқиғаға байланысын жоғалтып, бұлыңғыр жауап беруі мүмкін. Ал егер олардың орнына [SUM_1] және [DATE_1] сияқты бөлек белгілер қолдансаңыз, мағына әдетте жақсырақ сақталады.

Егер модельдерді AI Router сияқты шлюз арқылы шақырсаңыз да, тест бәрібір керек. Шлюз маршруттау мен инфрақұрылым мәселелерін шешеді, бірақ текст қаншалықты маскаланса да түсінікті болып қалуы — сіздің міндетіңіз.

Клиент өтініші мысалында

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

Здравствуйте. Меня зовут Айгуль Садыкова, мой телефон +7 701 123 45 67, ИИН 930512400123.
У меня второй день не проходит оплата в мобильном приложении. После подтверждения перевода вижу ошибку "операция отклонена", хотя лимит не превышен.
Проверьте, пожалуйста, что не так и как мне завершить платеж.

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

Текст для модели:
Здравствуйте. Меня зовут [NAME_1], мой телефон [PHONE_1], ИИН [IIN_1].
У меня второй день не проходит оплата в мобильном приложении. После подтверждения перевода вижу ошибку "операция отклонена", хотя лимит не превышен.
Проверьте, пожалуйста, что не так и как мне завершить платеж.

Карта замен:
[NAME_1] -> Айгуль Садыкова
[PHONE_1] -> +7 701 123 45 67
[IIN_1] -> 930512400123

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

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

Бұл мысалда модель карта статусын тексеруді, төлемді кейінірек қайта жасауды, қате басқа желіде де қайталана ма, соны көруді және қажет болса істі төлем командасына беруді ұсына алады. Оған аты да, телефоны да, ИИН де керек емес.

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

Финальный ответ клиенту:
Айгуль, здравствуйте. Мы видим повторяющуюся ошибку при оплате в приложении.
Попробуйте обновить приложение и повторить платеж чуть позже.
Если ошибка сохранится, мы передадим обращение в профильную команду и свяжемся с вами по текущему каналу.

Мұндай ағын утечка тәуекелін айтарлықтай азайтып, сұраудың мағынасын модель үшін сақтап қалады.

Өрістерді жауапқа қалай қауіпсіз қайтаруға болады

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

Кері қайтару кезінде тек модель өзгеріссіз берген токендерді ғана қолданыңыз. Егер сіз [PHONE_1] жіберіп, жауапта дәл сол [PHONE_1] келсе, нөмірді қалпына келтіруге болады. Егер модель [PHONE], скобкасыз PHONE_1 немесе жай ғана "клиенттің телефоны" деп жазса, ауыстыруды тоқтатқан дұрыс.

Тип бойынша тексеру де керек. Телефон тек телефон өрісіне, email тек email өрісіне, ИИН тек ИИН өрісіне қайтарылуы тиіс. Қарапайым жолдық ауыстыруды типті тексермей жасау тез арада күлкілі әрі қауіпті қателерге әкеледі: email кенеттен хаттың қолтаңбасына, ал телефон ат өрісіне түсіп кетеді.

Әдетте мына тәртіп жеткілікті:

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

Рұқсат етілген бөліктерді алдын ала анықтаған дұрыс. Мысалы, деректерді клиентке арналған мәтінге немесе CRM-нің нақты өрістеріне қайтаруға болады. Оларды қызметтік ескертпелерге, техникалық журналдарға, қателер трассировкасына және ішкі комментарийлерге қайтаруға болмайды. Егер сізде шлюз деңгейінде аудит-логтар болса, онда токендер мен алмастыру фактісін сақтаңыз, ал бастапқы мәндерді емес.

Модельдің өзіне [EMAIL_1] = [email protected] сияқты сәйкестік картасы қажет емес. Ол тек токендерді көруі керек. Картаны өз жағыңызда ұстаңыз: сұрау жадында, қысқа TTL-і бар қорғалған қоймада немесе мәндерді логтарға жазбайтын бөлек сервисте.

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

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

Қорғанысты бұзатын қателер

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

Ең жиі қателер мыналар:

• Редакттеуді тым кеш қояды. Егер API-шлюз, прокси, трассировка немесе debug-лог маскалауға дейін бастапқы мәтінді жазып үлгерсе, қорғаныс іске аспайды.
• Барлық адамдарды бірдей маркермен алмастырады. "Иван ақшаны Ольгаға аударды" деген сөйлемде [PERSON] токені рөлдер мен мағынаны тез бұзады. [PERSON_1], [PERSON_2], [ACCOUNT_1] қолданған дұрыс.
• Тек кәдімгі мәтінді ғана тазартады. Шын мәнінде PII PDF-те, скриншотта, кестеде, CSV-де және OCR-дан кейінгі мәтінде де өмір сүреді.
• Жасырын өрістерді еркін сөйлемге шаблонсыз қайтарады. Модель өрісті дұрыс емес жерге кірістіріп, нөмір форматын өзгертіп немесе екі клиенттің дерегін араластырып жіберуі мүмкін.
• Сәйкестік картасын сұраудың қасына сақтайды. Егер промпт, ауыстырулар және бастапқы мәндер бір жазбада болып, бір сервисте шектеусіз қолжетімді болса, тәуекел жойылмайды.

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

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

Деректерді қайтару жолын бөлек тексеріңіз. Кері подстановка жасайтын сервис өрісті қайда салатынын өзі болжауға тиіс емес. Ол тек [CLIENT_NAME] немесе [PHONE_1] сияқты рұқсат етілген слоттармен жұмыс істеп, олардың айналасындағы кез келген артық мәтінді қабылдамауы керек. Бұл жалықтыратын ереже, бірақ дәл сол ереже көбіне жасырын утечкелерден сақтап қалады.

Іске қоспай тұрып тексеру

Релиз алдында жүз беттен тұратын аудит қажет емес. Қысқа тексеру жеткілікті, бірақ оны адал өту керек. Егер кемі бір пунктке "жоқ" десеңіз, схеманы бір күнге тоқтатып, түзеткен дұрыс.

• Модельде бірде-бір шынайы аты-жөн, телефон, ИИН, карта нөмірі, адрес немесе келісімшарт нөмірі көрінбейтініне көз жеткізіңіз.
• Редакттеу логтарға, кэшке, кезекке, ретрайларға және трассировкаға дейін іске қосылатынын тексеріңіз.
• 20-30 нақты өтінішпен мағына жоғалуына тест жүргізіңіз, экзотикасыз.
• Кері подстановканы жасауға болатын жерлерді шектеңіз. Қайтару тек жауаптың соңғы қабатында және тек өрістердің ақ тізімі бойынша жүруі керек.
• Ережелердің иесін тағайындаңыз: сөздіктерді кім өзгертеді, жаңа PII түрлерін кім мақұлдайды және инциденттерді кім қарайды.

Бір сквозной тест проблемалардың жартысын ұстап қалады. "Менің атым Алия, нөмірім 8..." сияқты клиент өтінішін алып, оны бүкіл жолмен өткізіңіз: кіріс, лог, кэш, модель шақыруы, жауап, өрістерді подстановка. Әр қадамда нақты деректер қайда, ал маскалар қайда тұрғаны анық болуы керек.

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

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

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

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

Қалыпты бастапқы жоспар мынадай:

• барлық LLM шақырулары үшін біртұтас кіріс нүктесін таңдау
• маскаларды, ерекшеліктерді және өрістерді қайтару ережелерін бір жерге жазу
• 50-100 нақты сұрауда пилот іске қосу
• қателерді қолмен талдап, ережелерді кең ауқымды іске қоспай тұрып түзету

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

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

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

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