Регуляторные документы РФ по безопасности ИИ — с чем мы вступаем в 2026 год

Что было интересного в 2025 году по безопасности ИИ? Помимо развития решений по безопасности AI-агентов и их протоколов, в том числе гардрейлов, и также появления фреймворков, для российского рынка важно отметить появление нескольких новых официальных документов. О них и поговорим, так как я искренне считаю, что они выводят нашу нормативно-правовую базу на уровень одной из самых развитый и проработанных в мире. Но этот пост – не просто обзор)

Для кого: специалисты ИБ комплаенс, архитекторы, аудиторы, специалисты red team / pentest – все с уклоном в AI-решения, и собственно сами владельцы AI‑решений.

Что внутри: Указ №490, приказ ФСТЭК №117, Методика оценки защищенности ФСТЭК, раздел БДУ ФСТЭК по угрозам ИИ. И отдельно три зоны знаний, где практика еще не покрыта документами, и как ее можно покрыть.

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

Как читать: можно целиком, можно по разделам.

Существующие документы

Указ Президента №490

Вышедшие не в 2025, но в 2024, правки к Указу Президента №490 – основа российской нормативной базы. Даны термины касательно ИИ в целом, и в частности – есть несколько важных для ИБ пунктов.

Из важного для ИБ:

• п.5 пп.«ц»: определены «доверенные технологии ИИ» – технологии, обеспечивающие безопасность, объективность/недискриминацию, этичность, исключение вреда и нарушения прав граждан и государства;

• п.51: ИБ включено в направления развития разработки/внедрения/использования ИИ;

• п.53: сказано о создании межведомственной координации по безопасности ИИ.

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

Приказ №117 (ФСТЭК)

Главное регуляторное событие 2025 года в российском AI Seucity – вышел Приказ ФСТЭК №117 (от 11.04.2025, вступает в силу 01.03.2026). В нем затрагиваются базовые меры безопасности при использовании LLM.

Пункты, которые затрагивают безопасность ИИ:

• В п.34(т) — выделено отдельное мероприятие «защита информации при использовании ИИ».

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

• П.61 — контроль взаимодействия “запрос–ответ”:
  а) при шаблонных запросах/ответах — определить шаблоны и контролировать соответствие;
  б) при свободном тексте — определить допустимые тематики вопросов и ответов и контролировать их соблюдение;
  в) разработать статистические критерии выявления недостоверных ответов, дать пользователю возможность их отмечать и организовать сбор/анализ;
  г) обеспечить реагирование на недостоверные ответы (вплоть до ограничения области и функций, чтобы не принимать решения на их основе).
  Далее (абз. после п.61): не допускается нерегламентированное влияние на параметры модели и функционирование ИС;
  А напоследок сказано, что необходимо применять доверенные технологии ИИ или компоненты.

Что это означает? По сути, предъявлены требования к LLM-сервисам, и при чем важно понимать, что в отличие от своего предшественника, приказа №17, этот распространяется на все информационные системы государственных органов, унитарных предприятий и учреждений, а также муниципальные информационные системы, и их подрядные организации. Так что если ваш AI-ассистент будет предоставлять услуги государству, вы обязаны это выполнять. Что можно делать, что выполнять требования, подробнее я расписал в таблице.

Пример требований к системному промпту, кстати, я разбирал у себя в канале.

Методика оценки защищенности (ФСТЭК)

Намного менее громким событием стал выход еще одного документа – Методики оценки защищенности (ФСТЭК, 25.11.2025). Однако от малого внимания она отнюдь не становится менее важной. Более того, методика отлично дополняет 117 приказ, значительно раскрывая вопросы безопасности ИИ в рамках своей области действия.
В общих чертах, методика задает состав работ при анализе уязвимостей в рамках испытаний/аттестации и формализует состав проверок. И самое главное, что надо понимать – не все процедуры (с кодами) – это именно редтиминг. Здесь есть и аудиторская работа, и отдельные эксперименты в формате whitebox (по ИИ таких мер даже большинство).

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

