Почему математикой не решить все проблемы.

Недавно на AMLive вышел эфир, посвящённый MlSecOps. Я внимательно его посмотрел, услышал мысли и мнения экспертов - и теперь хочу представить свою, альтернативную точку зрения на ряд поднятых вопросов. К каждому из выступавших я отношусь с уважением, однако, на мой взгляд, тема была раскрыта не до конца. Звучали призывы «сказать», «начать», «выделить бюджет» - но, к сожалению, без конкретики. Вероятно, это связано с внутренними NDA: многое просто нельзя озвучивать публично. Тем не менее я выделил для себя несколько ключевых тезисов, по которым хотел бы высказать свою позицию. Это исключительно субъективное мнение - как и большинство постов, которые я публикую в своём канале.

1️⃣Первый тезис, прозвучавший на вебинаре: «Человек, который защищает или участвует в этом процессе, должен быть немного математиком, немного лингвистом и понимать, как устроена обвязка вокруг этой нейросети». На мой взгляд, опыт и общение с представителями разных компаний показывают, что куда больший эффект дают кроссфункциональные команды, чем попытка возложить всю ответственность за безопасность ИИ на ИИ-специалистов. Во многих случаях контекст настолько специфичен - не просто для ML в целом, а именно для конкретной команды или продукта, - что ИБ-специалист должен выступать скорее в роли заказчика, чем безапелляционного диктатора. Это обусловлено особенностями домена, ландшафта угроз и даже схожестью угроз между разными проектами.

2️⃣Второй, но уже мой тезис: создавать полностью новые инструменты - не всегда рациональное решение, как и отказываться от традиционных мер информационной безопасности при защите ИИ-инфраструктуры или моделей. В ряде случаев это приведёт лишь к неоправданным тратам - как финансовым, так и в виде человекочасов, потраченных на ненужный R&D и избыточную сложность. Некоторые участники вебинара критиковали существующие фреймворки безопасности ИИ, при этом предлагая отказаться от базовых подходов. Мне кажется, это неверный путь. Хотя многие сошлись во мнении, что MlSecOps - это надстройка над DevSecOps. Да, он действительно вводит новые требования к защите данных, но это не означает, что каждый специалист по DataOps должен быть глубоко погружённым математиком. Для базовых задач - таких как санитизация данных или настройка RBAC - этого не требуется. Конечно, на других этапах MlSecOps знания в области машинного обучения, а в случае вебинара - именно LLM, - действительно необходимы. Но здесь нужна медиана, а не перекос в сторону исключительно ИИ-экспертов.

3️⃣Третий вопрос - нужен ли регулятор и насколько сильно всё изменится. Многие участники ответили утвердительно, но мне сложно в это поверить. Регуляторы редко формулируют детальные, технически проработанные требования, ориентированные на экспертов. Скорее всего, вместо реальной защиты мы получим бумажную безопасность - формальные отчёты и чек-листы, от которых будет мало практической пользы. В таком случае, возможно, текущих фреймворков в целом достаточно. Многие из тех, что я видел, уже описывают процессы, выделяют широкий спектр угроз, структурируют и формализуют подходы, а иногда даже предлагают конкретные требования - хотя зачастую эти требования всё равно дорабатываются уже внутри организаций.

4️⃣Четвёртое - мне показалось, что угрозы обсуждались преимущественно в духе «страшилок», а не в контексте реальных бизнес-рисков. Между тем на канале уже не раз публиковались попытки моделировать угрозы для разных этапов, компонентов и типов ML-систем.

5️⃣Пятое - LLM не исчерпывают собой весь MlSecOps. Разговор на вебинаре почему-то в основном сводился к большим языковым моделям, тогда как другие направления - компьютерное зрение, CNN, предиктивные модели и так далее - остались в тени. Это смутило меня, хотя я сам часто пишу именно про LLM. Забывать об остальных типах моделей было бы ошибкой. Во многих организациях просто нет бюджета на гонку за «хайпом» - а ведь LLM уже перестали быть хайпом, пора — это признать. Напомню, что существует, например, сборник инструментов MlSecOps, в создании которого я принимал участие. Там видно, что для предиктивного ИИ тоже существует множество решений. Да, некоторые из них заброшены или сложны в настройке - но игнорировать этот пласт и сводить всё к LLM создаёт очевидную, но никем не закрываемую «дыру».

И, наконец, будущее MlSecOps - оно точно не в квантовых компьютерах. К сожалению, на вебинаре не прозвучало мнений о том, каким может быть ближайшее будущее этой области в России. А между тем оно может быть очень перспективным: формирование требований к агентам и RAG-системам, появление множества вайтпейперов, разработка комбинированных подходов к защите в облаках, развитие Large Action Models - и уже сейчас на российском рынке появляются первые инструменты. Всё это создаёт основу для объёмного, интересного и позитивного развития как для отдельных экспертов, так и для всей отрасли в стране.

Ну а если интересно что-то почитать по этой теме, то вот пост, который мы когда-то давно собрали. Он и сейчас объёмный и описывает, где можно прочитать про угрозы и всё-всё.

Участникам вебинара - спасибо, я уважаю их.

Как Garak и другие инструменты для тестирования моделей поменялись за 2 года ?

