Что произошло
Первые генеративные сценарии в крупных российских компаниях запускались на внешних сервисах: быстро, без оборудования, с демонстрацией через недели. Сейчас та же группа компаний переносит модели внутрь: на собственные серверы или в выделенный сегмент дата-центра, на российские или открытые модели, дообученные на корпоративных данных. Гибридные схемы — локальная модель для чувствительных данных, внешние модели через шлюз для остального — становятся стандартной архитектурой, а не компромиссом.
Первую волну переезда объясняли безопасностью и регуляторикой, и это объяснение верное, но неполное. Вторая волна началась в компаниях, которым регуляторика позволяла оставаться во внешнем облаке, — и переехали они по другой причине: счёт за ИИ стал переменной величиной, которую невозможно запланировать. Тарифы менялись, модели обновлялись без предупреждения, объём рос вместе с успехом внедрения, и операционные расходы компании оказались зависимы от решений другого юридического лица.
Сдвиг, который важно зафиксировать: собственный контур перестал быть «дорогой опцией для банков» и стал инструментом управления бюджетом. Вопрос сместился с «можно ли нам во внешнее облако» на «какая конфигурация даёт предсказуемую стоимость при приемлемом риске».
Как это устроено
Безопасность и регуляторика
Регуляторный слой в России многоуровневый, и каждая отрасль добавляет к базовым требованиям свои. Основание — 152-ФЗ и требования к обработке персональных данных, включая ограничения на трансграничную передачу. Поверх него — банковская тайна для финансового сектора, тайна связи для операторов, врачебная тайна для медицины, коммерческая тайна для всех. Для субъектов критической информационной инфраструктуры — режим КИИ с обязанностью перевода значимых объектов на отечественные решения к 1 января 2028 года.
Практическое следствие: любой запрос к модели — это передача данных. Если в запросе есть персональные данные клиента, содержание договора или внутренний документ, отправка его внешнему сервису — передача третьему лицу со всеми вытекающими обязанностями. Часть данных передавать нельзя в принципе, часть — после обезличивания, часть — свободно. Архитектура контура должна проводить эту границу автоматически, а не полагаться на дисциплину сотрудников.
Второй аспект — доказуемость. Проверяющему нужно показать, какие данные куда уходили, кто имел доступ, как обеспечен контроль. Внешний сервис даёт для этого ограниченные возможности; собственный контур — полный журнал каждого запроса и ответа.
Предсказуемость стоимости
Внешний сервис оплачивается по потреблению, и в этой модели скрыты три источника нестабильности.
Тариф. Цена за единицу устанавливается поставщиком и меняется по его усмотрению. Долгосрочный контракт с фиксацией цены — редкость, и он не защищает от смены модельной линейки.
Модель. Поставщик обновляет модели по своему графику. Новая версия может быть лучше в среднем и хуже на ваших задачах, изменить длину ответов и стоимость, сломать отлаженные промпты. Регресс приходится делать не когда удобно вам, а когда решил поставщик.
Объём. Успешное внедрение растёт: больше сценариев, больше пользователей, длиннее контексты. Статья расходов, незаметная на пилоте, за год вырастает в разы, и рост нелинейный — агентные сценарии с несколькими итерациями потребляют на порядок больше, чем разовые запросы.
Собственный контур переводит эту статью из переменной в управляемую. Оборудование — капитальные затраты с амортизацией. Стоимость инференса определяется загрузкой мощностей, а не тарифом. Обновление модели — ваше решение, после регресса на вашем оценочном наборе. Бюджет на год считается до начала работ и не меняется от чужого пресс-релиза. Это не значит, что контур дешевле в любой ситуации: при малом объёме оборудование простаивает, а люди для его обслуживания стоят столько же. Контур выигрывает там, где объём уже вырос или где чувствительность данных не оставляет выбора.
Четыре конфигурации
На практике встречаются четыре устойчивые схемы. Они различаются тем, какие данные покидают периметр и через что.
| Конфигурация | Что внутри | Что снаружи | Для кого | Главный риск |
|---|---|---|---|---|
| Облако напрямую | Ничего | Все запросы и данные | Пилоты на обезличенных данных | Передача данных третьему лицу, переменная стоимость, смена модели без вашего ведома |
| Облако через шлюз маскирования | Шлюз: обнаружение и замена ПДн, журнал, лимиты | Обезличенные запросы | Компании с ПДн в запросах, но без требований к автономности | Ошибки маскирования, остаточная чувствительность контекста |
| Гибрид | Локальная модель для чувствительных данных, шлюз-маршрутизатор | Нечувствительные запросы через шлюз | Средний и крупный бизнес с частью чувствительных сценариев | Сложность правил маршрутизации, две модели с разным поведением |
| Автономный контур | Все модели, инференс, дообучение, хранилища | Ничего | Финансы, КИИ, госсектор, компании с жёсткой политикой | Стоимость оборудования и людей, отставание моделей |
Между конфигурациями нет «правильной». Есть соответствие классу данных, объёму потребления и регуляторному режиму. Компания может начать со шлюза, перейти к гибриду по мере роста объёма и закончить автономным контуром, когда добавятся сценарии на чувствительных данных, — при одном условии, о котором ниже.
Принцип: среда не должна знать, какая модель отвечает
Это условие определяет, будет ли переход между конфигурациями изменением настроек или новым проектом.
Все сценарии — ассистенты, разбор документов, агенты — обращаются не к конкретной модели, а к единой внутренней точке доступа. За ней стоит маршрутизатор, который по классу данных, типу задачи и политике решает, куда направить запрос: в локальную модель, во внешнюю через маскирование или отклонить. Маршрутизатор ведёт журнал, применяет лимиты, считает стоимость, собирает метрики качества. Приложения не знают и не должны знать, что отвечает за ним.
Что это даёт. Замена внешней модели на локальную — правило в маршрутизаторе плюс регресс на оценочном наборе, без изменения приложений. Добавление нового класса данных — новое правило. Смена поставщика — новый адаптер за той же точкой доступа. Отказ внешнего сервиса — переключение на резервный маршрут. Компания, которая построила сценарии напрямую на API одного поставщика, при любом из этих событий переписывает интеграции; компания с маршрутизатором меняет конфигурацию.
Второе следствие — экономическое. Единая точка доступа считает стоимость по каждому сценарию и подразделению независимо от того, где выполнен запрос. Без неё стоимость ИИ размазана по счетам разных поставщиков и внутренним серверам, и ответить на вопрос «сколько стоит наш ИИ» невозможно.
Стоимость владения на год
Сравнивать конфигурации нужно по полной стоимости владения на горизонте года, а не по цене запроса.
| Статья | Внешний сервис | Собственный контур | Гибрид |
|---|---|---|---|
| Оборудование | Нет | Серверы с ускорителями, сеть, хранилище: капитальные затраты с амортизацией | Меньший объём под чувствительные сценарии |
| Размещение и энергия | Включено в тариф | ЦОД или собственная площадка, электропитание, охлаждение | Пропорционально объёму |
| Инференс | Тариф за единицу, переменная | Загрузка мощностей, фиксированная при известном объёме | Локальная часть фиксирована, внешняя переменная |
| Модели и лицензии | Включено в тариф | Открытые или российские модели, лицензии на коммерческое использование | То же плюс внешний тариф |
| Дообучение | Ограничено или недоступно | Разовые затраты на данные и вычисления, повторяются при обновлении | По необходимости для локальной части |
| Шлюз и маршрутизатор | Не нужен или минимальный | Нужен для управления и учёта | Ключевой компонент: маскирование, маршрутизация, учёт |
| Мониторинг и регресс | На вашей стороне, реактивно | На вашей стороне, по своему графику | На вашей стороне, для обеих частей |
| Люди | Разработчики сценариев | Плюс инженеры инфраструктуры и эксплуатации моделей | Плюс инженеры, меньшим числом |
| Риск изменения стоимости | Высокий, вне вашего контроля | Низкий, зависит от объёма | Средний, ограничен внешней частью |
В таблице нет цифр намеренно: они зависят от объёма, класса оборудования и зарплат в регионе. Но структура показывает, откуда берётся предсказуемость: в собственном контуре почти все статьи либо капитальные, либо фиксированные операционные, а во внешнем сервисе главная статья — переменная и управляется не вами.
Как это выглядит на практике
Банк из первой сотни. Регуляторные требования исключали внешние сервисы для любых данных, связанных с клиентами. Выбор — автономный контур: российские модели, дообучение на внутренних документах, векторное хранилище для поиска по регламентам, инференс на vLLM внутри периметра. Бюджет на год был посчитан до старта и не менялся. Главным результатом стала возможность добавлять сценарии без нового цикла согласований: контур аттестован один раз, а каждый следующий сценарий — конфигурация внутри него.
Производственный холдинг. Чувствительными были данные о производстве, поставщиках и ценах; маркетинговые материалы и общие вопросы — нет. Выбор — гибрид: локальная модель умеренного размера для документов и производственных данных, внешние модели через шлюз маскирования для черновиков, переводов и справок. Через год холдинг перевёл ещё два сценария на локальную модель — правилом в маршрутизаторе, без изменения приложений.
Компания среднего размера. Начала с внешнего сервиса напрямую. За полгода счёт вырос в разы: сценарии тиражировались, появились агентные цепочки. Затем поставщик заменил модель, и отлаженный разбор документов начал давать другой формат ответов, что сломало интеграцию. Переезд занял квартал: единая точка доступа, шлюз маскирования, затем локальная модель для сценария с персональными данными. Внешний сервис остался для части задач, но за шлюзом и с лимитами.
Что это значит для российской компании
Для российской компании вопрос контура редко бывает вопросом выбора: регуляторный режим отрасли задаёт минимальную конфигурацию. Финансовый сектор, госсектор, субъекты КИИ фактически начинают с автономного контура или гибрида с жёстко ограниченной внешней частью. Остальные могут начинать со шлюза, но должны закладывать переход к гибриду в архитектуру с первого дня.
Отечественный стек делает автономный контур реалистичным. Российские модели и открытые модели с коммерческой лицензией закрывают большинство корпоративных сценариев после дообучения на своих данных. Инференс на vLLM, векторные хранилища вроде Qdrant, PostgreSQL для метаданных, Kafka для потоков — всё это разворачивается внутри периметра без внешних зависимостей.
Кадры — реальное ограничение. Автономный контур требует инженеров, умеющих эксплуатировать модели: развёртывание, мониторинг, регресс, дообучение. Таких специалистов мало, и их стоимость — существенная статья владения. Для компаний без внутренней команды разумная модель — подрядчик строит контур и передаёт эксплуатацию с документацией и обучением, оставляя код, права и данные у заказчика. Контур, который может обслуживать только тот, кто его построил, — это зависимость, сменившая форму.
Единая точка доступа к моделям — единственный компонент архитектуры, который нельзя отложить «на потом»: без неё каждая смена конфигурации становится проектом.
Что делать: пошагово
- Классифицируйте данные, которые попадают в запросы. Три класса минимум: нельзя передавать за периметр, можно после обезличивания, можно свободно. Для каждого сценария определите класс его входов и контекста.
- Зафиксируйте регуляторный минимум конфигурации. По отрасли и статусу компании определите, какая из четырёх схем допустима как нижняя граница. Всё, что ниже, не рассматривается.
- Оцените объём потребления на год. Число сценариев, пользователей, запросов, средняя длина контекста, доля агентных цепочек. Недооценка в разы типична: считайте с учётом роста после успешного пилота.
- Посчитайте стоимость владения для допустимых конфигураций. По таблице статей, на год, с учётом людей. Сравнивайте не цену запроса, а годовой бюджет и его волатильность.
- Постройте единую точку доступа до первого сценария. Маршрутизатор, журнал, лимиты, учёт стоимости по сценариям и подразделениям. Даже если первое время за ним стоит один внешний сервис.
- Соберите оценочный набор для регресса. Запросы и эталонные ответы по каждому сценарию. Он нужен для любой смены модели — внешней, локальной, версии.
- Запускайте сценарии через точку доступа и ведите учёт. Через квартал у вас будет фактический объём и стоимость по сценариям — основание для решения о переходе к следующей конфигурации.
- Планируйте переход как изменение правил, а не как проект. Локальная модель добавляется за точкой доступа, проходит регресс, получает правило маршрутизации. Приложения не меняются.
Типичные ошибки
- Строить сценарии напрямую на API одного поставщика. Смена модели, тарифа или поставщика превращается в переписывание интеграций. Вместо этого — единая точка доступа с первого дня.
- Выбирать конфигурацию по цене запроса. Цена запроса не учитывает людей, оборудование и волатильность; на годовом горизонте картина может быть обратной. Вместо этого — стоимость владения на год по статьям.
- Считать шлюз маскирования полной защитой. Маскирование ловит формальные ПДн, но не контекст: договор без фамилий всё ещё раскрывает условия сделки. Вместо этого — классификация по содержанию и локальная модель для чувствительных классов.
- Строить автономный контур при малом объёме. Оборудование простаивает, люди стоят столько же, стоимость операции получается выше внешней. Вместо этого — гибрид с малой локальной частью и рост по факту объёма.
Как понять, что вы на верном пути
- Данные в запросах классифицированы, и для каждого класса определён допустимый маршрут.
- Все сценарии обращаются к единой внутренней точке доступа, ни один — напрямую к внешнему API.
- Стоимость ИИ известна по сценариям и подразделениям и совпадает со счетами.
- Бюджет на год посчитан по статьям владения, и его волатильность оценена.
- Оценочный набор существует, и ни одно обновление модели не проходит без регресса.
- Переход к следующей конфигурации описан как изменение правил маршрутизации, а не как проект.
- Есть люди, способные эксплуатировать контур без подрядчика, или план их подготовки.
- Журнал запросов позволяет ответить проверяющему, какие данные куда уходили.
Вопросы, которые нам задают
Локальные модели отстают от внешних. Не потеряем ли мы в качестве, уходя в контур? На универсальных тестах — отстают. На узкой корпоративной задаче после дообучения на ваших данных разрыв обычно небольшой, а иногда локальная модель выигрывает: она видела ваши документы, а внешняя — нет. Проверяется это одним способом — оценочным набором на вашей задаче, а не рейтингами.
Мы средняя компания без регуляторных ограничений. Нам вообще нужен контур? Полный автономный контур, скорее всего, нет. Единая точка доступа и шлюз маскирования — да, с первого дня: они дают учёт стоимости, защиту от смены модели и возможность добавить локальную модель, когда объём или чувствительность данных этого потребуют. Гибрид для среднего бизнеса — типовая целевая конфигурация.
Сколько нужно оборудования для автономного контура? Зависит от объёма и размера моделей, и ответ без расчёта нагрузки будет неверным. Порядок действий: оценка объёма на год, выбор моделей под сценарии, нагрузочное испытание на арендованных мощностях, затем закупка с запасом на рост. Покупка «на глаз» приводит либо к простою, либо к очередям.
Начните с инвентаризации: какие сценарии сегодня обращаются к моделям, к каким, с какими данными и сколько это стоит по каждому. Если на какой-то из вопросов ответить невозможно, первый шаг — не выбор конфигурации, а единая точка доступа, которая сделает ответы возможными.