Алексей Синадский и Денис Комаров, УЦСБ: Главный плюс российского подхода к регулированию ИИ – конкретность

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

В России сейчас выстроена иерархия документов: Указ Президента № 490 определяет стратегические границы, недавний Приказ ФСТЭК России № 117 вводит конкретные технические требования для ИИ-систем в составе ГИС. Проект федерального закона о госрегулировании ИИ уже опубликован Минцифры и в случае принятия начнёт действовать с сентября 2027 года.

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

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

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

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

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

Алексей Синадский: Противопоставление не абсолютно, российское регулирование тоже оперирует понятием риска. Указ № 490 определяет безопасность как «отсутствие неприемлемого риска», проект ГОСТ по ИИ в КИИ вводит категории критичности. Разница в пропорции: у нас оценка риска встроена в технические стандарты, на Западе технические требования встроены в систему управления рисками.

Приказ № 117 ФСТЭК России даёт прямые технические указания, не оставляя пространства для гадания: что именно проверять, какие метрики вводить, какие режимы реагирования определять. Российские документы покрывают полный жизненный цикл ИИ-системы, при этом опираясь на существующую систему защиты ГИС и КИИ, что снижает порог внедрения для организаций, уже выполняющих требования ИБ. К условным недостаткам можно отнести ориентацию на госсектор. Требования Приказа № 117 обязательны для ГИС, но для коммерческого сектора носят рекомендательный характер. Многие документы пока в статусе ПНСТ, а не ГОСТов, как, например, про ИИ в КИИ. Агентные ИИ-системы в обязательных НПА не отражены совсем или описаны очень обобщённо.

Западный подход даёт больше гибкости: системы классифицируются по уровням риска, низкорисковые сегменты не страдают от избыточного регулирования, при этом проектные команды получают богатую методологическую базу — сотни мер защиты, не привязанных к конкретному регулятору. С другой стороны, гибкость эта достигается ценой размытости. Классификация по уровням риска требует экспертной оценки, и два аудитора могут по-разному классифицировать одну и ту же систему. В США ситуация осложнена фрагментацией: после отмены указа Байдена требования ушли на уровень штатов, и бизнес должен учитывать существенно различающиеся отраслевые правила.

Денис Комаров: Я бы сказал, что текущий подход к регулированию ИИ в Российской Федерации имеет общее как с западными, так и с восточными методологиями. С одной стороны, явно прослеживаются идеи как европейского риск-ориентированного подхода (например, в ПНСТ про ИИ в КИИ предлагается деление систем на 4 класса), а с другой — широкий перечень отраслевых технических стандартов (более 140 доменно-ориентированных ГОСТов), характерных для подхода к регулированию в Китае. Одной из главных отличительных особенностей российского подхода является концентрация пристального внимания на вопросах доверенности ИИ-систем.

В целом, все подходы направлены на достижение единой цели: предотвращение технологических, социальных и этических рисков, связанных с применением технологий искусственного интеллекта в различных сферах жизни. Как показывает практика, каждый подход в реальном мире сталкивается с трудностями реализации. Так, сроки полноценного внедрения EU AI Act были перенесены для систем с высоким уровнем риска, при этом правила для систем общего назначения вступят в силу в соответствии с изначальным планом. Среди причин переноса отмечается недостаточная текущая проработка стандартов, проблемы на уровне контроля выполнения требований, а также технологические риски для бизнеса. Подходы к регулированию в Китае привели к другой особенности: доработка решений для реализации требований политической лояльности привела к появлению критических уязвимостей.

Алексей Синадский: В целом оцениваю положительно, хотя регулирование пока находится в стадии формирования. За последний год ФСТЭК выпустил и Приказ № 117, и методику анализа защищённости, и обновил банк данных угроз разделами по ИИ. Появились профильные проекты документов: методический документ о мерах защиты с выделением ИИ в отдельные комплексы, проект ГОСТ по ИИ в КИИ, проект федерального закона от Минцифры. Нормативная база по безопасности ИИ заметно ускорила развитие за этот период. Выстроена понятная иерархия: Указ № 490 задаёт стратегию, Приказ № 117 и методики ФСТЭК переводят её в практические требования, национальные стандарты наполняют их техническим содержанием.

Дорабатывать всегда есть что, но я бы начал со статуса документов — введение НПА в действие, разработка системы требований и штрафов, стимулирующих их выполнение в коммерческом секторе, которое пока добровольное. На мой взгляд, именно отсутствие обязательности за пределами госсектора и есть главный тормоз.

Денис Комаров: Один из актуальных «пробелов» связан с понятием доверенного ИИ. На текущий момент данный термин присутствует в нормативных актах, но нет явных критериев для отнесения ИИ-системы к классу доверенных, как нет и реестра таких систем. Но тут важно отметить, что работы в этом направлении уже активно ведутся. Главное, чтобы разрабатываемые нормы и стандарты были реализуемы на практике. В негативном сценарии многие отрасли могут быть сильно ограничены в использовании передовых технологий.

