Чтобы создать реестр рисков с помощью ИИ, определите цель и границы, соберите проверенные сведения о рисках и контролях и применяйте терминологию и шкалу, утверждённые организацией. ИИ может структурировать формулировки «причина — событие — последствие», искать дубликаты и пустые поля. Реальные владельцы подтверждают уровни риска, меры реагирования, триггеры, даты пересмотра и любые решения о принятии риска.

Реестр — это активная запись управления, а не перечень общих неприятностей. Руководство по ответственному применению ИИ задаёт общий принцип: источники и подотчётные люди остаются авторитетными.

Ключевые выводы

Связывайте каждый риск с целью, областью и временным горизонтом.

Разделяйте причину, неопределённое событие и влияние.

До новых действий фиксируйте существующие контроли и доказательства их работы.

Используйте только утверждённые критерии вероятности, последствий и эскалации.

Назначайте реального владельца риска и отдельных владельцев действий.

Задавайте наблюдаемые триггеры и даты пересмотра.

Оставляйте принятие риска и окончательные решения уполномоченным людям.

Что делает реестр рисков полезным?

Полезный реестр показывает, какая неопределённость может повлиять на цель, почему она существует, к чему приведёт событие, какие меры уже работают, кто отвечает и что делать дальше. Проверяющий может проследить доказательства, оспорить оценку и сравнить версии. Реестр не должен создавать иллюзию определённости или превращать балл риска в автоматическое решение.

UK Orange Book рассматривает управление рисками как часть руководства и принятия решений ради достижения целей. Он требует структурированного выявления и оценки, выбора мер, мониторинга, отчётности, сотрудничества и улучшения.［1］ NIST SP 800-30 также связывает оценку с контекстом, угрозами, уязвимостями, последствиями, вероятностью, неопределённостью и коммуникацией, а не с одиночным числом.［2］

Ведите одну строку на отдельный риск и версионируйте запись:

Поле	Назначение
ID и версия риска	Стабильная ссылка и история
Цель и область	Результат, на который влияет неопределённость
Причина — событие — последствие	Источник, возможное событие и последствие
Категория	Утверждённая таксономия
Действующие меры контроля	Уже действующие меры
Свидетельства контроля	Тест, отчёт, подтверждение владельца или наблюдение
Уровень риска	Оценка по утверждённому методу
Владелец риска	Ответственный за весь риск
Меры реагирования и действия	Избежать, снизить, разделить, принять или наблюдать
Исполнитель и срок	Исполнитель конкретной меры и срок
Условие срабатывания и эскалация	Наблюдаемый сигнал и обязательная реакция
Пересмотр и статус	Пересмотр, критическая проверка, статус и решение

Шаг 1. Определите цель, область и полномочия

Начните с цели, которая может пострадать. Укажите организацию, программу, процесс, регион, временной горизонт, зависимости и исключения. Одна и та же запись не может последовательно оцениваться, если один человек думает о шестинедельном выпуске, а другой — обо всём финансовом годе.

Зафиксируйте политику, таксономию, шкалу, владельца склонности к риску или допустимого уровня, маршрут эскалации и полномочия на принятие риска. Не поручайте ИИ создавать эти правила. Если утверждённой шкалы нет, остановите выставление баллов и откройте вопрос для решения по политике, а не заимствуйте популярную матрицу из интернета.

Заголовок области удерживает работу в границах:

Параметр	Синтетический пример
ID реестра	`RR-SERVICE-12`
Цель	Завершить утверждённый переход сервиса к согласованной дате
Горизонт	Подготовка и 30 дней после перехода
Включено	Персонал, поставщик, передача данных, готовность операций
Исключено	Стратегия продукта и долгосрочные прогнозы рынка
Политика риска	`RM-POL-04`, текущую версию подтвердил владелец
Полномочия на решение	Руководящая роль, указанная политикой
Периодичность пересмотра	Раз в две недели и при срабатывании триггера

Задачи, этапы и зависимости ведите в плане проекта. Реестр ссылается на них, но не заменяет план.

Шаг 2. Соберите доказательства до формулировки рисков

Используйте утверждения о целях и границах, реестр предположений и зависимостей, инциденты и предаварийные события, результаты аудита, тесты контролей, обязательства поставщиков, операционные метрики, требования политики и интервью специалистов. Сохраняйте ID документа и дату проверки.

Разделяйте факт, наблюдение, предположение и гипотезу. «Контракт требует уведомления за пять дней» — проверяемый факт. «В пиковой нагрузке поставщик может пропустить срок уведомления» — гипотеза, которой нужны причина и последствия. «Поставщик ненадёжен» — необоснованное суждение.

Не загружайте конфиденциальные контракты, уязвимости, персональные сведения или привилегированные консультации в неутверждённую модель. Для проверки структуры используйте отредактированные резюме или синтетические записи.

Шаг 3. Пишите «причина — событие — последствие»