• Сбор исходной информации (ИНП.9)
  Тут фиксируется, что является моделью, где ее инференс, какие модальности, есть ли RAG, какие каналы формирования запросов и ответов.

• Внешний анализ уязвимостей (МИИ.1.1, МИИ.1.3, МИИ.1.7, и, если есть внешние источники данных – МИИ.1.4 и МИИ.1.6)
  То есть поиск уязвимостей в режиме черного ящика – по сути, классический AI Red Team. Моделирование внешнего нарушителя На выходе идут отчеты о тестировании, описания PoC’ов джейлбрейков, логи запросов и ответов,

• Внутренний анализ уязвимостей (МИИ.1.2, МИИ.1.4, МИИ.1.5, МИИ.1.6, МИИ.1.8, МИИ.2.1, МИИ.2.2)
  Здесь речь про моделирование нарушителя внутреннего, и подразумевается и подмена конфигов, и отравление данных обучения или БД RAG, или даже прямые модификации весов моделей.

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

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

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

• Во-первых, он четко фиксирует, что промпт-атаки, утечки данных, отравление данных и слабые фильтры — это не случайные особенности поведения LLM, а результат действий нарушителя и, соответственно, моделируемый предмет анализа уязвимостей.

• Во-вторых, он заставляет переводить разговор про безопасность ИИ в структуру аудита: какие работы выполнялись, какие следы/артефакты получены, что было выявлено и как оценено.

Слабое место тоже понятно: методика перечисляет меры, но не описывает детали проведения тестирования и конкретные методики для каждого пункта МИИ (какие джейлбрейки применять, как внедрять их). Но это и не должно тут быть, это уже вотчина стандартов, внутренних корпоративных методик или публичных гайдов например от OWASP.

Раздел БДУ «Угрозы безопасности информации систем ИИ» (ФСТЭК)

Другая важная методологическая веха — появление раздела БДУ ФСТЭК «Угрозы безопасности информации систем ИИ» (конец декабря 2025). Это не документ, но одно из самых впечатляющих свидетельств развития регуляторного поля в стране, так как, с точки зрения федеральной службы, технологии RAG и AI-агентов появились совсем недавно, и то что к ним уже предложен подход к защите, не может не радовать.

Документ делит угрозы на две категории по объекту защиты:

• инфраструктура разработчика (этап разработки/обучения),

• инфраструктура оператора (этап эксплуатации).

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

Инфраструктура разработчика: что считается объектом и как атакуется

В разделе перечисляются объекты, которые должны рассматриваться как точки атаки и точки защиты: программное обеспечение для разработки и обучения, библиотеки/фреймворки, API и агентные компоненты (включая системы цензуры – то есть гардрейлы), входная/выходная модель (речь про дообучение), датасеты, веса. Отдельно отмечается, что результаты обучения и разработки могут включать LoRA-адаптеры и RAG, и это тоже становится объектом угроз.
Способы реализации угроз сведены в набор типовых сценариев (табл.1; СП.1–СП.6):

• эксплуатация уязвимостей;

• модификация ПО/конфигураций;

• отравление наборов обучающих данных;

• подмена весов модели/LoRA и данных RAG.

В разделе про инфраструктуру разработчика показано, что модель ИИ — это элемент релизного цикла. Соответственно, главная мысль – у модели есть пайплайн разработки, есть зависимости и артефакты, и нарушитель может это атаковать, как обычный supply chain. При этом ко всем терминам даны вполне адекватные и полные определения (RAG, LoRA, промпт, …)

Инфраструктура оператора: угрозы эксплуатации и реальные сценарии

Под оператором понимается владелец и управляющая сторона среды исполнения модели ИИ и приложения с ее использованием. В этой среде содержится уже обученная модель ИИ, ее расширения (LoRA/RAG), системный промпт, агент (в том числе как «исполнитель действий» через инструменты), и инфраструктура, которая обеспечивает всю детерминированную логику – вызовы API и тд.

Способы реализации угроз (табл.2; СП.1–СП.7) описывают основные негативные последствия, которые может вызвать нарушитель в рантайме:

• DoS за счет массовых запросов и исчерпания квот/токенов (СП.1, СП.7);

