Vendor lock-in в AI: как не привязать бизнес-процесс к одной LLM

Vendor lock-in обычно обсуждают как техническую зависимость от SDK. Мне кажется, это слишком узко. AI-система может использовать стандартный HTTP-клиент и всё равно быть глубоко привязана к одному провайдеру через prompts, tool semantics, structured outputs и собственные evals.

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

Если ответа нет, я бы не строил универсальную abstraction platform заранее. Сначала полезнее понять, где зависимость действительно опасна, а где она просто экономит время разработки.

Lock-in начинается с поведения, а не с названия API

Провайдеры различаются не только URL. У них разные форматы tool calls, ограничения контекста, streaming, multimodal inputs, structured outputs и нюансы системных инструкций.

При миграции часто приходится менять prompt и eval criteria даже если application-level interface выглядит одинаково. Anthropic публикует отдельные migration guides именно потому, что перенос поведения между моделями требует проверки, а не механической замены endpoint.

Я бы поэтому описывал зависимость на уровне capability contract: что именно процесс ожидает от модели и какие элементы специфичны для текущего провайдера.

Проверяемые источники: Anthropic — Migration guide

Prompt тоже часть платформенной зависимости

Prompt, который хорошо работает с одной моделью, может иначе вести себя на другой. Это особенно заметно в длинных инструкциях, работе с инструментами и неоднозначных задачах.

Если prompts хранятся как код с версиями и привязаны к eval-set, миграцию можно проверить. Если они разбросаны по workflow и редактируются вручную, реальная стоимость смены модели становится неизвестной.

Я бы не стремился к одному универсальному prompt для всех моделей. Иногда дешевле иметь небольшие provider-specific варианты, но общий набор тестов.

Проверяемые источники: Anthropic — Migration guide · Google Cloud — Gen AI evaluation service overview

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Tool layer можно отделить от модели разумной границей

Бизнес-команды вроде `create_invoice` или `find_customer` не обязаны повторять API конкретной LLM. Модель выбирает инструмент, а application layer проверяет параметры, права и вызывает внутренний контракт.

Такая граница полезна даже без планов смены провайдера. Она уменьшает blast radius и делает side effects тестируемыми отдельно от reasoning модели.

Но если ради portability мы строим собственный универсальный язык для каждой новой capability, цена абстракции быстро растёт. Я бы абстрагировал стабильный бизнес-контракт, а не все особенности моделей.

Проверяемые источники: Google Cloud — Apigee AI solutions: model abstraction and multicloud model routing

Data policy может оказаться самым жёстким lock-in

Иногда модель легко заменить технически, но процесс связан с конкретным регионом, contract terms, retention policy или интегрированной платформой данных. Тогда реальная зависимость находится не в prompt.

Поэтому migration plan должен включать не только качество ответа. Нужно проверить доступность нужного региона, модель данных, журналы, observability и разрешённые способы передачи контекста.

Я бы вынес такие требования в отдельный checklist до выбора provider. Их потом сложнее компенсировать архитектурой приложения.

Проверяемые источники: Google Cloud — Apigee AI solutions: model abstraction and multicloud model routing

Portability test полезнее абстрактной стратегии multi-model

Раз в несколько месяцев можно взять один критичный сценарий и прогнать его на альтернативной модели. Не обязательно переносить production. Важно оценить разницу в качестве, prompt changes и интеграционной работе.

Microsoft рекомендует при миграции агентов валидировать поведение на новых моделях, а не предполагать полную взаимозаменяемость. Для меня это хороший operational подход к lock-in.

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

Проверяемые источники: Microsoft Learn — Run and validate an AI model migration for Copilot Studio · Google Cloud — Gen AI evaluation service overview

Не всякая зависимость плоха

Специфичная capability может давать бизнесу существенное преимущество. Отказываться от неё только ради теоретической portability тоже странно.

Я бы оценивал два риска: вероятность необходимости смены поставщика и стоимость такой смены. Если оба низкие, глубокая интеграция может быть рациональной. Если один высокий, стоит инвестировать в contract boundaries и evals.

Цель не в том, чтобы сделать все LLM взаимозаменяемыми. Для меня цель скромнее: знать, где мы зависим от провайдера, почему согласились на эту зависимость и сколько будет стоить выход.

Проверяемые источники: Google Cloud — Apigee AI solutions: model abstraction and multicloud model routing · Microsoft Learn — Run and validate an AI model migration for Copilot Studio

Observability тоже может привязать систему к провайдеру

Команда часто думает о переносимости model call и забывает telemetry. Если traces, token accounting, safety events и debug tooling существуют только в proprietary console, после смены модели исчезает привычный способ видеть систему.

Я бы сохранял собственный correlation ID, operation outcome и минимальный набор provider-neutral telemetry. Provider-specific данные можно добавлять сверху, но расследование бизнес-операции не должно зависеть от одного кабинета.

Это не требует строить собственную observability platform. Достаточно определить, какие доказательства нужны процессу независимо от модели.

Проверяемые источники: Google Cloud — Apigee AI solutions: model abstraction and multicloud model routing · Google Cloud — Gen AI evaluation service overview

Вопросы, которые я бы уточнил до следующего шага

Как понять, есть ли у AI-системы vendor lock-in?

Попробуйте перенести один критичный сценарий на альтернативную модель. Зафиксируйте изменения prompts, tools, data policy, evals и observability. Это покажет реальную стоимость зависимости лучше архитектурной схемы.

Нужен ли единый API для всех LLM?

Иногда он полезен для базовых операций. Но слишком широкая абстракция может скрыть сильные возможности моделей и сама стать дорогим слоем поддержки.

Можно ли полностью избежать lock-in?

Практически любой production-процесс зависит от выбранных возможностей и платформы. Важнее сделать зависимость осознанной и проверяемой, чем пытаться устранить её полностью.

Если бы я хотел сохранить свободу выбора, я бы не начинал с multi-cloud схемы. Я бы начал с одного portability test и списка мест, где текущая LLM действительно встроена в поведение системы. После этого становится понятно, где нужна граница, а где зависимость можно спокойно принять.

Рядом с этой темой я бы держал для «vendor lock-in LLM»: kak vybrat llm dlya biznesa · llm routing dlya biznesa · Что происходит с бизнес-процессом, когда AI недоступен.