NIST AI RMF 1.0 на русском: рамочная модель управления рисками ИИ-систем

В 2023–2026 годах искусственный интеллект перестал быть экспериментом R&D-подразделений и стал частью корпоративного ИТ-ландшафта. Российские организации внедряют GigaChat и YandexGPT в контакт-центры, рекомендательные системы — в e-commerce, классификаторы — в скоринг и комплаенс, автоматические агенты — в документооборот и DevOps. Вместе с этим выросла потребность в единой методологии управления ИИ-рисками: традиционные подходы ИБ не покрывают специфику bias, галлюцинаций, data poisoning и недетерминированного поведения моделей. Первой попыткой создать всеобъемлющую рамку стал NIST AI Risk Management Framework — документ, опубликованный Национальным институтом стандартов и технологий США 26 января 2023 года.

TL;DR: NIST AI RMF 1.0 (NIST.AI.100-1) — добровольная рамочная модель управления рисками ИИ, опубликованная NIST 26 января 2023 года. Четыре функции: Govern, Map, Measure, Manage. Семь характеристик надёжной ИИ-системы: valid, safe, secure, accountable, explainable, privacy-enhanced, fair. В России аналога нет — AI RMF используется как референс при построении процессов безопасности ИИ в ГИС под ФСТЭК №117 и ИСПДн под 152-ФЗ.

Для российских специалистов NIST AI RMF важен даже с учётом иностранного происхождения: отечественного полноценного стандарта управления ИИ-рисками пока не существует, и до его появления рамочная модель NIST служит удобным референсом для построения собственных процессов. В этой статье — перевод и адаптация ключевых положений ИИ RMF 1.0 под российский контекст, разбор четырёх функций Govern/Map/Measure/Manage, семи характеристик надёжной (trustworthy) ИИ-системы, связи с требованиями приказа ФСТЭК №117, 152-ФЗ и практические рекомендации по внедрению в российскую инфраструктуру управления рисками.

Зачем нужен ИИ Risk Management Framework

До появления NIST AI RMF управление ИИ-рисками выглядело фрагментарно. Исследовательские статьи описывали adversarial-атаки на классификаторы, security-команды писали руководства по защите ML-инфраструктуры, этические комитеты обсуждали bias и справедливость — но единого языка, которым разговаривали бы ML-инженер, CISO, юрист и топ-менеджер, не существовало. В результате каждая организация с нуля изобретала свой подход, а регуляторы не имели точки опоры для оценки зрелости ИИ-программ.

Проблема усугубилась с массовым внедрением генеративного ИИ после ChatGPT. Новые риски — галлюцинации, prompt injection, утечки через memorization, overreliance — добавились к уже известным: bias классификаторов, непрозрачность чёрных ящиков, data poisoning, model theft. Традиционные фреймворки ИБ (ISO 27001, NIST CSF, в российском контексте — приказы ФСТЭК №21/117/239) не покрывают ИИ-специфику: они описывают защиту ИТ-инфраструктуры, но не содержат метрик справедливости или процедур оценки надёжности модели. Попытки внедрить ИИ-ассистента в корпоративную ИСПДн упираются в вопросы, на которые классические документы не отвечают.

NIST AI RMF закрывает именно этот разрыв. Его задача — не заменить существующие фреймворки ИБ, а дополнить их на уровне ИИ-специфики, дав организациям структурированный способ думать о рисках, планировать метрики и коммуницировать решения стейкхолдерам. Документ сознательно сделан agnostic к технологиям: он применим к классификаторам, рекомендательным системам, LLM, компьютерному зрению, ИИ-агентам — потому что работает на уровне принципов, а не конкретных алгоритмов.

История разработки и статус документа

NIST AI RMF разрабатывался в формате consensus-driven process: открытые публичные обсуждения с отраслью, академическим сообществом, общественными организациями. Путь от concept paper до релиза 1.0 занял около полутора лет. В июле 2021 года NIST получил мандат от Конгресса США на разработку рамочной модели для управления рисками ИИ — в рамках National AI Initiative Act. В июле 2022 года опубликован Initial Draft AI RMF для обсуждения, в августе — Second Draft, в январе 2023 года вышла финальная версия 1.0 с идентификатором NIST.AI.100-1.

