На предыдущую страницу
Блог

Безопасность данных при использовании внешних AI-сервисов: что нужно знать Enterprise

ИБ-отделы крупных компаний выстраивают многоуровневую систему защиты корпоративных данных, используя для этого широкий набор инструментов от межсетевых экранов до средств криптографической защиты информации. Однако массовое использование ИИ в работе породило новый и, зачастую, никем не контролируемый канал утечки чувствительных данных.  Самый доступный из них в 2026 году — это браузер. В Chrome, Edge, Яндекс Браузере ИИ-ассистент доступен по умолчанию. Сотрудник может написать запрос, содержащий корпоративные данные, которые отправятся во внешний сервис. При этом отделу ИБ контролировать такие утечки сложно. 

Отдельный класс рисков порождает использование AI-агентов. Агент обращается к внешним инструментам, вызывает API, работает с файлами. Проблема в том, что он не всегда отличает данные, которые обрабатывает, от команд, которые должен выполнять. Если злоумышленник спрячет вредоносную инструкцию (prompt injection) в письме или документе, агент выполнит ее. Например, обратится к базе, передаст данные за IT-периметр или изменит настройки. Так агент превращается в канал утечки данных, а что еще хуже, становится точкой входа киберпреступников во внутренний контур.

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

Универсального решения, которое закроет все риски использования ИИ, не существует. В зависимости от своих возможностей и уровня цифровой зрелости, бизнес выбирает разные сценарии. 

  • Полный запрет внешних AI-сервисов. Решение технически осуществимо через блокировку доменов, DLP и внедрение списка разрешенных приложений (allowlist). 
  • Отключение встроенного ИИ в используемом ПО. Точечная мера, доступная во всех основных браузерах: Chrome, Edge, Safari и других.

Такой подход блокирует утечку данных через корпоративные сервисы, но не решает проблему целиком. Сотрудники просто уходят в тень, то есть используют личные аккаунты на сторонних сервисах для рабочих задач. По данным глобального исследования MIT, официальную подписку на LLM закупают лишь 40% компаний, а сотрудники 90% компаний регулярно пользуются личными ИИ-инструментами для работы, становясь невидимыми для корпоративной службы ИБ.

Поэтому вместо политики запретов действенное решение — не блокировка, а выстраивание работы так, чтобы работа с ИИ не приводила к потенциальным утечкам данных. Для реализации такого подхода необходимо внедрить комплекс мер: от работы с персональными данными до выбора сервиса.

Персональные данные и внешние LLM: требования закона и методы обработки

Закон требует, чтобы первичный сбор и хранение персональных данных осуществлялись на территории России. Если это условие соблюдено, то данные можно передавать за рубеж, в том числе во внешние LLM. Перед передачей компания уведомляет Роскомнадзор, а если страна назначения не входит в перечень стран с адекватной защитой персональных данных, то ждет 10 рабочих дней. Если в этот срок регулятор не ограничил передачу, то можно передавать данные. 

Также необходимо решить, в каком виде данные будут передаваться. Для этого есть три основных способа: анонимизация, обезличивание и маскирование

  • Анонимизация безвозвратно разрывает связь данных с субъектом персональных данных. Соответственно, ответ модели невозможно привязать к клиенту или договору, из которого взяты данные. Это делает анонимизацию пригодной лишь для очень ограниченного числа сценариев работы с внешними LLM. Например, нужен лишь агрегированный результат обучения на модели на анонимизированном массиве данных.
  • Обезличивание используется редко, так как для работы с внешними LLM оно избыточно. У этого метода более мягкое требование, чем у анонимизации: восстановить исходные данные должно быть невозможно «без дополнительной информации». На практике это часто оставляет техническую лазейку, поэтому формально обезличенные данные могут по-прежнему считаться персональными. Кроме того, метод создавался для другой задачи, например для отчетности или анализа больших массивов данных. Он не рассчитан на то, чтобы скрыть данные от конкретного внешнего сервиса, а затем получить точный ответ по этому же кейсу.
  • Лучше всего задачу сокрытия данных от внешнего сервиса и восстановления исходных значений после получения ответа решает третий метод: маскирование. Перед отправкой в LLM реальные значения (имена, номера телефонов или договоров) заменяются техническими метками. Модель работает только с метками и не видит исходные данные. Таблица соответствия «метка → значение» хранится на стороне компании и никогда не покидает ее контур. Когда модель возвращает ответ, метки на стороне компании автоматически заменяются обратно на реальные значения.

Пример 

