Зрелость внедрения ИИ и зрелость информационной безопасности ИИ

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

В статье приведём обе оси к единой шкале CMMI, покажем, как организации проходят узнаваемые состояния (от отрицания до бесконтрольных агентов), и свяжем всё это с Приказом ФСТЭК № 117 и российскими стандартами.

1. Зачем измерять две зрелости

Любая организация живёт сразу в двух измерениях ИИ. Одно – насколько глубоко ИИ встроен в её процессы и продукты. Другое – насколько она вообще управляет тем, что с этим ИИ происходит с точки зрения ^[1] безопасности. По опыту ^[2] проектов эти измерения почти никогда не совпадают, и большую часть инцидентов и претензий регулятора даёт именно зазор между ними, а не сам факт использования ИИ.

Сложность в том, что отрасль описывает эти измерения на разных языках. Бизнес меряет внедрение по моделям вроде Gartner, безопасники – по OWASP AIMA или SAIF, регулятор оперирует пунктами Приказа. Свести их напрямую нельзя. Поэтому мы приводим обе оси к одной шкале – CMMI, пятиуровневой модели зрелости процессов, из которой в итоге выросли и SAMM, и построенная на нём AIMA. Дальше и внедрение, и безопасность ИИ описываются уровнями L1–L5, и разрыв между ними становится виден буквально как разница в номерах.

Суть в одной фразе:

Зрелость защиты ИИ должна догонять зрелость его внедрения, а лучше – слегка опережать. Организация на L3 по использованию ИИ и на L1 по его защите – это не «почти всё хорошо», а открытая дверь: и для утечек через теневые сервисы, и для прямого несоответствия Приказу № 117.

2. Единая шкала зрелости (CMMI)

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

2.1. Пять уровней CMMI

• L1: Начальный. Процессы непредсказуемы и реактивны, всё держится на отдельных людях.

• L2: Управляемый. Процессы выстроены на уровне отдельных проектов, но не унифицированы по организации.

• L3: Определённый. Появляются единые для организации стандарты и процессы, работа становится проактивной.

• L4: Количественно управляемый. Процессы измеряются и управляются по метрикам.

• L5: Оптимизирующий. Непрерывное улучшение на основе данных и обратной связи.

2.2. Сопоставление осей на шкале CMMI

Ниже обе оси и шкала OWASP AIMA приведены к общим уровням. AIMA пользуется компактной трёхуровневой шкалой, которая ложится в верхнюю часть CMMI (L2–L5); всё, что ниже, – это уже отсутствие управляемой практики.

3. Внедрение ИИ на шкале CMMI

Внедрение ИИ принято описывать пятиуровневой шкалой Gartner: осведомлённость, пилоты, эксплуатация, системное использование, трансформация. Содержательно она ложится на CMMI почти один в один, поэтому отдельную нумерацию мы не вводим – пользуемся уровнями L1–L5. Процессным якорем здесь служит ISO/IEC 42001:2023 (система менеджмента ИИ): это не шкала зрелости, но удобный источник ролей, политик и управления жизненным циклом.

Самая показательная точка – переход с L2 на L3. Именно здесь пилот превращается в боевую систему, и вместе с ним «включаются» обязательные требования к ИИ. По данным Gartner, на этом переходе застревает большинство организаций; добавим от себя, что ровно здесь чаще всего и расходятся две оси: использование уже промышленное, а защита всё ещё пилотная.

4. Безопасность ИИ на шкале CMMI

С безопасностью ИИ ситуация обратная: фреймворков много, а настоящая лестница зрелости среди них одна – OWASP AIMA (версия 1.0 вышла в августе 2025 года), наследник SAMM. AIMA раскладывает защиту ИИ на восемь доменов: Responsible AI, Governance, Data Management, Privacy, Design, Implementation, Verification, Operations – и оценивает каждый по трём уровням. Этих трёх уровней хватает, чтобы занять верхнюю часть CMMI.

Остальные рамки – не лестницы, а наполнение для неё.