Вместе с основным документом NIST выпустил сопровождающие материалы: AI RMF Playbook — практическое руководство с конкретными действиями под каждый подпункт функций, AI RMF Roadmap — план развития рамки, AI RMF Crosswalk — сопоставление с другими стандартами (ISO 42001, OECD AI Principles, EU AI Act). 30 марта 2023 года запущен Trustworthy and Responsible AI Resource Center (airc.nist.gov) — единый портал ресурсов для практиков.

26 июля 2024 года NIST опубликовал ключевое дополнение — Generative AI Profile (NIST.AI.600-1), адаптирующий рамку под специфику больших языковых моделей. Документ включает анализ 12 рисков генеративного ИИ (конфабуляции, опасный контент, утечки ПДн, информационная безопасность), которые требуют специального внимания при применении четырёх функций ИИ RMF к LLM. В 2025–2026 годах NIST готовит Critical Infrastructure Profile — версию рамки для критической инфраструктуры.

Принципиальный момент: NIST AI RMF — добровольный документ. Он не является нормативным стандартом ни в США, ни тем более в других юрисдикциях. Применение рамки — выбор организации, продиктованный зрелостью ИИ-программы и требованиями клиентов или регулятора. В США ИИ RMF постепенно становится де-факто стандартом: его упоминают в контрактах федеральных агентств, на него ссылаются суды, он лежит в основе отраслевых инициатив. В России рамка используется как методический референс — обязательной силы не имеет, но принимается во внимание зрелыми security-командами.

Четыре функции ИИ RMF: подробный разбор

Ядро рамки — четыре функции, которые выполняются итеративно на протяжении всего жизненного цикла ИИ-системы. Функции не последовательны: Govern обеспечивает организационный фон, а Map–Measure–Manage повторяются от разработки концепции до вывода модели из эксплуатации. Каждая функция разбита на категории и подкатегории с конкретными действиями, детализированными в ИИ RMF Playbook.

Govern — культура управления ИИ-рисками

Govern задаёт организационный контекст: кто отвечает за ИИ-риски, как они учитываются при принятии решений, как распределяются роли между разработчиками, security, юристами, бизнесом. Без функции Govern остальные три теряют смысл — можно идеально измерить риск и предложить меры защиты, но если в компании не выстроен процесс принятия решений, рекомендации не будут реализованы.

Конкретные элементы Govern в рамке NIST: формальная политика использования ИИ в организации (какие классы моделей разрешены, для каких задач, с какими данными), назначение ответственного за ИИ-риски уровня C-level (AI Risk Officer, Chief AI Officer или расширение роли CISO), создание ИИ Ethics Committee с участием представителей разных функций, процедуры due diligence при внедрении сторонних ИИ-сервисов, программа обучения сотрудников по ИИ-рискам, документирование всех ИИ-систем в реестре активов, связь ИИ-рисков с общим enterprise risk management.

Для российского контекста Govern хорошо ложится на требования приказа ФСТЭК №117 по организационным мерам защиты ГИС. Политика ИБ, утверждаемая руководством организации, должна учитывать использование ИИ-систем: отдельный раздел о допустимых моделях, запретах (например, запрет загрузки ПДн в зарубежные сервисы), ответственности сотрудников. Роли и зоны ответственности описываются в соответствии с требованиями организационно-распорядительной документации по ИБ, включая приказы о распределении обязанностей.

Map — картирование контекста и рисков

Функция Map отвечает на вопрос «что, собственно, за ИИ-система у нас есть и какие риски с ней связаны». Это не просто инвентаризация — это глубокий анализ контекста: какие люди, процессы и данные задействованы, какие последствия возможны при сбое модели, какие заинтересованные стороны несут риски.

