Изоляция данных ИИ-агента: on-prem, приватный контур, self-hosted
«Облако» само по себе не равно «утечка» — вопрос в том, что и как уходит за периметр. Разбираем три уровня изоляции данных для ИИ-агента и правило выбора: под чувствительность данных, а не по максимуму.
Изоляция данных — набор мер для контроля фактических маршрутов данных ИИ-агента. Минимизация и целевое маскирование сокращают payload, приватный контур ограничивает внешние маршруты, а self-hosted может поддержать строгий периметр при корректной изоляции. Ни один уровень сам по себе не гарантирует отсутствие ПДн или обходных каналов; границы подтверждают трассировкой и тестами.
Что такое изоляция данных
Когда ИИ-агент работает с данными бизнеса — заявками, клиентами, документами, — до внедрения нужно описать, где данные оказываются на каждом шаге и кто может их увидеть. Изоляция данных — набор мер для контроля этих потоков: минимизация, целевое маскирование, сетевые границы, явные внешние вызовы и проверяемая конфигурация.
Изоляция — не одна настройка, а шкала мер. Облачный и self-hosted варианты оба имеют внешние зависимости и операционные риски; строгий периметр достигается только при корректной конфигурации сети, телеметрии, обновлений и доступа. Уровень выбирают по модели угроз и юридическим требованиям конкретных данных.
Три уровня изоляции
На практике уровни выстраиваются от дешёвого и универсального к дорогому и специализированному:
Распознаваемые типы данных заменяются на метки до отправки в модель. Это снижает объём явных идентификаторов, но свободный текст может содержать нераспознанные имена, адреса, @handle и иные ПДн. Покрытие нужно тестировать под формат данных.
Чат на этом сайте маскирует email, российские телефоны и длинные цифровые идентификаторы; иные чувствительные сведения вводить нельзя.
Обработка проектируется внутри инфраструктуры компании, а внешние сервисы включаются через явные маршруты и политики. Контроль подтверждают сетевой конфигурацией, журналом разрешённых вызовов и тестами; одно название «приватный» не исключает ошибку или обходной канал.
Минимизация, целевое маскирование и сетевые границы складываются; юридическое обезличивание и фактический payload провайдеру оцениваются отдельно.
Собственная модель (например, через vLLM) может оставлять запросы внутри заданного периметра, если сеть, телеметрия, обновления, зависимости и доступ корректно изолированы. Нужны GPU-сервер, обслуживание и проверка отсутствия неучтённых внешних вызовов.
Выбор между своей моделью и облаком разобран в vLLM vs облачные API.
Уровни не взаимоисключающие, а складываемые: маскирование имеет смысл на любом из них, приватный контур может использовать и облачную модель (с обезличенными данными), и self-hosted. Проектирование изоляции — это выбор комбинации, а не одного пункта из трёх.
«Уходят данные» и «учится модель» — это разное
Два опасения про облако постоянно смешивают, а проверяются они по-разному. Первое — «какие данные уходят наружу»: описывается трассировкой потоков, минимизацией, маскированием и сетевыми политиками. Второе — «как провайдер использует запросы»: проверяется по актуальному договору, настройкам продукта, срокам хранения, региону обработки и условиям использования данных для обучения.
Облачный вызов означает передачу фактического payload провайдеру, но не позволяет автоматически заключить ни «утечка», ни «безопасно». Риск зависит от данных, маршрута, доступа, хранения, настроек продукта и договора. Его снижают минимизацией и техническими мерами, а self-hosted также требует проверки телеметрии, зависимостей и внешних вызовов.
Когда нужен self-hosted
Self-hosted оправдан там, где выход данных наружу недопустим по существу, а не «для спокойствия». Типичные основания:
- Гостайна и режимные данные. Где применимый правовой режим и юридическая оценка ограничивают внешнюю передачу.
- Чувствительные медицинские и финансовые данные. Где модель угроз и оценка ущерба обосновывают более строгий периметр.
- Требование хранить всё в собственном периметре. Внутренняя политика безопасности крупной организации.
Для сценариев без требования строгого периметра может подойти комбинация минимизации, целевого маскирования, контролируемых внешних вызовов и договора. Достаточность нельзя определить для «большинства задач» заранее: её подтверждают моделью угроз, составом данных, тестами границ и юридической оценкой.
Компромиссы и стоимость
У изоляции есть цена, и честный разговор о ней — часть проектирования. Маскирование добавляет разработку, тестирование покрытия и может удалить контекст, нужный модели. Приватный контур требует настройки и контроля границ. Self-hosted добавляет GPU, обновление модели и ответственность за доступность; качество конкретной открытой модели измеряют на задачах проекта.
Более строгая изоляция может увеличить стоимость и изменить качество или задержку ответа. Комбинацию выбирают по модели угроз, юридическим требованиям и измерениям конкретной модели; универсального «максимального» уровня без остаточного риска нет.
Как это делаем мы
Уровень изоляции мы подбираем под данные проекта, а не по единому шаблону. На этом сайте чат заменяет распознаваемые email, российские телефоны и длинные цифровые идентификаторы до вызова облачной модели. Фильтр снижает риск, но не распознаёт все возможные ПДн; иной чувствительный текст может уйти провайдеру. Границы строгого периметра тестируют и мониторят, но конечный набор проверок не доказывает отсутствие всех обходных каналов.
Как изоляция встроена в полный надзорный контур — в обзоре «Надзор и безопасность ИИ-агентов»; соответствие 152-ФЗ — в разборе «152-ФЗ для ИИ-систем»; состав работ — на странице ИИ-операторы. Ориентир по деньгам — от 150 000 ₽ за проект и от 50 000 ₽ в месяц за сопровождение; точная смета — по бесплатному разбору.
Частые вопросы
Обязательно ли self-hosted, чтобы данные ИИ-агента были в безопасности?
Нет. Self-hosted — один из инструментов строгого периметра, но сам по себе не гарантирует безопасность: нужны сетевые границы, контроль телеметрии, обновлений, зависимостей и доступа. Для другого сценария может подойти облако с минимизацией, целевым маскированием и договорными мерами. Достаточность определяют по данным, модели угроз и юридическим требованиям.
Если агент использует облачную модель, данные точно утекут?
Нет, но облачный вызов означает передачу провайдеру фактического содержимого запроса. Риск зависит от состава данных, покрытия маскирования, региона и условий обработки. Нужно проверить актуальный договор и настройки хранения или обучения, минимизировать запрос и считать нераспознанные ПДн возможными, а не обещать их отсутствие.
Чем маскирование отличается от приватного контура?
Целевое маскирование заменяет распознаваемые типы данных на метки, но может пропустить ПДн в свободном тексте. Приватный контур управляет инфраструктурой и маршрутами внешних вызовов. Эти меры складывают и тестируют: ни одна из них отдельно не подтверждает полное обезличивание или отсутствие обходного канала.
«Учится ли модель на наших данных» — как это исключить?
Это отдельный от сетевой изоляции вопрос. Проверяют актуальные условия конкретного API, настройки аккаунта, сроки хранения и договор обработки: политики провайдера и продукта могут различаться и меняться. Архитектура отвечает на «что уходит», договор и настройки — на «что с этим делает провайдер»; оба слоя требуют проверки.
Сколько стоит изоляция данных в проекте?
Зависит от состава данных и модели угроз. Маскирование требует разработки и тестов покрытия, приватный контур — настройки и мониторинга границ, self-hosted — GPU и эксплуатации модели. Комбинацию и критерии приёмки определяем после разбора данных; точная смета — по бесплатному разбору.
Хотите так же — но для вашего бизнеса?
30 минут разбора — бесплатно. Покажем, что реально автоматизировать в вашем случае и что это даст. Отвечает тот, кто ведёт проект.