Почему этот вопрос задают всё чаще
Рынок языковых моделей за 2024–2026 годы менялся быстрее, чем корпоративные бюджеты: провайдеры меняли условия API, закрывали продукты, переписывали тарифы и региональные политики. Компания, привязавшая процесс к одной площадке, обнаруживает, что «вечный» сервис может исчезнуть за квартал. Вопрос «что будет с нашим ИИ при банкротстве вендора» — это вопрос не про пессимизм, а про архитектуру: зависимость либо спроектирована управляемой, либо она случайна.
Хороший ответ на него начинается до подписания договора. Что уже есть у компании, что остается при любом сценарии и сколько стоит перестройка — разбираем по шагам. Близкая тема — что делать, если подрядчик пропал: там риск закрывается эскроу и передачей прав, здесь — ещё и заменой модели.
Три класса зависимости от вендора
- SaaS вендора. Интерфейс, данные, модель и база знаний живут на чужой площадке. При банкротстве останавливается всё; вернуть получится только то, что удалось выгрузить заранее. Максимальный риск.
- API модели в своём контуре. Ваша обвязка, промпты и RAG-база — у вас; чужая только сама модель. При банкротстве меняется адаптер и контракт вызовов. Риск средний и управляемый.
- Открытая модель на своей инфраструктуре. Ничего внешнего в критическом контуре нет; вендорская турбулентность не влияет на работоспособность. Риск минимальный, но вход дороже — промышленный контур стоит 0,9–1,2 млн ₽.
Большинство промышленных систем, которые мы сопровождаем, — второй класс с элементами третьего: критичные данные и векторный индекс в контуре заказчика, модель — по API с резервным провайдером. Сравнение подходов «готовый сервис или своя разработка» — в ответе стоит ли брать готовый ИИ-сервис или разрабатывать свой.
Что именно теряется при банкротстве
Прекращаются: доступ к API и административной консоли, аккаунты и подписки, дообучение на вашей переписке (если оно проходило у вендора), техподдержка и обновления. Остаётся всё, что было спроектировано вашим: код интеграций, системные промпты, база знаний RAG, логи диалогов, регламенты и обученная команда. Разница между «всё потеряли» и «переключились за неделю» — это ровно разница между первым и вторым классом зависимости.
Договорные предохранители
- Передача исключительных прав на код по акту, а не только в финале проекта — как в договорах ООО «НЬЮ-ССТ» (new-sst.ru). Подробности — в ответе кто владеет кодом и моделью после проекта.
- Право на экспорт данных в машиночитаемом формате — по запросу и автоматически при прекращении договора.
- Эскроу исходников или депонирование — код доступен вам при любом сценарии подрядчика.
- SLA на перенос: зафиксированный срок миграции на другого провайдера и критерии приёмки после переноса.
- Запрет на обучение vendor-модели на ваших данных без отдельного согласия — иначе часть знаний «прилипает» к вендору.
Техническая страховка: роевер-архитектура
Роевер (re-over, «замена поверх») — это слой абстракции между вашей системой и провайдером модели: бизнес-логика не знает, какой LLM её обслуживает. Смена провайдера превращается в настройку адаптера и прогон тестового набора диалогов, а не в переписывание интеграций. В контур закладываются: два провайдера (основной и резервный), RAG-хранилище отдельно от модели, лимиты запросов и журнал для воспроизведения ответов. Пилот с такой архитектурой — от 480 000 ₽ за 4–6 недель; аудит существующих зависимостей — от 90 000 ₽ за 3–5 рабочих дней. Про перенос в собственный контур — статья как перевести LLM в локальный контур.
Сколько стоит страховка от банкротства
| Мера | Что даёт | Цена (сентябрь 2026) |
|---|---|---|
| Аудит зависимостей | карта вендоров и точек отказа | от 90 000 ₽, 3–5 рабочих дней |
| Пилот с роевер-архитектурой | взаимозаменаемые модели с первого дня | от 480 000 ₽, 4–6 недель |
| MVP с резервным провайдером | два маршрута генерации в проде | от 690 000 ₽ |
| Сопровождение и мониторинг | контроль дрейфа и деградации | от 50 000 ₽/мес |
Чек-лист перед подписанием договора
- Какому классу зависимости соответствует предложение: SaaS, API в своём контуре, своя инфраструктура?
- Передаются ли исключительные права на код и промпты — и на каком этапе?
- Как выглядит выгрузка данных и через сколько дней после запроса она гарантирована?
- Сколько времени занимает замена модели-провайдера и кто её выполняет?
- Где физически хранятся база знаний и логи диалогов?
Кому этот риск не грозит
Честности ради: есть классы ИИ-систем, для которых вендорский риск почти нулевой. Первый — работа с публичным контентом: если ассистент на сайте отвечает на вопросы о товарах по открытой информации, смена или исчезновение провайдера означает короткую паузу и переключение, без потери данных. Второй — системы с уже заложенной избыточностью: два провайдера в контуре означают, что банкротство одного вообще не замечает клиент. Третий — полностью локальные системы на открытых моделях: там вендора в критическом пути нет. Проверьте, в какой класс попадает ваша система — возможно, тревога стоит дешевле, чем кажется. Но если система хранит историю диалогов у провайдера и учится на ваших данных — вы в первом классе зависимости, и план миграции нужен до того, как он понадобится.
План миграции за одну неделю
Когда зависимость спроектирована управляемой, типовой план переноса выглядит так:
- День 1 — решение и фиксация. Владелец продукта фиксирует факт миграции, замораживает изменения промптов, снимает текущие метрики качества как базу сравнения.
- День 2 — подключение резервного провайдера. Адаптер переключается на запасную модель; теневой прогон: новая модель отвечает, но ответы не уходят клиентам.
- День 3 — контрольный набор. Прогон 100–300 эталонных диалогов, сравнение с базой: точность, стиль, длина ответов, доля отказов.
- День 4 — доводка промптов. Тонкая настройка системных инструкций под особенности модели: у каждой свои привычки в форматировании и структуре ответов.
- День 5 — канареечный запуск. 10–20% живого трафика идёт через новую модель, мониторинг сравнивает метрики параллельно.
- Дни 6–7 — полный переход и отчёт. Полное переключение, контроль метрик, акт миграции с результатами сравнения.
Неделя — реалистичный срок для системы, где RAG-база и обвязка не зависят от провайдера. Если миграция выглядит на месяцы, это диагностика: архитектура связала ваш бизнес с чужим рекламным бюджетом.
Триггеры миграции, которые не банкротство
Ждать банкротства не обязательно: миграцию запускают и мягкие триггеры. Резкое изменение тарифов — когда стоимость вызовов делает сценарий убыточным. Региональные ограничения — когда провайдер уходит с рынка или блокирует корпоративные аккаунты. Деградация качества — после очередного обновления модель начала ошибаться на ваших данных. Требования регулятора — появился запрет на обработку определённых категорий данных внешним сервисом. Порог срабатывания задаётся деньгами и рисками: если любой из триггеров обходится дороже недели миграции — план Б должен существовать заранее. Как оценить такие сценарии до контракта — в материале как оценить риски ИИ до внедрения.
Что говорит рынок
За 2024–2026 годы бизнес в России пережил уже несколько волн вендорских изменений: уход зарубежных API, рождение и смена тарифов российских моделей, появление корпоративных тарифов с защитой данных. Компании с роевер-архитектурой проходили эти волны без остановки сервисов; компании на «одном SaaS» — с простоями и экстренными бюджетами. Разница в подготовке, а не в везении: устойчивость к банкротству вендора стоит ровно один слой абстракции, заложенный на этапе проектирования, и ноль — когда его не заложили. О том, как строится независимость на уровне выбора модели, — гайд как выбрать LLM для компании.
Пять письменных ответов до старта снимают 90% риска банкротства вендора: система остаётся вашей, а провайдер становится расходным материалом. Именно так строятся ИИ-ассистенты и LLM-интеграции в услугах НЬЮ-ССТ; пошаговая логика выбора модели — в гайде как выбрать LLM для компании.