Алексей Синадский: Если говорить о сути регулирования, то я бы добавил более подробные рекомендации для агентных систем. Действующие НПА описывают отдельные LLM, работающие в формате «запрос-ответ». В ситуации с агентным ИИ ситуация несколько сложнее — LLM, используя расширенные возможности, вызывает инструменты, обращается к API, формирует цепочки действий. Риски качественно иные: автономное выполнение опасных команд, каскадные отказы. Китайский AI Security Governance Framework 2.0 уже содержит рекомендации по kill-switch для автономных агентов, включая верификацию критически важных решений с участием человека. Нам тоже нужны требования к контролю исполнения команд и аварийным выключателям, при этом надо успевать формировать правила безопасной эксплуатации агентов ввиду скорости их внедрения в жизнь.

Алексей Синадский: Не в скором будущем, а уже сейчас. Проблема современных SOCов не в нехватке людей, а в том, что сама модель ручного анализа сработок перестаёт выдерживать объем и скорость современных атак. Тот, кто не использует ИИ (и тут речь не только про LLM) в реагировании, полагаясь только на живых аналитиков и операторов, уже чувствует рост нагрузки, в том числе финансовой. Угрозы такая конструкция, конечно, создаёт, но пока не существует идеального способа решения всех проблем, приходится искать оптимальные решения в сложившихся обстоятельствах.

Сама архитектура «одна LLM атакует, другая оценивает ответ, третья агрегирует отчёт» уже работает, но пока в основном на стороне атакующего: методы PAIR, TAP, AutoDAN-Turbo используют эту схему для автоматизированного подбора атакующих промптов. Логично ожидать, что та же модель будет применяться и для защиты. Проблема в том, что уязвимости исходной схемы при этом наследуются.

Денис Комаров: На мой взгляд, в скором будущем прямого противостояния ИИ-систем мы не увидим, поэтому переводить человека в разряд наблюдателей пока не стоит. Если автономные атакующие системы по типу ИИ-ботнетов только начали появляться, то автономный ИИ-защитник пока выглядит как футуризм. Практика показывает, что в вопросах безопасности ИИ сейчас используется как помощник: обогащение дополнительной информацией, анализ данных, приоритезация алертов и т.д., а делегирования ключевых решений по блокировке сетевых взаимодействий и других сценариев активного реагирования не происходит — риски слишком велики. Да и на стороне атакующих, ИИ в большинстве случаев — это скорее инструмент, который позволяет масштабировать атаки, повысить качество и охват фишинга, снизить минимальный перечень знаний злоумышленника.

Безусловно, активное использование ИИ влияет на обе противодействующие стороны. Одна и та же технология (например, большие языковые модели) применяется по обе стороны баррикады. Ключевое различие в степени применимости инструмента к конкретным задачам. Для злоумышленника средство, которое после 99 попыток атак дает 1 успешную, вполне может успешно использоваться в арсенале. Для стороны защиты же подобный инструмент, который дает 99 ложноположительных сработок из 100, будет бесполезен на практике. Из этого тезиса, может сложиться ложное ощущение, что ИИ слабо применим к текущим вопросам кибербезопасности. Это не так, просто подобные технологии в данный момент времени подходят не для всех задач.

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

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

Алексей Синадский: Secure-by-Design в ИИ-проекте означает, что безопасность встроена в архитектуру с первого дня. Этот принцип нужно растянуть на весь жизненный цикл модели, методологически можно опереться на фреймворки вроде Google SAIF или Swordfish SAIMM.

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

У любой дополнительной меры безопасности есть цена, в исследованиях это называют alignment tax. Дополнительные ограничения поведения модели могут сопровождаться снижением качества в отдельных сценариях. Каждый дополнительный системный промпт, фильтр, валидатор добавляет задержку и может усилить деградацию основного сервиса.

Современная ИИ-разработка опирается на десятки открытых библиотек и предобученных моделей. Инциденты с YOLO и LiteLLM показали, что компрометация одного компонента открывает доступ ко всей инфраструктуре. Secure-by-Design здесь означает верификацию всего графа зависимостей, а не только своего кода.

Многие специфические для ИИ уязвимости не имеют прямых аналогов в классической ИБ. Инъекция промптов, состязательные суффиксы, извлечение модели через API. Для них нет готовых сигнатур, защита требует постоянной адаптации, которая стоит денег.

Защита ИИ — непрерывный процесс. Невозможно один раз «защитить» модель и забыть. Нужен цикл: проектирование, тестирование, мониторинг, адаптация, и так по кругу.

