Claude отключили на 18 дней по решению властей США. Что делать бизнесу, чей процесс держится на одной ИИ-модели

В середине июня Anthropic на 18 дней закрыла доступ к своим новым флагманам, Fable 5 и Mythos 5. Не из-за аварии и не из-за неоплаченного счёта: доступ распорядилось закрыть правительство США, опасаясь, что модели способны находить критические уязвимости в чужом коде. Модели вышли за несколько дней до этого, в прод их мало кто успел поставить, и Opus с Sonnet всё это время работали. К началу июля доступ вернули. Компенсаций за простой не было — в пользовательских соглашениях такой сценарий даже не описан.

Реального массового простоя это не вызвало. Но важен не масштаб, а механизм: доступ к работающей модели закрыли не санкции и не сбой, а решение чужого правительства — глобально и без предупреждения. Если у вас на одной модели держится бот поддержки, разбор входящих документов или контент-конвейер, этот разбор про то, какой у такой конструкции реальный риск и что в ней менять.

За июнь–июль выключатель дёргали трижды, и каждый раз — разные руки.

Государство провайдера. История с Claude: 18 дней глобального отключения по требованию властей США. Лояльность юрисдикции не спасла — под отключение попали и американские компании.

Государство, где работает бизнес. С 15 июля в Китае действует правило о человекоподобных ИИ-сервисах. Оно бьёт по эмоциональным агентам-компаньонам и ботам-персонажам. ByteDance и Alibaba спорить не стали и за ночь отключили пользовательских агентов в Doubao и Qwen: люди потеряли своих ботов и историю переписок, у Qwen без миграции и возврата. Механизм показан: регулятор в вашей юрисдикции способен обнулить целый класс агентов одним решением. Построившие на них процессы получают уведомление, а не выбор.

Сам провайдер. Самый частый и будничный случай — тарифы и лимиты. Неделю назад я разбирал переход GitHub Copilot на оплату за токены: у части команд расчётный месячный счёт вырос с $29 до сотен долларов при том же объёме работы. Сюда же исчезновение моделей из бесплатных тиров и снятие моделей с поддержки: у крупных провайдеров это плановый процесс с горизонтом в месяцы.

Всё это не довод отказываться от ИИ, как риск единственного поставщика — не довод закрывать склад. Это довод считать привязку к провайдеру операционным риском, таким же, как единственный поставщик товара или сервер без бэкапа.

Под новостью об отключении на Hacker News разошлись во мнениях. Одни считали миграцию на другую LLM «работой на один вечер»: почти все провайдеры совместимы с API OpenAI. Другие возражали точнее: сменить эндпоинт — вечер, сохранить качество — нет.

Практика на стороне вторых. Промпты, отлаженные под одну модель, на другой ведут себя иначе: другая манера следовать инструкциям, другая устойчивость в вызове инструментов, другие слабые места. Разработчики LiteLLM, популярнейшей библиотеки-прослойки, до сих пор чинят многошаговые вызовы инструментов для Gemini, а под модели Kimi держат жёстко прописанные правила совместимости. Совместимость на уровне протокола есть. Совместимости на уровне поведения — нет.

Опаснее всего, что деградация тихая. Ошибку 500 видно в логах сразу. Резервную модель, которая стала на 15% чаще путать поля в заявках, в логах не видно — она проявится в жалобах клиентов через две недели.

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

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

Я собрал такой слой для собственных проектов, библиотека llm-rotator (открытый код, MIT). Задача у неё одна: запрос обязан дойти до ответа. Провайдер ответил 429 («лимит») — эта связка ключа и модели блокируется ровно на время из заголовка Retry-After, запрос уходит на следующий ключ. Ключ умер (401) — исключается насовсем. Провайдер лёг (5xx) — один быстрый повтор и переход к следующему кандидату. Ротация идёт «сверху вниз» по качеству: сначала все ключи сильной модели, только потом модель попроще. А простые задачи можно принудительно держать на дешёвых моделях, чтобы они не выедали лимиты сильных. Инженерные детали я разбирал в статье про агентный харнес; здесь важнее вывод для бизнеса.

Вывод такой: страховка от «провайдер лёг» и «провайдер ограничил» стоит один слой абстракции, и это давно не эксклюзивная инженерия. Mozilla.ai в июле выпустила Otari — открытый «пульт управления» LLM-инфраструктурой: маршрутизация между 40+ провайдерами, бюджеты, отказоустойчивость. Есть и коммерческие шлюзы вроде OpenRouter.

Две оговорки, обе важные.

Роутер решает доступность, не качество. Резервная модель отвечает по-другому — см. предыдущий раздел. Без прогонов на своих задачах об этом узнают клиенты раньше вас.

Шлюз сам становится зависимостью. Коммерческий посредник — ещё одна компания, которая может изменить условия, и ещё один узел, через который идут ваши данные. Открытый код (Otari, свой слой) этот риск снимает, а коммерческий сервис переносит его на другой этаж.

