Вчера прошел эфир AM Live, посвященный теме MLSecOps. Эта тема, в отличие от многих других, впервые была представлена на проекте и, также впервые уже в моей практике модерации, по итогам эфира 0% зрителей ответили, что они ничего не поняли из эфира. Даже на последнем эфире по SIEM, а эта тема на AM Live звучит не первый год уже, 17% ответили, что ничего не поняли. А тут первый блин и не комом!

С другой стороны, тема совсем новая и поэтому по ней еще нет какой-то сложившейся практики, продуктов, технологий и прошедший эфир это четко продемонстрировал. Я не буду пересказывать все 2,7 часа разговоров с коллегами, отмечу только несколько сделанных мной инсайтов или озвученных коллегами выводов:
1️⃣ В MLSecOps лучше идти из ML или, на крайнем случае, из DevOps. Безопасникам в этой теме очень тяжело, так как надо знать много нетипичного, включая математику машинного обучения и различные архитектуры в этой сфере. Ну и без знания DevOps там тоже делать нечего.
2️⃣ Все участники прям жаждут нормативку по безопасности ИИ, в первую очередь, требования к средствам защиты ИИ (LLM Firewall и т.п.). Никогда не понимал вот этого стремления к получению требований; как будто без них продукт не продастся (тогда у меня вопросы к самому средству).
3️⃣ Многие воспринимают MLSecOps как развитие DevSecOps, но с несколькими дополнительными компонентами, например, в виде защиты датасетов, определения их происхождения и т.п.
4️⃣ Владельцем MLSecOps-процесса должно быть ML-подразделение, но никак не ИБ. Может быть потом, спустя какое-то время, как это происходит постепенно с DevSecOps, который от разработчиков постепенно сдвигается в ИБ.
5️⃣ Мониторить LLM/ML с точки зрения ИБ без наложенных средств защиты а-ля LLM Firewall или guardrail бесполезно. И сама по себе задача мониторинга требует более глубокого погружения в контекст, чем обычно в ИБ.
6️⃣ DLP для мониторинга доступа к LLM не работает.
7️⃣ Для большинства атак на ML недостаточно иметь наложенные средства защиты – надо встраиваться во все этапы жизненного цикла – от работы с данными и пайплайном до отправки промптов через Web UI или API и межагентского взаимодействия. И делать это можно с помощью либо специализированных библиотек, либо путем зашумления датасетов или результатов работы ML, либо путем обучения моделей на атаках, сгенерированных GAN, либо... (тут много либо, но большинство из них не из области готовых продуктов).
8️⃣ Даже LLM Firewall, как самостоятельный продукт, вряд ли готов быть отчуждаемым от вендора, который должен сопровождать свое детище у заказчика, внедряя его, тестируя, создавая правила обработки запросов и ответов, и вот это вот все (не все участники были согласны с этой позицией). MLDR / MLSecOps-as-a-Service – это возможное будущее.
9️⃣ Рынок MLSecOps очень быстро растущий и в 2026-м году будет уже достаточно существенным, чтобы заинтересовать стартапы и специалистов, идти в эту область.

Ну а про остальные интересные советы, идеи, инсайты вы можете узнать из уже сделанной записи эфира, которую можно найти по ссылке 👇

#mlsecops