Верифицируемый ИИ в российском регулировании 2026–2027

С 1 марта 2026 года в российской нормативной практике информационной безопасности произошел тектонический сдвиг: вступил в силу Приказ ФСТЭК России №117 от 11 апреля 2025 года. Этот документ, полностью заменивший действовавший более десяти лет Приказ №17, впервые на уровне государственного стандарта закрепил жесткий запрет на использование внешних облачных ИИ-сервисов для обработки государственной тайны и информации ограниченного доступа.

Несмотря на то, что утвержденные технические методики реализации этих требований регулятором еще не опубликованы, правовой вакуум отсутствует. Опубликованный 18 марта 2026 года проект Федерального закона «Об основах государственного регулирования применения технологий искусственного интеллекта» вводит фактическую презумпцию виновности разработчиков и операторов ИИ-систем в случае причинения вреда или нарушения законодательства.

Для операторов значимых объектов критической информационной инфраструктуры (ЗО КИИ), CISO, банковского и государственного секторов это означает необходимость экстренного перехода на локальные, полностью верифицируемые контуры (on-prem). Ситуация усложняется тем, что по данным ИТ-исследований на весну 2026 года лишь около 9% отечественных организаций полностью обеспечены вычислительной GPU-инфраструктурой для локального развертывания искусственного интеллекта.

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

Нормативный слом: Приказ №117 и бесповоротный запрет на ИИ в облаке

Принятие Приказа ФСТЭК России №117 знаменует собой переход отечественного госсектора и КИИ от формального «бумажного» комплаенса к непрерывному операционному контролю. В отличие от старого Приказа №17, новый документ интегрирует в базовый состав организационных и технических мер защиты ИТ-ландшафта современные векторы угроз, включая контейнеризацию, API-интеграции и искусственный интеллект.

Пункт 61 Приказа №117 вводит прямой запрет на использование внешних облачных ИИ-сервисов (таких как API зарубежных или публичных отечественных моделей) при обработке конфиденциальных данных и информации ограниченного доступа. Регулятор требует, чтобы любые варианты коммуникации между пользователем и алгоритмами ИИ закладывались на этапе проектирования системы и находились под полным контролем оператора. Фактически требования req-60 и req-61 Приказа №117 предписывают контролировать поведение сотрудников, запрещая неконтролируемую передачу данных разработчикам сторонних моделей.

Техническая логика регулятора базируется на внедрении четырех обязательных механизмов контроля ИИ-систем на этапе эксплуатации:

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

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

Проект ФЗ об ИИ от 18 марта 2026 года: презумпция виновности и статья 10.1

Вторым вектором регуляторного давления выступает проект Федерального закона «Об основах государственного регулирования применения технологий искусственного интеллекта», опубликованный 18 марта 2026 года. Главной целью этого закона провозглашено обеспечение государственного технологического суверенитета: критически важные нейросети должны создаваться, обучаться и эксплуатироваться внутри страны.

Статья 7.2 проекта ФЗ вводит понятие «суверенных моделей», устанавливая три жестких критерия для получения данного статуса: все стадии разработки, обучение наборов данных и непосредственная эксплуатация должны осуществляться гражданами РФ или российскими юридическими лицами исключительно на территории Российской Федерации.

В развитие этого положения Статья 8 предусматривает создание Реестра доверенных моделей искусственного интеллекта. Попадание в данный реестр требует прохождения проверок безопасности во ФСТЭК и ФСБ России. Применение моделей, не включенных в данный реестр, в ГИС и на значимых объектах КИИ Статьей 8.1 прямо запрещается, что полностью отсекает использование любых иностранных API.

Для CISO и compliance-юристов ключевыми являются Статьи 10.1, 11.2 и 11.3 законопроекта, перераспределяющие юридическую ответственность:

Статья 10.1 вменяет в обязанность разработчикам и операторам обеспечивать безопасность созданной модели с обязательным документированием всех принятых решений.
Статья 11.2 вводит презумпцию виновности разработчика, оператора и владельца сервиса ИИ за любой противоправный результат работы нейросети, если они заведомо знали или должны были знать о возможности его получения.
Статья 11.3 предоставляет единственный легальный способ защиты: разработчик и оператор освобождаются от ответственности только в том случае, если докажут, что предприняли «исчерпывающие технические и организационные меры» для предотвращения инцидента и полностью соблювали требования законодательства.

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

Инфраструктурный тупик: масштаб аппаратного дефицита