Первый шаг Map — описание ИИ-системы: тип модели (классификатор, регрессия, генеративная, агент), архитектура, обучающие данные, механизмы обновления, точки интеграции с другими системами. Второй шаг — идентификация пользователей и затронутых сторон: кто напрямую взаимодействует с моделью, кто получает последствия её решений, какие уязвимые группы могут пострадать от bias. Третий — картирование обрабатываемых данных с указанием категорий (ПДн, коммерческая тайна, государственная тайна), что напрямую пересекается с требованиями 152-ФЗ для российских операторов. Четвёртый — идентификация специфических для ИИ рисков: bias, галлюцинации, prompt injection, data poisoning, model drift, privacy leakage. Для LLM-систем полезно использовать OWASP Top 10 для LLM как готовый каталог угроз, дополняющий Map.

Для ГИС, где внедряется ИИ-компонент, Map интегрируется с этапом моделирования угроз по методике ФСТЭК. Классическая модель угроз ФСТЭК дополняется ИИ-специфическими угрозами — prompt injection, model DoS, training data poisoning — и становится основой для выбора мер защиты из приказа №117. На этом же этапе формируется перечень бизнес-последствий: финансовые потери от неверных решений модели, репутационные риски, штрафы за нарушение 152-ФЗ.

Measure — количественная и качественная оценка

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

Категории метрик в NIST AI RMF включают: метрики качества модели (accuracy, precision, recall, F1, AUC — привычные для ML-инженеров), метрики безопасности и устойчивости (результаты adversarial testing, robustness к возмущениям входа, устойчивость к distribution shift), метрики справедливости (disparate impact, equal opportunity, demographic parity — проверяют, нет ли систематического ущемления отдельных групп), метрики приватности (differential privacy, membership inference resistance, memorization tests — оценивают, не утекают ли обучающие данные через модель), метрики объяснимости (качество SHAP-объяснений, интерпретируемость feature importance), метрики эксплуатационной производительности (latency, throughput, частота fallback на человека).

Важный принцип Measure — метрики должны быть привязаны к контексту. Для медицинской диагностики 1% ложноположительных критичен, для рекомендательной системы — терпим. Для кредитного скоринга fairness-метрики обязательны из-за антидискриминационного законодательства, для генерации маркетингового текста — могут быть опциональны. Без привязки к бизнес-контексту численное измерение риска превращается в бессмысленную коллекцию цифр.

В российских реалиях Measure сталкивается с проблемой: отечественных методик измерения справедливости ИИ и устойчивости LLM фактически нет. Специалисты используют зарубежные библиотеки (Fairlearn от Microsoft, AIF360 от IBM, Garak для LLM) и адаптируют их под свои задачи. Это даёт техническое решение, но создаёт вопрос аудита и соответствия — при проверке регулятор может не признать результаты тестов, выполненных несертифицированными средствами.

Manage — приоритизация и обработка рисков

Manage замыкает цикл: выявленные и измеренные риски приоритизируются, обрабатываются и мониторятся. Подходы к обработке — стандартные риск-менеджерские: mitigate (снижение через меры защиты), accept (принятие с документированием), transfer (перенос через страхование или контракты с вендорами), avoid (отказ от использования ИИ-системы).

Для ИИ-систем Manage включает специфические аспекты: план мониторинга model drift (изменение точности модели со временем из-за изменения распределения входных данных), процедуры retrain при деградации, план ответа на инциденты ИИ-безопасности (обнаружен jailbreak — что делаем), процедура вывода модели из эксплуатации (включая удаление её из reference-архитектур и reference-документов), связь с процессами управления изменениями.

Важный элемент — continuous monitoring. В отличие от традиционных систем, где риски относительно стабильны, ИИ-модель деградирует со временем: входные данные меняются, бизнес-контекст эволюционирует, появляются новые атаки. Без постоянного мониторинга метрик модель, бывшая надёжной при релизе, через год может давать недопустимый уровень ошибок. Manage должен включать процессы регулярного retest.