Google SAIF даёт риск-карту по четырём областям (Data, Infrastructure, Model, Application) и инструмент самооценки; версия SAIF 2.0 добавляет то, без чего сегодня уже нельзя, – безопасность агентов: разрешения на инструменты, отравление памяти ^[3], многоагентные сценарии. NIST AI RMF задаёт четыре функции управления рисками (Govern, Map, Measure, Manage).

Слой проверки закрывают каталоги атак MITRE ATLAS и OWASP Top-10 для LLM-приложений. Управленческий контур – ISO/IEC 42001 и 23894, матрица контролей CSA AICM и открытая риск-карта CoSAI-RM, в которую Google передал данные SAIF.

5. Эволюция проблемы на практике

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

5.1. Отрицание: «у нас ИИ нет»

Самый обманчивый ответ. Политики нет, инвентаризации нет – потому что «нечего инвентаризировать». А по факту сотрудники уже носят рабочие данные в публичные чат-боты и копайлоты. Угроза здесь не столько техническая, сколько управленческая: организация не видит собственного периметра. Утечка по 152-ФЗ или режиму ограниченного доступа уже возможна – просто её некому заметить. На шкале это твёрдый L1.

5.2. Неподконтрольный Shadow AI

Отрицание сменяется признанием, но не контролем. ИИ обнаруживается повсюду – в SaaS-сервисах, плагинах, ассистентах, – а единых правил, журналирования и DLP под него по-прежнему нет. Это худшее из устойчивых состояний: пользы уже много, видимости почти никакой. Большинство будущих нарушений пунктов 60–61 Приказа №117 родом именно отсюда. По внедрению организация уже на L2, по защите – всё ещё на L1.

5.3. LLM под контролем, агенты – вне контроля

Дальше наводят порядок в очевидном – в чат-интерфейсах и LLM. Появляется единый шлюз, фильтрация запросов и ответов, guardrails, проверки достоверности. По LLM это честный L3. Но пока строился этот контур, рядом вырос новый – агенты. Они не просто отвечают, а действуют: вызывают инструменты, ходят по API, через MCP подключаются к внутренним системам, общаются между собой. Меры, заточенные под «вопрос-ответ», их не покрывают.

Возникает характерный перекос: по LLM зрелость L3, по агентам – снова L1. Это сегодняшняя передовая большинства зрелых команд, и именно сюда смотрит SAIF 2.0. Перекос опасен тем, что субъективно ощущается как «у нас всё под контролем» – ведь самый заметный, чат-интерфейсный, риск действительно закрыт.

5.4. Управляемый агентный контур

Закрытие этого перекоса и есть переход на L4: разрешения инструментов по принципу минимума прав, изоляция и идентичность агентов, мониторинг их действий, метрики.

L5 добавляет то, что превращает защиту в живой процесс, – регулярный red-teaming и обновление мер под новые классы атак быстрее, чем те становятся массовыми. До этого уровня сегодня доходят единицы, и это нормально: важно осознанно двигаться, а не имитировать L5 на фоне неуправляемого L1 в соседнем контуре.

6. Российский регуляторный слой

Зарубежные модели молчат о главном для российского заказчика – об обязательных требованиях. А они за 2025–2026 годы изменились сильно, и игнорировать их при оценке зрелости нельзя: этот слой задаёт не лестницу, а планку, ниже которой опускаться запрещено.

6.1. Приказ ФСТЭК России № 117

Приказ ФСТЭК № 117 (от 11 апреля 2025 года) заменил Приказ № 17 и с 1 марта 2026 года действует в полную силу. Впервые требования к ИИ закреплены нормативно – в пунктах 60 и 61. Важная деталь: ИИ-систему регулятор не выделяет в отдельный тип объекта. Это обычная информационная система по 149-ФЗ, внутри которой работает ИИ; требования действуют и на собственную разработку, и на чужой сервис, вызываемый по API.

Что конкретно требуется:

• использовать только доверенные технологии ИИ (по подп. «ц» п. 5 Национальной стратегии развития ИИ);

• не передавать информацию ограниченного доступа разработчику модели; не применять облачные ИИ-сервисы для гостайны и сведений ограниченного доступа;

• контролировать наборы данных; задавать допустимые форматы запросов и ответов (правила для шаблонных операций и допустимую тематику для свободного текста);

• использовать статистические критерии достоверности ответов и ограничивать решения на их основе; запрещать нерегламентированное влияние ИИ на собственные параметры модели и на работу ИС.

Сопутствующее: метрики защищённости КЗИ/ПЗИ с отчётностью раз в полгода, разработка по ГОСТ Р 56939-2024, мониторинг по ГОСТ Р 59547-2021 в связке с ГосСОПКА и почти кадровое требование – не меньше 30% подразделения ИБ с профильным образованием.

Где срабатывает требование

Львиная доля требований к ИИ включается не при разработке, а при переводе системы в боевую эксплуатацию (для ГИС – обязательно с 1 марта 2026 года). То есть переход с L2 на L3 не просто технический: он переводит пункты 60–61 из «когда-нибудь» в «прямо сейчас».

6.2. Доверие и безопасная разработка

Базовый якорь доверия – ГОСТ Р 59276-2020 «Способы обеспечения доверия», на который опираются и методические рекомендации Банка России по доверенному ИИ на финрынке. Безопасную разработку задаёт ГОСТ Р 56939-2024. Отдельный стандарт ФСТЭК по безопасной разработке ИИ (MLSecOps) пока готовится.

6.3. ИИ в критической инфраструктуре

1 июля 2025 года ТК 164 опубликовал проект ГОСТ Р «Искусственный интеллект ^[4] в критической информационной инфраструктуре. Общие положения» (разработчик – ФСТЭК) – первый комплексный документ по безопасности ИИ-систем в ключевых отраслях.

30 января 2026 года Росстандарт выпустил приказ № 2-ПНСТ, где утвердил предварительный национальный стандарт (ПНСТ) 1046-2026 с тем же названием: «Искусственный интеллект в критической информационной инфраструктуре. Общие положения». То есть проект трансформировался в официальный нормативный документ, просто в формате ПНСТ, а не сразу в ГОСТ Р.

Документ распространяется на системы ИИ, которые используют в составе программно-аппаратных комплексов объектов КИИ. Он задаёт общие положения для всего жизненного цикла таких систем. Документ гармонизирован с ISO/IEC 27001, 22989, 42001 и 187-ФЗ и разделяет два жизненных цикла ИИ-системы. Для значимых объектов КИИ это отдельный, более строгий контур.

6.4. Сводка регуляторных якорей

 Чего пока нет в требованиях

Качество самих моделей – объяснимость решений и борьбу с галлюцинациями – регулятор сознательно выносит за скобки: контролируется лишь достоверность ответов, и то статистически. Это и осторожность, и подсказка: зрелые команды закрывают этот участок сами, не дожидаясь отдельного норматива.

7. Разрыв между осями

Сложим разделы 2 и 6 – и сразу виден системный пробел. Модели внедрения меряют бизнес и молчат об ИБ. Модели ИБ меряют защиту, но не привязаны ни к уровню внедрения, ни к российским требованиям. Регуляторика задаёт планку, но не лестницу. В итоге никто не отвечает на главный практический вопрос: если по использованию ИИ мы на L3, на каком уровне обязана быть наша защита?

Ответ: на том же. Опасна именно диагональ: высокое внедрение при низкой ИБ. Организация на L3–L4 по использованию и на L1–L2 по защите одновременно копит неуправляемый риск и нарушает пункты 60–61 Приказа №117. Все три состояния из раздела 5 – отрицание, Shadow AI, неподконтрольные агенты – это и есть точки на этой диагонали.

8. Модель сопряжения: внедрение → ИБ → требования РФ

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

8.1. Матрица сопряжения