• специальные запросы (в том числе через RAG/внешнюю аугментацию), направленные на утечку или нарушения функционирования, в том числе промпт-атаки (СП.2);

• атака через выявление недостатков модели (СП.3) – я так понимаю, речь про извлечение системного промпта;

• модификация весов (СП.4);

• модификация конфигурации, включая системный промпт и конфигурацию агентов (СП.5);

• кража модели через обучение другой модели на ответах (СП.6).

Отдельно оговорено: если у оператора включаются режимы дообучения/continuous learning или изменяется RAG, то ему нужно учитывать и угрозы «зоны разработчика». Оценка угроз при этом проводится по методике ФСТЭК от 05.02.2021.

БДУ по сути сделал краткий аналог OWASP Top10 для LLM и AI-агентов. То есть теперь есть официальный материал, который можно использовать как основу для модели угроз и для планирования мер безопасности ИИ в любой российской организации.

Вывод по существующим документам, сквозной пример

Российский регуляторный вектор по ИИ-безопасности сейчас очень практикоориентирован: требования → проверяемость → модель угроз → привязка к реальным объектам (данные/веса/LoRA/RAG/промпты/агенты). И скорость развития — высокая.

И вот здесь, как мне кажется, начинается самое интересное. Если собрать вместе №490 как рамку, №117 как требования к внедрению, методику как набор проверяемых шагов аудита и БДУ как модель угроз по объектам, то получается почти замкнутый практический контур: что считать важным → что требовать → как проверять → по каким угрозам строить защиту. При этом по мере взросления GenAI и особенно агентных систем появляются несколько зон, где инженерная практика уже ушла вперёд формальных формулировок: доступы у «нечеловеческих» субъектов (агентов), новые носители/каналы данных (контекст, RAG, логи, embeddings) и “уязвимости поведения” (prompt-инъекции, jailbreak), которые по сути уже эксплуатируются как уязвимости, но пока описываются разными словами и живут в разных документах.

Еще, конечно, нельзя не сказать, что в России действуют и некоторые сателлитные, рекомендательные документы, которые затрагивают безопасность ИИ. В их числе ГОСТ про управление и термины ГОСТ Р ISO/IEC 42001-2024 (AIMS), ГОСТ Р ISO/IEC 24029-2-2024 (робастность), Кодекс этики ИИ (Альянс, 2021), Кодекс ответственного применения ИИ на финрынке (Банк России, 2025).

Приведу пример применения документов для объекта защиты: система с LLM‑ассистентом, использующим RAG, и с агентом, который создает заявки в ИТ‑системе.

• По п.60 №117 объектами защиты становятся: данные (включая RAG‑источники и журналы диалогов), модель/параметры, сервисы обработки данных и поиска решений.

• По новому разделу БДУ ФСТЭК строится модель угроз: что можно подмешать в RAG/контекст, что можно изменить в конфигурации агента/системного промпта, как выглядит DoS по токенам, где лежит риск кражи модели. И при чем сделать это так, чтобы бы нанесен вред бизнесу.

• В рантайме по п.61 приказа №117 в проекте появляются: фиксированные версии системного промпта/шаблонов, политика допустимых тематик, правила детектирования сигналов в потоках входных/выходных данных для создания инцидентов, плейбуки реагирования.

• На дизайнтайме по методике оценки защищенности (МИИ‑блок) с какой-то регулярностью перед выводом в прод нового релиза проверяются: устойчивость системы к промпт‑атакам на обход ограничений и вызов инструментов (МИИ.1.1 и МИИ.1.7), утечки через ответы и контекст (МИИ.1.3). Необходимо также провести аудит систем управление доступом к модели и интеграциям (МИИ.1.6), оценить уязвимости библиотек и окружения (МИИ.2.1 и МИИ.2.2).

Зоны развития регуляторики, и идеи

Дальше я попробую рассказать три своих идеи того, как пробелы в существующей нормативке можно было бы закрывать с помощью новых документов. Расскажу про их возможную связь с тем, что описал выше, возможный вид этих документов, и конечно какую суть в них можно было бы заложить. Каждую идею можно использовать и просто как подход к решению некоторых частных вопросов кибербезопасности GenAI.