Функция Manage в российской инфраструктуре реализуется через процесс управления рисками ИБ в SGRC-платформе — в КиберОснова модуль управления рисками позволяет вести реестр ИИ-рисков, связывать их с мерами защиты из приказов ФСТЭК, назначать ответственных и сроки, отслеживать статус обработки в едином интерфейсе.

7 характеристик надёжной ИИ-системы

Параллельно с функциями NIST AI RMF определяет семь характеристик, которыми должна обладать trustworthy AI. Они описывают не процесс, а качества конечной системы, к которым стремятся Govern–Map–Measure–Manage.

Valid and Reliable (достоверная и надёжная) — модель корректно решает задачу, для которой создана, и демонстрирует предсказуемое поведение на схожих входных данных. Валидность означает соответствие реальным закономерностям, а не артефактам обучающей выборки. Надёжность проверяется через тестирование на holdout-наборе и robustness-тесты.

Safe (безопасная) — модель не приводит к физическому, психологическому или финансовому вреду людей. Безопасность оценивается через анализ последствий сбоев: что произойдёт при неверном ответе, есть ли необратимые решения, требуется ли human-in-the-loop. Для автономных систем (робототехника, беспилотный транспорт) критически важна.

Secure and Resilient (защищённая и устойчивая) — модель защищена от атак (prompt injection, adversarial examples, model extraction) и способна восстанавливаться после инцидентов. Эта характеристика ближе всего к классической кибербезопасности; её содержание подробно раскрыто в OWASP Top 10 для LLM, где перечислены конкретные атаки и меры защиты. В инфраструктуре ГИС для устойчивости ИИ-компонентов применяются общие требования приказа №117 к обеспечению доступности и отказоустойчивости.

Accountable and Transparent (подотчётная и прозрачная) — должно быть понятно, кто отвечает за решения модели, какие данные использовались при обучении, какая версия модели активна в продакшене. Transparency не означает раскрытие весов — она означает документированную цепочку ответственности и информированность пользователей о том, что решение принято AI.

Explainable and Interpretable (объяснимая и интерпретируемая) — модель или процесс её работы должны быть понятны человеку настолько, чтобы специалист мог оценить корректность решения. Для простых моделей (линейная регрессия, решающие деревья) интерпретируемость встроена. Для LLM и глубоких сетей применяются техники post-hoc объяснений: SHAP, LIME, attention visualization. Для критичных решений (медицина, правосудие, кредитование) интерпретируемость — обязательное требование.

Privacy-Enhanced (с соблюдением приватности) — модель уважает приватность субъектов данных и не допускает утечек ПДн. Для российских операторов это прямо связано с 152-ФЗ: запрет передачи ПДн в иностранные юрисдикции, локализация баз данных, контроль над трансграничной передачей. Технические механизмы — differential privacy, federated learning, data minimization, удаление ПДн из обучающих выборок.

Fair with Harmful Bias Managed (справедливая, с управлением вредоносной предвзятостью) — модель не дискриминирует защищённые группы и активно управляет bias. Полностью устранить bias невозможно, но можно идентифицировать, измерить и снизить. В российском контексте антидискриминационное регулирование менее развито, чем в США или ЕС, но отдельные отраслевые нормы (банковский сектор, трудоустройство) содержат требования к недискриминации, которые распространяются и на ИИ-системы.

Применение NIST AI RMF в российском контексте

Для российских организаций NIST AI RMF работает как методическая надстройка над существующими требованиями ИБ. Ниже — конкретные паттерны применения, которые используют зрелые security-команды.

Референс при отсутствии отечественного стандарта. Отечественного полноценного ИИ RMF в России не существует, документы ТК 164 Росстандарта закрывают отдельные аспекты (терминология, надёжность, тестирование), но не образуют единой рамки. В этой ситуации NIST AI RMF используется как методический шаблон: структура Govern–Map–Measure–Manage, семь характеристик, набор метрик — всё это переиспользуется во внутренних политиках, адаптированных под российскую юрисдикцию.