Год назад запасной маршрут через открытую модель означал заметную потерю качества. Июнь–июль 2026 показали, насколько всё сдвинулось — по иронии, ровно в те недели, когда закрытые модели отключали.

Zhipu выложила GLM-5.2 (открытые веса, MIT): на публичных бенчмарках кодинга она обгоняет GPT-5.5 и идёт почти вровень с Claude Opus 4.8 в вызове инструментов, при цене примерно в шесть раз ниже. Tencent выложила Hy3 (295 млрд параметров, Apache 2.0), тоже на уровне флагманов в агентском поиске и работе с инструментами. Meituan открыла LongCat-2.0 на 1,6 трлн параметров (MIT), обученную без единого чипа Nvidia, на собственном железе. Сбер выпустил GigaChat 3.5 Ultra с открытыми весами. А Moonshot представила Kimi K3 (2,8 трлн параметров, местами на уровне Fable 5) — веса обещают выложить в конце июля. Открытую модель нельзя отключить извне: веса лежат у вас, лицензия не отзывается задним числом.

Подключить открытую модель можно тремя способами, по нарастанию сложности.

Через API-провайдеров открытых моделей (Together, Groq, российские облака). Дёшево — открытые модели по API стоят в разы меньше флагманов. Риск отключения конкретного сервиса остаётся, но исчезает риск потерять модель: те же веса поднимает любой другой провайдер, поведение модели не меняется, промпты остаются рабочими.

На арендованном GPU. Мой вариант для экспериментов, лаборатория на RunPod: окружение разворачивается скриптами за минуты, под гасится, когда не нужен. По железу ориентиры такие: модели класса Mistral 7B хватает одной RTX 4090, модели класса 70B нужны уже 4×H100 — это другой порядок бюджета.

На своём железе. Самый дорогой и самый независимый вариант. Про экономику скажу прямо, потому что «хостите открытую модель, это же бесплатно» — самая дорогая фраза в этой теме. При расходах на API до ~$50 в месяц свой хостинг не окупится никогда. Скрытые издержки (настройка, мониторинг, обновления) добавляют 20–40% к цене железа, в продакшене с резервированием больше. Квантизация (сжатие модели под доступную память) срезает 5–10% качества. Свой контур заводят ради независимости и контроля данных; экономия появляется позже, на больших объёмах.

Для российского бизнеса у этой истории есть слой, который перевешивает остальные. Обновлённый 152-ФЗ запрещает передавать персональные данные граждан РФ в иностранные облачные сервисы и LLM. А имена, телефоны и паспортные данные из заявок, счетов и претензий под определение ПДн попадают. Роскомнадзор с сентября 2025-го вправе дистанционно сканировать сайты и политики обработки. Штраф для юрлица 150–300 тыс. ₽, повторное нарушение — до 500 тыс., об утечке нужно уведомить в течение 24 часов.

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

Рабочих схем две. Первая — маскирование до отправки: DLP-слой вырезает из текста персональные данные (ФИО, номера, реквизиты) и подменяет их плейсхолдерами, наружу уходит обезличенный текст. Вторая — суверенный контур: обработка ПДн на российской модели (GigaChat, YandexGPT) или на открытой модели на российском хостинге, а внешние флагманы остаются для задач без персональных данных.

Это и есть самый практичный итог всей архитектуры: не тотальный переезд на свои GPU, а маршрутизация по типу задачи.

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

Резервный провайдер — это дорого?
Сам по себе нет: второй API-ключ бесплатен, платите за фактические запросы. Реальная цена — время на проверку, что резервная модель приемлемо решает ваши задачи. Ориентир: день на сбор проверочного набора, дальше он переиспользуется при каждой смене модели.

Открытые модели правда не хуже закрытых?
В прикладных задачах (классификация, извлечение данных, типовые ответы, вызов инструментов) разрыв сжался до единиц процентов; GLM-5.2 и Hy3 тому примеры. В сложных многошаговых рассуждениях флагманы впереди. Ответ для вашего случая дают прогоны на ваших задачах, а не чужие бенчмарки.

Обязательно ли покупать GPU, чтобы уйти от зависимости?
Нет. Большинству хватает связки «роутер + открытая модель через API-провайдера»: раз веса открыты, сервис заменяем. Своё железо оправдано при стабильных больших объёмах либо когда данные нельзя выпускать из контура — тогда это требование, а не оптимизация.

Мы уже отправляем заявки клиентов в зарубежный API. Что делать в первую очередь?
Разделить поток. Персональные данные — либо маскировать до отправки (DLP-слой), либо увести на российскую или локальную модель. Остальные задачи могут остаться где были. Это точечная доработка конвейера, а не переписывание системы.

Ловили ли вы отключения, лимиты или тихую деградацию — и как устроен ваш запасной путь: второй провайдер, открытая модель или осознанное «принимаем риск»? Расскажите в комментариях, особенно если ваша схема сложнее моей.

Разборы таких архитектур с кодом и цифрами регулярно выкладываю в Telegram-канале: @dmitra_ai.