Ваши промпты не уходят на обучение чужих моделей: как устроен корпоративный шлюз
Почему при работе через корпоративный шлюз ваши запросы к моделям не попадают в обучение провайдера: контур, маскирование ПДн, журналирование.
Сотрудники всё активнее носят рабочие задачи в публичные чат-боты, и бизнес спрашивает, что происходит с этими данными
Публичный чат-бот удобен. Открыл вкладку, написал задачу, получил ответ. Без установки, без настройки, без согласований. Поэтому сотрудники и пользуются, часто не задумываясь о том, что именно они туда пишут.
Но в какой-то момент в этот процесс включается служба безопасности. И задаёт вопрос, который звучит просто, а ответ на него требует понять несколько вещей сразу: «А вы не учитесь на том, что мы вам пишем?»
Что реально уходит наружу
Проблема не абстрактная. В свободном тексте промпта легко оказываются вещи, которые там быть не должны.
Пример из практики: разработчик просит модель «помочь разобраться с ошибкой в запросе к базе клиентов», вставляет фрагмент кода и для контекста добавляет реальные данные из тестовой выгрузки: имена, телефоны, адреса. Задача решена, разработчик доволен. Только что именно было в этом запросе и куда он отправился, никто не отслеживал.
Другой сценарий: менеджер описывает ситуацию с конкретным клиентом, называет компанию, сумму сделки, детали переговоров, просит помочь сформулировать письмо. Коммерческая тайна в промпте - это уже не гипотетический риск.
На публичных тарифах ряда провайдеров содержание запросов может использоваться для дообучения модели. Условия зависят от тарифного плана и региона, но по умолчанию некоторые провайдеры включают использование данных для улучшения сервиса, если не указано иное. Читать эти условия стоит до того, как сотрудники начинают активно пользоваться инструментом.
Как устроен корпоративный шлюз
Когда мы разворачиваем корпоративный шлюз в вашем контуре, меняется несколько вещей одновременно.
Единая точка входа. Все обращения к языковым моделям идут через один шлюз в вашей инфраструктуре, а не напрямую с рабочих станций сотрудников или из приложений по личным ключам. У вас появляется видимость: кто, когда, с каким типом запроса обращался к модели.
Маскирование ПДн перед отправкой. Перед тем как запрос уходит к провайдеру, шлюз обрабатывает его по правилам маскирования: имена, телефоны, адреса, идентификаторы заменяются синтетическими значениями. Модель получает структурно корректный запрос, но без реальных персональных данных. Это требование 152-ФЗ в практическом выражении: оператором персональных данных остаётесь вы, технический контур не пропускает их дальше без обработки.
Выбор провайдера и режима. Шлюз позволяет явно задать, к каким провайдерам и на каких условиях идут запросы. Провайдеры, которые декларируют отказ от использования запросов для обучения на платных тарифах (OpenAI Enterprise, Anthropic API, ряд других), подключаются именно в таком режиме. Это не доверие на слово, а выбор конкретного тарифа с задокументированными условиями.
Журнал под вашим контролем. Лог всех обращений хранится у вас, а не у провайдера. Вы можете проверить, что именно уходило в запросах, в любой момент. При инциденте или аудите это часы на разбор, а не недели переписки с поддержкой.
Разграничение доступа. Принципы zero-trust применяются и здесь: разные команды и приложения получают доступ к разным моделям с разными ограничениями. Аналитики не используют тот же ключ, что и продуктовое приложение.
Кейс: команда разработки, единая точка входа
Одна из команд разработки, с которой мы работали, столкнулась с типичной ситуацией. Несколько разработчиков пользовались языковыми моделями активно, у каждого был свой личный ключ, обращения шли напрямую к провайдеру. Никакой видимости у компании не было.
После подключения шлюза провели аудит первых двух недель работы через него. Картина оказалась предсказуемой, но показательной: в части запросов обнаружились фрагменты с ФИО и телефонными номерами из тестовых выгрузок. Маскирование убрало эти данные из того, что реально уходило к провайдеру. Разработчики не нарушали что-то намеренно: просто так было удобнее, взял данные из-под руки, вставил в запрос.
После этого установили правила для команды: какие данные допустимо передавать в запросах, а какие нельзя. Журнал помог быстро проверить, что правила соблюдаются.
Честный компромисс
Маскирование не бесплатно. Чтобы оно работало правильно, нужно разметить, какие поля и форматы считаются чувствительными в вашем контексте. Для структурированных данных (таблиц, выгрузок с известными полями) это делается один раз и работает надёжно. Сложнее со свободным текстом: если сотрудник пишет «клиент Иванов Иван Иванович из Краснодара заказал...» - это тяжелее поймать автоматически, чем поле телефон: +7 900 000 00 00.
Накладные расходы на маскирование существуют, но они невелики относительно задержки ответа модели.
Есть и более принципиальный момент: шлюз даёт контроль над тем, что уходит к внешним провайдерам, но не устраняет вопрос полностью. Если нужна абсолютная уверенность, что данные вообще не покидают ваш периметр, ответ другой: модель разворачивается локально, запросы никуда не уходят. Это отдельная история со своими требованиями к железу, но логика там именно такая.
Что это даёт на практике
Корпоративный шлюз решает задачу, которую иначе не решить административными мерами. Запретить сотрудникам пользоваться публичными чат-ботами можно, но работать это не будет: неудобный инструмент обходят через личные устройства. Дать доступ без контроля, тогда вопрос «что уходит наружу» останется открытым навсегда.
Шлюз даёт третий вариант: инструмент работает, сотрудники им пользуются, но вы видите, что происходит, и чувствительные данные не уходят наружу в исходном виде. Контроль над тем, что попадает к модели, остаётся у вас.
Если хотите понять, как это устроить применительно к вашему стеку, начните с разговора. Подробнее об услуге на странице LLM API.