Почему математикой не решить все проблемы.Недавно на AMLive вышел эфир,
посвящённый MlSecOps. Я внимательно его посмотрел, услышал мысли и мнения экспертов - и теперь хочу представить свою, альтернативную точку зрения на ряд поднятых вопросов. К каждому из выступавших я отношусь с уважением, однако, на мой взгляд, тема была раскрыта не до конца. Звучали призывы «сказать», «начать», «выделить бюджет» - но, к сожалению, без конкретики. Вероятно, это связано с внутренними NDA: многое просто нельзя озвучивать публично. Тем не менее я выделил для себя несколько ключевых тезисов, по которым хотел бы высказать свою позицию. Это исключительно субъективное мнение - как и большинство постов, которые я публикую в своём канале.
1️⃣Первый тезис, прозвучавший на вебинаре: «Человек, который защищает или участвует в этом процессе, должен быть немного математиком, немного лингвистом и понимать, как устроена обвязка вокруг этой нейросети». На мой взгляд, опыт и общение с представителями разных компаний показывают, что куда больший эффект дают кроссфункциональные команды, чем попытка возложить всю ответственность за безопасность ИИ на ИИ-специалистов. Во многих случаях контекст настолько специфичен - не просто для ML в целом, а именно для конкретной команды или продукта, - что ИБ-специалист должен выступать скорее в роли заказчика, чем безапелляционного диктатора. Это обусловлено особенностями домена, ландшафта угроз и даже схожестью угроз между разными проектами.
2️⃣Второй, но уже мой тезис: создавать полностью новые инструменты - не всегда рациональное решение, как и отказываться от традиционных мер информационной безопасности при защите ИИ-инфраструктуры или моделей. В ряде случаев это приведёт лишь к неоправданным тратам - как финансовым, так и в виде человекочасов, потраченных на ненужный R&D и избыточную сложность. Некоторые участники вебинара критиковали существующие фреймворки безопасности ИИ, при этом предлагая отказаться от базовых подходов. Мне кажется, это неверный путь. Хотя многие сошлись во мнении, что MlSecOps - это надстройка над DevSecOps. Да, он действительно вводит новые требования к защите данных, но это не означает, что каждый специалист по DataOps должен быть глубоко погружённым математиком. Для базовых задач - таких как санитизация данных или настройка RBAC - этого не требуется. Конечно, на других этапах MlSecOps знания в области машинного обучения, а в случае вебинара - именно LLM, - действительно необходимы. Но здесь нужна медиана, а не перекос в сторону исключительно ИИ-экспертов.
3️⃣Третий вопрос - нужен ли регулятор и насколько сильно всё изменится. Многие участники ответили утвердительно, но мне сложно в это поверить. Регуляторы редко формулируют детальные, технически проработанные требования, ориентированные на экспертов. Скорее всего, вместо реальной защиты мы получим бумажную безопасность - формальные отчёты и чек-листы, от которых будет мало практической пользы. В таком случае, возможно, текущих фреймворков в целом достаточно. Многие из тех, что я видел, уже описывают процессы, выделяют широкий спектр угроз, структурируют и формализуют подходы, а иногда даже предлагают конкретные требования - хотя зачастую эти требования всё равно дорабатываются уже внутри организаций.
4️⃣Четвёртое - мне показалось, что угрозы обсуждались преимущественно в духе «страшилок», а не в контексте реальных бизнес-рисков. Между тем на канале уже не раз публиковались попытки моделировать угрозы для разных этапов, компонентов и типов ML-систем.