За 2️⃣ года экосистема инструментов для тестирования безопасности LLM превратилась из нескольких экспериментальных скриптов в экосистему из более чем 25 многофункциональных инструментов (по данным репозитория и исходя из сохранёнок во втором канале), охватывающих весь цикл защиты - от поиска уязвимостей до автоматической генерации отчётов и интеграции в CI/CD. Изначально такие инструменты представляли собой простые скрипты для ручных или полуавтоматических проверок. В 2023 году одними из первых появились Garak от NVIDIA и внутренние скрипты команды Microsoft AI Red Team(позже это сформировалось как PyRIT), но они позволяли выполнять лишь ограниченные проверки отдельных уязвимостей и имели монолитную архитектуру - с жёстко заданными наборами атак и детекторов.

В 2024 году появилось множество специализированных инструментов. К ранним решениям присоединились LLMFuzzer для фаззинга API-интерфейсов, Vigil и LLM Guard для перехвата атак в реальном времени, PyRIT от Microsoft с автоматизацией red teaming и Promptfoo, внедривший полноценные adversarial-сценарии.
Каждый новый инструмент расширял возможности предшественников: он позволял генерировать сотни атак за минуты, автоматически классифицировать ответы и формировать отчёты об уязвимостях. Прорывом стала модульная архитектура. Инструменты теперь состоят из независимых компонентов: Generators (динамическая генерация атак), Orchestrators (управление сценариями), Detectors (анализ ответов) и Reporters (формирование отчётов в JSON, HTML или Markdown).

Начиная с 2024 года в инструментах стал появляться механизм автоматического обучения на основе успешных атак - так называемый adaptive probing. В отличие от ранних решений, которые лишь фиксировали факты нарушений - инструменты вроде Garak и DeepTeam стали анализировать результаты как успешных, так и неудачных попыток и в реальном времени корректировать стратегию генерации промптов, повышая эффективность тестирования.

К началу 2025 года появились решения для тестирования AI-агентов, инструменты тестирования путём взаимодействия через диалоги (Petri от Anthropic) и решения для непрерывного мониторинга в продакшене. Они поддерживают сложные сценарии: вместо одиночных атак типа prompt injection такие решения моделируют цепочки взаимодействий с участием нескольких LLM-агентов, запускают «атакующие» и «защитные» модели в одной сессии и отслеживают полный контекст - историю диалога, системные промпты и переменные состояния. Это позволяет выявлять сквозные уязвимости, которые невозможно обнаружить при одношаговых проверках.

Важным стала интеграция в CI/CD. Если в 2023 году тесты запускались вручную, то к 2025 году такие решения, как Promptfoo, PyRIT и Petri, предоставляют CLI и REST API для запуска в GitLab CI, GitHub Actions или Jenkins, а также веб-хуки для автоматической блокировки деплоя при обнаружении критических уязвимостей.

Параллельно сформировались единые стандарты тестовых сценариев. Вместо разрозненных, ad hoc-скриптов появились готовые реализации OWASP LLM Top 10 и NIST AI RMF, а также встроенные механизмы проверки соответствия требованиям GDPR и HIPAA - особенно для корпоративных решений.

Как итог, инструменты в 2025 году могут предоставить интерактивные дашборды и оценку по различным метрикам безопасности: Success Rate атак по категориям, Time to Detection, Trend Analysis по релизам.

Недавно в разговоре с автором канала OK ML мы обсуждали собак🕺🕺🕺 — и то, как часто при создании чего-то нового мы возвращаемся к старым идеям. Это особенно заметно в случае с ИИ-агентами: раньше они были скорее экспериментом, а теперь повсеместно интегрируются в разные системы — от чат-ботов до автономных решений.

Этот разговор натолкнул меня на мысль: если появление AGI, ASI и других форм продвинутого ИИ кажется неизбежным, насколько тогда очевидна безопасность таких систем? Что ожидать в 2026 году? В прошлом посте я затронул этот вопрос, но тему стоит развить. Поэтому я проанализировал научные публикации, регуляторные инициативы и текущую практику, и выделил несколько ключевых тезисов, которые, определят тренды в области безопасности ИИ.

В 2026 году безопасность ИИ станет обязательной комплаенс-функцией под давлением международного регулирования. С августа 2025 года AI Act требует провайдеров моделей общего назначения обеспечивать прозрачность, соблюдение авторских прав и снижение системных рисков, а с 2026-го — вводит строгие требования к системам с высоким риском в части надёжности и качества данных. ✊

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

Традиционные методы выравнивания (alignment), контролирующие лишь начальные токены вывода, уже не справляются с такими угрозами, как adversarial suffix или fine-tuning poisoning. Им на смену могут прийти более глубокие механизмы - например, DeepRefusal, восстанавливающий 👩‍⚕️ защиту после джейлбрейка, и deliberative alignment с backtracking, позволяющий агенту перепроверять свои решения.

Ландшафт угроз радикально меняется: угрозы в 2026 будут ещё больше смещаться от статических LLM к автономным агентам.

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

Именно функция tool-use (использование внешних инструментов) существенно расширяет поверхность атаки: текстовая инъекция теперь ведёт не к генерации вредоносного контента, а к полному захвату системы - через выполнение небезопасных команд в API, файловых системах или сетевых интерфейсах.

Более опасными являются уязвимости мультиагентных систем. Недавние исследования показывают: если 41,2 процента моделей уязвимы к prompt injection, то 82,4 % могут быть скомпрометированы через эксплуатацию границ доверия между агентами. Это означает, что даже хорошо защищённая модель, устойчивая к внешним атакам, выполнит вредоносную инструкцию, если она поступит от «доверенного» пирингового агента.

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