Юрист хочет получить от модели резюме условий договора. Перед отправкой в LLM система маскирования заменяет названия сторон, номер договора, сумму и даты на условные метки. Таким образом, вместо реальных значений модель видит только структуру текста. Она возвращает резюме, оперируя теми же метками, а на стороне компании вместо меток автоматически подставляются реальные значения. 

Выбор внешнего сервиса: агрегаторы LLM

Прямой доступ к популярным API OpenAI, Anthropic и Google из России на практике недоступен, так как западные разработчики ограничивают доступ для пользователей из России. Как следствие, на рынке широко представлены несколько типов агрегаторов LLM, которые предоставляют доступ к нескольким языковым моделям от разных вендоров. Их можно классифицировать на три типа. 

  • Легальные российские агрегаторы. Это компании, предоставляющие доступ к широкому списку моделей с оплатой в рублях. В подавляющем большинстве они не аттестованы согласно ФЗ-152 и не обеспечивают необходимый уровень безопасности для работы с персональными данными. 
  • Серые агрегаторы. Такие компании не обеспечивают даже минимальных требований к безопасности данных, им доступен весь трафик компании. Кроме того, для максимизации прибыли они могут перенаправлять трафик на более дешевую модель без ведома клиента. 
  • Иностранные агрегаторы. Для работы с ними необходима карта зарубежного банка, при этом сервис может в любой момент отказать российским пользователям в доступе.  

В целом работа с агрегатором, как правило, не решает проблему утечки данных.

Корпоративный AI-шлюз: системный подход к работе с ИИ

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

  • Локальное развертывание. Компания разворачивает AI-шлюз на своей инфраструктуре. Такой подход обеспечивает максимальный контроль над данными и возможность дообучать собственные модели, полностью исключая выход данных за пределы доверенного контура. Обратная сторона локального развертывания связана со значительными инвестициями в инфраструктуру и ее эксплуатацию. Как следствие, решение подходит лишь для крупного бизнеса. 
  • Облачное развертывание по модели AI as a Service. Компания получает доступ к управляемой AI-платформе в облаке провайдера с управлением доступом, квотами по подразделениям и предсказуемым биллингом. Преимущество облачного развертывания, это в первую очередь оптимизация затрат: ресурсы масштабируются под нагрузку, а компания избегает капитальных вложений в собственную GPU-инфраструктуру.

AI as a Service от ITGLOBAL.COM

ITGLOBAL.COM предлагает собственный корпоративный AI-шлюз с единой точкой доступа к более чем 100 LLM. Все персональные данные обрабатываются на территории РФ согласно требованиям 152-ФЗ. Клиентам предоставляются средства контроля и защиты персональных данных на уровне платформы. К ним относятся инструменты для автоматического выявления персональных данных в запросах, их маскирования, блокировки передачи или перенаправления на локальные модели в зависимости от заданных политик. 

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

Архитектурно решение опирается на собственную GPU-инфраструктуру и объединяет весь стек технологий: от физических серверов до высокоуровневого API-шлюза.

На выбор предоставляются два формата:

Базовый подходит компаниям, которым нужен быстрый старт. Они получают единый API к 100+ моделям с управлением доступом и квотами, без необходимости разворачивать собственную инфраструктуру. 

Private AI Cloud предназначен для организаций с повышенными требованиями к информационной безопасности. Они получают изолированный AI-контур на вычислительных мощностях ITGLOBAL.COM. 

Вывод 

Безопасная работа с ИИ, это реализуемая задача. Она требует системного подхода к работе с чувствительными данными и надежного партнера, обладающего инфраструктурой, аттестованной согласно 152-ФЗ. Такой партнер берет на себя значительную часть работы по обеспечению безопасности и предоставляет масштабируемые мощности для работы с ИИ.

Защитите инфраструктуру компании

Часто задаваемые вопросы (FAQ) 

Для этого необходимо выполнить два условия. Данные должны собираться и храниться на серверах в РФ, а перед отправкой в LLM персональные данные должны маскироваться.

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

Не всегда. Договор с российским агрегатором не решает вопрос обработки персональных данных, если модель все равно работает на зарубежных серверах, а зарубежный провайдер не подписывает договор поручения по 152-ФЗ. Соответствие закону обеспечивает не сам факт работы через агрегатора, а то, маскируются ли персональные данные до того, как запрос уходит к провайдеру модели.

Оцените данную статью

Узнавайте о выходе новых статей в блоге первыми!

Подпишитесь на нашу рассылку