Привет! Я Чернышов Юрий, к.ф.-м.н., доцент УрФУ, руководитель исследовательского центра UDV Group (компания разработчик ПО для ИБ в Екатеринбурге).
17-19 сентября меня пригласили принять участие в круглом столе “Современные вызовы в безопасности AI и пути их решения”, который являлся частью международного форума “Kazan Digital Week - 2025” в Казани. Совместно с коллегами из фонда «Сколково», «Яндекса», «Телеком Интеграции», Банка ПСБ, компании «Фишман» и компании «Аватек» обсудили актуальные вопросы безопасности инновационных технологий и решений с применением ИИ. Участников было много, по сути я ответил только на пару вопросов ведущего (ниже). Но слушая коллег и обсуждая уже после мероприятия эту важную тему - фиксировал мысли и заметки, которые, после незначительного оформления оставлю здесь.
Вопрос: Модели, особенно обученные на уникальных корпоративных данных, несут угрозы, включая кражу конфиденциальной информации?
Да, несут. Хороший и правильный вопрос, поскольку за утечку конфиденциальной информации сейчас повышается ответственность. Об этом важно помнить, внедряя самые передовые и инновационные технологии. При этом угрозами для корпоративных данных являются не только кража, но и повреждение данных, а также их модификация в интересах злоумышленника.
Сейчас ИИ-системы работают с различными источниками информации: данные пользователей, финансовые данные и коммерческая тайна, интеллектуальная собственность, информация о внутренней инфраструктуре предприятия. Все это представляет интерес для злоумышленников, стремящихся украсть коммерческие секреты, провести первичную OSINT разведку предприятия, повредить, либо использовать в своих целях инфраструктуру. В классификации фреймворка OWASP Top 10 LLM уязвимость «Утечка конфиденциальной информации» входит в число десяти наиболее опасных уязвимостей, связанных с большими языковыми моделями (LLM).
«Утечка конфиденциальной информации» (уязвимость OWASP LLM02:2025), к которой относятся персональные, юридические, медицинские данные. Также конфиденциальной информацией являются данные о работе самой информационной системы, в том числе ее архитектура, аутентификация пользователей. Если GenAI для своей работы получает доступ к подобным данным, то неудачная реализация системы может позволить злоумышленнику также получить доступ к этим данным.
Для систем искусственного интеллекта защита конфиденциальных данных имеет дополнительную сложность, поскольку термин «информация» в этом случае может означать разное, например:
знания ИИ модели, вложенные в нее при основном обучении (pretrain), или дополнительном специализированном дообучении (finetuning),
-
содержимое баз знаний, к которым выполняется доступ через LLM агентов, в том числе
корпоративные базы данных
данные внутренних ИТ систем мониторинга и аналитики
корпоративный портал
CRM
система внутреннего документооборота предприятия
инструменты разработчиков: git, jira, confluence
информация в документах, добавляемых с помощью технологии RAG к запросу, а также сами эмбеддинги (числовые векторы, соответствующие текстовым документам), которые хранятся в векторной базе
Для каждого вида информации в ИИ системах применяются свои методы защиты, однако существуют и общие принципы: непрерывный мониторинг и контроль входных данных и выходных результатов, авторизация доступа к ресурсам и минимизация необходимых разрешений, включение человека в ключевые точки принятия решения.
Сложнее всего защищать знания «внутри» ИИ модели, которые состоят из миллиардов параметров, так как такие знания сложно локализовать. Часто этой ситуации способствуют сами пользователи, отдавая ИИ модели конфиденциальную информацию при постановке задач. Поэтому необходимо устранить этот риск на этапе анализа промпт-запроса к модели, а также делать дополнительную проверку результата, который дает модель.
При наличии доступа к источникам информации (базам данных, внутренним корпоративным документам на файл-сервере, CRM, и пр.) необходимо реализовывать ролевую модель доступа и применять авторизацию доступа к информации, чтобы агент LLM не получал доступ к информации, не требующейся ему для выполнения задач.
При открытом пользовательском интерфейсе, позволяющем пользователям (и злоумышленникам) выполнять произвольные запросы к LLM, необходимо организовывать защиту против джейлбрейков, которые заставляют модели нарушать заложенные при разработке принципы этики и безопасности, а также технологические ограничения.
Джейлбрейк (jailbrake) это атака на ИИ, заключающаяся в создании специального запроса к LLM, который нарушает ее работу. Успешный джейлбрейк приводит к тому, что модель ИИ выдает информацию, которую должна отказываться предоставлять при прямом нормальном запросе. Усилия злоумышленника направлены на нарушение политики информационной безопасности в отношении контента, либо нарушение эксплуатационных ограничений (производительность, потребление токенов, приоритеты в задачах).
Часто считается, что развернуть локальную ИИ систему в собственной локальной инфраструктуре является более безопасным, чем получать такую услугу из облака. Однако и в этом вопросе есть важные детали. Уровень защиты в облачных сервисах является очень высоким, поскольку такие сервисы уже давно находятся в области внимания многочисленных злоумышленников, облачные системы работают под высокими нагрузками, обрабатывая очень большое количество самых разных запросов пользователей. Такой опыт позволил провайдерам ИИ систем сформировать экспертные команды и организовать процессы, повышающие уровень информационной безопасности, в том числе и в вопросах сохранения конфиденциальной информации. Открытые модели open-source являются общедоступными, их можно установить в полностью локализованной инфраструктуре, в том числе и без доступа в Интернет, однако такие модели не имеют защитных механизмов, для них также требуется создавать процессы и команды мониторинга и реагирования на инциденты. Облачные и локальные сервисы имеют свои преимущества и недостатки, поэтому правильный вариант необходимо подбирать исходя из основной задачи.
В заключение я бы привел пример, относящийся как к предприятиям, так и обычным пользователям. Сейчас существует множество ИИ сервисов в Интернет, которые помогают сделать презентацию, проанализировать договор, сделать поздравительную открытку. При этом, как правило, такие сервисы запрашивают информацию, в том числе и являющуюся конфиденциальной: персональные данные, изображения, схемы, информацию о предприятии. Подобные сервисы предоставляются как крупными надежными провайдерами услуг (например, gigaChat от Сбер или YandexGPT от Яндекс), так и небольшими неизвестными компаниями, среди которых могут оказаться злоумышленники. Важно помнить, что при загрузке документа, например, текста договора, в недоверенную систему, вы раскрываете всю информацию. Поэтому, если вы не знаете архитектуру и логику работы системы ИИ, которая использует ваши данные, или не имеете договорные отношения с зафиксированным SLA с поставщиком таких сервисов, то надо понимать, что передавать данные в такую систему небезопасно.
Вопрос: что такое MLSecOps, примеры применения и недостающие инструменты?
Сначала разберемся с терминологией. Методология DevOps (сокращение от Development Operations, то есть процессы и операции, возникающие при разработке программного обеспечения) содержит инструменты и процессы для оптимизации процессов разработки, повышения скорости вывода продукта в эксплуатацию, улучшения качества и снижения уровня ошибок. Основные задачи DevOps это непрерывный мониторинг и контроль, а также автоматизация задач, возникающих на различных этапах разработки программного обеспечения: написание и валидация кода, хранение и управление версиями кода и конфигурационных файлов, тестирование, сборка системы, управление вспомогательными системными компонентами (контейнеризация, виртуализация, специализированные библиотеки и модули), развертывание (доставка) в промышленную эксплуатацию. Задачи безопасности в этих процессах решает DevSecOps, в который входят методы контроля и защиты артефактов процесса разработки: контроль качества кода и поиск уязвимостей с помощью анализаторов SAST/DAST, контроль безопасности цепочки поставок сторонних программных модулей и библиотек, безопасность контейнеров и систем виртуализации, а также другие специализированные методы и программное обеспечение, в зависимости от содержания проекта и используемых компонентов.
При появлении машинного обучения (machine learning, ML) усложнилась архитектура проектов, появились новые процессы и артефакты. К таким процессам относятся: сборка/передача/хранение/обработка данных, обучение модели ML, проверка корректности кода модели ML, специализированное тестирование ML (стабильность, устойчивость к помехам в данных), сборка системы и вывод в промышленную эксплуатацию, мониторинг эксплуатации (контроль данных, потребление ресурсов для модели ML, правильность работы). Артефактами ML процессов являются: данные, программные окружения, сами модели ML, программный код, специализированные модули и библиотеки. MLOps это методология решения задач DevOps для ML проектов, а MLSecOps играет ту же роль для MLOps, что DevSecOps для DevOps, то есть защищает процессы и артефакты, возникающие при решении задач MLOps/DevOps: данные, инфраструктуру, модель, специализированные приложения (AI/LLM агентов).
Благодаря такой наследственности в методологиях для MLSecOps многое может быть использовано из MLOps и DevSecOps. Однако существуют новые сложные задачи, для которых пока нет готовых инструментов и подходов, либо они еще не прошли проверку временем и не стабилизировались. Например, не хватает автоматизированных цензоров качества результатов работы LLM систем, поскольку для LLM сложно контролировать качество на уровне содержания и смысла (семантики) ответов, для этого по-прежнему часто привлекают человека эксперта, как на этапе обучения (Reinforcement Learning with Human Feedback, RLHF), так и на этапе валидации в процессе итогового тестирования или эксплуатации. Проблемы могли бы решить эталонные доверенные наборы данных (бенчмарки), которых пока тоже не хватает. И создание таких отраслевых бенчмарков и платформ для независимого тестирования качества работы и безопасности ИИ систем является необходимым условием для прогресса и активного использования ИИ как для производственных задач, так и для обычных пользователей. Важную работу делает в этом направлении созданный в 2024 году «Консорциум Исследований безопасности технологий ИИ».
Одной из наиболее сложных задач для MLSecOps является контроль качества работы модели ИИ, поскольку большой проблемой являются галлюцинации моделей и информационный сдвиг в ответах модели, из-за которых может исказиться результат. В ML сложно анализировать причины ухудшения качества работы модели. Например, очень сложно на практике найти причину падения метрики работы модели на 0.1%, что может быть вызвано сдвигом в данных, неправильной моделью, атакой злоумышленника, нарушением работы инфраструктуры или «просто шумом». MLOps помогает вовремя диагностировать нарушение работы, установить причину и принять меры. MLSecOps добавляет к этому решение задач информационной безопасности ИИ-системы, связанные с контролем и защитой доступности, целостности и конфиденциальности системы.
Как и в любых других эксплуатируемых системах для систем с GenAI необходимо проводить постоянный поиск и исследование новых возможностей для атак злоумышленников, проводить анализ защищенности всех компонентов системы, включая модели ИИ, в том числе с применением специальных программных средств и методов социальной инженерии.
Важным аспектом, повышающим уровень надежности и защищенности системы с ИИ, является улучшение взаимодействия с пользователями. Это может включать в себя: контроль диалога, отслеживание токсичности, выявление факта применения джейлбрейков со стороны пользователя, дополнительные меры аутентификации, в том числе по косвенным признакам, сохранение и использование истории взаимодействия с пользователем. Зачастую проведение специального обучения для пользователей вопросам безопасности при работе с ИИ дает очень значимый эффект.
Очень важно накапливать, упорядочивать и распространять лучшие методики и практические сведения о защите ИИ систем. Хорошо, что есть распространяемый мировой опыт в данной области: MITRE, NIST, OWASP, DASF компании DataBricks, NIST AI RMF. Например, 10.09.2025 команда OWASP GenAI Security Project выпустила документ «Threat Defense COMPASS 1.0». Это фреймворк с описаниями проверок безопасности на всех этапах жизненного цикла GenAI-приложений, собранный с опорой на цикл OODA (Observe–Orient–Decide–Act). Описания техник и тактик для атаки и защиты ИИ систем можно найти в MITRE ATLAS. Отечественные исследователи и разработчики также работают в этом направлении, в апреле 2025 года вышла первая российская модель угроз AI: компания Сбер опубликовала модель угроз для кибербезопасности ИИ. Этот документ является очень полезным для повышения уровня осведомленности о возможных угрозах, для планирования и реализации мер защиты. В документе описано 70 угроз для моделей генеративного (GenAI) и предиктивного (PredAI) искусственного интеллекта. Создание подобной модели угроз особенно актуально в свете растущего использования GenAI-моделей в критически важных бизнес-процессах и возникающих в связи с этим новых киберугроз. В сентябре 2025 года Команда безопасности Yandex B2B Tech опубликовала документ AI-SAFE с практическими рекомендациями по безопасной разработке AI агентов.
Методы защиты систем с ИИ в настоящее время развиваются, это важно для того, чтобы появляющиеся технологии оставались безопасными, надежными, объяснимыми для человека, соответствовали нормам этики и требованиям регуляции. Компании-разработчики совместно с вузами активно занимаются исследованиями и разработкой систем защиты ИИ. В будущем количество исследований и компаний, занимающихся вопросами безопасности ИИ, включая стартапы, будет увеличиваться, поскольку существует множество открытых для работы ниш: усиление SOC для работы с ИИ системами, разработка и внедрение инструментов полноценного мониторинга инцидентов ИИ, расширение образовательных программ для специалистов по ИБ, разработка методов харденинга инфраструктуры и многое другое.
Компания-разработчик систем ИИ должна обладать необходимой компетенцией в технологиях безопасной разработки DevSecOps и MLSecOps/LLMSecOps, применять эти принципы на практике. Это значит, что анализу защищенности необходимо уделять внимание уже на этапе проектирования архитектуры системы, использовать безопасные паттерны проектирования и безопасного кода, добавлять средства мониторинга защищенности, предусматривать необходимые тесты безопасности. При этом при внедрении практик MLSecOps важно понимать и учитывать специфику конкретного проекта, поскольку слепое копирование успешных методов из других проектов может существенно замедлить ход работы, увеличить time-to-market для продукта, осложнить работу участников команд разработки. Следовательно, важен практический опыт специалистов MLSecOps, их кругозор, позволяющий взаимодействовать с другими участниками команды разработки ИИ системы.
В итоге, MLSecOps это совокупность процессов, практик и технологий, нацеленных на обеспечение безопасности всего цикла процесса разработки приложений с моделями ИИ, в том числе защищающих доступность, целостность и конфиденциальность моделей и данных. В промышленной разработке и эксплуатации важен непрерывный мониторинг и анализ компонентов создаваемых информационных систем: процессов, интерфейсов взаимодействия, исполняемых инструкций и команд, получаемого и создаваемого контента, пользовательских действий, состояния инфраструктуры. Важнейшими задачами при создании и эксплуатации ИИ систем является постоянный контроль и обеспечение соблюдения норм этики, выполнение требований регуляции. Для решения этих задач и предназначена методология MLSecOps, являющаяся новой и быстро развивающейся областью знаний.