LLM үшін аудит-логтар: банк пен мемлекеттік сектор не сақтау керек

Неге журналсыз бәрі шатасады

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

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

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

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

Бір оқиға журналы бірден бірнеше сұраққа жауап беруі керек:

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

Кәдімгі жағдайды елестетіңіз. Банктегі чат-бот кенет тым ұзақ жауап беріп, ішкі шаблонды ашып жіберді. Егер өзгерістер тарихы болмаса, команда жаңа system prompt кінәлі ме, әлде token limit өсті ме деп дауласады. Егер маршрут жоқ болса, бәрі model A-ға қарап отырады, ал жауап шын мәнінде model B-ден, басқа провайдер арқылы келген болады. Егер алғашқы сигнал уақыты жазылмаса, инцидентті нақты релизбен байланыстыру қиын.

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

Бір оқиға неден тұруы керек

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

Уақыттан бастаңыз. Дәл timestamp-ті миллисекундқа дейін жазыңыз және уақыт белдеуін сақтаңыз. Тіпті екі мәнді қатар сақтау одан да жақсы: UTC және жүйенің жергілікті уақыты. Банк пен мемлекеттік сектор үшін бұл ұсақ нәрсе емес. API, queue және қосымша әртүрлі аймақта өмір сүрсе, ашық уақыт белдеуінсіз жазбаларды ретімен қою мүмкін емес.

Келесісы — идентификаторлар. Бір оқиғада әдетте request_id болады, ал көбіне session_id және пайдаланушы не сервис ID-і де болады. Бұл өрістер LLM шақыруын оператор экранымен, пакет тапсырмасымен немесе ішкі микросервистермен байланыстырады. Егер user_id ашық күйде сақталмаса, тұрақты псевдоним немесе хэш қалдырыңыз. Сонда жеке тұлға ашылмай-ақ әрекеттер тізбегі көрінеді.

Жазбада не болуы керек

Минималды құрам әдетте мынадай:

• шақыру уақыты, уақыт белдеуі, орта және аймақ;
• сұрауды кім бастады: пайдаланушы, сервис, арна және қол жеткізу кілті;
• сұрау қайда кетті: модель, провайдер, маршрут, жүйелік промпт немесе шаблон нұсқасы;
• бәрі немен аяқталды: статус, қате коды, ұзақтығы, кіріс және шығыс токен саны, құны;
• көрші оқиғаларды қалай табуға болады: trace_id, correlation_id немесе басқа ортақ тізбек идентификаторы.

Өңдеу маршрутына бөлек блок керек. Егер команда AI Router сияқты шлюз қолданса, модель атауының жалғыз өзі жеткіліксіз. Бір OpenAI-үйлесімді шақыру әртүрлі ережелермен әртүрлі провайдерлерге өтуі мүмкін. Сондықтан журналда тек model_name емес, сонымен бірге provider, route_id және маршруттау саясатының нұсқасы да сақталғаны дұрыс. Әйтпесе сіз "gpt-4.1" көресіз, бірақ неге кеше кідіріс 900 мс болып, бүгін 4 секунд болғанын түсінбейсіз.

Оқиғаның соңы да маңызды. Уақыт өткенін білу аз. Журнал HTTP-статусты немесе ішкі статус­ты, қате кодын, қадамдар бойынша ұзақтығын, токендерді және бағаны көрсетуі керек. Егер сұрау ретрайдан кейін құласа, оны да белгілеу керек. Сонда талдауда мәселе модельде ме, провайдерде ме, қол жеткізу лимитінде ме, әлде қолданбаның өзінде ме — көрініп тұрады.

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

Нені жазу керек, нені бірден жасыру керек

LLM үшін аудит-логтарға бәрін үйіп-төгіп салуға болмайды. Егер журналға толық карта нөмірі, ЖСН немесе телефон түссе, логтың өзі қауіп көзіне айналады. Сонда инцидентті тек модель бойынша емес, журналдың өзінен болған утечка бойынша да талдауға тура келеді.

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

Жазбада нені қалдыру керек

Жақсы жазба сұрау мәтінін қызметтік метадеректерден бөледі. Метадеректер дерлік әрқашан керек: уақыт, request_id, сервис, модель, промпт нұсқасы, маршрут, жауап статусы, токен саны, қате коды, API-ді кім шақырды және қандай саясат іске қосылды.

Сезімтал өрістер үшін бастапқы мәннің орнына қауіпсіз түрін сақтаған дұрыс:

• визуалды салыстыруға арналған маска, мысалы 4403****1298;
• дәл сәйкестікті табуға арналған хэш;
• аты-жөні мен байланыс нөмірлерінің орнына ішкі клиент ID-і;
• сұрауда PII табылғаны туралы белгі;
• дерек класы: ашық, ішкі, жеке, банк құпиясы.

Мұндай схема талдауды айқын жеңілдетеді. Команда сұраудың мобильді арнадан келгенін, нақты модельге кеткенін, таймаут алғанын және жеке деректерді қамтығанын көреді, бірақ біреудің телефон нөмірін тұтас оқымайды.

Нені бірден жасыру керек

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

Егер пайдаланушы: "Менің ЖСН-ым 123456789012, телефоным 87771234567, картаны 4403... қайта шығарыңыз" деп жазса, журналда мағына мен контекстті қалдырып, тікелей идентификаторларды жасырыңыз. Мысалы: "Картаны қайта шығару туралы сұрау; ЖСН, телефон және карта нөмірі табылды". Бұл операция түрін және инциденттің барысын түсіну үшін жеткілікті.

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

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

