Прибуток:
- Здатність розробити мінімальну схему контрольного сліду, достатню для реконструкції події
- Можливість запобігти тому, щоб журнал став джерелом витоку, маскуючи підказку/відповідь
- Можливість створення журналів, які можна перевірити, із кореляційною тотожністю, незмінністю та періодом зберігання
У системі штучного інтелекту одного разу обов’язково буде поставлено запитання: «Чому це рішення було прийнято таким чином, що саме сталося того дня?» Це питання може поставити замовник, аудитор, регулятор або суд. Ваша відповідь буде або аудиторським слідом, який можна перевірити, або «ми не знаємо». Останнє неприпустимо в корпоративному середовищі. У цьому розділі ми дізнаємося, що потрібно, а що не слід реєструвати в журналі для ШІ, як створити журнал аудиту та як зберегти баланс між безпекою та конфіденційністю журналів.
Чому журналювання відрізняється від ШІ?
У класичному програмному забезпеченні «хто що зробив» реєструється. У ШІ до цього додано три нові виміри: яку модель/версію використовували, яке підказку було надіслано та яку відповідь було отримано. Коли виникає помилка чи скарга, ви не можете відтворити інцидент без цих трьох. Але ця підказка/відповідь може містити ідентифікаційну інформацію, як ми бачили в блоці 2, тобто сам журнал може стати джерелом витоку. Це мистецтво рівноваги.
Застереження: журналювання не означає "реєструвати все". Занадто велика кількість журналів створює ризик конфіденційності, а надто низька кількість створює брак доказів. Мета полягає в тому, щоб зберегти достатню кількість ідентифікаційної інформації, щоб реконструювати подію шляхом її маскування.
Що потрібно реєструвати? Схема аудиту
Надійний контрольний слід AI включає, як мінімум:
- Хто: ідентифікатор користувача та роль (або ідентифікатор служби).
- Коли: мітка часу (якщо можливо, лише додайте).
- Що: Бажана дія та викликані інструменти.
- Яка модель: назва та версія моделі (наприклад, claude-opus-4-8), важливі параметри, як-от температура.
- Дайджест введення/виведення: замаскована версія або дайджест/хеш запиту та відповіді.
- Рішення: чи було воно оброблено автоматично, чи передано людині, чи воно схвалено чи відхилено?
- Результат: операція успішна чи помилка, який ресурс зачеплено?
Крок за кроком: створення аудиторського сліду
- Поставте мету. Хто читатиме ці журнали і навіщо? (Реагування на інциденти, аудит відповідності, налагодження.) Мета визначає, що ви зберігаєте.
- Застосовуйте політику ідентифікаційної інформації. Замаскувати підказку/відповідь перед входом (блок 2).
- Забезпечити незмінність. Нехай критичні журнали будуть лише доданими; Ніхто не повинен мати можливість мовчки стерти минуле.
- Визначити термін зберігання. Визначте тривалість відповідно до балансу правових вимог і конфіденційності; Автоматично видаляти після закінчення часу.
- Обмеження доступу. Доступ до журналів також має бути захищений за допомогою RBAC; Читання журналу також слід реєструвати.
- Додайте ідентифікатор кореляції (ідентифікатор трасування). З’єднайте всі етапи запиту (введення, виклик інструменту, перевірку, вихід) за допомогою єдиного ідентифікатора.
Чотири шаблони, які можна копіювати
Схема журналу аудиту (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": "..."}
Підказка керування журналом ідентифікаційної інформації:
Перегляньте приклади журналів нижче. Чи заповнені поля, необхідні для контрольного сліду (хто, коли, модель, рішення, результат)? Чи стався витік необробленої ідентифікаційної інформації? Для кожного рядка повідомте: "недостатньо / бракує місця: ... /витік ідентифікаційної інформації: ..." <logs>{{ examples }}</logs>
Запит на перебудову події:
Наступні записи аудиту належать до одного trace_id. Перетворіть подію на розповідь у хронологічному порядку: що хотів користувач, що зробила модель, які перевірки проводилися, як було прийнято рішення, який був результат? Позначити пропущені або непослідовні кроки.<records>{{ trace_registers }}</records>
Правило прийняття рішень про політику збереження:
Для кожного типу журналу визначте: - Чи існує юридичне зобов’язання щодо зберігання? (мінімальний період, якщо є) - Чи містить він ідентифікаційну інформацію? (якщо включено, скоротити тривалість, звузити доступ)- Докази інциденту безпеки? (зберігання не можна змінити) Результат: "зберігати N днів + лише додавання mi + рівень доступу".
Слабка підказка / Сильна підказка
поганий підхід
Сильний підхід
Взагалі не реєструється ("не потрібно")
Реєстрація мінімального набору для реконструкції події
Реєстрація необробленого запиту/відповіді як є
Замасковане резюме + реєстрація ID трасування
Зберігайте журнали необмежено
Період зберігання з балансом юридичні та конфіденційні дані
Будь-хто може видалити журнали
Критичні журнали можна лише додавати, доступ до них контролюється
Три міні-чохли
Випадок 1 — Trace ID скоротив день розслідування до 15 хвилин. «Мою заявку було несправедливо відхилено», — сказав клієнт банківському помічнику з попередньої оцінки кредитів. Завдяки ідентифікатору кореляції команда реконструювала введення цієї програми, перевірки співробітників і рішення за 15 хвилин; показав, що причиною помилки було неправильне порогове значення під час перевірки правила, і виправив її.
Випадок 2 — під час аудиту було виявлено надмірну кількість журналів. Компанія електронної комерції записувала всі підказки/відповіді в необроблені журнали для налагодження. Під час щорічного аудиту виявилося, що ці журнали містили адреси та номери телефонів клієнтів і зберігалися протягом 2 років. Знахідку було закрито шляхом переходу на політику маскування + 90-денне зберігання; Функцію контрольного сліду було збережено.
Випадок 3 — журнал лише додавання виявив внутрішнє порушення. Співробітник одного постачальника намагався видалити журнали, щоб приховати зроблену ним помилкову партію. Оскільки журнали доступні лише для додавання, а спроби читання/видалення журналу реєструються, спроба була відразу видима; Інцидент спричинив дисциплінарні та процесуальні виправлення.
Порада: призначте ідентифікатор кореляції (ідентифікатор трасування) кожному запиту та проведіть його через усі кроки. Коли виникає проблема, можливість зібрати «все про цей запит» за допомогою одного запиту є найбільшим прискоренням відповіді на інцидент.
Поширені помилки
- Зовсім не реєструється або реєструється настільки мало, що неможливо відтворити подію.
- Реєстрація необробленого запиту/відповіді без маски та перетворення журналу на джерело витоку.
- Не реєструється назва моделі/версія та рішення (автоматично/людино).
- Зберігання журналів протягом необмеженого періоду часу підвищує ризик конфіденційності.
- Залишення критичних журналів з можливістю змін; Доступ до журналу не реєструється.
- Неможливо з’єднати кроки разом, оскільки не використовується ідентифікатор кореляції (ідентифікатор трасування).
Підсумовуючи
- Журнал AI додає три виміри до того, «хто що зробив»: яка модель/версія, який запит, яка відповідь.
- Мета полягає в тому, щоб ідентифікаційна інформація була достатньо мінімальною, щоб відтворити подію шляхом її маскування — ні більше, ні менше.
- Журнал аудиту повинен включати поля хто/коли/що/яка модель/рішення/результати.
- Критичні журнали мають бути доступні лише для додавання, доступ має бути обмеженим, і доступ до журналу також має реєструватися.
- Ідентифікатор кореляції (ідентифікатор трасування) поєднує всі кроки запиту та прискорює розслідування інциденту.
Аплікаційне завдання
Виберіть запит із власного потоку штучного інтелекту та напишіть для нього ідеальний контрольний журнал за допомогою схеми JSON вище. Потім виконайте два тести: (1) Чи можете ви розповісти історію від початку до кінця лише за допомогою цього запису? (2) Чи є в записі необроблена ідентифікаційна інформація? Якщо немає поля, додайте його, якщо є ідентифікаційна інформація, замаскуйте його. Нарешті, установіть період зберігання та рівень доступу.
контрольний список
- [ ] Журнал аудиту включає поля хто/коли/що/шаблон/рішення/результат.
- [ ] Підказка/відповідь маскується перед журналами (без ідентифікаційної інформації).
- [ ] Ідентифікатор кореляції (ідентифікатор трасування) призначається кожному запиту.
- [ ] Критичні журнали доступні лише для додавання та контролю доступу.
- [ ] Термін зберігання визначається юридичним балансом + конфіденційність і видаляється в кінці періоду.
- [ ] За допомогою журналів я можу реконструювати подію менш ніж за 30 хвилин.