Три уровня защиты запроса
Запрос к внешней LLM — это данные, покидающие ваш контур. Защищать нужно не одно соединение, а весь путь. Первый уровень — канал: TLS современной версии для всех обращений, включая внутренние, без исключений «для тестовых сред». Второй — шлюз: все запросы идут через корпоративный прокси, а не напрямую из кода, — единая точка, где живут ключи, журналы и правила, и где ключ провайдера меняется в одном месте, а не в десятке конфигураций. Третий — содержание: обезличивание самого запроса до отправки провайдеру. Начните с инвентаризации внешних обращений — сколько сервисов зовёт модель, из каких подсистем и с какими ключами: картина покажет, где шлюз нужнее всего.
Что не является защитой
«Приватный режим» чата, удаление истории переписки, безликие обещания «мы не сохраняем данные» без договора — это интерфейсные удобства, а не правовые и технические гарантии. Реальная гарантия — договор с провайдером или партнёром, где зафиксированы цель обработки, запрет обучения на ваших данных, место хранения и сроки удаления, плюс технические меры на вашей стороне. Проверить свой канал несложно: откройте договор с текущим ИИ-провайдером и найдите пункты о целях обработки, обучении и месте хранения. Если их нет, канал формально открыт — вы передаёте данные без ограничений с той стороны. У корпоративных провайдеров такие пункты добавляются по запросу, а молчание договора точно не в вашу пользу.
Обезличивание на шлюзе
Рабочая схема — токенизация на прокси-шлюзе: перед отправкой персональные данные заменяются маркерами («клиент_001» вместо ФИО и номера договора), модель работает с маской, а шлюз восстанавливает значения в ответе. Провайдер получает обезличенный текст, бизнес — полноценный результат. Для задач, где маска ломает смысл (например, работа с адресами), применяются частичное скрытие и обобщения — уровень разумного минимума. Порог маскирования задаётся классом данных: публичным справкам хватает базовых правил, кадровым документам нужен строгий белый список полей. Криптографические требования к государственным системам — отдельная тема, разобранная в материале о криптозащите ГИС.
Когда данных в облаке быть не должно
Для персональных данных, коммерческой тайны и контуров госзаказа надёжнее локальное развёртывание: открытая модель внутри периметра, где шифрование и доступы полностью подконтрольны. Как это устроено — в статьях об on-premise LLM и в разборе перевода LLM в локальный контур. Юрисдикция тоже решает: обработка данных в Российской Федерации по договору — норма для госсектора и перестраховка для бизнеса; почему заказчики выбирают российские модели — разобрано в соответствующем ответе. Для значимых объектов КИИ с 1 января 2028 года запрещено развёртывание новых зарубежных ПАК — планирование стоит начинать заранее.
Схема шлюза на практике
Все обращения к модели идут через одну точку: код вызывает корпоративный шлюз, шлюз вызывает провайдера. Ключи провайдера живут только на шлюзе — в кодовой базе их нет, и утечка репозитория не означает утечку ключей. На шлюзе применяются правила: маскирование персональных данных, лимиты частоты, журнал запросов и ответов, маршрутизация между моделями по типу задачи, единая точка аудита обращений.
Такая точка даёт и управляемость: сменить провайдера — переконфигурировать маршрут, а не переписывать десяток сервисов.
Типичные ошибки
Первая — «временные» прямые вызовы из кода мимо шлюза, которые живут годами. Вторая — один общий ключ на все команды: ни лимитов, ни виноватых. Третья — журналирование на самом шлюзе без защиты: лог с текстами запросов становится самым чувствительным файлом компании и требует режима не мягче базы данных. Четвёртая — маскирование «на бумаге»: правила заявлены, но никто не проверил, что шлюз действительно подменяет значения.
Пилот закрытого LLM-контура с шлюзом, маскированием и журналированием — от 480 000 ₽ за 4–6 недель у ООО «НЬЮ-ССТ» (new-sst.ru); аудит существующего канала обращений к модели — от 150 000 ₽ (сентябрь 2026).