Как компаниям выстраивать защиту ИИ
5 мин
75
5
Топ-3 типичных ошибок, которые допускает бизнес при внедрении ИИ
- Попытка всё запретить вместо того, чтобы предлагать контролируемые альтернативы. Это лишь загоняет использование ИИ в тень, делая его ещё более опасным.
- Или, наоборот, игнорирование теневого использования ИИ сотрудниками.
- Слишком быстрое внедрение ИИ с предоставлением агентам избыточных полномочий без оценки рисков. Многие руководители «на хайпе» дают ИИ доступ ко всем базам, не понимая, какие последствия может иметь даже случайный промпт.
Как избежать таких проколов, обсудили участники конференции «Next Generation Security 2026: AI vs AI».
Начать с аудита
«Реальность такова, что сотрудники пользуются внешними нейросетями независимо от корпоративных политик. Это создаёт колоссальные риски утечек. Однако задача служб безопасности не в том, чтобы поставить железный заслон, а в том, чтобы сделать этот стихийный процесс управляемым, прозрачным и безопасным для бизнеса», — сказал директор по развитию технологий искусственного интеллекта компании «Ростелеком» Андрей Зима.
Первый шаг — аудит, без которого любые защитные меры будут малоэффективными, уверен руководитель центра ИИ и перспективных технологий BI.ZONE Александр Балабанов. ИИ-сервисы различаются не только по функциональности, но и по уровню потенциального риска: одно дело — чат-бот с локальной моделью, другое — автономный агент с доступом к корпоративным системам и данным. Поэтому, прежде чем выстраивать защиту, CISO необходимо понять, какие решения уже используются и к каким ресурсам подключены, говорит он.
При этом одной инвентаризации используемых сервисов недостаточно. Руководитель направления по безопасности AI в VK Алина Князева отмечает, что аудит должен охватывать все этапы жизненного цикла ИИ — от разработки (MLOps) до эксплуатации, включая проверку используемых датасетов, моделей, библиотек и инструментов.
Кейс «Ростелекома»: нейрошлюз как единая точка контроля
В 2023 году «Ростелеком» запустил внутренний продукт «нейрошлюз» — единую точку входа ко всем внешним LLM для сотрудников компании. Идея проста и прагматична: поскольку сотрудники всё равно будут пользоваться нейросетями, пусть делают это через корпоративный прокси-сервер со встроенными DLP-механизмами и логированием. Это позволило не только контролировать, какие данные уходят во внешний контур, но и собирать статистику использования, чтобы понимать реальные потребности бизнеса и выявлять самые популярные сценарии. В «Ростелекоме» расширяют и внутреннюю экосистему ИИ-инструментов. Помимо проксирования внешних моделей компания развивает собственных агентов для работы с документами, сервисы транскрибации, умный поиск и другие решения.
«Неразумный человек»
Один из главных вопросов при внедрении ИИ — какие данные и действия ему можно доверить. Андрей Зима предлагает относиться к LLM, особенно в роли агента, как к «не очень разумному человеку»: не давать ей больше полномочий, чем необходимо для выполнения конкретной задачи. Такой «человек» может проболтаться, выдать конфиденциальную информацию, выполнить опасную команду или случайно получить избыточные полномочия. Поэтому все классические принципы ИБ — минимальные привилегии, ролевое разграничение доступа, логирование и возможность отката — здесь применяются не менее эффективно, чем в традиционной ИТ-инфраструктуре.
Самый популярный вектор атак, связанных с ИИ, — это промпт-инъекции, против которых нет стопроцентной защиты, говорит Александр Балабанов. Если ассистент имеет доступ к избыточным данным, злоумышленник через серию целенаправленных запросов может извлечь информацию, к которой он не должен иметь доступа. Чтобы снизить этот риск, важно ограничить круг данных, доступных агенту (RAG должен индексировать только те документы, которые разрешены для данной роли), и использовать ролевое разграничение на уровне хранилища.
В январе 2026 года стало известно об обнаруженной исследователями ИБ-компании Miggo Security уязвимости в Gemini. Она позволяла использовать приглашения Google Calendar для кражи данных. Злоумышленник помещал скрытую инструкцию в описание события. Когда пользователь обращался к Gemini с обычным вопросом о расписании, ИИ-ассистент мог выполнить эту команду, собрать сведения о закрытых встречах и записать их в новое событие, доступное атакующему. Google устранила уязвимость после уведомления исследователей.
ИБ-эксперты отмечают: важно, чтобы агент изначально не имел доступа к продуктивным системам, а работал в изолированной среде. Если ему требуется доступ к данным через MCP-протокол или через API, то он должен авторизоваться под учётной записью пользователя и наследовать его ролевую политику. Это означает, что агент не сможет видеть или изменять данные, к которым сам пользователь не имеет доступа.
Что ещё можно и чего нельзя делать при работе с ИИ-агентами
Можно
- Использовать структурированный вывод с проверкой по заданной схеме.
- Подписывать и проверять сообщения между агентами.
- Изолировать память и контекст между пользователями и сессиями.
- Ограничивать количество токенов, стоимость, число повторных попыток и длину цепочек вызова инструментов.
- Проводить тестирование на устойчивость к атакам до запуска и после изменений промптов, инструментов, памяти или моделей.
Нельзя
- Хранить конфиденциальные данные в памяти агента без шифрования или маскировки.
- Записывать персональные данные и учётные сведения в журналы в открытом виде.
- Передавать непроверенные данные между агентами в многоагентных системах.
- Полагаться только на вывод модели при принятии решений об авторизации.
- Разрешать неограниченную рекурсию, повторные попытки и цепочки вызова инструментов.
Кросс-функциональная ответственность
Эксперты считают, что ответственность за безопасность ИИ не должна лежать только на CISO. Это совместная задача, в решении которой участвуют владельцы процессов, руководители AI-центров, юристы, HR и бизнес-подразделения.
Андрей Зима привёл пример сквозной цепочки ответственности: перед клиентом отвечает владелец сервиса, перед владельцем сервиса — поставщик решения (интегратор), перед поставщиком — разработчик модели, а перед разработчиком — владелец самой модели (если она внешняя). Внутри компании та же логика: каждый процесс или продукт имеет своего владельца, который несёт ответственность за связанные с ним ИИ-риски, включая утечки данных, некорректные ответы и юридические последствия.
Как рассказала Алина Князева, в VK команды разработчиков продуктов сами заинтересованы в ИБ, потому что любой сбой или утечка напрямую ударит по репутации и пользовательскому опыту. ИБ-команде не стоит полагаться исключительно на технические средства — важна ещё и разъяснительная работа с сотрудниками, говорит эксперт. По её словам, в VK регулярно проводят внутренние обучения, где рассказывают о рисках промпт-инъекций и утечек, объясняют, как пользоваться корпоративными инструментами и почему нельзя загружать во внешние ИИ-ассистенты документы с персональными данными. При этом технические контроли — прокси, DLP, категоризаторы данных — по-прежнему необходимы.
Чек-лист безопасного внедрения ИИ:
- Составить перечень всех ИИ-решений, выявленных в ходе аудита (внешних сервисов, локальных моделей и агентов), для каждого указать владельца, сценарии использования, обрабатываемые данные и доступы к корпоративным системам.
- Разработать и внедрить внутренний governance — свод правил, политик и инструкций для разработчиков и пользователей. Описать, какие данные разрешено отправлять в публичные LLM, какие — только в локальные, какие требуют маскировки. Определить ролевую модель доступа к данным через RAG и MCP.
- Встроить автоматические проверки безопасности в CI/CD, контролировать изменения промптов, моделей, библиотек и инструментов, а также настроить мониторинг для выявления теневых подключений и аномального поведения агентов.