Переход на локальные ИИ-контуры (on-prem) требует колоссальных вычислительных ресурсов, однако рынок столкнулся с глубоким инфраструктурным дефицитом. Согласно результатам исследования ИТ-холдинга «Т1» («Рынок ИИ-ускорителей: обзор российского рынка GPU для задач в области ИИ»), опубликованного в марте 2026 года, лишь 9% организаций в России полностью обеспечены необходимыми вычислительными мощностями для задач ИИ. Больше половины отечественных компаний (51%) испытывают острую потребность в GPU-ресурсах для инференса и дообучения моделей.

В условиях санкционных ограничений и дефицита корпоративных ускорителей уровня NVIDIA A100/H100 организации вынуждены пересматривать свой стек. Вместо гигантских проприетарных моделей фокус смещается на оптимизированные локальные open-weights архитектуры (такие как адаптированные версии Llama-3, Qwen-2.5 или отечественный GigaChat), разворачиваемые на собственных мощностях предприятий. Процесс инференса оптимизируется за счет применения глубокого квантования и специализированных микросервисных архитектур, что позволяет запускать модели на ограниченном парке оборудования.

Параметр сравнения	Облачные ИИ-сервисы (Public API)	Верифицируемый локальный ИИ-контур (On-prem)
Соответствие Приказу №117	Не соответствует; прямая угроза отзыва аттестата ГИС	Полное соответствие при условии реализации мер защиты
Соответствие проекту ФЗ об ИИ	Запрещено для ГИС и КИИ (Статья 8.1)	Соответствует при использовании моделей из Реестра доверенных
Юридические риски руководства	Максимальные; прямая ответственность по Ст. 11.2	Минимальные; защита через подтверждение «исчерпывающих мер» (Ст. 11.3)
Инфраструктурные затраты	Низкие (оплата по факту использования токенов)	Высокие; необходимость закупки дефицитного оборудования
Контроль утечки данных (DLP)	Невозможен; данные передаются третьей стороне	Полный контроль на уровне сетевого периметра и изоляции сред
Зависимость от санкций	Критическая (риск мгновенной блокировки аккаунтов)	Отсутствует на этапе эксплуатации локальных мощностей

Смежная экосистема ИБ: КИИ, 187-ФЗ, Приказ №239 и ГОСТ Р 57580.1

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

187-ФЗ и Приказ ФСТЭК №239 (КИИ): если ИИ-компонент внедряется в технологические или бизнес-процессы значимого объекта КИИ, он автоматически становится объектом защиты. Это накладывает требования по непрерывному мониторингу ИБ, интеграции с ГосСОПКА и соблюдению жесткого регламента устранения уязвимостей. В рамках систем КЗИ уязвимости должны устраняться по строгому SLA: критические — за 24 часа, высокие — за 7 дней, уязвимости из БДУ ФСТЭК — за 5 рабочих дней.
ГОСТ Р 57580.1 (Безопасность финансовых операций): для организаций финансового сектора внедрение ИИ актуализирует требования к обеспечению целостности данных и непрерывному аудиту. Каждый запрос пользователя (промпт) и каждый ответ модели должны непрерывно логироваться и храниться в неизменяемом виде (WORM) не менее 1 года.
ГОСТ Р 56939-2024 (Безопасная разработка): Приказ №117 впервые на нормативном уровне делает обязательным соблюдение требований безопасной разработки ПО для ГИС. Применительно к ИИ это требует обязательного сканирования весов моделей на предмет скрытых закладок и бэкдоров. В частности, Методики ФСТЭК предписывают полный отказ от использования уязвимого формата сериализации pickle (риск удаленного выполнения произвольного кода при загрузке модели) и переход на безопасные альтернативы, такие как safetensors.

Проектирование «по духу»: архитектура верифицируемого контура

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

+---------------------------------------------------------------------------------+
|                                 СЕТЕВОЙ ПЕРИМЕТР                                |
|  [ Пользователь / Система-потребитель ] <--->                                   |
+---------------------------------------------------------------------------------+
                                         |
                                         v
+---------------------------------------------------------------------------------+
|                            СЛОЙ ВХОДНОЙ ФИЛЬТРАЦИИ                              |
|  ---> Анализ на инъекции и утечку ПД                                            |
+---------------------------------------------------------------------------------+
                                         |
                                         v
+---------------------------------------------------------------------------------+
|                       ИЗОЛИРОВАННАЯ СРЕДА ИСПОЛНЕНИЯ                            |
|  [ Локальная LLM (On-Prem GPU) ] <--->                                          |
+---------------------------------------------------------------------------------+
                                         |
                                         v
