Безопасность ИИ-сервисов: 5 факторов надежности SaaS

Это не гипотетическая угроза: 38% обращений сотрудников к генеративным сервисам содержат чувствительную информацию. В таких запросах встречаются исходный код и конфигурации, персональные и финансовые данные, элементы интеллектуальной собственности, пароли, токены и API-ключи.

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

Масштаб проблемы: 38% запросов как точка компрометации

Корпоративная среда сгенерировала парадоксальную картину. 40% российских IT-компаний внедрили проекты на базе генеративного ИИ, 45% создали профильные отделы или центры компетенций. Массовое внедрение произошло быстрее, чем появление периметральных политик. Сотрудник получает доступ к удобному инструменту раньше, чем служба безопасности успевает определить, какие данные разрешено отправлять в него, кто должен видеть журнал запросов и как отозвать доступ при инциденте.

На практике это выглядит буднично. Разработчик копирует проприетарный SQL-запрос в публичный ChatGPT, чтобы оптимизировать его на 10%. Аналитик отправляет в модель выгрузку с клиентскими обращениями, не удалив идентификаторы. Сотрудник поддержки вставляет в промпт текст внутренней переписки вместе с номером договора и реквизитами. Каждый отдельный эпизод кажется небольшим, но вместе они формируют канал вывода данных, который не проходит через привычные средства контроля.

В разбивке конфиденциальных обращений выделяются следующие типы информации:

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

Цепочка риска обычно начинается не с атаки на модель. Она начинается с отсутствия правил:

1. сотрудник выбирает внешний ИИ-сервис, потому что он быстрее внутреннего инструмента;

2. в запрос попадает рабочий контекст, который кажется «технической деталью»;

3. запрос покидает корпоративный контур и обрабатывается на стороне провайдера;

4. компания не может самостоятельно проверить весь путь данных, сроки хранения и круг лиц, имеющих доступ к журналам;

5. после этого приходится выяснять, можно ли удалить отправленную информацию и какие последствия повлекла её передача.

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

Vendor lock-in здесь работает в обратную сторону: компания зависит не только от интерфейса или API, но и от чужой инфраструктуры обработки данных. Если сервис становится критичным для разработки, поддержки или аналитики, отказ от него уже нельзя организовать одним переключателем. Поэтому надежность SaaS ИИ-платформы нужно оценивать не только по качеству ответов и доступности API, но и по возможности контролировать данные на каждом этапе их движения.

Скорость внедрения ИИ превысила скорость построения DLP-периметра. 50,5% компаний фиксируют или подозревают утечки через ИИ-инструменты, но сама эта доля не означает, что каждый случай был обнаружен уже после состоявшегося инцидента: речь идёт о выявленных или предполагаемых передачах данных.

Анатомия угроз: от промпт-инъекций до кражи интеллектуальной собственности

Индустриальным ориентиром для оценки рисков служит OWASP Top 10 для LLM и генеративного ИИ. Методология описывает десять классов атак — от манипуляции пользовательским вводом до извлечения весов модели. Для бизнеса ценность такого перечня не в самом рейтинге, а в смене оптики: защищать нужно не только API и сервер, на котором запущена модель, но и все связанные с ней данные, инструменты и бизнес-процессы.

Почему одной фильтрации промптов недостаточно

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

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

Sensitive Information Disclosure также не ограничивается прямым вопросом к модели. Утечка может происходить через:

• системный промпт, в котором случайно зашиты внутренние правила;
• ответ, включающий фрагмент закрытого документа;
• журнал запросов, доступный подрядчику или администратору;
• ошибочно настроенный RAG-индекс;
• отладочные трассировки, которые сохраняют полный контекст;
• интеграцию, передающую результат модели в систему с более широкими правами доступа.

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

Excessive Agency: когда ответ превращается в действие

Excessive Agency — критическая угроза для мультиагентных систем. LLM с доступом к инструментам выполняет действия от имени пользователя: отправляет письма, проводит транзакции, создаёт заявки, изменяет записи в CRM, запрашивает данные из внутренних API или запускает код.

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

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

