Печалби:
- Възможност за проектиране на минимална схема за одитна пътека, достатъчна за реконструкция на събитието
- Възможност за предотвратяване на дневника да бъде източник на изтичане чрез маскиране на подканата/отговора
- Възможност за създаване на проверими регистрационни файлове с корелационна идентичност, неизменност и период на съхранение
В една AI система един ден със сигурност ще бъде зададен въпросът: „Защо това решение беше взето по този начин, какво точно се случи този ден?“ Този въпрос може да бъде зададен от клиент, одитор, регулатор или съд. Вашият отговор ще бъде или проверима одитна пътека, или „не знаем“. Последното е недопустимо в корпоративна среда. В този раздел ще научим какво трябва и какво не трябва да се регистрира специфично за AI, как да създадем одитна пътека и как да поддържаме логовете в баланс със сигурността и поверителността.
Защо регистрирането е различно в AI?
В класическия софтуер "кой какво е направил" се регистрира. В AI към това се добавят три нови измерения: какъв модел/версия е използван, какъв подканващ сигнал е изпратен и какъв отговор е получен. Когато възникне грешка или оплакване, не можете да реконструирате инцидента без тези три. Но тази много подкана/отговор може да съдържа PII, както видяхме в модул 2 — което означава, че самият дневник може да стане източник на течове. Това е изкуството на баланса.
Внимание: Регистрирането не е „регистриране на всичко“. Твърде много регистриране създава риск за поверителността, а твърде малкото регистриране създава липса на доказателства. Целта е да се запази достатъчно PII, за да се реконструира събитието, като се маскира.
Какво трябва да се регистрира? Схема за одитна пътека
Солидната одитна пътека за AI включва най-малко:
- Кой: Потребителски идентификатор и роля (или идентификатор на услуга).
- Кога: Времево клеймо (само добавяне, ако е възможно).
- Какво: Желано действие и призовани инструменти.
- Кой модел: Име на модела и версия (напр. claude-opus-4-8), критични параметри като температура.
- Дайджест за вход/изход: Маскирана версия или дайджест/хеш на заявката и отговора.
- Решение: Обработено ли е автоматично, отиде ли при човек, одобрено ли е или отхвърлено?
- Резултат: Успешна ли е операцията или грешка, кой ресурс е засегнат?
Стъпка по стъпка: Създаване на одитна пътека
- Поставете си цел. Кой ще чете тези дневници и защо? (Реагиране на инциденти, одит на съответствие, отстраняване на грешки.) Целта определя какво запазвате.
- Прилагане на политика за PII. Маскиране на подканата/отговора преди влизане (единица 2).
- Осигурете неизменност. Нека критичните регистрационни файлове са само за добавяне; Никой не трябва да може да изтрие миналото безмълвно.
- Определете периода на задържане. Определяне на продължителността според баланса между законови изисквания и поверителност; Автоматично изтриване, когато времето изтече.
- Ограничете достъпа. Достъпът до регистрационни файлове също трябва да бъде защитен с RBAC; Четенето на дневника също трябва да се регистрира.
- Добавяне на ID на корелация (ID на трасиране). Свържете всички стъпки на заявка (вход, извикване на инструмент, проверка, изход) с една самоличност.
Четири копируеми шаблона
Схема на журнал за проверка (JSON):
{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "<masked>", "response_summary": "<masked>", "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "approval": "approved|rejected|none", "result": "success|error", "affected_resource": "..."}
Регистрирайте PII контролен ред:
Вижте примерите за регистрационни файлове по-долу. Попълнени ли са полетата, изисквани за одитната пътека (кой, кога, модел, решение, резултат)? Също така изтекла ли е необработена лична информация? За всеки ред докладвайте като: „недостатъчно / липсващо място: ... /изтичане на PII: ...“ <logs>{{ examples }}</logs>
Подкана за възстановяване на събитието:
Следните одитни записи принадлежат към един trace_id. Превърнете събитието в разказ в хронологичен ред: какво е искал потребителят, какво е направил моделът, какви проверки са извършени, как е взето решението, какъв е бил резултатът? Маркирайте липсващи или непоследователни стъпки.<records>{{ trace_registers }}</records>
Правило за вземане на решения за политиката за задържане:
За всеки тип дневник определете: - Има ли законово задължение за съхранение? (минимален период, ако има такъв) - Съдържа ли PII? (ако е включено, съкратете продължителността, стеснете достъпа) - Доказателство за инцидент със сигурността? (съхранението не може да бъде променено) Резултат: "съхранение N дни + добавяне само mi + ниво на достъп".
Слаба подкана / Силна подкана
лош подход
Силен подход
Изобщо не се регистрира („не се нуждая“)
Записване на минималния набор за реконструиране на събитието
Регистриране на необработена подкана/отговор, както е
Маскирано резюме + регистриране на ID за проследяване
Съхранявайте регистрационни файлове неограничено
Период на съхранение с баланс между правни и поверителност
Всеки може да изтрие регистрационни файлове
Критичните регистрационни файлове са само за добавяне, достъпът е контролиран
Три мини калъфа
Случай 1 — Trace ID намали еднодневното разследване до 15 минути. „Моята молба беше несправедливо отхвърлена“, каза клиент на асистента по предварителна кредитна оценка на банка. Благодарение на идентификатора на корелация, екипът реконструира входа на това приложение, проверките на служителите и решението за 15 минути; показа, че грешката е причинена от неправилен праг при валидиране на правило и го поправи.
Случай 2 — При одита беше открито прекомерно регистриране. Компания за електронна търговия пишеше всички подкани/отговори в необработени регистрационни файлове за отстраняване на грешки. По време на годишния одит се видя, че тези регистрационни файлове съдържат адреси и телефонни номера на клиенти и се съхраняват в продължение на 2 години. Констатацията беше затворена чрез преминаване към политика за маскиране + 90-дневно задържане; Функцията на одитната пътека беше запазена.
Случай 3 — Дневник само за добавяне разкри вътрешна злоупотреба. Служител на един доставчик се опита да изтрие регистрационни файлове, за да скрие грешна партида, която е направил. Тъй като регистрационните файлове са само за добавяне и опитите за четене/изтриване на регистрационни файлове се записват, опитът беше незабавно видим; Инцидентът доведе до дисциплинарна и процесуална корекция.
Съвет: Задайте ИД на корелация (идентификатор на проследяване) на всяка заявка и я пренесете през всички стъпки. Когато възникне проблем, възможността да се събере „всичко за тази заявка“ с една заявка е най-големият ускорител на отговора на инцидента.
Често срещани грешки
- Изобщо не се регистрира или се регистрира толкова малко, че не можете да реконструирате събитието.
- Регистриране на необработената заявка/отговор без маска и превръщане на дневника в източник на изтичане.
- Не се записва име/версия на модела и решение (автоматично/човешко).
- Съхраняването на регистрационни файлове за неограничен период от време увеличава риска за поверителността.
- Оставянето на критични регистрационни файлове подлежи на промяна; Не се регистрира достъп до журнала.
- Невъзможност за свързване на стъпките заедно, защото не използва ИД на корелация (ИД на проследяване).
В обобщение
- Регистрирането на AI добавя три измерения към „кой какво е направил“: кой модел/версия, коя подкана, кой отговор.
- Целта е PII да бъде достатъчно минимален, за да реконструира събитието, като го маскира - нито повече, нито по-малко.
- Одитната пътека трябва да включва кой/кога/какво/кой модел/решение/полета за резултати.
- Критичните регистрационни файлове трябва да бъдат само за добавяне, достъпът трябва да бъде ограничен и достъпът до регистрационните файлове също трябва да се регистрира.
- Идентификатор на корелация (ID на проследяване) свързва всички стъпки на заявка и ускорява разследването на инцидента.
Задача за приложение
Изберете заявка от вашия собствен AI поток и напишете идеалната одитна пътека за нея с JSON схемата по-горе. След това направете два теста: (1) Можете ли да разкажете историята от началото до края само с този запис? (2) Има ли необработена лична информация в записа? Ако има липсващо поле, добавете го, ако има PII, маскирайте го. Накрая задайте период на съхранение и ниво на достъп.
контролен списък
- [ ] Одитната пътека включва полета за кой/кога/какво/модел/решение/резултат.
- [ ] Подканата/отговорът е маскиран преди регистрационните файлове (без PII).
- [ ] Идентификатор на корелация (идентификатор на проследяване) се присвоява на всяка заявка.
- [ ] Критичните регистрационни файлове са само за добавяне и достъпът им се контролира.
- [ ] Периодът на съхранение се определя от правния баланс + поверителността и се изтрива в края на периода.
- [ ] С регистрационни файлове мога да реконструирам събитие за по-малко от 30 минути.