Как обезопасить системы на базе искусственного интеллекта?

Второй эфир Global Digital Space, который модерировал в рамках конференции Next Generation Security, был посвящен теме обеспечения безопасности самого искусственного интеллекта.

Посмотрите мои заметки с первого эфира про ИИ в руках хакеров.

Начну я сразу с финала, в котором я попросил всех участников назвать несколько типовых и частых ошибок, в том числе и по ИБ, при внедрении искусственного интеллекта.

Ошибки при внедрении ИИ

1. Слишком резко бежать в ИИ, давать много полномочий и ожидать быстрых эффектов.
2. Слишком сильно верить в ИИ, считать, что он быстро заменит людей и решит все задачи.
3. Слишком сильно зажимать ИИ, ничего не пробовать и пытаться все запретить.
4. Не учитывать, что сотрудники все равно будут пользоваться внешними решениями.
5. Внедрять ИИ в невыстроенный процесс, где нет понятных ролей, данных, метрик и ожидаемого результата.
6. Оставлять Shadow AI без внимания.
7. Давать ИИ-сервисам и агентам слишком много прав.
8. Не описывать governance и правила использования ИИ.
9. Рассчитывать на один продукт как на универсальную защиту.
10. Не выстраивать диалог между ИБ, ИИ-командами, бизнесом и юристами.

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

Первые шаги, с которых необходимо начинать

1. Провести аудит текущего использования ИИ. Понять, кто чем пользуется, в каких процессах, где официальные решения, где Shadow AI.
2. Выявить процессы, где сотрудники уже используют ИИ в обход корпоративных инструментов. Именно там формируется backlog первоочередных мер.
3. Выбрать массовые и понятные кейсы для безопасной автоматизации. Оценить их по деньгам, массовости, пользе и рискам.
4. Дать сотрудникам внутренние безопасные инструменты. Чтобы им не приходилось использовать случайные внешние сервисы и телеграм-боты.
5. Создать AI governance. Описать правила использования, разработки, выбора моделей, работы с данными, MCP, внешними и внутренними LLM.
6. Обеспечить минимум привилегий. ИИ-сервис должен получать только те права, которые нужны для конкретной задачи.
7. Проверить доступы и данные. Какие данные доступны ассистенту, RAG, агенту, MCP, внешним моделям и пользователям?
8. Встроить проверки в CI/CD. Особенно при изменении промптов, моделей, интеграций и критичной логики.
9. Развивать MLSecOps-компетенцию. Внутри компании или через специалистов, которые понимают безопасность моделей, датасетов, пайплайнов, LLM и агентов.
10. Строить безопасность как процесс, а не покупку коробки. Финальный акцент эфира был предсказуем, но очень важен: безопасный ИИ требует перестройки практик, а не установки одного продукта.

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

ИИ – это слишком широкий термин, и сначала надо понять, что именно внедрено

В начале дискуссии участники зафиксировали важную мысль: когда компания говорит «мы внедряем ИИ», это может означать очень разные вещи. Это может быть компьютерное зрение, предиктивная аналитика, рекомендательные системы, антифрод, чат-боты, голосовые помощники, RAG, LLM, агенты, MCP-интеграции или внутренние корпоративные сервисы. Для безопасника это означает, что нельзя сразу бросаться защищать «LLM вообще». Сначала нужно понять, какой именно объект защиты появился в компании: обычный чат-бот, локальная модель, внешний API, RAG, агент с инструментами, агент с доступом к корпоративным данным или полноценная ИИ-платформа.

Современный ИИ стал зонтичным термином

Прозвучала мысль, что ИИ сейчас превратился в зонтичное понятие. Под ним могут скрываться совершенно разные классы технологий и разные классы рисков. Поэтому безопасность ИИ нельзя строить одним универсальным способом. Участники подчеркивали: каждый объект нужно защищать по-разному. Чат-бот с локальной моделью, агент с доступом к корпоративным системам и ML-пайплайн требуют разных мер.

Большие языковые модели и внешние ИИ-сервисы уже используют все

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

Главная особенность современных LLM – делегирование задач