+---------------------------------------------------------------------------------+
|                            СЛОЙ ВЫХОДНОЙ ФИЛЬТРАЦИИ                             |
|  ---> Блокировка системных команд, ПД и галлюцинаций                            |
+---------------------------------------------------------------------------------+
                                         |
                                         v
+---------------------------------------------------------------------------------+
|                             СЛОЙ СИСТЕМНОГО АУДИТА                              |
|                                                                                 |
+---------------------------------------------------------------------------------+

1. Слой сетевой изоляции среды выполнения

Среда эксплуатации ИИ-моделей (продуктивный контур) должна быть полностью изолирована от среды разработки ИИ. Прямой доступ из сегмента разработки в пром-контур запрещается. Все вызовы API модели внутри корпоративной сети защищаются многофакторной аутентификацией (MFA) и проходят через шлюз API с обязательным квотированием запросов (Rate Limiting) по IP-адресам и учетным записям для предотвращения DDoS-атак и попыток кражи весов модели.

2. Слой входной фильтрации запросов (Input Guardrails)

Любой запрос пользователя перед отправкой в нейросеть перехватывается специализированным микросервисом-фильтром. Этот слой решает две задачи:

Выявление попыток обхода системных промптов (Prompt Injection) и атак класса Jailbreak.
Сканирование запроса на предмет наличия конфиденциальных сведений (персональные данные, коммерческая тайна). Обнаруженные данные маскируются или полностью блокируются с выдачей предупреждения.

3. Слой выходной верификации (Output Guardrails)

Ответ ИИ-модели перед отправкой пользователю проходит автоматическую валидацию:

Проверка формата ответа (ограничение вывода структурированным JSON/XML без возможности выполнения несанкционированного кода).
Сканирование на содержание системных команд операционной системы и блокирование потенциально вредоносного вывода.
Фильтрация случайных галлюцинаций модели, которые могут содержать чужие персональные данные.

4. Слой непрерывного аудит-трейла (Audit Trail)

Все транзакции (исходный промпт, очищенный промпт, ответ модели, метаданные) в обязательном порядке логируются. Лог-файлы передаются во внутреннюю SIEM-систему по защищенному каналу и хранятся на отчуждаемых носителях в режиме защиты от записи (WORM) не менее 1 года. Это технически закрывает требования Статьи 10.1 проекта ФЗ об ИИ в части документирования безопасности.

Вектор РФ vs ЕС: суверенитет против управления рисками

Развитие систем ИИ в России и Европейском союзе демонстрирует два принципиально разных подхода к обеспечению доверия и безопасности, хотя оба контура движутся к концепции доказуемости (provability) и строгого документирования ИИ-систем.

Европейский союз в рамках своего EU AI Act (стандартизация которого активно разворачивается с мая 2026 года под эгидой CEN и CENELEC) опирается на риск-ориентированный подход. Законодательство ЕС делит ИИ на категории риска (неприемлемый, высокий, ограниченный, минимальный) и фокусируется на защите здоровья, безопасности и фундаментальных прав человека. Для систем высокого риска (High-Risk) вводится обязательная предварительная оценка влияния на права (Fundamental Rights Impact Assessment, FRIA), требования к качеству обучающих данных и человеческий контроль. Соответствие гармонизированным стандартам ЕС является формально добровольным, но дает презумпцию соответствия закону. Сроки вступления в силу правил высокого риска для автономных систем отложены до 2 декабря 2027 года, а для систем, встроенных в продукты, — до 2 августа 2028 года.

При этом в руководящих принципах Европейской комиссии от 26 мая 2026 года зафиксированы жесткие правила толкования сложных систем. Например, «правило комплексных систем» предписывает оценивать цепочки взаимосвязанных агентов (Agentic AI) как единую систему высокого риска в случае выполнения ими критических задач, закрывая лазейки для модульного обхода требований. Также ужесточен контроль над целевым назначением систем (Intended Purpose): если маркетинговые или презентационные материалы разработчика позиционируют модель как применимую в критических сферах, контрактные ограничения в Terms of Service не спасут его от классификации системы как высокорисковой.

Российский вектор регулирования (проект ФЗ об ИИ и Приказ №117) игнорирует западные концепции этики ИИ и деления на уровни риска, базируясь на жестком локализационном мандате и национальной безопасности. Безопасность ИИ в РФ трактуется не через отсутствие предвзятости данных (bias mitigation), а через физическую изоляцию вычислений от внешнего периметра и полную суверенизацию разработки.

