LLM в закрытом периметре: что может выбрать регулируемая компания и во что обходится каждый вариант

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

У API провайдера модели периметр держится на договоре с этим провайдером. У управляемого сервиса моделей облачной платформы — на договоре с облаком. У модели с открытыми весами на серверах, которые эксплуатируете вы, — на вашей собственной сети, и вместе с этим к вам переходят все обязанности, которые иначе выполнял бы провайдер.

Запишите, что запрещает периметр, прежде чем сравнивать варианты

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

• Кто вне компании может видеть промпты и ответы модели, включая сотрудников провайдера, проверяющих их на злоупотребления
• В каких регионах данные могут обрабатываться, а не только где они хранятся
• Что может храниться после запроса, как долго и кто может это удалить
• Может ли трафик идти через публичный интернет, пусть даже в зашифрованном виде
• У кого находятся ключи шифрования и логи, доказывающие, кто к чему обращался
• Какие договоры, реестры и аудиты влечёт за собой использование внешнего провайдера

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

Вариант первый: API провайдера, периметр — в договоре

Здесь периметр определяют договор и документация провайдера, поэтому их читают построчно. Документация OpenAI о данных в API указывает, что с 1 марта 2023 года данные, отправленные в API, не используются для обучения или улучшения моделей OpenAI, если клиент сам не дал на это согласия (opt-in). На той же странице указано, что логи мониторинга злоупотреблений, которые могут содержать промпты и ответы, создаются по умолчанию и хранятся до 30 дней, если более длительное хранение не требуется по закону и не является обоснованно необходимым для защиты сервиса или третьих лиц от вреда.

Оба условия можно ужесточить, и каждое ужесточение — это согласование, а не настройка:

• Zero Data Retention (нулевое хранение данных) или Modified Abuse Monitoring (изменённый мониторинг злоупотреблений) исключает контент клиента из логов мониторинга злоупотреблений после того, как OpenAI одобрит клиента. Эндпоинты, которые документация помечает как не подпадающие под эти режимы (not eligible), всё равно могут хранить состояние приложения, часть из них — до его удаления, а OpenAI оставляет за собой право с письменным уведомлением исключать из этих режимов отдельные модели
• Резидентность данных (data residency) настраивается на уровне проекта или выбирается для отдельного запроса, доступность проверяется через отдел продаж, а для любого региона, кроме США, требуются согласование средств управления мониторингом злоупотреблений и Modified Retention amendment (дополнение об изменённом хранении)
• При резидентности данных контент клиента хранится (at rest) в выбранном регионе; инференс выполняется там же только в тех регионах, которые документация помечает как поддерживающие региональную обработку
• Резидентность данных не распространяется на системные данные — данные аккаунта, метаданные и данные об использовании без контента клиента, — которые могут обрабатываться и храниться за пределами выбранного региона
• На той же странице указано, что для эндпоинтов с резидентностью данных действует надбавка 10% на подходящие модели, выпущенные 5 марта 2026 года или позже

Модель тоже живёт по графику провайдера. На странице OpenAI об устаревании моделей (deprecations) указаны минимальные сроки уведомления до вывода из эксплуатации, если соображения безопасности или комплаенса не требуют более сжатых сроков: не менее 6 месяцев для общедоступной модели, не менее 3 месяцев для её специализированных вариантов и гораздо более короткий срок, например 2 недели, для preview-моделей. Каждый вывод из эксплуатации означает, что замену нужно оценить на ваших собственных документах до этой даты, поэтому миграция — регулярная плановая работа, а не инцидент.

Вариант второй: управляемый сервис моделей вашей облачной платформы

Облачные платформы предоставляют модели нескольких разработчиков, часть из них — в рамках облачного договора, который у компании, возможно, уже есть. Документация Microsoft о моделях, которые продаёт Azure в Microsoft Foundry, указывает, что промпты, ответы (completions) и эмбеддинги недоступны OpenAI и другим провайдерам этих моделей. В том же каталоге есть модели, которые Microsoft не продаёт: для моделей Claude в Microsoft Foundry её документация называет Anthropic продавцом, оператором и независимым обработчиком данных в отношении промптов и ответов модели, а при одном из вариантов размещения они обрабатываются на инфраструктуре Anthropic — возможно, за пределами выбранного региона Azure.

Документация Amazon Bedrock описывает отдельный аккаунт развёртывания моделей для каждого провайдера моделей в каждом регионе: им владеет и управляет команда сервиса Bedrock, у провайдеров моделей доступа к нему нет, поэтому они не видят промпты и ответы (completions) клиентов.

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

