Vendor lock-in в AI: как не попасть в зависимость от одного провайдера

Что такое vendor lock-in в AI

Vendor lock-in это когда твой продукт настолько привязан к одному провайдеру что переехать на другого это либо очень дорого, либо невозможно.

В мире AI это особенно актуально. Ты начинаешь с OpenAI потому что он популярный. Пишешь код под их API. Используешь их функции вроде assistants. Подвязываешь на их формат запросов и ответов. Через полгода у тебя сотни часов работы завязаны на эту платформу.

Потом OpenAI меняет цены. Или меняет условия использования. Или закрывает конкретную модель которая тебе подходила. Или у вас трения по GDPR. Ты хочешь уйти. Но уйти это значит переписать половину кода.

Это и есть lock-in. И попасть в него легко.

Как я это предотвращаю

Первый принцип: абстракция над провайдером. Я никогда не вызываю API OpenAI или Anthropic напрямую из кода бизнес-логики. У меня есть слой-прослойка который принимает стандартный запрос и передаёт его любому провайдеру. Смена провайдера это правка конфига, а не переписывание сценария.

Второй принцип: стандартный формат промптов. Я стараюсь не использовать специфические фичи одного провайдера (assistants API, отдельные нетривиальные настройки), если они не критически нужны. Я держу промпты в форме которая работает у всех: системный промпт, пользовательский промпт, список функций, параметры.

Третий принцип: несколько провайдеров в работе. В крупных проектах я с первого дня работаю на двух разных провайдерах параллельно. Один основной, второй резервный. Это не только защита от lock-in, но и защита от сбоев: если основной лег, мы переключаемся на резерв без остановки работы.

Четвёртый принцип: готовность к локальному развёртыванию

Даже если клиент сейчас живёт на API, я проектирую так, чтобы в любой момент можно было переехать на локальную модель. Это значит не полагаться на уникальные фичи одного провайдера. Использовать function calling в стандартной форме которая работает и в GPT, и в Claude, и в локальной Gemma 4.

На старте это может выглядеть избыточно. Но когда клиент через полгода говорит "наши юристы запретили пускать данные через публичные API", я за неделю мигрирую весь стек на локальную модель без переписывания логики. Те клиенты кто с этим не парился, переделывают проект месяцами.

Типы lock-in кроме моделей

Векторные базы. Если ты используешь проприетарную векторную БД (Pinecone, например), смена на другую это миграция данных. Я чаще беру Qdrant, PGVector, или локальные решения которые можно перенести без геморроя.

Фреймворки. LangChain, CrewAI, LangGraph. Все они в какой-то мере запирают тебя на свои абстракции. Я выбираю тот фреймворк который даёт мне выход: где я могу вытащить логику в чистый Python если понадобится.

Оркестраторы. Готовые платформы типа Zapier или no-code AI builders дают быстрый старт, но заперают тебя в их мире. Если твой проект серьёзный, стройте на коде.

Сторонние сервисы эмбеддингов. Если ты используешь OpenAI embeddings, ты завязан на них. Если внезапно ценник растёт, ты либо платишь, либо перестраиваешь всю базу под другие эмбеддинги. Я либо беру открытые модели эмбеддингов с самого начала, либо держу возможность быстрой миграции.

Когда lock-in приемлем

Иногда использование специфических фич одного провайдера оправдано. Если у OpenAI есть уникальная функциональность которая экономит месяц работы, и проект в любом случае краткосрочный, можно взять её.

Я принимаю lock-in осознанно, с пониманием цены выхода. Это не "попал случайно", а "решил сознательно в обмен на скорость".

Что делать тебе

Если ты сейчас строишь AI-проект или заказываешь его у подрядчика, задай три вопроса: как мы переключимся на другого провайдера если понадобится? Сколько времени это займёт? Можем ли мы запустить локально если понадобится?

Если ответы звучат размыто, это риск.

Если ты уже в lock-in и хочешь из него выйти, это решаемо. Работы будет, но не месяц и не два. Напиши в t.me/kulmashev, оценю твой случай.