1) Управление доступом для AI-агентов

С появлением агентных приложений у нас в контуре появляется субъект, который не укладывается в привычный IAM. Агент — это не человек и не сервисная учётка в классическом смысле. Он планирует шаги, держит контекст, вызывает инструменты и может выполнять цепочки операций, которые в обычном мире выполнялись бы руками администратора или операторов через UI.

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

Взаимодействие с информацией у агента происходит при совершении вызова инструментов (tool-call). Это означает, что на каждом tool-call необходим контроль доступов, и необходимо описать отдельный режим выдачи привилегий для опасных действий (human-in-the-loop). Более того, особенно важно вести реестр агентов, чтобы была сформирована матрица “пользователь → система → агент → инструмент → операции”. При чем итоговый уровень доступа к операции формируется на основе пересечения доступов пользователя, промежуточной системы и самого AI-агента.
А также для AI-агентов очень важен JIT-доступ: права выдаются кратко, под конкретную цель, на конкретный ресурс, в конкретном временном окне. И в частности это должно использоваться для human-in-the-loop, чтобы действия над критичным активом в зависимости от контекста можно было заблокировать и не допустить негативное последствие. Эту технологию в OWASP Top 10 Agentic AI авторы называют intent-signed tokens: токен доступа подписывается доверенным компонентом (policy engine / tool-gateway) и содержит не только указатель на уполномоченное лицо, но и идентификатор агента с упоминанием, какое совершается действие, объект действия, ограничения по данным/объему/времени, контекст выполнения.

Технически это проще всего реализуется как короткоживущий JWT-подобный артефакт с набором claim’ов: intent_id, action, resource, data_class, ttl, nonce, approver (если было подтверждение человеком). При совершении действия агент сначала обращается к пользователю за авторизацией, получает intent-signed token, и уже с ним идет к инструменту. Инструмент/шлюз валидирует подпись и ограничения, отказывает при несоответствии, и пишет в аудит “интент → действие → результат”.

Скорее всего, это может воплотиться в виде отдельного отраслевого стандарта.

2) Безопасность данных в GenAI-контурах

В проектах c генеративным ИИ часто спроектированное вначале решение пересматривается. При чем во много из-за специфики работы с данными – под ним могут пониматься и данные обучения моделей, и данные валидации бизнес-кейсов приложений с GenAI, и набор системных инструкций под разные сценарии работы приложения (представляющего из себя разветвленный LLM-workflow), и документы в СУБД в виде чанков и эмбеддингов для RAG, собираемые на этапе эксплуатации логи диалогов чатбота. Данные стали принимать множество разных форм, которых еще вчера не предполагали, а соответственно, не учитывали, и главное – не защищали.

Приказ №117 закрепляет базовую тройку объектов защиты: данные, модель, приложения (п.60). Детализации нет, но и не должно быть, потому что приказ – верхнеуровневый документ. Поэтому, для внедрения на основе требований приказа каких-либо практик ИБ, требуются отдельные технические документы, поясняющие и рекомендующие варианты выполнения требований. В таких документах необходимо описать, какие именно «носители» информации возникают вокруг LLM на всех этапах жизненного цикла, какие форматы могут принять данные. Это может быть отдельный ГОСТ, инструкция по обеспечению управления доступом к данным в системах с использованием ИИ, или частью нормативного или рекомендательного акта с более широкой областью действия (например, стандарт по информационной безопасности данных, используемых системами с ИИ).