• какое действие запрашивается;
• с какими данными оно выполняется;
• от имени какой роли;
• разрешено ли оно в текущем контексте;
• требует ли оно подтверждения человека;
• можно ли безопасно повторить операцию после сбоя;
• какие записи должны попасть в журнал.

Такой подход меняет саму единицу контроля. Ею становится не запрос к LLM, а конкретное действие агента и его место в цепочке.

Стандарты защиты: роль ISO/IEC 42001:2023 в управлении рисками ИИ

ISO/IEC 42001:2023 — международный стандарт менеджмента ИИ, или AIMS (AI Management System). Он задаёт не набор фильтров для промптов, а управленческий каркас: кто отвечает за систему, как оцениваются риски, какие решения документируются и каким образом модель контролируется на протяжении жизненного цикла.

Для компании это важное различие. Можно установить DLP-шлюз и при этом не знать, какие команды используют ИИ без согласования. Можно ограничить передачу персональных данных, но не иметь процедуры проверки стороннего плагина. Можно купить изолированный deployment, но оставить без аудита людей, которые имеют административный доступ к данным и логам.

AIMS связывает технические и организационные меры в несколько блоков:

• Governance — назначение ролей, политики допустимого использования, порядок согласования новых сценариев и процедуры эскалации;
• Risk Management — идентификация угроз, оценка вероятности и ущерба, выбор мер снижения риска и пересмотр оценки при изменении системы;
• Impact Assessment — документированный анализ влияния ИИ на субъектов данных, сотрудников, клиентов и бизнес-процессы;
• Lifecycle Management — контроль этапов разработки, внедрения, обновления и вывода модели из эксплуатации;
• Monitoring and Improvement — постоянное наблюдение за качеством, безопасностью и изменениями в поведении системы.

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

Внедрение AIMS должно быть связано с уже действующими практиками. ISO/IEC 27001 закрывает широкий контур информационной безопасности, ISO/IEC 27701 помогает выстроить управление приватностью, а NIST AI RMF даёт прикладную рамку для оценки и обработки рисков ИИ. Эти подходы не заменяют друг друга. Их задача — не создать ещё одну папку с политиками, а распределить ответственность между безопасностью, разработкой, юристами и владельцами продуктов.

Сертификация по ISO/IEC 42001 — не панацея и не доказательство того, что конкретный SaaS-сервис никогда не допустит утечку. Это точка входа в режим непрерывного аудита ИИ-систем. Сертификат не отменяет необходимости проверять конфигурацию, журналы, права доступа, обработку промптов и фактическое поведение модели в рабочих сценариях.

Надежность SaaS ИИ-платформ измеряется не только SLA провайдера, а зрелостью AIMS и технического контроля на стороне заказчика.

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

За пределами LLM-файрволов: переход к Agent Runtime Security

Классический AI Firewall обычно работает как stateless-прокси с Input/Output Guardrails. Архитектура проверяет промпт на входе и ответ на выходе, блокирует запрещённые паттерны, ищет PII, токсичный контент или попытки раскрыть системные инструкции. Такой слой полезен для однократных запросов к модели и должен оставаться частью защиты.

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

Agent Runtime Security — концепция контроля поведения агента во время выполнения. Она включает проверку каждого вызова инструмента, stateful-мониторинг сессии, валидацию действий в контексте роли и разрешений, а также возможность остановить цепочку до того, как она достигнет критичной операции.

Какие компоненты нужны в рантайме агента

Технологический стек Agent Runtime включает несколько уровней.

Policy engine задаёт правила действий. OPA или Cerbos могут использоваться для проверки разрешений: агент вправе прочитать документ, но не экспортировать его; может сформировать платёж, но не подтвердить его; может подготовить письмо, но не отправить без согласования.

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

Observability связывает запрос, ответ, вызов инструмента и итоговое изменение в системе. OpenTelemetry и LangSmith могут использоваться для трассировки, но сама по себе видимость не гарантирует безопасности. Важно, чтобы из трассы можно было восстановить, почему агент выбрал конкретное действие и какие данные ему были доступны.

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

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

