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