Денис Комаров: На самом деле ИИ-система по-прежнему является программным продуктом, поэтому в первую очередь необходимо использовать уже наработанные подходы к безопасной разработке ПО. При этом особенности, разумеется, есть: ИИ-системы подвержены ряду специфических атак. По этой причине в отличие от классических DevSevOps-подходов появляются отдельные области защиты, например, необходимость защиты и управления датасетами, обеспечение безопасности на этапе обучения, доставки и инференса моделей. Это привело к формированию отдельного направления MLSecOps, которое сейчас инкапсулирует лучшие накопленные практики безопасной разработки, отказоустойчивости, науки о данных и ML-инжиниринга.

Сейчас разрабатывается ГОСТ по безопасной разработке программного обеспечения, реализующего технологии искусственного интеллекта. Я считаю, что в будущем его стоит брать за основу при выстраивании процессов. Помимо этого, уже сейчас есть ряд методологий, например, Yandex AI Secure Agentic Framework Essentials и Google Secure AI Framework, наработки которых уже сейчас можно и нужно использовать при разработке новых систем и защите существующих.

Алексей Синадский: Инструменты есть разные, но их эффективное применение — отдельная задача. Ключевая проблема в том, что единого инструмента, закрывающего весь цикл, не существует. LLM-фаервол без предварительной оценки защищённости не знает, к чему модель уязвима, а сканер без фаервола находит проблемы, но не закрывает их. На практике приходится комбинировать несколько классов инструментов, что требует глубокой экспертизы. Подобрать связку, которая закроет конкретную систему без конфликтов и дублирования, — нетривиальная задача.

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

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

Алексей Синадский: Если говорить про LLM Security как наиболее популярный класс запросов от бизнеса, то для встраивания в CI/CD подходят лёгкие сканеры, работающие на CPU, для продвинутого red-teaming с адаптивными атаками существуют более продвинутые инструменты с атакующей LLM. PII-детекторы выявляют и маскируют чувствительные данные, LLM-фаерволы фильтруют запросы и ответы, прокси-серверы контролируют доступ, специализированные утилиты проверяют файлы моделей. При этом накопленная методологическая база позволяет системно подойти к проектированию защиты, хотя большинство фреймворков ещё не стали отраслевыми стандартами и требуют адаптации под конкретную систему.

Насчёт сложности — всё возможно, вопрос эффективности и цены этой защиты. Сегодня задача состоит не в полном предотвращении атак на ИИ, а в снижении вероятности их успешного применения, своевременном обнаружении и корректном реагировании. Полную гарантию не даст ни один инструмент.

Денис Комаров: На сегодняшний день большие языковые модели являются наиболее популярными с точки зрения практического внедрения ИИ. Именно поэтому в нашем обзоре акцент сделан на системы, построенные на основе LLM. Однако, безусловно, ИИ-системы используют и классические ML-подходы, компьютерное зрение, обучение с подкреплением и так далее. Если обратиться к перечню угроз, описанных в рассматриваемых в работе методологиях, то многие из них применимы не только к LLM.

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

Алексей Синадский: Для систем, использующих классический ML или CV, в качестве основной угрозы я бы выделил использование атакующими состязательных примеров. Минимальные изменения входных данных, незаметные для человека, способны кардинально поменять результат работы ML-модуля — например, наклейки на одежде, обманывающие распознавание. Также актуальны отравление данных через внедрение вредоносных примеров в обучающую выборку и восстановление обучающих примеров через запросы к модели. И для любой системы остаются актуальными атаки на цепочку поставок.

Отдельно стоит выделить агентные ИИ-системы. Это уже не просто генераторы текста, а «руки», которыми злоумышленник может действовать в вашей инфраструктуре. В зависимости от реализации, агент может иметь доступ к внутренним API, базам данных, командной строке в особо запущенных случаях, и атака на LLM-ядро превращается в несанкционированное выполнение команд на хосте. OWASP уже выпустил профильные документы по уязвимостям протоколов взаимодействия агентов с внешними сервисами. Грань между обманом LLM и получением доступа к серверу-хосту практически стирается и, на мой взгляд, это качественно новый уровень риска.

Алексей Синадский: Самый простой способ без развёртывания собственного LLM-контура — это ИИ-шлюз с фильтрацией данных. PII-детекторы находят чувствительные данные и маскируют их до отправки запроса на внешние серверы. LLM-фаерволы устанавливаются на ИИ-шлюзе между пользователем и LLM-провайдером и блокируют запросы с чувствительными паттернами до их отправки вовне. Но надо иметь в виду, что эти меры лишь снижают риск.

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

Денис Комаров: Сразу оговорюсь, что подход с запретом использования подобных сервисов без предоставления альтернатив способен в лучшем случае только отложить появление проблемы Shadow AI, но никак не решить.

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

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

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

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

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

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