Методология тестирования AI Firewall от SecureIQLab, заявленная на март 2026 года, включает 32 сценария атак, учитывающих многошаговую эксплуатацию агентов. Сам факт появления таких тестов показателен: безопасность всё меньше оценивается по способности фильтра заблокировать отдельную запрещённую фразу и всё больше — по способности выдержать последовательную атаку на состояние, память и инструменты.

Развёртывание Agent Runtime Security требует интеграции с CI/CD и оркестратором агентов, включая Kubernetes с CRD для AI workloads. Но не каждой компании нужно начинать с полного технологического стека. Для пилота достаточно определить ограниченный набор инструментов, разделить операции по уровню риска, включить журналирование и поставить ручное подтверждение перед необратимыми действиями. Архитектура должна расти вместе с реальным уровнем автономности агента, а не с презентацией поставщика.

Стратегия внедрения: как сбалансировать инновации и безопасность в 2026 году

Корпоративный заказчик в 2026 году работает на пересечении трёх ограничений: скорости внедрения, регуляторных требований и операционной безопасности. Бизнесу нужен быстрый результат, юридическая служба должна учитывать 152-ФЗ и отраслевые требования, а CISO — не допустить вывода чувствительных данных в неконтролируемый контур.

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

1. Инвентаризация и классификация

Сначала нужно понять, какие ИИ-сервисы уже используются. В каталог попадают не только официально закупленные платформы, но и личные аккаунты сотрудников, плагины редакторов, боты в корпоративных мессенджерах, встроенные функции офисных приложений и API, подключённые к внутренним инструментам.

Shadow IT detection через DNS, CASB и EDR с интеграцией в SIEM помогает увидеть фактический трафик. Но технического обнаружения мало. Для каждого сервиса нужно определить:

• какие данные в него попадают;
• где они обрабатываются и хранятся;
• есть ли журналирование;
• кто отвечает за доступ;
• можно ли отключить сервис без остановки процесса;
• какие бизнес-функции от него зависят.

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

2. DLP на уровне промптов

DLP для ИИ не должен ограничиваться поиском паспортных номеров или банковских реквизитов. Система должна уметь распознавать исходный код, конфигурации, внутренние названия проектов, фрагменты договоров, токены, служебные идентификаторы и другие признаки корпоративного контекста.

Основные меры включают:

• клиентское шифрование там, где оно поддерживается архитектурой;
• удаление или маскирование PII перед отправкой в LLM;
• запрет передачи исходного кода в публичные сервисы;
• разделение политик для разных подразделений и типов данных;
• предупреждение пользователя с объяснением причины блокировки;
• безопасную замену чувствительных значений псевдонимами с обратным восстановлением внутри корпоративного контура.

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

3. Сегментация и tenancy

Не все задачи требуют одинакового уровня изоляции. Публичная LLM может быть допустима для работы с открытыми материалами, частный deployment — для внутренних документов, а on-premise-модель — для наиболее чувствительных операций. Ошибка состоит не в использовании облака как такового, а в отсутствии правил, связывающих класс данных с конкретным контуром обработки.

Сегментация должна учитывать:

• публичные и частные модели;
• разные пространства арендаторов;
• отдельные ключи и роли доступа;
• сетевые маршруты к внутренним API;
• запрет прямого обмена данными между агентами без политики;
• требования к региону хранения и обработки.

Zero Trust для inference-запроса означает, что доверие не возникает автоматически из факта нахождения пользователя в корпоративной сети. Каждый запрос проверяется по пользователю, устройству, приложению, типу данных и назначению операции.

4. Governance framework

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

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

Governance также включает регулярные red team-учения против собственных ИИ-систем. Тестировать нужно не только модель, но и связку из модели, RAG, инструментов, политик и журналов. Система может успешно проходить проверку на прямую утечку и при этом раскрывать данные через цепочку из нескольких невинных на вид действий.

5. Incident Response и мониторинг

План реагирования на утечку через ИИ должен быть отдельной частью общего Incident Response. Он включает изоляцию скомпрометированных каналов, отзыв API-ключей, блокировку подозрительных интеграций и forensic-анализ логов провайдера.

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