Сокращения: ИОД – информация ограниченного доступа; РБПО – разработка безопасного ПО; КЗИ/ПЗИ – показатели защищённости информации.

8.2. Как читать матрицу

Матрицу читают в обе стороны. Сверху вниз – как обязательство: дошли по внедрению до L3, значит и защита обязана быть L3. Снизу вверх – как тормоз: не тяните внедрение выше того уровня, который реально закрываете по ИБ. Любой разрыв – это либо риск, либо несоответствие, а чаще и то и другое сразу.

9. Как применять модель

Применяется в три шага. Сначала честно определяем уровень по внедрению. Затем – по защите, по доменам AIMA, наполненным контролями SAIF и MITRE и сверенным с требованиями ФСТЭК. После этого смотрим разрыв и строим дорожную карту от ближайшего обязательного уровня, а не от идеала.

Где здесь технические средства. Большая часть обязательных мер уровня L3 – это runtime-слой: единый шлюз, фильтрация запросов и ответов, контроль форматов, проверки достоверности, guardrails. Его и закрывают специализированные средства защиты ИИ-приложений (LLM Firewall), что делает их прямым способом дотянуть защиту до L3 и выполнить пункты 60–61. На L4–L5 к ним добавляются непрерывный мониторинг, контроль агентного контура и MLSecOps.

Привязка к продуктам

В терминах этой шкалы средства класса AI.Firewall закрывают runtime-уровень, обязательный начиная с L3, а инструменты безопасной разработки – слой РБПО, нужный уже на пилотах (L2). Оценка зрелости становится точкой входа в разговор с заказчиком, а конкретные продукты – понятным маршрутом закрытия разрыва.

10. Выводы

• Внедрение ИИ и его защита – две разные зрелости. Мерить нужно обе и смотреть на разрыв между ними, а не на каждую по отдельности.

• CMMI даёт общий язык: и Gartner-уровни внедрения, и домены AIMA, и требования ФСТЭК ложатся на одну шкалу L1–L5.

• На практике организации проходят узнаваемые состояния – отрицание, неподконтрольный Shadow AI, контроль LLM при бесконтрольных агентах. Каждое из них – точка на опасной диагонали.

• Российские требования (Приказ № 117, ГОСТы, проект по КИИ) задают обязательный минимум и привязывают нагрузку к моменту перевода ИИ в эксплуатацию (переход L2 → L3).

• Runtime-средства защиты – прямой способ дотянуть ИБ до уровня внедрения начиная с L3. Агентный контур – следующий рубеж, L4 и выше.

Источники

Шкала и международные рамки

• CMMI (модель зрелости процессов; ISO/IEC 33001 и CMMI Institute) – общая шкала уровней L1–L5.

• OWASP AI Maturity Assessment (AIMA), v1.0, август 2025; OWASP SAMM; OWASP Top-10 для LLM-приложений.

• Google Secure AI Framework (SAIF) и SAIF 2.0; CoSAI Risk Map (CoSAI-RM).

• NIST AI Risk Management Framework и профиль для генеративного ИИ; MITRE ATLAS; CSA AI Controls Matrix (AICM).

• ISO/IEC 42001:2023; ISO/IEC 23894; ISO/IEC 22989. Модель зрелости внедрения ИИ (пятиуровневая, Gartner); модель MIT CISR.

Российские документы

• Приказ ФСТЭК России № 117 от 11.04.2025 (в силе с 01.03.2026) и сопровождающий методический документ.

• ГОСТ Р 59276-2020; ГОСТ Р 56939-2024; ГОСТ Р 59547-2021.

• Проект ГОСТ Р «Искусственный интеллект в критической информационной инфраструктуре. Общие положения» (ТК 164, 01.07.2025).

• БДУ ФСТЭК; Национальная стратегия развития ИИ; 187-ФЗ; 152-ФЗ; методические рекомендации Банка России по доверенному ИИ.

Модели зрелости Gartner и ряд стандартов ISO распространяются на условиях правообладателей; здесь используются их общедоступные структурные описания.