Сақтау мерзімін қалай таңдау керек

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

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

Тәжірибеде мерзімді былай бөлу ыңғайлы:

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

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

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

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

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

Кімге қол жеткізу беру керек

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

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

ИБ-ге кеңірек қол жеткізу керек, бірақ бәріне емес және дәлелсіз де емес. ИБ командасы аномалияларды, жаппай түсірілімдерді, rate limit айналып өтуді, PII-ді промптқа жіберу талпыныстарын тексереді. Ол үшін толық оқиға тізбегі, IP, service account, контент белгілері және құқық өзгерістерінің тарихы пайдалы.

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

Тәжірибеде бөлу былай көрінеді:

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

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

Әр қарау мен әр экспортты бөлек журналға жазу керек. LLM оқиғалары жатқан сол ағынға емес, логтармен жасалған әрекеттер журналына. Сонда команда кім жазбаны ашқанын, кім файл жүктегенін және кім сезімтал өрістермен іздеуге тырысқанын тез көреді.

Уақытша қол жеткізуді "апта соңына дейін" деп қалдыруға болмайды. Инцидент талданды — қолжетімділік бірден жабылады. Бірнеше сағаттан кейін автоматты түрде аяқталу қолмен уәдеден сенімдірек.

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

Журналды қадамдап қалай баптау керек

Өрістерден емес, ағын картасынан бастаңыз. Команда сұраудың LLM-ге түсуі мүмкін барлық жерді көруі керек: қосымшаның чаты, оператор интерфейсі, backend-сервис, пакет өңдеу, сыртқы құралдарды шақыратын агент. Бір кірісті болса да өткізіп алсаңыз, журнал тесікті болады да, инцидентті талдау қайтадан болжамға тіреледі.

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

Минималды тәртіп

1. Барлық кіру нүктесін және сұрау өзгеретін барлық нүктені белгілеңіз. Бұған ретрайлар, басқа модельге fallback және tools шақырулары кіреді.
2. Оқиғаның міндетті құрамын келісіңіз. Әдетте request_id, уақыт, пайдаланушы немесе сервис, арна, модель, провайдер, промпт нұсқасы, жауап статусы, кідіріс, токен және құрал шақырылғаны туралы белгі жеткілікті.
3. Журналға жазбас бұрын маскалауды қосыңыз. Кейін тазалаймыз деген үмітпен шикі деректерді сақтамаңыз.
4. Сақтау мерзімдерін бөліңіз. Оқиғаның толық ізі қысқалау сақталуы мүмкін, ал обезличенный метадерек тергеу мен есеп беру үшін ұзағырақ тұрады.
5. Қолжетімділік рөлдерін тағайындаңыз. Әзірлеуші техникалық өрістерді көреді, ИБ қызметі инцидент журналын көреді, ал шикі фрагменттер тек өтінім бойынша тар шеңберге ашылады.

Өрістерді баптау кезінде бәрін бірдей жазуға тырыспаңыз. Артық шу бос логтардан кем кедергі емес. Егер команда OpenAI-үйлесімді шлюз қолданса, маршрутты да жазған пайдалы: қай модель таңдалды, басқа провайдерге ауысу болды ма, rate limit қай жерде іске қосылды және маскалау қосылды ма.

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

Артық теориясыз инцидент мысалы

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

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

Оқиға карточкасында команда бірден көреді:

• қай модель шақырылды;
• сұрау қай провайдер немесе маршрут арқылы өтті;
• сервис system prompt-тың қай нұсқасын қолданды;
• маскалаудан кейін қандай контекст модельге түсті;
• клиентке қандай жауап кетті және шақыру қанша уақыт алды.

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

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

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

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

Командалар қай жерде жиі қателеседі

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

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

Екінші қате одан да қарабайыр: test пен prod бір журналға жазылады. Содан кейін тергеушілер, қауіпсіздік мамандары және әзірлеушілер фактілердің орнына шу көреді. Реалистік сценарийлерді көп сынайтын команда болса, тестік трафикті боевойдан шатастыру оңай. Соңында prod-тегі инцидент жобалық тексерістер мен оқу сұрауларының арасында жоғалып кетеді.

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

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

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

Әдетте бес ереже жетеді:

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

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

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

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

Банк пен мемлекеттік сектор үшін мұндай минимум әдетте жеткілікті:

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

Өшіру ережесін бөлек тексеріңіз. Ол ескі деректерді кесте бойынша тазалауы керек, бірақ сақтау мерзімінің шетінде басталған инцидентті талдауды бұзбауы тиіс. Әдетте бұл үшін ticket немесе инцидент бойынша өшіруді қысқа уақытқа мұздататын кезең қалдырады.

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

Бұдан кейін не істеу керек

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

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

Алдын ала бірнеше ережені бекітіп алған дұрыс:

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

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

Егер аудит-логтар біртұтас шлюз арқылы өтсе, оны қолмен тексеріңіз. AI Router үшін шлюз оқиғаларды бір форматта жаза ма, PII-ді жазбас бұрын маскилей ме, деректерді ел ішінде сақтауды қолдай ма және қол жеткізу кілті деңгейінде rate limits қоя ма — соны қараңыз. Бұл ұсақ-түйек емес. Кейін осының бәрі бойынша кім сұрау жібергені, нақты не модельге кеткені және неге инцидент ертерек тоқтамағаны көрінеді.

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