Искусственный интеллект быстро вошел в корпоративные процессы: помогает готовить документы, анализировать договоры, искать сведения в базах знаний, обрабатывать обращения, писать код, собирать отчеты и поддерживать сотрудников в рутинных задачах. Но вместе с пользой компании получили новый класс рисков.
ИИ-системы работают не только с открытой информацией. В запросы, обучающие выборки, RAG-хранилища, корпоративные базы знаний и промпты могут попадать персональные данные, коммерческая тайна, финансовые показатели, сведения о клиентах, внутренняя переписка, данные об инфраструктуре, токены, пароли и другие чувствительные сведения. Если такой контур не контролировать, ИИ превращается в новый канал утечки.
Проблема в том, что рынок уже понял необходимость защиты ИИ, но единые требования, зрелые инструменты, профильные специалисты и устоявшиеся практики только формируются. Компании внедряют технологии быстрее, чем успевают описать правила их безопасного использования.
По мнению экспертов компании UDV Group, главный риск для бизнеса заключается не в самом факте применения ИИ, а в том, что модели, агенты и внешние сервисы получают доступ к данным без полноценной инвентаризации, ролевой модели, мониторинга и понятной ответственности за результат.
Утечка через ИИ может начаться с обычного запроса
Для классической ИТ-системы понятно, где находятся данные: в базе, файловом хранилище, корпоративной почте, CRM, документообороте или репозитории кода. В ИИ-системах границы сложнее. Информация может находиться в обучающей выборке, в дообученной модели, в векторной базе, в документах RAG, в пользовательском запросе, в системном промпте или в памяти ИИ-агента.
Из-за этого защита конфиденциальной информации становится более сложной. Нужно контролировать не только место хранения данных, но и весь путь их использования: какие сведения попали в модель, какие источники доступны агенту, что добавляется к запросу, какие документы используются для ответа, какие результаты получает пользователь и не раскрывает ли модель лишнее.
Например, сотрудник может загрузить в открытый ИИ-сервис текст договора, презентацию, внутреннюю схему, фрагмент кода или файл с клиентскими данными, не воспринимая это как утечку. Формально он просто ускоряет работу. Фактически компания передает конфиденциальную информацию в систему, архитектура и правила обработки которой могут быть ей неизвестны.
Особенно опасны сервисы без понятных договорных обязательств по безопасности. Крупные провайдеры, как правило, имеют зрелые процессы защиты и команды безопасности. Но на рынке много небольших ИИ-сервисов, которым пользователь может добровольно передать документы, изображения, персональные данные или коммерческую информацию. Если поставщик неизвестен, риск ложится на саму компанию.
ИИ-агенту нельзя давать больше прав, чем сотруднику
Новые риски усиливаются с появлением ИИ-агентов. Если обычный чат-бот просто отвечает на запрос, агент может ходить в корпоративные системы: базы данных, CRM, порталы, почту, репозитории, Jira, Confluence, системы мониторинга и управления инфраструктурой. Это делает его полезным, но одновременно превращает в полноценного участника модели доступа.
К ИИ-агентам нужно применять тот же принцип, что и к сотрудникам: минимально необходимые права. Если агенту не нужны финансовые документы, он не должен их видеть. Если задача ограничена поддержкой пользователей, ему не нужен доступ к репозиторию кода. Если агент работает с внутренней базой знаний, он должен получать только те документы, которые разрешены для его сценария.
По опыту компании-разработчика ИБ-решений UDV Group, компании часто недооценивают именно этот слой: доступ агента к данным выглядит как техническая интеграция, но по последствиям он ближе к выдаче прав новому пользователю или сервисной учетной записи.
Поэтому для ИИ-агентов нужны авторизация, ролевые модели, журналирование действий, контроль запросов и ограничение доступных источников. Иначе модель может случайно раскрыть данные не тому пользователю, использовать лишний документ в ответе или стать инструментом для извлечения информации через специально подготовленный запрос.
Локальная модель не гарантирует безопасность
Распространенная идея звучит просто: если развернуть ИИ внутри собственной инфраструктуры, данные будут защищены лучше, чем в облаке. В отдельных сценариях это действительно так. Локальная модель позволяет контролировать контур, исключить передачу данных внешнему поставщику и ограничить доступ к интернету.
Но локальная установка не делает ИИ безопасным автоматически. Открытые модели доступны всем, включая атакующих, которые могут изучать их поведение, искать слабые места и готовить атаки. Кроме того, многие open-source-модели не имеют встроенных механизмов корпоративной защиты, которые есть у зрелых облачных платформ. Значит, компании придется самостоятельно выстраивать мониторинг, контроль доступа, защиту от джейлбрейков, проверку промптов, фильтрацию ответов и реагирование на инциденты.
Облачные ИИ-сервисы тоже не являются универсально безопасными или опасными. У крупных провайдеров есть опыт обработки большого количества запросов, защита от атак, процессы реагирования и команды специалистов. Но при передаче конфиденциальных данных в облако нужно понимать условия договора, режим обработки информации, хранение запросов, использование данных для обучения и доступность журналов.
Выбор между локальной и облачной моделью должен зависеть от задачи, категории данных, требований регуляторов, зрелости ИБ-команды и способности компании сопровождать выбранную архитектуру.
RAG и эмбеддинги тоже нужно защищать
Многие корпоративные ИИ-сценарии строятся на RAG: модель получает вопрос пользователя, находит релевантные документы в корпоративной базе знаний и добавляет их к запросу. Это удобно, потому что компании не нужно заново обучать модель на всех внутренних данных. Но у такого подхода есть свои риски.
Документы, которые попадают в RAG, могут содержать конфиденциальную информацию. Эмбеддинги, которые хранятся в векторной базе, тоже являются частью информационного контура. Даже если они выглядят как числовые представления текста, их нельзя воспринимать как безопасный мусор. Через ошибки доступа, неправильную фильтрацию или некорректную настройку поиска модель может подтянуть документ, который пользователь не должен видеть.
Поэтому RAG-система должна учитывать права доступа на уровне источников. Если сотрудник не имеет доступа к документу в исходной системе, ИИ не должен использовать этот документ в ответе. В противном случае модель станет обходным путем к закрытой информации.
Нужно контролировать и качество самих источников. Устаревшие инструкции, дублирующиеся документы, черновики, внутренние комментарии и непроверенные материалы могут попадать в ответы и создавать ошибочные рекомендации. Для ИИ качество базы знаний становится вопросом безопасности и управляемости.
Промпты могут содержать секреты
Системные и служебные промпты часто воспринимают как внутренние настройки. Но на практике в них могут попадать сведения об архитектуре, организационной структуре, доступных инструментах, внутренних системах, сценариях работы, именах пользователей, токенах, паролях и других секретах.
Это опасная привычка. Промпт может быть раскрыт через ошибку, джейлбрейк или некорректное поведение модели. Если в нем содержатся секреты, утечка становится прямым инцидентом. Поэтому служебные инструкции для ИИ должны проектироваться как чувствительный артефакт: без паролей, ключей, токенов и лишних подробностей об инфраструктуре.
Защита от джейлбрейков здесь становится обязательной частью архитектуры. Открытый пользовательский интерфейс, где человек может задавать произвольные запросы, должен иметь фильтры, контроль входных данных, анализ подозрительных инструкций и проверку результата перед выдачей ответа.
MLSecOps становится обязательной дисциплиной
Безопасность ИИ невозможно свести к одному продукту. Она должна сопровождать весь жизненный цикл: сбор данных, обучение, дообучение, валидацию, хранение модели, интеграцию с корпоративными системами, эксплуатацию, мониторинг, обновления и вывод из использования. Именно для этого формируется подход MLSecOps.
MLSecOps наследует многое от DevSecOps, но работает с более сложными артефактами. В обычной разработке нужно защищать код, зависимости, контейнеры, конфигурации и окружения. В ML-проектах добавляются датасеты, модели, эмбеддинги, пайплайны обучения, метрики качества, поведение модели, промпты, агенты и пользовательские взаимодействия.
В UDV Group считают, что MLSecOps должен стать для ИИ тем же, чем DevSecOps стал для классической разработки: способом встроить безопасность не в финальную проверку, а во все этапы создания и эксплуатации системы.
Это особенно важно для LLM-приложений. У них сложно заранее проконтролировать качество ответа на уровне смысла. Модель может галлюцинировать, искажать контекст, уверенно выдавать ошибочный вывод или менять качество из-за сдвига в данных. Для проверки часто нужен человек-эксперт, а отраслевых доверенных бенчмарков и независимых платформ тестирования пока не хватает.
Пентест ИИ должен отличаться от обычного
ИИ-системы нужно проверять не только как веб-приложение или инфраструктурный сервис. Пентест должен учитывать модель, промпты, источники данных, RAG, API, агентов, права доступа, защиту от джейлбрейков, возможность извлечения конфиденциальной информации, устойчивость к манипуляциям и качество реакции на опасные запросы.
Атакующий может не взламывать сервер напрямую. Он может попытаться заставить модель раскрыть системный промпт, выдать закрытый документ, выполнить запрещенное действие через агента, обойти ограничения, изменить контекст, повлиять на данные, которыми пользуется модель, или получить сведения для дальнейшей OSINT-разведки.
Поэтому анализ защищенности ИИ-систем должен включать технические методы и элементы социальной инженерии. Важно проверять не только инфраструктуру, но и диалог с пользователем: токсичность, манипуляции, подозрительные инструкции, попытки обойти правила, а также дополнительные механизмы аутентификации и контроля.
Эксперты UDV Group отмечают, что безопасность ИИ требует постоянного поиска новых сценариев атак. Методы быстро развиваются, поэтому проверка один раз перед запуском не решает задачу: систему нужно мониторить, тестировать и пересматривать по мере изменения модели, данных и пользовательских сценариев.
ИИ должен оставаться управляемым для человека
Главная задача защиты ИИ — не запретить технологию, а сделать ее безопасной и управляемой. Для этого нужны понятные правила работы с данными, контроль доступа, мониторинг входных и выходных сообщений, проверка результатов, участие человека в ключевых точках принятия решений и регулярный анализ уязвимостей.
Компаниям нужно заранее определить, какие данные можно передавать модели, какие запрещено, кто отвечает за качество ответа, где нужна валидация человеком, как фиксируются действия ИИ-агента, какие логи сохраняются, кто расследует инцидент и как система отключается при некорректной работе.
Особенно важно не подменять безопасность доверием к технологии. Даже самая современная модель не должна получать неограниченный доступ к корпоративной информации и самостоятельно принимать критичные решения без контроля. ИИ может ускорять процессы, но ответственность за данные, инфраструктуру и последствия остается на компании.
Развитие ИИ невозможно без доверия. А доверие появляется только там, где система объяснима в пределах своего сценария, защищена от утечек, ограничена по правам, проверяется на устойчивость и встроена в процессы безопасности. Без этого искусственный интеллект становится не конкурентным преимуществом, а новым источником неконтролируемого риска.
Комментарии