Полигон Минцифры для ИИ: тестирование безопасности

Минцифры разрабатывает законопроект, который вводит обязательное тестирование и сертификацию искусственного интеллекта перед использованием на критически важных объектах – от госсистем до инфраструктуры энергетики, транспорта, связи и финансов. В основе инициативы – создание специального полигона для проверки ИИ на безопасность. Прошел проверку – получил допуск к внедрению на объектах критической информационной инфраструктуры (КИИ).

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

Четыре уровня риска ИИ: как читать классификацию бизнесу и ИТ

Законопроект вводит четыре уровня критичности ИИ-систем: минимальный, ограниченный, высокий и критический. Определение уровня и ведение реестра допущенных систем завязывается на Национальный центр ИИ в сфере госуправления при правительстве.

Чтобы не утонуть в терминах, я предлагаю смотреть на это как на дерево решений по последствиям:

• Минимальный риск – ИИ не влияет существенно на права и безопасность, типичный пример – рекомендации, подсказки, ранжирование.
• Ограниченный риск – ключевое требование не про безопасность, а про прозрачность: пользователь должен понимать, что взаимодействует с ИИ.
• Высокий риск – ИИ используется на объектах КИИ. Здесь важен не жанр системы, а место внедрения.
• Критический риск – потенциальная угроза жизни и здоровью, безопасности государства, а также автономные решения без человека в контуре.

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

Полигон Минцифры: когда это реально повышает безопасность, а когда становится формальностью

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

Минимальный набор испытаний, который дает прикладную пользу и хорошо ложится в требования безопасности:

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

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

Сертификация ФСТЭК и ФСБ: на чем чаще всего ломаются команды

Для высоких и критических систем заявлена необходимость сертификата соответствия требованиям безопасности ФСТЭК и ФСБ, а сами требования обещают закрепить отдельным документом позже. В таких режимах обычно ломается не модель, а дисциплина вокруг нее.

Если готовиться заранее, полезно собрать набор доказательств, который переживает любые формулировки регулятора:

• Паспорт ИИ-системы: назначение, границы, сценарии, запреты, что система не делает никогда.
• Модель угроз: перечень реальных атак и отказов с последствиями, а не абстрактные слова про безопасность.
• Регламент изменений: кто имеет право обновлять, как фиксируются версии, как проводится откат, как подписываются сборки.
• Журналы и трассировка: что именно логируется, как долго хранится, кто имеет доступ, как проводится расследование инцидентов.
• Матрица доступов: какие роли, какие права, какие действия запрещены на уровне платформы, а не договоренностей в команде.

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

Запрет ИИ с иностранным правообладателем для КИИ: суверенитет не равен безопасности

Законопроектом заявлен запрет на использование на КИИ ИИ-систем, права на которые принадлежат иностранным лицам. Мотивация понятна: технологический суверенитет и снижение рисков передачи данных.

Но у этой меры есть два практических эффекта, о которых бизнесу стоит думать заранее:

• Риск аварийной миграции. Многие компании уже используют зарубежные ИИ-решения, включая open source, и резкий запрет может ударить по процессам.
• Риск подмены сути формой. Юридическое происхождение не гарантирует технический контроль. Если развертывание, данные и обновления не контролируются, отечественный статус не спасает.

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

Что меняется для рынка ИИ в России: рост, концентрация и цена комплаенса

По оценке Smart Ranking, рынок ИИ в России в 2025 году вырос на 25-30% и составил 1,9 трлн руб., а 95% выручки от монетизации ИИ пришлось на топ-5 компаний. Это важный фон: любое обязательное регулирование повышает стоимость комплаенса и почти всегда усиливает лидеров, потому что у крупных игроков больше ресурсов на безопасность, юристов и процессы.

Если требования будут сформулированы грубо и одинаково для разных классов систем, рынок получит две крайности:

• Либо запретительную модель, которая замораживает внедрения в чувствительных отраслях.
• Либо формальные проверки, которые не ловят реальные риски, но создают видимость контроля.

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

Как я бы проектировал ИИ под полигон и допуск в КИИ

Ни один продукт не обязан жить в КИИ. Но многие B2B-платформы в итоге туда приходят через крупных клиентов. Поэтому разумно проектировать архитектуру так, чтобы прохождение проверок не превращалось в переписывание системы.

Схема, которая снижает риски и стоимость соответствия:

• Разделять совет и действие: рекомендации можно спорить, действия нужно жестко ограничивать и подтверждать.
• Вводить режимы: безопасный режим по умолчанию, расширенные действия только по явным правилам и правам.
• Делать воспроизводимость: версия модели, версия промптов, версия правил, версия данных, чтобы любой инцидент можно было повторить и разобрать.
• Управлять изменениями как релизом в критичной системе: тесты, канареечные выкладки, откат, журналирование.

В Андате мы в целом так и смотрим на внедрения: выигрывает не самая умная модель, а самая управляемая система, которая стабильно дает результат и переживает проверки.

Вывод

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

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

Источник: rbc.ru