Интеграция с моделированием угроз ФСТЭК. Функция Map естественно встраивается в этап моделирования угроз по методике ФСТЭК. Базовый каталог угроз из БДУ ФСТЭК дополняется ИИ-специфическими угрозами: prompt injection, model DoS, training data poisoning, bias, privacy leakage. Итоговая модель угроз покрывает как традиционные ИБ-риски, так и ИИ-специфику — и принимается аудиторами, поскольку соответствует формальной методике ФСТЭК.

Связь с 152-ФЗ через характеристику Privacy-Enhanced. Обработка ПДн в ИИ-системах регулируется 152-ФЗ. Требования локализации, контроля трансграничной передачи, получения согласия субъектов применяются к ИИ так же, как к любой другой ИСПДн. NIST AI RMF через характеристику Privacy-Enhanced даёт язык для документирования privacy-by-design подхода, а нарушение — чревато оборотными штрафами по 420-ФЗ, которые с 2025 года стали ощутимым финансовым риском.

Ограничения применимости. AI RMF содержит ссылки на американские документы (NIST SP 800-53, NIST CSF, NIST Privacy Framework), которые не применяются в России напрямую. При адаптации рамки нужно заменять американские ссылки на соответствующие отечественные — приказы ФСТЭК №21/117/239, ГОСТ Р ИСО/МЭК 27001, 152-ФЗ. Playbook AI RMF содержит конкретные рекомендации по реализации функций, но они ориентированы на американскую экосистему инструментов и не всегда применимы к российскому стеку.

Российские инициативы. Параллельно в России развиваются собственные документы: ГОСТ Р 59276 серии «Системы искусственного интеллекта», Кодекс этики в сфере ИИ (2021), Национальная стратегия развития ИИ до 2030 года, методические материалы Сбера и Яндекса по ответственному AI. Эти документы не заменяют NIST AI RMF, но создают базу для отечественного аналога, который, по прогнозам, появится в 2027–2028 годах.

Сравнение NIST AI RMF с OWASP Top 10 для LLM

NIST AI RMF и OWASP Top 10 для LLM — документы, которые часто путают, считая альтернативами. На самом деле они работают на разных уровнях и дополняют друг друга.

Зрелая ИИ-безопасность-программа использует оба документа. NIST задаёт каркас управления — как принимаются решения, кто отвечает, какие метрики отслеживаются. OWASP наполняет функцию Map конкретными векторами атак для LLM-приложений. Функция Measure из NIST опирается на adversarial-тесты, описанные в OWASP-экосистеме (Garak, LLM-Guard). Результаты тестирования OWASP-уязвимостей становятся входом для функции Manage NIST. Без NIST OWASP превращается в список технических проверок без связи с бизнес-целями; без OWASP NIST остаётся абстрактной рамкой без конкретного контента для ИИ-приложений.

Практический чеклист применения NIST AI RMF

Ниже — практический список действий, который позволит специалисту ИБ начать применение рамки NIST AI RMF к своим ИИ-системам в ближайшие недели.

