День, когда зарубежная модель перестаёт отвечать, наступает по чужому решению, а его цена для компании определяется тем, что было сделано заранее: неделя перенастройки или месяцы переписывания системы, пока люди вручную делают работу, которую она делала. Зависимость от зарубежных моделей — это ситуация, когда рабочий процесс компании держится на сервисе, условия которого вы не контролируете: оплату, юрисдикцию обработки данных, само обслуживание. Ниже — какие виды зависимости бывают, какая страховка стоит несколько дней работы, что закрыть договором и когда страховка не нужна вовсе.
Зависимость от зарубежных моделей бывает трёх видов, и по-настоящему опасен один
Зависимость от конкретной модели. Промпты настроены под её поведение, качество проверено на ней. Переключение потребует перенастройки — это неприятно, но измеримо: обычно недели работы.
Зависимость от API конкретного поставщика. Вызовы разбросаны по коду, форматы ответов зашиты в логику. Здесь переезд превращается в переписывание — и это уже месяцы.
Зависимость от возможностей, которых нет у альтернатив. Самая опасная. Если система построена вокруг функции, которую даёт только один поставщик, аналога может просто не быть, и переключаться будет некуда.
Что это значит на практике. Для российской компании риск не абстрактный: OpenAI, Anthropic и Google не включают Россию в список стран, где доступны их API, поэтому к их моделям обычно подключаются через посредников, и любое звено этой цепочки может измениться без вашего участия. Открытые модели, развёрнутые в собственном контуре, — отдельный случай: у них нет поставщика, который может отключить доступ. Первые два вида зависимости при этом лечатся инженерной работой, третий — только выбором архитектуры до начала проекта.
Вердикт: спрашивать стоит не «на какой модели работает система», а «куда она переедет и за сколько».
Один внутренний интерфейс снимает самую дорогую зависимость за несколько дней
Базовое инженерное решение занимает несколько дней и снимает вторую зависимость целиком. Все обращения к модели идут через один внутренний интерфейс: остальной код не знает, кто отвечает за ним.
Что должно быть внутри этого слоя: сам вызов, приведение ответа к единому формату, обработка ошибок и повторов, учёт расхода. Смена поставщика тогда — это правка в одном месте плюс перенастройка промптов, а не ревизия всего проекта.
Стоит потратить эти дни даже если менять поставщика вы не собираетесь: тот же слой пригодится, когда захочется отправлять разные задачи в разные модели — а почему руководителю в этот момент важнее путь поручения, чем имя модели, описано в статье про агента-координатора.
Вердикт: если смена поставщика требует поиска по всему коду, зависимость уже не от модели, а от собственной архитектуры.
План переключения готовят до отключения, а не в его день
- Вторая модель выбрана и проверена. Не «есть варианты на рынке», а конкретная альтернатива, на которой прогнан ваш эталонный набор. Вы должны знать, насколько просядет качество: на два процента или на двадцать.
- Промпты для неё подготовлены. Формулировки, работающие на одной модели, не всегда переносятся на другую один в один. Держите второй комплект.
- Переключение сделано настройкой, а не выкладкой кода. В момент отключения не должно требоваться участия разработчика.
- Известно, что деградирует в первую очередь. Обычно это сложные случаи и длинные документы. Значит, на период переключения по ним усиливается человеческий контроль.
Эталонный набор здесь — главный актив. Это несколько десятков реальных примеров из работы компании с правильными ответами, на которых сравниваются модели. Как его собрать за неделю, разобрано в статье о бенчмарках нейросетей; для плана переключения он нужен по той же причине: без него «просядет ли качество» остаётся мнением.
Вердикт: план переключения, который ни разу не прогоняли, — это описание надежды.
Поставщика модели выбирают по оплате и юрисдикции не меньше, чем по качеству
Помимо качества и цены — три вопроса, которые задают редко, а стоят они дорого.
Способ оплаты. Валютные платежи усложняют жизнь даже при работающем сервисе: карта не проходит, оплата задерживается, доступ приостанавливается на ровном месте.
Юрисдикция обработки данных. Для части отраслей это не предпочтение, а требование. Проверять нужно до внедрения, а не при первой проверке.
Наличие совместимого интерфейса у альтернатив. Если несколько поставщиков поддерживают один формат вызовов, переключение упрощается кратно. Это техническая деталь, которая на практике решает больше, чем разница в бенчмарках.
Вердикт: лучшая модель, за которую нельзя стабильно заплатить, хуже второй лучшей, за которую можно.
При переключении первым ломается не качество, а формат, контекст и лимиты
Про качество думают все, и оно как раз проверяется просто. Гораздо чаще проект спотыкается о вещи, которые считались техническими деталями.
Формат вывода. Если ваш код рассчитывает получить строгий JSON заданной структуры, а новая модель иногда добавляет пояснение перед ним, ломается разбор ответа, а не смысл. Длина контекста. Промпт, который помещался у одного поставщика, у другого не влезает, и приходится переделывать способ подачи документов. Лимиты. Ограничения на число обращений в минуту у разных поставщиков отличаются в разы, и то, что работало при пиковой нагрузке, начинает упираться в очередь.
Отдельная строка — цена. Она считается не за запрос, а за объём текста, и модель, которая отвечает подробнее, при той же цене за единицу выходит дороже на практике. Это выясняется на первом счёте, если не посчитать заранее на своём реальном потоке. К тому же разные модели по-разному делят русский текст на токены, и одинаковая цена за единицу у двух поставщиков не означает одинаковой цены за один и тот же документ.
Вердикт: переключение проверяют на своём потоке целиком, а не на десяти удачных вопросах.
Запасной вариант стоит денег, и сравнивать их нужно с неделей простоя
Готовность к переключению — не бесплатная страховка, и честный разговор о ней начинается с суммы. Затраты складываются из трёх частей, и все три регулярные.
Первая — разработка и поддержка абстракции над поставщиком: несколько дней на старте и небольшая доля времени при каждом изменении. Вторая — прогон эталонного набора на альтернативе: если делать раз в квартал, это несколько часов работы плюс стоимость самих обращений. Третья — минимальный оплаченный доступ к запасному поставщику, чтобы в нужный момент не оказаться в очереди на регистрацию.
Сравнивать эту сумму нужно не с нулём, а со стоимостью простоя. Посчитайте, во что обойдётся неделя без работающей системы: сколько разговоров останется без разбора, сколько обращений без ответа, сколько людей вернётся к ручной работе. Обычно после такого расчёта вопрос о целесообразности закрывается сам.
Условный пример. AI-агент отвечает на 300 обращений в день. Если он отключился и обращения разбирают операторы по 5 минут на каждое, это 1 500 минут, то есть 25 часов работы в день — больше трёх полных восьмичасовых смен, которых в штате нет. Неделя такого простоя — это либо сверхурочные, либо обращения, оставшиеся без ответа. Цифры условные; подставьте свой поток и время обработки.
Вердикт: страховка дорогая ровно до первого расчёта недели без неё.
Момент переключения записывают заранее, пока нет новостей
Решение о переключении принимается плохо, когда принимается на новостях: обсуждение начинается на эмоциях, аргументы подбираются под уже сложившееся мнение, и любой выбор кажется рискованным.
Условия проще задать заранее, в спокойное время, и записать. Три из них универсальны. Доля ошибок на эталонном наборе выросла и не вернулась после двух попыток настройки. Изменились условия оплаты или обслуживания так, что дальнейшая работа требует отдельного решения. Появился отказ в обслуживании по любой причине, даже разовый.
Четвёртое условие компания задаёт под себя: обычно это цена, выросшая выше заданного порога, или требование поставщика, несовместимое с вашими обязательствами перед клиентами. Записанные заранее, эти условия превращают переключение из спора в выполнение плана.
Вердикт: решение, принятое в день плохих новостей, обычно принимается не по данным, а по заголовкам.
Часть риска дешевле закрыть договором, чем кодом
Часть рисков снимается не инженерно, а на бумаге, и обходится это дешевле любой технической страховки. Четыре пункта стоит обсуждать до подписания, а не после.
Срок уведомления об изменении условий и о прекращении обслуживания: месяц против трёх дней — это разница между плановым переключением и авралом. Порядок вывоза данных: в каком формате и за какой срок вы получаете всё, что накопили, если уходите. Обязательства по доступности и что происходит при их нарушении. И условия по обработке данных: где они хранятся, кто имеет доступ, используются ли для обучения.
Последний пункт часто оказывается решающим не по соображениям риска, а по требованиям ваших собственных клиентов: если вы обещали им, что их данные не покидают периметр, договор с поставщиком должен это подтверждать, а не подразумевать.
Вердикт: обещание «данные не покидают периметр», которого нет в договоре с поставщиком модели, держится на честном слове третьей стороны.
Страховка не нужна, если без модели процесс спокойно переживёт неделю
Всё сказанное выше — работа и деньги, и тратить их имеет смысл не везде. Если отключение модели не остановит ничего, за что платят клиенты, достаточно знать, как поступить в этот день, и не строить запасной контур.
Первый случай — вспомогательные задачи. Черновики писем, пересказ совещаний, подготовка текстов для внутреннего пользования: при отключении люди неделю сделают это сами, и потеря меньше стоимости любой страховки. Второй — пилот или прототип. Пока не подтверждено на данных, что система вообще приносит результат, вкладываться в её переносимость рано; достаточно не зашивать вызовы модели по всему коду, чтобы не переписывать его при переходе в эксплуатацию. Третий — малый поток: если модель обрабатывает десяток документов в день, ручной запасной режим дешевле второго поставщика. Четвёртый — система уже работает на модели, размещённой в вашем контуре или у российского поставщика с договором и оплатой в рублях: основная часть рисков из этой статьи к ней не относится, остаются обычные вопросы доступности.
Я бы в любом из этих случаев ограничился одной страницей: что делаем в день отключения, кто это решает, какие задачи возвращаются людям. Эта страница стоит час работы и закрывает большую часть неопределённости.
Вердикт: страховать стоит процесс, остановка которого стоит денег, а не каждый вызов модели в компании.
Ни «только российское», ни «только лучшее» не работает как стратегия
Две крайние стратегии одинаково плохи. «Используем только российское, чего бы это ни стоило» — теряете в качестве там, где могли бы не терять. «Строим на лучшей модели и не думаем» — принимаете риск, которым не управляете.
Рабочая середина: критичные процессы работают на том, что вы контролируете или можете быстро заменить; экспериментальные и вспомогательные — на лучшем доступном. И между теми и другими — общий слой абстракции, который делает переключение вопросом настройки. Сравнение конкретных вариантов — в статье про российские LLM.
Так устроены и наши продукты: например, в тарифе «Старт» AI-агента Дирижёр работают GigaChat и YandexGPT, а Claude через российский прокси подключается в тарифе «Бизнес» — это видно на странице тарифов. Данные при этом хранятся в России по требованиям 152-ФЗ. Для заказчика смысл простой: основной контур не зависит от того, что решит зарубежный поставщик.
Вердикт: зарубежная модель — хороший инструмент для задач, которые переживут её отключение, и плохой фундамент для тех, что не переживут.
Что посчитать, пока доступ ещё работает
Главное следствие для решения: вопрос «уходить ли с зарубежной модели» ставится неправильно. Правильный вопрос — во что обойдётся неделя без неё и сколько стоит сделать эту неделю короче. Ответ на него зависит от процесса, а не от новостей, и получить его можно в спокойное время.
Проверить свою ситуацию можно за день. Выпишите процессы, где работает модель, и для каждого отметьте: что происходит при её отключении, кто делает эту работу вместо неё и сколько часов в день это займёт. Для процессов, где ответ — «клиенты остаются без ответа», проверьте три вещи: спрятаны ли вызовы за одним интерфейсом, прогонялась ли альтернатива на эталонном наборе, записаны ли условия переключения. Чем российские модели отличаются на практике и где они уже сопоставимы — в сравнении GigaChat и YandexGPT.