MTTR остаётся важным KPI для архитектурного комитета, но его нельзя рассматривать отдельно от времени обнаружения и полноты журналирования. Быстро восстановить сервис, не понимая, какие данные были затронуты, — это не полноценное устранение инцидента. В ИИ-контуре важно восстановить и техническую работоспособность, и доверие к результатам модели.

Что проверять при выборе SaaS ИИ-платформы

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

На переговорах с провайдером стоит отдельно обсуждать:

• Срок хранения данных. Нужно различать хранение содержимого запросов, технических логов, резервных копий и данных для поддержки. Формулировка «не храним промпты» может не распространяться на диагностические записи.
• Регион хранения и обработки. Data residency влияет на юридические риски, маршрутизацию и возможность проведения расследования.
• Доступность журналов для заказчика. Важно понимать, какие события доступны, в каком формате они выгружаются и как долго сохраняются.
• Исключение из обучения. Opt-out должен быть не только переключателем в интерфейсе, но и обязательством, закреплённым договором и применимым ко всем нужным режимам обработки.
• Модель управления ключами. Следует выяснить, кто контролирует ключи шифрования, как устроена ротация и можно ли ограничить доступ к данным со стороны персонала провайдера.
• Поддержка приватных deployment. VPC, выделенный контур или on-premise-развёртывание дают разные уровни контроля и разные операционные расходы.
• Изоляция арендаторов. Нужно оценивать не только наличие multi-tenancy, но и описание механизмов разделения данных, ролей и журналов.
• Процедуры уведомления об инцидентах. В договоре должны быть понятны сроки, каналы коммуникации и объём предоставляемой информации.
• Сертификации и независимые проверки. ISO 27001, SOC 2 Type II и ISO/IEC 42001 полезны как сигналы зрелости, но не заменяют анализа конкретной архитектуры и условий сервиса.
• Возможность смены провайдера. Экспорт промптов, конфигураций, индексов и журналов снижает стоимость миграции и ограничивает vendor lock-in.

Отдельно нужно проверить поведение платформы в отказных сценариях. Что произойдёт, если провайдер временно недоступен? Сможет ли компания переключиться на другую модель без передачи лишних данных? Сохранится ли контроль над очередью запросов? Не попадут ли сообщения, созданные во время сбоя, в сторонний сервис повторно после восстановления соединения?

Защита данных в облачных LLM — не задача одного подразделения. Это инфраструктурный контур, требующий связки CISO, архитектурного комитета, юридической службы и владельцев продуктов. Юристы оценивают основания обработки и договорные условия, архитекторы — границы систем, безопасность — политики и мониторинг, а продуктовая команда — реальную ценность и допустимый уровень автономности.

Vendor lock-in снижается через мульти-провайдерную стратегию и абстракцию inference-слоя, например через OpenAI-совместимый API или LiteLLM как прокси. Но абстракция интерфейса не делает модели взаимозаменяемыми автоматически. Отличаются форматы контекста, ограничения, стоимость, качество вызова инструментов и правила обработки данных. Поэтому переносимость нужно проверять на реальном сценарии, а не только на уровне совместимости endpoint.

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

В конечном счёте надежность SaaS ИИ-платформ складывается из пяти факторов: прозрачности обработки данных, управляемости доступа, устойчивости модели к атакам на контекст, контроля действий агентов и зрелости процессов вокруг самой системы. Сервис с хорошим SLA, но непрозрачными логами и широкими разрешениями не становится надёжным только потому, что редко выходит из строя.

Критерии безопасности нейросетей удобно рассматривать через три измерения:

• Confidentiality — предотвращение утечек с помощью DLP, шифрования, сегментации, маскирования и контроля журналов;
• Integrity — защита моделей, датасетов и RAG-контуров от отравления, подмены и компрометации цепочки поставки;
• Availability — SLA inference, отказоустойчивость, резервные сценарии и disaster recovery.

Эти измерения не существуют отдельно. Слишком жёсткая блокировка может остановить полезный процесс, а чрезмерная доступность без контроля превращает сервис в постоянный канал вывода данных. Рабочая стратегия строится на градации: открытые задачи — в одном контуре, внутренние — в другом, критичные действия — под усиленным контролем и с возможностью ручного подтверждения.

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