1. Проведите инвентаризацию ИИ-активов — составьте реестр всех моделей, используемых в организации: собственной разработки, from-vendor, SaaS-сервисов вроде GigaChat. Зафиксируйте тип модели, владельца, данные, бизнес-процесс.
2. Назначьте ответственного за ИИ-риски — обычно это CISO с расширением мандата или Chief AI Officer. Формализуйте роль приказом.
3. Сформируйте политику использования ИИ — документ верхнего уровня с принципами: какие модели разрешены, какие задачи, какие данные (запреты на ПДн в зарубежные сервисы), как оформляется согласование.
4. Создайте ИИ Ethics Committee — междисциплинарный орган из представителей ИБ, ИТ, юристов, бизнеса. Заседает ежемесячно, рассматривает новые ИИ-проекты.
5. Для каждой ИИ-системы проведите Map — опишите контекст, данные, пользователей, заинтересованные стороны, идентифицируйте специфические риски.
6. Выберите набор метрик для Measure — привяжите к контексту. Для LLM — тесты на prompt injection и галлюцинации. Для классификаторов — accuracy + fairness metrics.
7. Проведите baseline-тестирование — запустите adversarial-тесты (Garak для LLM), замерьте метрики. Зафиксируйте baseline в реестре рисков.
8. Спланируйте обработку рисков (Manage) — для каждого выявленного риска решите: mitigate, accept, transfer, avoid. Назначьте ответственного и срок.
9. Внедрите continuous monitoring — метрики модели отслеживаются в эксплуатации, алертинг при деградации.
10. Свяжите с моделью угроз ФСТЭК — добавьте ИИ-специфические угрозы в модель угроз по методике ФСТЭК, свяжите с мерами защиты из приказа №117.
11. Обучите команду — ML-инженеры должны понимать ИИ-риски, security-команда — специфику ИИ, юристы — регуляторные требования к AI.
12. Задокументируйте решения — каждое решение по ИИ-системе фиксируется в SGRC-платформе для аудита и истории.
13. Запланируйте retest — регулярная переоценка рисков раз в квартал или при существенных изменениях модели.
14. Подготовьте инцидент-процедуру — что делаем, если обнаружен jailbreak, утечка ПДн через LLM, деградация модели.
15. Коммуницируйте статус руководству — квартальный отчёт о покрытии ИИ-рисков для C-level.

Как КиберОснова автоматизирует управление ИИ-рисками

КиберОснова SGRC не заменяет специализированные ИИ security-инструменты вроде Garak или LLM-Guard, но закрывает управленческий слой — те самые функции Govern и Manage из NIST AI RMF, которые требуют организационной работы, документирования и отчётности.

• Реестр ИИ-активов. ИИ-системы регистрируются как отдельный класс ИТ-активов в модуле инвентаризации с атрибутами: тип модели, провайдер, версия, данные, бизнес-процесс, ответственный. Это основа для Map из NIST AI RMF.
• Каталоги угроз с ИИ-спецификой. В модуле управления рисками доступны каталоги угроз, включающие prompt injection, model DoS, training data poisoning, bias и другие ИИ-специфические риски. При моделировании угроз по методике ФСТЭК каталог расширяется ИИ-векторами.
• Связь с БДУ ФСТЭК. Уязвимости ML-фреймворков (PyTorch, vLLM, TensorFlow) отслеживаются через реестр БДУ ФСТЭК как обычное ПО. При появлении новой CVE в компоненте LLM-стека создаётся задача с SLA по приказу №117.
• Шаблоны политик и ОРД. Платформа содержит шаблоны политик использования ИИ, регламентов обработки ПДн через корпоративные LLM, инструкций для сотрудников по безопасной работе с GigaChat и YandexGPT. Эти документы — готовая база для функции Govern.
• Дашборды покрытия NIST AI RMF. Визуализация статуса внедрения четырёх функций и семи характеристик trustworthy AI. По каждому пункту видно, какие меры реализованы, какие в работе, какие отсутствуют.

Попробовать управление ИИ-рисками по модели NIST AI RMF через КиберОснова SGRC можно, запросив демо. На встрече покажем, как вести реестр ИИ-активов, запускать моделирование угроз с ИИ-спецификой, связывать риски с мерами защиты из приказов ФСТЭК и генерировать отчётность по четырём функциям рамки.

Будущее ИИ Security в России

На апрель 2026 года российское регулирование ИИ находится на стадии формирования. Существуют точечные документы: серия ГОСТ Р 59276 «Системы искусственного интеллекта» (надёжность, классификация, терминология), Кодекс этики в сфере ИИ (2021), Национальная стратегия развития ИИ до 2030 года, методические материалы Сбера, Яндекса, Минцифры. Однако полноценного отечественного аналога NIST AI RMF, покрывающего все аспекты управления ИИ-рисками, пока нет.