Итак, хранилища и средства передачи данных, с помощью которых LLM получает фактическое содержание – это объект учета и защиты. Организациям имеет смысл разделять «обычные» СУБД от СУБД, работающих на контур генеративного ИИ, по одному признаку: данные из хранилища могут попасть в контекст модели или повлиять на действия агента без участия человека. Для учета “GenAI-хранилищ” необходимо понимать всю цепочку состояний данных при передаче. Она для каждой задачи, процесса и IT-ландшафта компании уникальна, и может принять например такой вид: холодное хранение (СУБД №1) → горячее хранение (СУБД №2) → передача контекста (топик в Kafka как шина) → формирование ответа (СУБД #3, in-memory) → отображение в браузере (СУБД #4, in-memory на стороне клиента в браузере). Можно продолжать цепочку и далее, но суть не изменится. Хранилище, участвующее хотя бы в одной из таких цепочек, становится частью контура “GenAI-данных”.

Учет СУБД и систем транспортировки данных (ETL), обрабатывающих данные для GenAI-приложений и сгенерированные ими, предполагает определенные специфичные меры, которые к ним должны применяться. Эти специфичные меры должны быть направлены на предотвращение двух классов угроз: внедрение промпт-атак в данные и внедрение данных с конфиденциальной информацией (или персональными данными).

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

3) Уязвимости ИИ: не только свойства программных компонент, но и свойство данных, приводящее к неустойчивости к промпт-атакам

В проектах с генеративным ИИ понятие «уязвимость» перестаёт быть синонимом ошибки в коде. Но на практике с GenAI-системами появляется второй слой: уязвимости появляются у данных и моделей тоже. Если формализовать, то я бы сказал, что уязвимость GenAI-модели – воспроизводимая последовательность входных запросов, которая приводит к нарушению требований безопасности к GenAI-модели. К ним относятся не только пользовательские промпты, это еще и документы, которые подмешиваются в контекст через RAG, и память агента, и шаблоны системных инструкций, описания инструментов. Уязвимости принимают много форм, которые раньше не описывали, не учитывали и не проверяли.

Детализации уязвимостей и порядка их учёта нет пока ни в каком документе (за рубежом при чем, кажется, тоже). Документ, посвященный способу их выявления и устранения, должен описать: что считается уязвимостью ИИ в эксплуатационном смысле, как её подтверждать, как оценивать критичность, какие артефакты считать доказательством, как проводить повторную проверку, как митигировать. Это может быть отдельный ГОСТ, методические рекомендации по анализу защищённости систем с ИИ, либо раздел в стандарте по управлению уязвимостями, расширенный под особенности LLM и агентных приложений.

Итак, уязвимости в контурах GenAI имеет смысл учитывать как отдельный класс. Жизненный цикл, необходимый для управления ими, похож на классический: выявление → подтверждение → оценка критичности → устранение → повторная проверка (в том числе при каждом новом релизе используемой модели или смене любой части системных инструкций). Главное – формализовать критерии подтверждения, иначе каждый кейс будет превращается в спор с разработчиками о важности результатов.
Минимальный набор критериев для подтверждения уязвимости (параметров уязвимости) может выглядеть так:

• канал атаки: пользовательский ввод, документ RAG, память/журналы, системная инструкция, описание инструмента, межагентный обмен;

• условия: какие права нужны, какие данные доступны, включены ли инструменты, есть ли доступ к RAG-источникам, есть ли память;

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

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

• воспроизводимость в числах: доля успешных попыток при фиксированных условиях (например, k из n) и при допустимой вариативности контекста;

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

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

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

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

Подводя итоги

Прошлый год был богат на новшества в регуляторной части нашей отрасли, на свет появились несколько фундаментальных вещей: №117 приказ с требованиями к GenAI-сервисам, методика оценки защищенности с базовыми процедурами AI Red Team, а также модель угроз для двух типов организаций – разработчик GenAI и пользователь GenAI.

Основные 5 требуемых мер по безопасности ИИ для тех кому лень читать:

1. описать границы AI‑контура и перечень активов (п.60 №117);

2. собрать модель угроз по БДУ и сопоставить ее со своими требованиями и ИТ-архитектурой.

3. зафиксировать системный промпт/шаблоны и правила изменения (п.61 №117);

4. определить допустимые тематики контента и правила детектирования и реагирования на инциденты в рантаймовых входных/выходных потоках данных (п.61 №117);

5. построить план проверок по МИИ‑блоку методики и требуемые артефакты;

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

Больше интересных статей и постов про AI Security есть у меня в канале “Борис_ь с ml“.