Один из участников сформулировал различие между классическим «слабым» ИИ и современными LLM так: современные модели получают от человека все больше делегированных задач. Чем больше задач им делегируют, тем больше их нужно защищать. Проблема не только в модели как таковой, а в том, какие действия ей разрешили делать, к каким данным она получила доступ и какие интеграции вокруг нее построены.

Безопасность ИИ начинается с аудита

Практически все участники сошлись на том, что первым шагом должен быть аудит. Нужно понять, что уже используется в компании: внешние ИИ-сервисы, локальные модели, внутренние ассистенты, агенты, RAG, MCP, кодовые агенты, телеграм-боты, браузерные сервисы, API, корпоративные платформы. Без инвентаризации непонятно, что защищать, какие угрозы актуальны и где уже возник Shadow AI.

Ответственность за ИИ – кросс-функциональная история

Ответственность нельзя повесить только на CISO или только на ИИ-команду. В зависимости от сценария должны участвовать владельцы процессов, центр компетенций по ИИ, CISO, CDO/команды данных, юристы, ИТ, продуктовые команды и владельцы сервисов. Отдельно прозвучала мысль, что ответственность всегда выстраивается «цепочкой»: клиент – владелец сервиса – поставщик решения – владелец модели. Внутри компании аналогично: владелец продукта отвечает перед бизнесом, а внутренние команды – перед владельцем продукта.

Безопасность ИИ должна быть соразмерна риску

ИИ не нужно защищать одинаково везде. Защита должна соответствовать цене ошибки. Если ассистент отвечает по одной публичной странице – риск один. Если ассистент покупает билеты, меняет данные в личном кабинете, работает с финансовыми операциями или имеет доступ к персональным данным, требования к защите резко растут.

Кто сказал недопустимые события? 🙂

Нет одной главной точки риска – защищать нужно весь контур

На вопрос, что важнее защищать – датасеты, модель, процесс обучения, harness, интеграции, промпты, MCP – участники ответили, что это комплекс. В каждом этапе свои риски и свои методы защиты. Но для бизнеса были выделены три наиболее критичные зоны:

1. Интеграции, которые могут привести к необратимым последствиям.
2. Данные, к которым ИИ-система имеет доступ.
3. Shadow AI на рабочих станциях и во внешних сервисах.

Интеграции опаснее самой модели

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

Prompt injection назван ключевым вектором риска

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

LLM надо воспринимать как «не очень разумного человека»

Один из участников предложил практичную аналогию: относиться к LLM как к человеку, но не очень разумному. Такой «человек» может проболтаться, сделать не то, ошибиться или выполнить лишнее действие, если у него есть доступ. Из этого следует подход: давать модели только те полномочия, которые можно было бы дать такому человеку в конкретном процессе.

Классические подходы ИБ остаются полезными, но не всегда достаточными

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

ИИ-агент – это третья сущность между пользователем и приложением

В обсуждении ИИ-агентов прозвучала важная мысль: агент – это не просто пользователь и не просто приложение. Он может действовать автономно, скачивать библиотеки, работать с файлами, обращаться к внешним ресурсам, использовать инструменты, задавать много запросов на разрешение. Возникла аналогия с MFA bombing: если агент постоянно спрашивает разрешение, пользователь в какой-то момент может нажать «да», и тогда произойдет плохое действие.

Агентам нельзя давать полный доступ по умолчанию

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

Хотя зачем тогда эти агенты нужны?

Простого запрета ИИ не получится

Участники неоднократно подчеркивали: «все запретить» не работает. Люди все равно будут пользоваться внешними сервисами, телеграм-ботами, кодовыми агентами и другими инструментами, потому что это удобно. Поэтому стратегия должна быть не в тотальном запрете, а в управлении хаосом: дать удобные внутренние сервисы, контролируемый контур, прокси, шлюзы, мониторинг, обучение и понятные правила.

Shadow AI – один из самых опасных практических рисков

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

Внутренний ИИ-шлюз нужен как единая точка контроля

Обсуждалась идея единой точки входа к внешним и внутренним моделям. Такой шлюз позволяет видеть, что сотрудники отправляют, применять DLP, управлять политиками, строить внутренние сервисы, давать сотрудникам удобную альтернативу внешним инструментам. В одном из примеров внутреннее решение начиналось как единая точка доступа к внешним моделям, а затем выросло в «офис по искусственному интеллекту» с внутренними сервисами, RAG, агентами, транскрибацией и мультиагентными сценариями.