Разработка идёт по нескольким направлениям. ТК 164 Росстандарта продолжает работу над ГОСТ Р в сфере ИИ, в 2025–2026 годах ожидается появление новых документов по тестированию, безопасности, объяснимости. Минцифры обсуждает законопроект о регулировании искусственного интеллекта, который может ввести обязательные требования к маркировке ИИ-контента, ответственности за решения ИИ, сертификации критичных систем. Банк России готовит методические рекомендации по применению ИИ в финансовой сфере. В Совете Федерации обсуждается законодательство о защите прав граждан при взаимодействии с AI.

По оценкам экспертов, полноценный отечественный ИИ Risk Management Framework появится не ранее 2027–2028 годов. До этого момента зрелые российские организации применяют NIST AI RMF как методический референс, адаптируя его под отечественную нормативную базу. Это разумный подход: ждать регулятора — значит отставать в управлении реальными рисками, которые возникают уже сейчас при каждом новом внедрении LLM в корпоративные процессы.

Практические шаги, которые можно сделать уже сегодня без ожидания регулятора: провести инвентаризацию ИИ-активов, сформировать внутреннюю политику использования ИИ, назначить ответственного, интегрировать ИИ-угрозы в модель угроз ФСТЭК, внедрить adversarial-тестирование для критичных моделей, документировать решения в SGRC-платформе. Организации, которые это сделают в 2026 году, к моменту появления обязательных требований окажутся в выигрышной позиции — у них уже будет работающий процесс, который останется лишь формализовать под новые нормативы.

FAQ

Что такое NIST AI RMF и зачем он нужен?

NIST AI Risk Management Framework 1.0 (идентификатор NIST.AI.100-1) — рамочный документ Национального института стандартов и технологий США, опубликованный 26 января 2023 года. Он описывает подход к управлению рисками ИИ-систем через четыре функции: Govern (культура управления), Map (картирование контекста), Measure (измерение) и Manage (управление). Документ нужен организациям, внедряющим ИИ, чтобы систематизировать работу с рисками и выстроить процессы оценки надёжности моделей — от классификаторов до больших языковых моделей. NIST AI RMF не содержит обязательных требований, он помогает привести внутренние политики в соответствие с лучшими практиками и закрыть управленческие пробелы, которые не покрывают традиционные фреймворки ИБ вроде ISO 27001 или требований ФСТЭК.

Обязательно ли применять NIST AI RMF в российских организациях?

Нет, NIST AI RMF не является обязательным ни в России, ни в США — это добровольный документ, который не имеет нормативной силы даже в стране происхождения. В российской юрисдикции отсутствует прямое регулирование ИИ-рисков: нет отдельного закона об искусственном интеллекте, нет обязательного отечественного аналога ИИ RMF. Для госсектора применяется приказ ФСТЭК №117 по защите ГИС, для персональных данных — 152-ФЗ, но ни один из этих документов не описывает специфические ИИ-риски вроде bias, галлюцинаций или prompt injection. В такой ситуации NIST AI RMF полезен как методический референс: российские CISO и product-owner'ы используют его структуру для построения внутренних политик по ИИ-рискам, не ожидая, когда появится отечественный стандарт. Применение рамки добровольно, но демонстрирует зрелость подхода перед аудиторами и клиентами.

Чем NIST AI RMF отличается от OWASP Top 10 для LLM?

NIST AI RMF и OWASP Top 10 для LLM — документы разного уровня, они дополняют друг друга, а не конкурируют. OWASP Top 10 for LLM Applications — технический каталог конкретных уязвимостей: prompt injection, insecure output handling, training data poisoning, model DoS. Он нужен разработчикам и пентестерам, которые работают с LLM-приложением на уровне кода и запросов. NIST AI RMF — стратегическая рамка уровня организации: как устроено управление ИИ-рисками, кто отвечает, какие метрики отслеживаются, как принимаются решения о внедрении модели. OWASP отвечает на вопрос «какие технические атаки возможны», NIST — «как построить процесс управления рисками в масштабе компании». На практике зрелая программа ИИ-безопасности использует оба документа: NIST задаёт каркас управления, OWASP наполняет его конкретными угрозами для LLM-приложений.

Четыре функции ИИ RMF — что они означают?