• Где выполняется инференс: в Azure тип развёртывания с меткой Global может обрабатывать промпты и ответы в любой географии, где развёрнута модель, тип Data Zone — в пределах зоны данных, а привязанный к географии тип Standard или Provisioned — в пределах указанной клиентом географии; для всех них хранимые данные (at rest) остаются в назначенной клиентом географии
• Какие модели вам доступны: Microsoft указывает, что новые модели сначала выходят в Global Standard, позже появляются в Data Zone и региональных типах развёртывания, и их появление в каждом типе развёртывания не гарантируется
• Сколько живёт версия: Azure назначает дату вывода общедоступной модели из эксплуатации через 18 месяцев после запуска и закрывает её для новых клиентов через 12 месяцев; для общедоступных моделей Anthropic, DeepSeek, Fireworks и Mistral AI действует 12-месячный жизненный цикл, а Microsoft оставляет за собой право на экстренный вывод из эксплуатации с сокращённым сроком уведомления
• Как трафик доходит до модели: Amazon Bedrock поддерживает интерфейсные VPC-эндпоинты через AWS PrivateLink для своего runtime API, поэтому вызовы из вашего VPC доходят до модели без интернет-шлюза и публичных IP-адресов
• Кто проверяет контент на злоупотребления: в Azure клиенты, соответствующие дополнительным критериям Limited Access (ограниченного доступа), могут подать заявку на изменение мониторинга злоупотреблений; после одобрения промпты и ответы не сохраняются для проверки людьми, хотя автоматическая проверка может продолжать работать

Для финансовой организации ЕС, подпадающей под DORA, облачный договор уже относится к соглашениям со сторонними поставщиками ИКТ-услуг. 18 ноября 2025 года Европейские надзорные органы (ESAs) опубликовали перечень критически важных сторонних поставщиков ИКТ-услуг, подлежащих надзору на уровне ЕС, и в него входят Amazon Web Services EMEA, Google Cloud EMEA и Microsoft Ireland Operations. Европейская служба банковского надзора (EBA) отмечает, что DORA применяется с 17 января 2025 года и что организации, подпадающие под его действие, обязаны вести реестр своих договорных соглашений со сторонними поставщиками ИКТ-услуг. Поэтому провайдер модели, с которым организация раньше не заключала договор, или новый сервис в рамках уже действующего облачного договора — это вопрос для этого реестра, а не только для архитектуры.

Вариант третий: модель с открытыми весами на инфраструктуре, которую эксплуатируете вы

Размещение на своей инфраструктуре — на собственном оборудовании или на виртуальных машинах в вашем облачном аккаунте — переносит инференс внутрь вместе со всеми обязанностями, которые выполнял провайдер. Первая из них — прочитать лицензию, потому что общей лицензии у моделей с открытыми весами нет. Mistral Small 3, Qwen3-32B и gpt-oss-120b от OpenAI опубликованы на Hugging Face под лицензией Apache 2.0. Llama 3.3 Community License от Meta, под которую подпадает модель Llama 3.3 70B, чьи требования к железу разобраны ниже, требует, чтобы использование соответствовало её политике допустимого использования. Она также требует, чтобы лицензиат, у чьих продуктов или сервисов, включая продукты и сервисы его аффилированных лиц, в календарном месяце перед датой релиза было более 700 миллионов активных пользователей в месяц, запросил лицензию, которую Meta может предоставить по своему единоличному усмотрению.

Требования к железу вытекают из числа параметров и точности. У Llama 3.3 70B Instruct около 70,6 млрд параметров; при 16 битах на параметр одни только веса занимают около 141 ГБ (131 ГиБ), что не помещается на один ускоритель на 80 ГБ ещё до выделения памяти под KV-кеш параллельных запросов. В карточке модели gpt-oss-120b указано, что квантизация весов mixture-of-experts в MXFP4 позволяет запускать модель на одном GPU на 80 ГБ.

Слой сервинга становится вашей границей безопасности. Документация vLLM по безопасности указывает, что связь между узлами многоузлового развёртывания по умолчанию небезопасна и её нужно защищать, размещая узлы в изолированной сети, а также что опция API-ключа защищает только эндпоинты с определёнными префиксами пути, тогда как у других чувствительных эндпоинтов на том же сервере аутентификации нет. Файл модели тоже относится к цепочке поставок: документация Python предупреждает, что модуль pickle небезопасен и что вредоносные данные pickle могут выполнить произвольный код при десериализации (unpickling), поэтому формат safetensors, созданный, в отличие от pickle, для безопасного хранения тензоров, — более безопасный выбор для весов.

