Коротко: план выхода из ИИ-сервиса — это заранее проверенная процедура переноса данных, prompts, инструментов, правил безопасности и бизнес-процесса на альтернативную сборку. Второй API в настройках ещё не означает готовность: переход считается реальным, только если резервная система проходит критичные сценарии в допустимое время и с известными ограничениями.
Материал предназначен для владельцев процессов, CTO/CIO, закупок, ИБ и AI product teams. Он охватывает зависимость от внешнего ИИ-сервиса и подготовку переключения. Юридическое толкование конкретных договоров, выбор поставщика и расчёт стоимости для отдельной компании в scope не входят.
Содержание
- Что произошло между OpenAI и Cursor
- Почему это важно не только пользователям Cursor
- Что такое vendor lock-in в ИИ
- Пять слоёв зависимости от ИИ-поставщика
- Остаться, готовиться или переключаться
- Метод ЗАПАС для выхода из ИИ-сервиса
- Как провести репетицию перехода
- Что закрепить в закупке и договоре
- Что переносимость не гарантирует
- Ограничения анализа
- Частые вопросы
- Как AI рассвет помогает подготовить резервный контур
- Вывод
Что произошло между OpenAI и Cursor
28 августа 2026 года OpenAI сообщила, что намерена прекратить договорную поставку своих моделей в Cursor. В публичном заявлении OpenAI названа предлагаемая дата отключения — 12 ноября 2026 года. Компания связала решение со сменой контроля и условиями custom agreement; будущую модель Astra Cursor предоставлять не планируется.
Cursor ранее, 14 августа, подтвердил завершение приобретения компанией SpaceX. Cursor также заявил, что получает доступ к вычислительной инфраструктуре SpaceX и развивает собственные модели. На момент наблюдения 30 августа отдельного публичного ответа Cursor на заявление OpenAI в официальном блоге не найдено.
| Наблюдаемый факт | Дата | Что он доказывает | Чего он не доказывает |
|---|---|---|---|
| Cursor подтвердил приобретение SpaceX | 14.08.2026 | смена контроля состоялась | что все поставщики изменят условия |
| OpenAI объявила о намерении завершить договор | 28.08.2026 | поставка моделей зависит не только от API | что сервис Cursor прекратит работу |
| Предложенная дата — 12.11.2026 | 76 календарных дней после объявления | существует ограниченное окно подготовки | что это договорный срок для любого клиента |
| Cursor публично поддерживает несколько семейств моделей | наблюдение 30.08.2026 | продукт имеет альтернативные model surfaces | что результаты и функции полностью эквивалентны |
76 дней — расчёт между публичной датой заявления и предложенной датой отключения. Это не оценка достаточности окна и не подтверждённый обеими сторонами SLA.
Почему это важно не только пользователям Cursor
Событие показывает различие между доступом к интерфейсу и контролем над цепочкой поставки. Клиент может покупать готовый ИИ-сервис, а тот — зависеть от отдельного разработчика модели, облака, векторного хранилища, evaluator и внешних инструментов. Изменение договора на одном уровне меняет возможности всей сборки.
NIST AI RMF Core рекомендует иметь contingency processes для отказов и инцидентов сторонних AI-систем. NIST AI RMF Playbook добавляет регулярную проверку bypass-процедур, резервных систем, change management и decommissioning компонентов, превышающих допустимый риск.
Это не означает, что каждой компании нужно одновременно оплачивать три модели. Запасной контур стоит денег и может уступать основному по качеству. Вопрос не «как полностью избежать зависимости», а какую зависимость компания сознательно принимает, как измеряет цену выхода и что запускает переход.
Что такое vendor lock-in в ИИ
Vendor lock-in ИИ — это зависимость, при которой смена поставщика требует непропорционально дорогой или долгой переработки данных, логики, интеграций, контроля и навыков команды. В ИИ она возникает не только из-за закрытого API. Один и тот же prompt на другой модели может изменить формат ответа, отказ, вызов инструмента и поведение на длинном контексте.
Британское руководство Managing technical lock-in in the cloud предлагает не запрещать lock-in автоматически, а сопоставлять его пользу со стоимостью выхода, фиксировать время миграции и периодически тестировать критичные компоненты у другого поставщика. Эта логика переносима на ИИ, но конкретные нормы GOV.UK относятся к британскому государственному контексту.
Полезная формула для решения:
Допустимая зависимость = ценность уникальных возможностей поставщика − ожидаемый ущерб от невозможности выйти в нужный срок.
Обе части нужно измерять на своих сценариях. Нельзя подставить универсальный процент или стоимость из чужого кейса.
Пять слоёв зависимости от ИИ-поставщика
| Слой | Что обычно привязано | Проверка переносимости |
|---|---|---|
| Модель | system prompt, контекст, structured output, safety behavior | парный прогон замороженных кейсов |
| Обвязка | tool calling, retries, routing, budgets, memory | replay действий и ошибок |
| Данные | файлы, embeddings, labels, conversation state | полный экспорт и контрольный импорт |
| Контроль | журналы, approvals, moderation, evaluator | сохранение обязательных доказательств |
| Договор и люди | сроки, права, поддержка, компетенции | exit register, ответственные и репетиция |
Абстракция API уменьшает стоимость замены endpoint, но не нормализует смысл. Например, два поставщика могут принять один JSON Schema, но по-разному решить, когда вызвать инструмент, остановиться или передать задачу человеку. Поэтому статья про обвязку ИИ-агента рекомендует принимать замороженную модель–harness сборку, а не имя модели отдельно.
Скрытая зависимость часто находится в данных. Если vendor-managed memory, embeddings или trace нельзя экспортировать в читаемом формате, формально доступная резервная модель начинает без контекста. Если бизнес-решение требует журнала approvals, переход без сохранения evidence trail может быть хуже краткого простоя.
Остаться, готовиться или переключаться
| Состояние | Наблюдаемые условия | Разумное действие |
|---|---|---|
| Остаться | контракт стабилен, exit time укладывается в tolerance, резерв недавно проверен | продолжать основной контур и пересматривать риск |
| Готовиться | смена контроля, условий, цены, региона или model roadmap; тест резерва устарел | заморозить кейсы, обновить экспорт, провести rehearsal |
| Переключаться | подтверждённое прекращение, неприемлемое изменение или нарушение порога риска | запустить согласованный cutover и усиленный контроль |
| Остановить функцию | ни одна альтернатива не проходит критичные требования | вернуть ручной процесс или ограничить scope |
Смена контроля — триггер пересмотра, а не автоматический приказ мигрировать. В случае OpenAI и Cursor именно change-of-control window, по заявлению OpenAI, позволило отменить custom agreement. Но клиент другого сервиса должен читать собственный договор и фактическую архитектуру.
Автоматическое переключение также подходит не всем. Для чернового суммирования можно принять умеренную деградацию. Для платежа, медицинского текста или изменения прав доступов безопаснее остановить автоматизацию, чем незаметно отправить задачу модели с другим профилем ошибок.
Метод ЗАПАС для выхода из ИИ-сервиса
Предлагаем метод ЗАПАС. Это редакционный синтез управления поставщиками, cloud exit planning, AI evaluation и change management; он не является стандартом OpenAI, Cursor, NIST, GOV.UK или ЕС.
З — Зависимости и триггеры
Нарисуйте не логотипы поставщиков, а полный путь одного критичного запроса: входные данные, preprocessing, модель, инструменты, memory, policy, evaluator, журнал и бизнес-эффект. Для каждой зависимости задайте триггеры: прекращение сервиса, изменение владельца, цены, региона обработки, условий данных, capability или security posture.
А — Артефакты под контролем компании
Храните переносимые копии system prompts, JSON schemas, tool definitions, acceptance cases, policies, конфигураций retrieval и справочников. Зафиксируйте формат экспорта, частоту, владельца и процедуру удаления у старого поставщика. Секреты и персональные данные не должны попадать в переносимый пакет без основания и контроля доступа.
П — Проверочный набор
Соберите небольшой замороженный набор из частых, редких, критичных, атакующих и невыполнимых кейсов. Для каждого задайте допустимый ответ, обязательный отказ, вызов инструмента, human approval и запрещённый эффект. Сравнивайте не только текст, но и завершение бизнес-задачи.
А — Альтернативная сборка
Подготовьте конкретную комбинацию: модель, адаптер, prompts, инструменты, лимиты, safeguards и наблюдаемость. «Подключим другую модель позже» не является резервом. Альтернатива считается готовой после развёртывания, выдачи минимальных прав и парного теста с основной системой.
С — Срок и решение о переключении
Назначьте владельца cutover, пороги качества, максимальный простой, допустимую деградацию и срок восстановления. Решение должно различать четыре исхода: продолжить, переключить часть трафика, перейти полностью или остановить автоматизацию. Запишите rollback и коммуникацию пользователям.
Минимальный exit register помещается в одну таблицу:
| Поле | Пример содержания |
|---|---|
| Критичная функция | классификация входящих претензий |
| Основная сборка | provider/model/harness version |
| Альтернатива | provider/model/harness version |
| Данные и экспорт | форматы, последняя проверка, владелец |
| Acceptance set | версия, сегменты, запрещённые эффекты |
| Exit time | результат последней репетиции, а не обещание |
| Триггер | notice, breach, threshold, change of control |
| Решающий | ФИО/роль владельца риска |
Как провести репетицию перехода
Не начинайте rehearsal во время аварии. Выберите 20–50 репрезентативных кейсов — диапазон является редакционной рекомендацией, а не стандартом — и выполните шесть шагов.
- Заморозьте основной и резервный manifests. Запишите model ID, prompts, tools, policies и budgets.
- Экспортируйте состояние. Проверьте не наличие кнопки, а читаемость, полноту и восстановление данных в тестовом контуре.
- Запустите paired evaluation. Один case проходит обе сборки; результаты проверяет общий rubric.
- Измерьте эффект. Зафиксируйте completion, критичные ошибки, approvals, latency и фактические затраты только там, где данные доступны.
- Проиграйте cutover. Переключите ограниченный shadow-трафик или обратимый процесс, проверьте журналы и rollback.
- Подпишите решение. Укажите остаточные риски, срок следующей проверки и события для внепланового запуска.
Мы применили эту логику к публичному событию как desk test: проверили семь первичных/официальных источников, отделили дату заявления от даты сделки, разложили зависимость на пять слоёв и сформировали trigger matrix. Мы не имели доступа к договорам OpenAI–Cursor, внутренней архитектуре клиентов, production traces или измеренным затратам миграции; поэтому выводы ограничены процессом управления риском.
Ключевой показатель — не «совпадение ответов», а доля критичных сценариев, завершённых в пределах допуска без запрещённого эффекта. Паритет по всем словам обычно невозможен и не нужен. Важно сохранить функцию, контроль и доказательства.
Что закрепить в закупке и договоре
Британский Digital, Data and Technology Playbook рекомендует связывать exit plan исходящего поставщика с мобилизацией нового и включать действия, сроки, роли, риски, зависимости и передачу активов. Для российского бизнеса это полезный шаблон управления, а не применимое право.
Для ИИ-закупки обсудите с юристами и архитекторами:
- notice при прекращении модели, существенном изменении условий и change of control;
- список exportable data и digital assets, формат, частоту и стоимость выгрузки;
- доступ к logs, prompts/configs, labels и evidence, принадлежащим заказчику;
- поддержку перехода, удаление копий, подтверждение удаления и судьбу backups;
- возможность временного overlap двух поставщиков;
- model/version change notices и regression window;
- ограничения на перенос защищённой интеллектуальной собственности поставщика.
EU Data Act содержит договорные требования к переключению data-processing services, экспорту данных и digital assets, continuity и открытым interfaces. Его применимость зависит от услуги, территории и исключений; это не юридическая оценка конкретного LLM API. Право на экспорт также не создаёт автоматическую функциональную эквивалентность модели.
Что переносимость не гарантирует
План выхода уменьшает операционный риск, но не даёт пяти гарантий.
- Равное качество. Модели по-разному рассуждают, отказывают и вызывают инструменты.
- Нулевой простой. Экспорт, проверка доступа и re-indexing требуют времени.
- Одинаковую безопасность. Safeguards и журналирование различаются.
- Правовую достаточность. Технический экспорт не заменяет анализ договора и данных.
- Экономию. Резерв, rehearsal и двойная эксплуатация могут увеличить расходы.
Также не обязательно строить «универсальный слой» для всего. Чем больше abstraction скрывает различия моделей, тем выше риск потерять полезные capability и важные safety signals. Часто лучше стандартизировать входы, доказательства и acceptance tests, а provider-specific adapters оставить явными.
Связанная тема — роутер моделей ИИ. Роутер может распределять задачи, но не заменяет exit plan: он сам становится компонентом, который нужно версионировать, тестировать и уметь обходить.
Ограничения анализа
Публичное заявление OpenAI описывает позицию одной стороны. Полный custom agreement, переговоры и клиентские планы не опубликованы. Дата 12 ноября названа как proposed shutoff date; статья не утверждает, что отключение обязательно произойдёт в точности тогда.
Cursor публично поддерживает несколько моделей, но это не доказывает эквивалентность функций, цен, latency, privacy, safety или результатов после возможного прекращения поставки OpenAI. Мы не измеряли пользовательский трафик, отказы, стоимость перехода или влияние на бизнес.
NIST AI RMF носит добровольный характер. GOV.UK и EU Data Act имеют собственный государственный и территориальный контекст. Для российского договора нужны отдельные юридическая, информационно-безопасностная и налоговая оценки. Search volume, difficulty, rankings, traffic, CTR, backlinks и AI citations для темы остаются Unknown.
Частые вопросы
Что такое план выхода из ИИ-сервиса?
Это документированная и проверенная процедура переноса данных, конфигураций, контроля и бизнес-функции на альтернативную сборку или ручной процесс. В ней есть триггеры, сроки, ответственные, acceptance tests, cutover и rollback.
Достаточно ли подключить второй LLM API?
Нет. Нужно проверить prompts, structured output, инструменты, memory, safeguards, журналы и бизнес-эффект. Второй endpoint без теста может создать тихую деградацию вместо устойчивости.
Нужно ли постоянно держать две модели в production?
Не всегда. Для некритичной функции может хватить регулярной репетиции и готового manifest. Для непрерывной критичной функции может понадобиться warm standby или распределение части трафика.
Смена владельца ИИ-сервиса всегда требует миграции?
Нет. Это повод пересмотреть договор, данные, roadmap, security posture и срок выхода. Переключение запускается только при согласованном триггере или превышении tolerance.
Что тестировать при переходе между моделями?
Тестируйте completion по сегментам, критичные ошибки, обязательные отказы, tool calls, approvals, latency, расходы и сохранность evidence trail. Средний quality score без критичных сегментов недостаточен.
Как часто проверять резервный контур?
Единой частоты нет. Запускайте тест после материального изменения модели, harness, данных или договора, а также с периодичностью, которая короче допустимого устаревания резерва для вашего процесса.
Как AI рассвет помогает подготовить резервный контур
AI рассвет может связать план выхода с реальной ИИ-сборкой:
- провести аудит одного процесса и составить карту моделей, данных, инструментов и прав;
- подготовить переносимые prompts, retrieval-артефакты, tool schemas и критерии приёмки;
- собрать альтернативную LLM/RAG или on-prem сборку с ограниченными правами;
- провести парный тест, cutover rehearsal и зафиксировать результаты для владельца риска.
Безопасный первый шаг — выбрать один процесс, записать его текущий baseline, источники данных, ограничения и критерий приёмки.
Вывод
История OpenAI и Cursor показывает: доступ к ИИ-модели зависит не только от качества API, но и от договоров, владельцев и цепочки поставки. Однако разумный ответ — не паническая миграция и не обязательный multi-model для каждой функции.
Сначала зафиксируйте зависимости и триггеры, верните под контроль артефакты, соберите проверочный набор, разверните конкретную альтернативную сборку и измерьте срок перехода. Тогда план выхода станет операционной способностью, а не разделом договора, который впервые читают в день отключения.