AI RMF выделяет четыре ключевые функции управления рисками. Govern (Управление) — создание культуры и структуры, включая политики, роли, подотчётность руководства за использование ИИ и обучение команды. Map (Картирование) — идентификация контекста использования модели: что за система, кто пользователи, какие данные обрабатываются, какие риски и последствия возможны. Measure (Измерение) — количественная и качественная оценка рисков через метрики качества модели, безопасности, справедливости, приватности, включая adversarial-тесты и fairness-аудиты. Manage (Управление) — приоритизация выявленных рисков, принятие решений об их обработке (mitigate, accept, transfer, avoid), мониторинг в эксплуатации, реагирование на инциденты. Функции не последовательны, а цикличны: Govern задаёт фон, Map-Measure-Manage повторяются на протяжении всего жизненного цикла ИИ-системы от разработки до вывода из эксплуатации.

Как NIST AI RMF связан с требованиями ФСТЭК?

Прямой связи между NIST AI RMF и приказами ФСТЭК нет — это документы разных юрисдикций и разных целей. Однако на практике их полезно использовать вместе, когда ИИ-система внедряется в государственную информационную систему или в ИСПДн. Приказ ФСТЭК №117 требует моделирования угроз и выбора мер защиты для ГИС — функция Map из ИИ RMF помогает структурировать идентификацию ИИ-специфических угроз (prompt injection, data poisoning, bias), которые затем включаются в модель угроз по методике ФСТЭК. Функция Measure дополняет техническое тестирование метриками справедливости и надёжности модели, которые в ФСТЭК-методиках пока не регламентированы. Функция Govern согласуется с требованиями приказа №117 по организационным мерам — политика ИБ, роли, обучение персонала. Manage соответствует процессу управления рисками ИБ и обработки инцидентов. Таким образом, NIST AI RMF удобно использовать как методологическую надстройку над российскими требованиями, закрывающую пробелы по ИИ-специфике.

Существует ли российский аналог NIST AI RMF?

На апрель 2026 года полноценного отечественного аналога NIST AI RMF не существует. Разработкой стандартов по искусственному интеллекту в России занимается технический комитет ТК 164 Росстандарта «Искусственный интеллект» — на его счёту серия ГОСТ Р 59276 по надёжности систем ИИ, ГОСТ Р по тестированию, документы по терминологии и классификации. Это полезные, но точечные документы, не образующие единой рамки управления рисками. Отдельные инициативы включают Кодекс этики в сфере ИИ (2021 год), Национальную стратегию развития ИИ до 2030 года, обсуждения в Минцифры и Совете Федерации законопроектов о регулировании AI. Полноценный отечественный ИИ RMF, по оценкам экспертов, появится не ранее 2027–2028 годов. До этого момента российские организации используют NIST AI RMF как референс, адаптируя его под отечественную нормативную базу — приказы ФСТЭК, 152-ФЗ, отраслевые требования Банка России.

Как внедрить NIST AI RMF в организации с нуля?

Внедрение NIST AI RMF начинается не с документов, а с инвентаризации существующих ИИ-активов: какие модели используются, кто их разработчики, какие данные они обрабатывают, какие решения принимают. Без этого шага рамка повисает в воздухе. Далее — определение владельца программы ИИ-рисков (обычно CISO или Chief AI Officer), формирование ИИ Ethics Committee с участием бизнеса, ИТ, ИБ, юристов, формализация политики использования ИИ. Параллельно запускается пилот — одна ИИ-система, к которой применяются все четыре функции: Govern (назначение ответственного), Map (модель угроз и карта заинтересованных сторон), Measure (набор метрик — качество, безопасность, справедливость), Manage (план обработки рисков, мониторинг). После успешного пилота подход тиражируется. Типичный срок запуска программы ИИ RMF в enterprise — 6–12 месяцев. SGRC-платформа КиберОснова поможет ускорить этот процесс за счёт готовых реестров ИИ-активов, каталогов угроз и шаблонов политик — запросите демо, чтобы увидеть поддержку NIST AI RMF в действии.