Что компания теперь эксплуатирует сама:

• Мощности ускорителей, рассчитанные на пиковый объём, купленные или зарезервированные заранее, до появления спроса, с запасом на отказ узла
• Драйверы, движок сервинга и операционная система, которые патчатся по графику, допустимому одновременно с точки зрения безопасности и оценок на приёмочном наборе
• Сетевая изоляция, аутентификация перед сервером модели и логи доступа, которые может прочитать аудитор
• Обновления моделей: более новая модель с открытыми весами попадает в прод, только когда кто-то оценит её на ваших документах и выпустит
• Дежурства по серверу модели, потому что его не покрывает ни одна статусная страница провайдера

Доказательства соответствия: что запрашивает аудитор в каждом варианте

Обязательства по GDPR, а также по ISO/IEC 27001, если компания сертифицирована по этому стандарту, остаются обязательствами самой компании, какой бы вариант она ни выбрала, даже когда провайдер выступает её обработчиком. Меняется то, откуда берутся доказательства:

• API провайдера: условия обработки данных у провайдера, согласования средств управления хранением и резидентностью, его субобработчики, а для финансовой организации, подпадающей под DORA, — запись об этом соглашении в реестре
• Управляемый сервис моделей: тип развёртывания и регион каждого развёртывания модели, конфигурация приватного эндпоинта, любое согласованное изменение мониторинга злоупотреблений, а также то, входит ли новый сервис в охват уже имеющихся у облака аудиторских отчётов (assurance reports)
• Модель на своей инфраструктуре: ваши собственные доказательства по серверу модели и всему, что вокруг него, — от сетевой изоляции и логов доступа до лицензии каждой модели и происхождения каждого файла весов в проде, плюс уже действующее соглашение с облаком, если серверы — виртуальные машины в облачном аккаунте

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

Задержка и пропускная способность: общие мощности или собственные

На общих мощностях потолок пропускной способности задаёт чужая политика. OpenAI применяет лимиты запросов (rate limits), которые измеряются в запросах и токенах в минуту и в сутки. По мере роста расходов организации OpenAI автоматически переводит её на более высокий уровень использования (usage tier), что обычно повышает эти лимиты, и может замедлять трафик, который растёт слишком быстро, даже в их пределах. Microsoft указывает, что её provisioned-типы развёртывания обеспечивают гарантированную пропускную способность и меньший разброс задержки, тогда как standard-типы работают по принципу best-effort.

У зарезервированных мощностей свои условия. Amazon Bedrock Provisioned Throughput можно купить без обязательств либо на срок в один или шесть месяцев, в течение которого его нельзя удалить. Microsoft отмечает, что ни квота PTU, ни резервирование не гарантируют наличия мощностей в регионе и что удаление или уменьшение provisioned-развёртывания освобождает его мощности без гарантии, что те же мощности будут доступны позже. OpenAI направляет корпоративных клиентов, чей трафик регулярно упирается в лимиты скорости наращивания (ramp-rate limits), к Scale Tier или, для GPT-5.6 и более поздних моделей, к Reserved Tier — ради более предсказуемых мощностей.

Работе, которую никто не ждёт, эти мощности не нужны. Batch API от OpenAI обрабатывает асинхронные запросы на 50% дешевле со сроком выполнения 24 часа, хотя, согласно странице OpenAI о данных, эндпоинты batch и file не подпадают под Zero Data Retention, а их данные хранятся до удаления. В Azure есть пакетные типы развёртывания со скидкой 50%: Global Batch может обрабатывать данные в любой географии, где развёрнута модель, а Data Zone Batch направляет трафик только в дата-центры в пределах зоны данных.

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

Люди: кто дежурит в каждом варианте

Варианты различаются перечнем работы, которая остаётся внутри компании:

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

Пилот может месяцами работать без дежурств; прод — не может. Считать стоимость варианта с моделью на своей инфраструктуре без людей, которые её эксплуатируют, — значит сравнивать себестоимость модели с ценой сервиса.

Сочетание вариантов — это правило маршрутизации, и сложнее всего именно правило

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

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

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

Компания, которая строит это внутри вашего периметра, сначала спрашивает о периметре

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

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

Компания, которая рекомендует модель, не задав этих вопросов, уже выбрала за вас периметр, не сказав об этом.

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

Что amBrain может подтвердить публично помимо интеграции в проде, описанной в кратком ответе выше: amBrain пишет софт с 2019 года. Мы работаем в трёх форматах: полная разработка, выделенная команда или наши инженеры в вашей команде.