Применяйте форму:

Из-за причины существует возможность неопределённого события, которое может привести к последствию для цели.

Например: «Из-за совпадения утверждённого окна миграции с периодом заморозки изменений поставщика необходимая конфигурация может не поступить до переключения, что задержит переход сервиса». Это полезнее, чем «риск задержки поставщика».

Проверьте каждую часть:

Причина: условие или источник неопределённости, подтверждённый доказательствами.
Событие: то, что может произойти или не произойти; не проблема, которая уже случилась.
Последствие: влияние на цель без выдуманного масштаба.

Если событие уже произошло, перенесите его в управление проблемами и свяжите записи, если остаточная неопределённость сохраняется. Не объединяйте несколько независимых причин и последствий в одной строке: разделяйте их, если у них разные владельцы, контроли, триггеры или меры реагирования.

Шаг 4. Запишите существующие контроли и доказательства

Перечислите превентивные, направляющие, обнаруживающие и корректирующие меры контроля, которые реально меняют вероятность или последствия согласно местной системе. Для каждой укажите владельца, периодичность, цель, свидетельство работы, дату теста, исключения и зависимости.

Письменная политика не равна эффективному контролю: описание контроля показывает задуманную конструкцию, а доказательства — работал ли он. Orange Book различает конструкцию контроля и подтверждение эффективности, основанную на объективной информации о его работе.［1］ Руководство GOV.UK по грантам также требует активно обсуждать реестр, документировать контроли и получать соразмерное подтверждение.［3］

Используйте явные состояния:

Состояние	Смысл
Разработано, но не внедрено	Конструкция утверждена, работа не началась
Работает, но не проверено	Владелец сообщает о работе, независимого теста нет
Проверено с исключениями	Тест есть, исключения связаны
Проверено и эффективно	Доказательство покрывает указанные время и область
Неизвестно	Доказательство отсутствует или противоречиво

ИИ видит пустое поле, но не наблюдает контроль. Гладкое резюме не должно превращать unknown в effective.

Шаг 5. Чтобы создать реестр рисков с помощью ИИ, поручите ему только структурирование и критическую проверку

Передайте утверждённый шаблон, область, идентификатор источника, формулировки, записи контролей и запреты:

Разложи предоставленные доказательства по одной строке на риск.
Сохрани идентификатор источника и раздели причину, неопределённое событие и последствие.
Не добавляй общие риски как факты этой организации.
Не выдумывай вероятность, последствия, баллы, склонность к риску, эффективность,
владельцев, сроки, меры реагирования, принятие риска и утверждение.
Отмечай нехватку и противоречия как [VERIFY], дубликаты вынеси отдельно.

Внимательно проверяйте предложенные дубликаты: похожий текст не означает одинаковых причин, событий, наборов контролей и владельцев. Объединяйте записи, только если ответственный владелец подтверждает, что одной записью можно управлять согласованно. NIST отмечает риски выдуманных ответов, конфиденциальности, целостности информации и конфигурации «человек — ИИ».［4］ Видимые ID и неизвестные помогают заметить проблему, но не устраняют её.

Шаг 6. Применяйте только утверждённую оценку

Используйте критерии вероятности и последствий, горизонт, правило агрегации и пороги мер реагирования из действующей политики. Скопируйте точные определения уровней в пакет проверки или дайте ссылку на их контролируемую версию. Если нужен вычисляемый балл, рассчитывайте его в защищённой таблице или системе с проверенными формулами.

Не выдумывайте вероятность или влияние: не просите ИИ назвать процент, степень серьёзности или «отраслевой» балл. Уверенный текст не является измерением, а матрица 5×5 не универсальна. Рядом с оценкой сохраняйте качество доказательств, уверенность, изменчивые предположения, диапазоны, зависимости и несогласие. Два риска с одинаковым баллом могут требовать разных мер, если один плохо подтверждён или может быстро измениться.

Разделяйте понятия:

исходный уровень: оценка до указанных контролей, если её использует местная политика;
текущий или остаточный уровень: оценка с учётом контролей, подтверждённых доказательствами;
целевой уровень: желаемое состояние после мер, а не утверждение, что меры сработали;
принятие риска: решение уполномоченного лица по политике, а не результат одной формулы.

Шаг 7. Назначьте владельцев, меры и триггеры

Владелец риска отвечает за понимание и управление всем риском. Исполнитель действия выполняет конкретную задачу. Эти роли могут не совпадать, а название комитета полезно, только если его положение определяет, кто может действовать и отвечает за запись. Для меры реагирования запишите основание, действие, владельца, срок, ресурсы, ожидаемое изменение контроля, проверку результата и возможный вторичный риск.

Если решение требует сравнения затрат и выгод, свяжите отдельный анализ затрат и выгод. Не прячьте финансовые предположения в примечании.

