Журнал инцидентов ИИ помогает передать обнаруженную ошибку от сотрудника тому, кто организует разбор и исправление. В карточке нужны наблюдаемый факт, затронутые материалы, ссылки на сохранённые свидетельства, ответственный и основание закрытия. Нейросети можно поручить черновик записи по разрешённым сведениям; подтверждать причину, последствия и завершение случая должен человек.
Разберём редакционный шаблон для команды, которая использует ИИ при подготовке рабочих документов. Он нужен после обнаружения проблемы. Как проверять ответ до использования, рассказано в статье о проверке результата ИИ человеком. Здесь результат другой: переданная ответственному карточка конкретного случая с историей действий.
Все примеры ниже вымышлены. Это не отчёт об инцидентах AURMIND, инструкция по расследованию компьютерных атак или юридическая квалификация события. При подозрении на утечку, нарушение прав или угрозу безопасности действует принятый в организации порядок обращения к профильным специалистам. Заполнение журнала не должно задерживать такое обращение.
Что считать случаем для журнала?
Для этого шаблона условимся записывать обнаруженное расхождение, если оно затронуло рабочий результат или требует решения за пределами обычной правки черновика.
Это внутреннее рабочее определение, которое организация может изменить. Оно не подменяет определения инцидента в её правилах безопасности и применимых требованиях.
Например, сотрудник заметил неверное название в личном черновике и исправил его до передачи. Команда может учесть такую правку в обычных заметках. Другая ситуация: ошибочная памятка уже попала в общую папку, а неизвестно, кто успел сделать копию. Здесь нужен владелец случая, список затронутых версий и решение о распространении исправления.
Не ждите доказанной причины, чтобы передать наблюдение.
Запись «в памятке указан срок, которого нет в утверждённой инструкции» проверяема. Запись «модель перепутала версии из-за сбоя памяти» содержит гипотезу. Сохраните первую как факт, а вторую — только как вопрос для разбора, если у неё есть основание.
Предложите владельцу процесса три категории: ошибка дошла до использования; ошибка перехвачена перед использованием; сигнал пока не подтверждён. Это редакционная схема сортировки. Она помогает не смешивать наступившие последствия с возможными, но сама по себе не определяет важность случая.
Факт. В NIST AI RMF Playbook, MANAGE 4.3, среди предлагаемых действий есть учёт ошибок, почти случившихся событий, инцидентов и негативных последствий, а также сведений о реакции на них. NIST отдельно называет рамку и Playbook добровольными ресурсами. Поля нашей карточки и названия статусов ниже разработаны для учебного примера, а не перенесены из обязательной формы NIST.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Карточка: факт отдельно, неизвестное отдельно
Начните с короткого сообщения, которое ответственный сможет понять без доступа ко всей переписке. Подробности храните в согласованном месте. Для общего журнала достаточно указателей; право читать исходные материалы определяется отдельно.
| Поле | Что записать | Чего не утверждать без проверки |
|---|---|---|
| Идентификатор | Внутренний номер случая | Что новый номер означает новый тип проблемы |
| Обнаружение | Когда и в каком процессе заметили расхождение | Что ошибка появилась именно в этот момент |
| Наблюдаемый факт | Точное расхождение с доступным основанием | Предполагаемую причину как установленную |
| Материал | Название, версия, место хранения | Что перечислены все существующие копии |
| Использование | Кому передали; что известно о применении | Что отсутствие ответа означает отсутствие последствий |
| Свидетельства | Ссылки на сохранённые материалы и ограничения доступа | Что ссылка на изменяемый файл сохраняет прежнюю версию |
| Действия | Кто, что и когда сделал | Что предложенное действие уже выполнено |
| Следующий шаг | Ответственный, вопрос и условие следующей проверки | Что назначение ответственного завершает разбор |
Добавьте поле «Неизвестно». В него можно записать: «не подтверждено, открывали ли получатели старую памятку». Это точнее, чем оставлять пустую ячейку, которую следующий участник прочтёт как «проблем нет».
Один случай может иметь несколько сообщений. Если сотрудники сообщили об одной и той же версии памятки, свяжите сообщения с общей карточкой и сохраните каждое наблюдение. Не удаляйте дополнительные сигналы только потому, что тема уже знакома. Вместе с тем не объединяйте случаи по одному слову «ошибка»: разные материалы и адресаты могут потребовать разных действий.
Схема разделяет содержание записи на наблюдение, пробелы и передачу. Такое разделение полезно проверить до отправки: сохранился ли исходный факт, видны ли открытые вопросы, понятно ли, кто продолжит работу.
Какие свидетельства сохранить?
Согласуйте с ответственными, какие материалы допустимо хранить и кто получит доступ. В учебном примере это исходная инструкция, ошибочная памятка, сведения о её версии и запись о передаче. Полный запрос и ответ модели сохраняют только там, где это разрешено внутренними правилами; в них могут быть сведения, которые нельзя распространять вместе с карточкой.
Не переписывайте исходную ошибочную версию поверх исправленной.
Укажите отдельно прежний материал и новую редакцию. Если система позволяет сохранять версии, используйте её принятый порядок. Если прежняя версия недоступна, так и запишите: «исходный файл не сохранён; описание восстановлено по сообщению сотрудника». Восстановленное описание не равно оригиналу.
Снимок экрана может показать наблюдаемый фрагмент, но не раскрывает весь контекст. В карточке отметьте, что именно он подтверждает. Не делайте по одному снимку вывод, какие данные получала модель, кто отправил документ или сколько людей его прочитало.
Для внешнего обсуждения подготовьте отдельную разрешённую выжимку. Удаление имени из текста само по себе не делает весь набор сведений допустимым для передачи. Если допуск неясен, передайте вопрос ответственному по данным, а не загружайте материалы в ИИ для оценки их конфиденциальности.
Как поручить ИИ черновик записи?
Используйте синтетический пример для первого упражнения. В рабочем процессе допускается только согласованная среда и разрешённый набор сведений. Не нужно давать модели весь архив ради заполнения нескольких полей.
Пример задания:
Составь черновик карточки только по сведениям ниже. Раздели ответ на «наблюдаемые факты», «неизвестно», «уже выполненные действия» и «вопрос ответственному». Не устанавливай причину, виновного, тяжесть или отсутствие последствий. Не добавляй даты и действия, которых нет во входе. Если оснований мало, укажи пробел. После черновика перечисли, какие фразы ты сократил или переформулировал.
После задания передайте разрешённые вводные. Для упражнения: «В учебной памятке версии А появился срок ответа. В инструкции версии Б срок не установлен. Памятка размещена в общей учебной папке. Автор сообщил владельцу процесса о расхождении. Неизвестно, кто скачал файл».
Проверьте результат построчно. Фраза «пользователи не пострадали» не следует из этих вводных. «Документ отозван» тоже не подходит: сообщение владельцу процесса ещё не означает отзыв. Исправьте такие подмены до передачи карточки.
Нейросеть может помочь привести запись к форме, но сама форма не подтверждает её содержание. Приёмка черновика состоит в сверке каждой строки с разрешёнными исходными сведениями. Для общей техники запросов есть отдельный материал о промптах для рабочих задач; здесь ограничьте задачу заполнением карточки.
Условный пример: памятка с неподтверждённым сроком
Команда проводит учебное упражнение. В инструкции написано: «Координатор передаёт вопрос специалисту; срок ответа в этой инструкции не установлен». В подготовленной с ИИ памятке появилась фраза «ответ поступит на следующий день». Памятку версии А разместили в учебной папке. Участник заметил расхождение и сообщил владельцу процесса.
Это все исходные сведения примера. Дальнейшие шаги ниже — предложенный сценарий разбора, а не описание уже произошедших действий.
| Раздел карточки | Запись по имеющимся сведениям |
|---|---|
| Факт | В версии А указан срок ответа, отсутствующий в инструкции |
| Основание | Сопоставление указанной фразы с разделом инструкции о передаче вопроса |
| Известное использование | Версия А размещена в учебной папке |
| Неизвестно | Кто скачал материал и применял ли его вне упражнения |
| Выполнено | Участник сообщил владельцу процесса о расхождении |
| Вопрос | Кто проверит распространение версии А и организует замену? |
| Причина | Не установлена; требуется разбор подготовки памятки |
Владелец процесса может поручить проверить доступные записи о распространении, согласовать исправленную версию и способ уведомления получателей. В карточке каждое поручение пока останется планом. После выполнения исполнитель добавит результат и основание, доступное проверяющему.
Исправление фразы не доказывает, что все копии заменены.
Если сведения о скачиваниях отсутствуют, сохраните эту границу. Ответственный может принять решение при неполных данных, но запись должна показывать, что именно осталось неизвестным и какое действие согласовано по этому поводу.
Мнение. В карточке полезнее оставить явное «не установлено», чем заставить автора выбрать правдоподобную причину из списка. Список можно использовать для гипотез при дальнейшем разборе, сохранив их отдельный статус.
Передача, исправление и закрытие — разные записи
Для учебного журнала предложим статусы «зарегистрирован», «передан ответственному», «разбирается», «исправление проверяется» и «закрыт».
Это не обязательный жизненный цикл из NIST. Если у организации уже есть система обращений или инцидентов, лучше согласовать поля и статусы с её владельцем, чем заводить несвязанный параллельный журнал.
При передаче запишите, кто принял случай и что должен уточнить.
Отправленное сообщение и подтверждённое принятие — разные события. Пока принятие не подтверждено, карточка должна показывать, кто проверит доставку по внутреннему маршруту.
Для исправления понадобятся ссылка на новую версию, описание изменения и способ проверки. Для закрытия — решение уполномоченного участника, сведения о выполненных действиях и оставшиеся ограничения. Сроки реакции и полномочия не назначайте универсально по статье: их определяет организация.
Факт. MANAGE 4.3 в Playbook связывает документирование случая с тем, как ошибку обнаружили, исправлена ли она и как исправления могут быть доведены до затронутых пользователей. Это основание обсудить распространение исправления, а не считать замену одного файла достаточным завершением.
Например, проверяющий подтвердил отсутствие неподтверждённого срока в новой памятке. Это закрывает вопрос к тексту новой версии. Вопрос о старых копиях требует отдельного результата. Если ответственному не удалось установить их наличие, в решении нужно сохранить это ограничение и согласованные действия, а не ставить отметку «все копии удалены».
Как использовать журнал на обучении команды?
Подготовьте обезличенный в бытовом смысле, но отдельно согласованный учебный набор — либо полностью вымышленную ситуацию, как в этой статье. Участники получают вводные, черновик карточки с намеренными подменами и основания для сверки. Попросите найти, где гипотеза стала фактом, план стал выполненным действием, а отсутствие сведений — отсутствием последствий.
Результат упражнения — исправленная карточка и вопрос конкретному ответственному.
Это не оценка пригодности сотрудника к должности. Для повторной попытки измените материал и канал распространения, сохранив проверку тех же различий.
Ведущий может принять работу, если участник сохранил наблюдаемый факт, отметил неизвестное, сослался на основания и не закрыл случай без решения. Если участник просто красиво переписал описание, верните его к исходным сведениям. Здесь тренируется точность передачи, а не литературная редактура.
Для настройки упражнения на задачах вашей команды можно обсудить программу корпоративного обучения ИИ. Сначала согласуйте процесс, разрешённые учебные материалы и участников предметной проверки.
Частые вопросы
Можно ли доверить ИИ оценку тяжести?
В этом шаблоне такую оценку не поручаем модели. Она может оформить уже принятое уполномоченным участником решение с указанным основанием. Если решения нет, поле остаётся открытым; категория по догадке не заменяет внутренний порядок оценки.
Нужен ли отдельный сервис для журнала?
Статья не требует нового инструмента. Обсудите с владельцем существующей системы, можно ли добавить поля и связи с версиями материалов. Условия хранения, доступ и уведомления важнее выбора формы таблицы.
Как отличить повторный случай от дополнения?
Сопоставьте материал, версию, наблюдение и распространение. Новое сообщение о той же версии можно связать с прежней карточкой, сохранив самостоятельную запись. Другую версию или новый затронутый процесс не объединяйте автоматически; решение принимает назначенный ответственный.
Источники
- NIST AI RMF Playbook: MANAGE — MANAGE 4.3: учёт случая, реакции и распространения исправлений.
- NIST: описание AI RMF Playbook — добровольность и возможность выбирать подходящие рекомендации.
- NIST: вопросы об AI RMF — назначение рамки и отсутствие обязательности её использования.
