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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фрагмент Приказа №117

Что делать

Типовые артефакты выполнения

п.60 (объекты защиты)

описать границы AI‑контура и перечень активов

архитектурные схемы, перечень активов, владельцы активов

п.61(а) (шаблоны)

зафиксировать системный промпт/шаблоны, сделать механизм контроля расположения СП в дистрибутиве

перечень требований к формированию системного промпта (СП)

п.61(б) (тематики)

определить допустимые классы вопросов/ответов и политику отсечения

политика тем, правила фильтрации, тест‑корзины по темам

п.61(в) (критерии недостоверности)

ввести метрики/правила фиксации недостоверности + канал обратной связи

метрики/пороговые правила, UI‑функция для обратной связи, журнал инцидентов

п.61(г) (реагирование)

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

система управления реагированием на инциденты GenAI регламент реагирования на такие инциденты (с плейбуками)

абзац после п.61 (нерегламентированное влияние)

явно описать и контролировать «кто может менять» параметры/конфиги/поведение

матрица изменений, разграничение прав, аудит изменений

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

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

Намного менее громким событием стал выход еще одного документа - Методики оценки защищенности (ФСТЭК, 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, или даже прямые модификации весов моделей.

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

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

Этап

Код меры по анализу

Что нужно определить / где искать уязвимость

Где искать (точка тестирования)

Типовой артефакт меры

Сбор исходной информации

ИНП.9

состав ПО, реализующего модели МЛ/ИИ

контур разработки/эксплуатации

инвентаризация компонентов, карта зависимостей (SBOM/AIBOM)

Внешний анализ уязвимостей

МИИ.1.1

искажение поведения через спецзапросы (промпты)

интерфейсы «запрос–ответ» агента или приложения

отчет о тестировании, журнал запросов/ответов, описание PoC, условия успеха

МИИ.1.3

утечка конфиденциальной информации через ответы

интерфейсы «запрос–ответ» агента или приложения и источник конф. инф.: данные обучения модели/системный промпт/RAG/ресурсные системы

аналогично МИИ.1.1 + связь с источником утечки

Внутренний анализ уязвимостей

МИИ.1.2

влияние модифицированных данных обучения, возможность отравить данные обучения/дообучения

инфраструктура обучения/дообучения

отчет об эксперименте: сценарий отравления, доказательства влияния

МИИ.1.4

процедуры контроля/управление данными, используемыми моделью

RAG‑источники, контекст ‑ сборка

трассировка цепочки данных, права/роли

МИИ.1.5

какие способы модификации обучающих данных реализуемы

хранилища датасетов/пайплайны обработки данных

раздел отчета в составе артефакта для меры МИИ 1.2 (журнал изменений данных, результаты контроль целостности)

МИИ.1.6

механизмы управления доступом к модели

API, сервис инференса

матрица доступов, аудиты вызовов

МИИ.1.7

слабые механизмы фильтрации входа/выхода

фильтры, гардрейлы, политика тем

раздел отчета в составе артефакта для меры МИИ 1.1

МИИ.1.8

прочие уязвимости конфигурации модели

системный промпт, параметры, режимы

diff конфигурации, журнал изменений

МИИ.2.1

уязвимости библиотек/фреймворков (supply chain)

контур разработки/инференса

перечень версий, результаты сканирования

МИИ.2.2

уязвимости ПО модели МЛ

окружение исполнения

отчеты анализа, версии/патчи

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

  • Во-первых, он четко фиксирует, что промпт-атаки, утечки данных, отравление данных и слабые фильтры — это не случайные особенности поведения 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".