Триггером может быть неудачный тест контроля, уведомление поставщика, превышение порога, изменение политики, инцидент или задержка зависимости. Укажите сигнал, источник, порог или событие, периодичность, владельца и эскалацию. Триггер запускает пересмотр, но не утверждает ответ автоматически, если политика явно не даёт таких полномочий.

Шаг 8. Проведите независимую проверку и утвердите версию

Привлеките специалистов по цели, операциям, контролям, финансам, безопасности, праву и затронутым пользователям. Попросите их проверить:

согласованы ли цель и горизонт;
описывают ли формулировки риски, а не проблемы или смутные опасения;
подтверждены ли причины и последствия доказательствами;
реальны, уместны и проверены ли тестами контроли;
соответствуют ли оценки утверждённым критериям;
могут ли владельцы действовать и работают ли маршруты эскалации;
не создают ли меры другие риски;
остаётся ли недостающая информация видимой.

Сохраните особые мнения и нерешённые вопросы. Владелец риска предлагает обновление, а указанное политикой лицо утверждает принятие риска. Выпущенная версия содержит дату действия, проверяющих, открытые задачи и ссылки на пакет доказательств.

Шаг 9. Пересматривайте при изменении условий

Проверяйте реестр по графику и при триггере, изменении цели, отказе контроля, инциденте, сдвиге зависимости, устаревании доказательств или смене владельца. Сравнивайте версии вместо перезаписи истории.

Сценарный анализ проверяет поведение рисков при согласованных наборах условий, но сценарий не доказывает вероятность. Проверка ответа ИИ подтверждает ссылки и утверждения, но не предоставляет полномочий на риск.

На каждом пересмотре спрашивайте, что изменилось в причине, событии, последствиях, контролях, доказательствах, уровне риска, мерах, триггере, владельце или политике. Цвет статуса без такого объяснения почти ничего не даёт для аудита.

Как не превратить реестр в простой список?

Итоги

Начинайте с цели и проверенных источников, а не общего запроса.
Пишите конкретную цепочку причины, события и последствий и отделяйте уже наступившие проблемы.
Оценивайте существующие контроли по доказательствам работы.
Оставляйте шкалы, расчёты, склонность к риску и принятие риска под управлением политики.
Используйте ИИ только для ограниченного структурирования и критической проверки.
Назначайте владельцев, наблюдаемые триггеры и пересмотр.

Часто задаваемые вопросы (FAQ)

Реестр рисков и журнал RAID — одно и то же?

Не совсем. Журнал RAID часто объединяет риски, предположения, проблемы и зависимости проекта. Реестр сосредоточен на управлении рисками и сохраняет отдельные поля для контролей, уровней риска, владельцев, мер реагирования, триггеров и принятия риска.

Чем риск отличается от проблемы?

Риск — неопределённое событие или условие, способное повлиять на цель. Проблема уже наступила и требует разрешения. Она может создать новые риски, поэтому связывайте записи, не переписывая историю.

Зачем использовать форму причина—событие—последствие?

Она разделяет источник неопределённости, возможное событие и значение для цели. Это облегчает назначение владельца, сопоставление контролей и триггеров и исключает ярлыки вроде «риск сроков».

Нужно ли показывать исходный и остаточный риск?

Только если эти понятия определены политикой организации. Укажите, какие меры контроля и доказательства включены в каждый вид, и не представляйте целевую оценку как достигнутый результат.

Может ли ИИ выставлять баллы риска?

ИИ может проверить соответствие введённой оценки тексту утверждённого критерия, но не выбирает вероятность, последствие, уверенность, склонность к риску или принятие риска. Люди вводят доказанную оценку, а детерминированный инструмент считает результат.

Кого назначить владельцем риска?

Человека с полномочиями и сведениями для мониторинга, контроля, поддержки мер реагирования и эскалации. Владельцы действий выполняют задачи, но общая подотчётность должна оставаться явной.

Каким должен быть триггер пересмотра риска?

Он должен быть наблюдаемым достаточно рано и иметь источник, порог или событие, периодичность, владельца и реакцию. «Ситуация ухудшается» непроверяемо; отказ названного контроля или срок зависимости — проверяемы.

Как часто пересматривать реестр?

Выберите периодичность по значимости цели и изменчивости, затем добавьте событийные проверки. Пересмотр нужен при изменении цели, предположений, контролей, инцидентов, зависимостей, политики, качества доказательств и владельцев.

Источники

HM Treasury, The Orange Book: Management of Risk—Principles and Concepts — https://www.gov.uk/government/publications/orange-book/the-orange-book-management-of-risk-principles-and-concepts
NIST, Guide for Conducting Risk Assessments (SP 800-30 Rev. 1) — https://csrc.nist.gov/pubs/sp/800/30/r1/final
GOV.UK, Risk, Controls and Assurance — https://www.gov.uk/government/publications/government-functional-standard-govs-015-grants/7-risk-controls-and-assurance-html
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 сентября 2026 г.

Как создать реестр рисков с помощью ИИ