LLM Firewall / AI Gateway – класс решений еще формируется, но он нужен

Участники считают, что прослойка между пользователями, приложениями, агентами и моделями нужна. Ее могут называть AI Gateway, LLM Firewall, встроенным модулем WAF или иначе. Типизация таких средств еще не устоялась, но функции востребованы: авторизация, observability, DLP, rate limits, routing, контроль внешних и внутренних моделей, защита от prompt injection и других угроз.

В России сейчас разработано уже 5-6 LLM Firewall и, похоже, их число растет, напоминая историю с NGFW, когда их в какой-то момент было под 5-6 десятков.

Маскирование чувствительных данных работает не идеально

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

Можно посмотреть модели Privacy Filter от OpenAI, GLiNER, GLiNER Guard, которые как раз для этой задачи разработаны (для английского и русского языков).

Матрица данных нужна, но в компаниях ее часто нет в рабочем виде

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

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

Прозвучала важная оговорка: сотрудник мог подписать документы о конфиденциальности 15 лет назад, когда никто не думал про LLM, внешние ИИ-сервисы и новую геополитическую ситуацию. Поэтому одной старой подписи недостаточно для реального управления рисками.

Локальная модель нужна не всегда

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

Размер локальной модели зависит от задачи

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

MLSecOps отличается от DevSecOps, но часть практик можно переиспользовать

Участники говорили, что часть практик из DevSecOps можно использовать: анализ кода, SCA, проверка зависимостей. Но в ML/AI появляются новые элементы: проверка скачанных моделей, анализ датасетов, проверка промптов, тестирование на prompt injection, сканирование моделей, red teaming LLM, контроль пайплайна обучения и инференса. Было сказано, что нужны отдельные специалисты или хотя бы отдельная компетенция внутри компании.

Обычного пентестера можно доучить до AI red teaming

На вопрос, нужен ли отдельный ИИ-пентестер, прозвучала позиция: обычного пентестера можно докрутить, но LLM-тестирование отличается. Нужно искать «волшебные слова» при реализации prompt injection и джейлбрейков, сценарии, при которых модель выдаст то, что не должна и т.п. При этом разовый пентест недостаточен, потому что ИИ-сервисы быстро меняются.

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

Модель можно защищать не только обучением, но и окружением

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

Скачанные модели и датасеты требуют проверки

В контексте Hugging Face и open-source моделей обсуждалось, что скачанную модель нужно анализировать: смотреть уязвимости, использовать инструменты сканирования, SCA, проверять обвязку, проверять модель в тестах. С датасетами тоже осторожно: лучше использовать внутренние датасеты, а внешние данные – только из проверенных источников. Иначе можно столкнуться со сценариями, когда данные для обучения могут быть отравлены, а модель – модифицирована так, чтобы по ключевой фразе вести себя иначе. Участники говорили, что это требует отдельной экспертизы и ресурсов: нужно контролировать входные данные, выход модели, датасеты, embeddings, векторные представления и результаты обучения.

Регуляторика пока воспринимается как неопределенность, но не как гарантированная катастрофа

Участники обсуждали закон об ИИ и возможные подзаконные акты. Прозвучало, что ранние версии могли восприниматься как «кандалы», но текущая версия не выглядит настолько ограничительной. При этом основные риски могут появиться в подзаконниках, особенно если будут особые требования к национальным или суверенным моделям. Компании уже думают о сценарии, когда для определенных заказчиков или средств защиты придется использовать суверенные/национальные модели.

Не исключено строительство и потемкинских деревень – на бумаге будет все национальное и суверенное, а в реальности – то, что работает и приносит пользу.

Безопасность ИИ – это не коробка, а процесс

Финальный вывод модератора, то есть меня, был прост – в отличие от некоторых областей ИБ, здесь нет продукта, который закроет 90% задач. И, вероятно, такой «волшебной пули» никогда не появится. Безопасность ИИ – это процесс, который требует перестройки практик, архитектуры, разработки, контроля данных, ответственности и обучения.

Ну а теперь, почитав краткие тезисы, вы можете и запись самого эфира увидеть:

На других площадках видео тоже можно посмотреть: VK Видео  YouTube RUTUBE Дзен