Параметр сравнения	EU AI Act (Европейский союз)	Проект ФЗ об ИИ + Приказ №117 (Российская Федерация)
Базовая концепция	Риск-ориентированная модель (защита прав граждан)	Технологический суверенитет и национальная безопасность
Локализация вычислений	Требования отсутствуют; допускается использование глобальных облаков	Обязательная обработка на территории РФ для ГИС и КИИ
Требования к разработчикам	Ограничений по гражданству нет; обязательна регистрация в базе данных ЕС	Исключительно российские граждане и юридические лица
Ответственность	Оборотные штрафы до 7% от глобального дохода компании	Презумпция виновности (Ст. 11.2) с риском уголовного преследования
Трактовка мультиагентных систем	Оценка всей цепочки агентов как единой системы высокого риска	Запрет на внешние сетевые вызовы и автономные изменения архитектуры

Стратегия CISO: дорожная карта оператора до выхода методик

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

Шаг 1. Инвентаризация и классификация ИИ-активовНеобходимо выявить все используемые в организации сервисы и внутренние ИТ-системы, содержащие элементы ИИ и машинного обучения. По каждому компоненту составляется паспорт: назначение, разработчик, тип используемой модели, место хостинга (облако или локально), состав обрабатываемых данных. При обнаружении внешних облачных интеграций, обрабатывающих информацию ограниченного доступа, их использование должно быть немедленно приостановлено.
Шаг 2. Аудит и консолидация вычислительных мощностейС учетом дефицита вычислительных мощностей необходимо провести инвентаризацию имеющегося серверного парка и консолидировать доступные ресурсы GPU. Целесообразно развернуть оркестратор контейнеров (например, защищенную сборку Kubernetes) с поддержкой GPU-виртуализации (vGPU) для совместного использования ускорителей разными ИИ-сервисами.
Шаг 3. Изоляция среды разработки и эксплуатацииСреда эксплуатации ИИ-моделей (продуктивный контур) должна быть полностью изолирована от среды разработки ИИ. Прямой доступ из сегмента разработки в пром-контур запрещается. Все вызовы API модели внутри корпоративной сети защищаются многофакторной аутентификацией (MFA) и проходят через шлюз API с обязательным квотированием запросов (Rate Limiting) по IP-адресам и учетным записям для предотвращения DDoS-атак и попыток кражи весов модели.
Шаг 4. Переход на безопасные форматы и MLSecOpsИз пайплайнов разработки и эксплуатации исключаются уязвимые форматы сериализации данных (запрет pickle). Внедряется обязательное сканирование скачиваемых из публичных репозиториев моделей (HugginFace и др.) антивирусными средствами и специализированными сканерами на наличие бэкдоров. Разрабатывается регламент устранения уязвимостей по SLA ФСТЭК (24 часа на критические уязвимости, 7 дней — на уязвимости высокого уровня).
Шаг 5. Внедрение шлюзов безопасности (Guardrails)На сетевом периметре ИИ-контура разворачиваются прокси-сервисы входной и выходной фильтрации. Должны быть настроены регулярные выражения (RegEx) для поиска персональных данных и классификаторы промптов на предмет инъекций кода.
Шаг 6. Настройка логирования запросов и ответовВсе транзакции (входной промпт, очищенный промпт, системный промпт, ответ модели, метаданные времени выполнения и ID пользователя) логируются. В соответствии с требованиями Методики ФСТЭК, эти журналы должны храниться в неизменяемом виде (Write-Once-Read-Many, WORM) не менее 1 года для обеспечения возможности расследования инцидентов ИБ.
Шаг 7. Разработка ОРД для закрытия статьи 10.1 и 11.3Этот шаг является ключевым элементом защиты CISO и руководства организации от уголовного преследования в рамках презумпции виновности (Статья 11.2 проекта ФЗ об ИИ). Юридический департамент совместно со службой ИБ обязан разработать и утвердить внутренний регламент безопасного применения ИИ. В документе детально фиксируется, какие именно технические и организационные компенсирующие меры были приняты (изоляция контура, фильтрация, аудит-трейл). Данный документ создается в рамках исполнения Статьи 11.3 проекта ФЗ как материальное доказательство принятия «исчерпывающих мер».

Закрытие контраргументов: почему «поза ожидания» юридически смертельна

Среди ИТ-директоров и руководителей ИБ распространена позиция: «Поскольку детальных технических методик ФСТЭК по ИИ еще нет, любое созданное нами сегодня решение всё равно не будет им соответствовать на 100%. Рациональнее занять выжидательную позицию, дождаться официальных документов и только потом закупать оборудование и строить контур».

Этот аргумент содержит критическую системную ошибку и несет в себе колоссальные риски. Стратегия выжидания в текущих реалиях является юридически несостоятельной:

Во-первых, Приказ ФСТЭК №117 уже вступил в силу 1 марта 2026 года. Прямой запрет на использование облачных ИИ-сервисов для обработки чувствительной информации действует прямо сейчас. Продолжение работы через внешние API под предлогом «отсутствия методик» квалифицируется регулятором как умышленное нарушение базовых требований защиты.

Во-вторых, в случае любого инцидента безопасности, связанного с ИИ (утечка персональных данных через промпты, выдача моделью ложного решения, повлекшего ущерб), организация, выбравшая «позу ожидания», лишается возможности использовать правовой щит Статьи 11.3 проекта ФЗ об ИИ. Без локального верифицируемого контура и задокументированных архитектурных решений у CISO и генерального директора не будет доказательств принятия «исчерпывающих мер» для предотвращения инцидента, что автоматически активирует презумпцию виновности по Статье 11.2.

Здесь возникает важнейший «адвокатский мост»: соответствие «по духу» требований в сочетании с документированной осмотрительностью является единственным легитимным способом минимизации рисков. Официальные методики ФСТЭК не создадут принципиально новую физику защиты информации.

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

FAQ

Какие системы подпадают под действие Приказа ФСТЭК №117?

Под действие Приказа №117 подпадают государственные информационные системы (ГИС), муниципальные информационные системы (МИС), а также информационные системы госорганов, государственных унитарных предприятий (ГУП), госучреждений. Также требования де-факто распространяются на значимые объекты критической информационной инфраструктуры (КИИ) через сопряжение с Приказом ФСТЭК №239.

Можно ли использовать зарубежные LLM (например, OpenAI GPT) через российские провайдеры-посредники?

Нет. Если в системе обрабатывается государственная тайна или информация ограниченного доступа, передача этих данных в любые внешние облачные сервисы напрямую запрещена пунктом 61 Приказа №117. Тот факт, что провайдер-посредник является российским юрлицом, не отменяет трансграничной передачи данных и неконтролируемого характера обработки информации на стороне конечного зарубежного сервера.

Каковы штрафы за нарушение требований Приказа №117 при работе с ИИ?

Сам Приказ №117 не устанавливает штрафы, но его несоблюдение ведет к невозможности аттестации ГИС. В случае эксплуатации неаттестованной системы госорганам грозит приостановка работы ИС. Кроме того, проект ФЗ об ИИ вводит личную ответственность для разработчиков и операторов ИИ-систем (Статья 11.2), которая при нанесении ущерба или утечке данных может повлечь уголовное преследование.

Что такое коэффициент защищенности информации (КЗИ) и как он рассчитывается для ИИ?

Коэффициент защищенности информации (КЗИ) — это количественная метрика, введенная Приказом №117 взамен бинарной оценки соответствия. Он рассчитывается в режиме реального времени по 16 критериям. Интеграция недоверенных ИИ-инструментов, отсутствие логирования запросов или наличие критических уязвимостей в ИИ-контуре снижают значение КЗИ ниже нормативного уровня 1.0, что блокирует прохождение аттестации безопасности.

Как решить проблему нехватки GPU при развертывании локального ИИ-контура?

Поскольку только 9% компаний в РФ полностью обеспечены ИИ-инфраструктурой, рекомендуется использовать оптимизированные квантованные модели (GPTQ/AWQ/GGUF), которые требуют значительно меньше видеопамяти. Также эффективны технологии динамического распределения мощностей (vGPU) и использование специализированных платформ инференса, позволяющих запускать LLM на стандартных серверных процессорах CPU, хотя и с потерей скорости генерации.

Почему ФСТЭК запрещает использовать формат pickle для ИИ-моделей?

Формат pickle выполняет произвольный Python-код в процессе десериализации (загрузки файла модели или датасета). Это позволяет злоумышленникам внедрять вредоносный код (закладки, бэкдоры) непосредственно в файлы весов моделей, публикуемые в открытом доступе. При загрузке такой модели система будет мгновенно скомпрометирована. ФСТЭК требует перехода на безопасные форматы (например, safetensors), которые хранят исключительно массивы чисел (тензоры) и физически не могут исполнять код.

Telegram-канал