Любой ИИ-сервис, используемый в бизнес-процессах, привязывает компанию к конкретному поставщику — это и называют vendor lock-in. Поставщик может изменить цены, лимиты, правила обработки данных, доступность или поведение модели. Если она участвует в поддержке пользователей либо работе с базой знаний, замена превращается в отдельный проект.

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

Например, компания хочет заменить основную облачную модель собственной локальной LLM. Harness сохраняет инструменты, скрипты, память, навыки, правила и форматы работы, поэтому перестраивать весь сервис не придётся. Менее мощная модель не заменит сильную во всем, но отдельные типовые задачи можно перенести на нее без пересборки системы. Команда прогоняет обе модели на реальных задачах проекта и сравнивает результаты по собственным показателям: точности, соблюдению формата, правильности вызова инструментов и доле ответов без ручной правки. Если локальная модель достигает заданного уровня, ее подключают вместо облачной — без привязки к общим рейтингам и без неприемлемой потери качества в конкретном рабочем сценарии.

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

У нас это не одна система, а несколько разных процессов: у каждого свой класс задач, свой входной канал и свои требования к качеству, задержке и обращению с данными. Общий у них принцип устройства. Прикладные правила, инструменты, память и проверки живут в обвязке, а модель подключается через адаптер: часть запросов уходит во внешние API — Anthropic, OpenAI, OpenRouter, — часть обрабатывается открытыми моделями на нашем сервере, крупными или компактными, в зависимости от задачи. Именно эта граница и позволяет менять исполнителя. Без нее процесс быстро обрастает деталями под конкретную модель, которые потом мешают ее заменить.

Связь закрепляется сразу на нескольких уровнях, и цена — не главный из них:

• инструкция: в системный промпт переезжают правила компании — формулировки, порядок согласования, исключения. Промпт перестает быть настройкой модели и становится описанием процесса;
• формат ответа: удобную для конкретной модели структуру начинают разбирать смежные системы — карточки обращений, отчеты, рассылки. Изменится формат — сломается не одна интеграция;
• инструменты и контекст: размер окна и правила вызова инструментов у моделей заданы по-разному, поэтому описания и порядок вызова подгоняют под то, как их понимает именно эта модель;
• память и данные: история, примеры и справочники накапливаются в формате одного интерфейса, а условия хранения данных у поставщиков отличаются;
• версии: новая версия прежней модели может иначе трактовать ту же инструкцию, и это отдельный источник зависимости — даже без смены поставщика.

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

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

Обвязка выносит рабочие правила в независимые компоненты. Через единый внутренний интерфейс и адаптеры модель получает задачу и возвращает результат. Адаптеры все равно нужны: сходный формат программного интерфейса не означает одинаковое поведение моделей. Отдельно хранятся инструкции, память, примеры, схемы данных, проверки, журналы действий и ограничения прав. Интеграции с почтой, базами и внутренними сервисами не должны зависеть от одного поставщика.

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

Запасной сценарий задают заранее: задачу можно передать другой модели, отложить или направить сотруднику. Сложный случай разумнее вернуть сильной модели. Автоматическое переключение без учета типа задачи может незаметно снизить качество.

Обвязку не нужно изобретать с нуля — рабочие примеры у всех на виду, просто их редко называют этим словом.

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

Claude Code — та же идея в терминале и в редакторе. Инструменты, разрешения на действия, память проекта в отдельном файле, подагенты и подключаемые внешние источники вынесены из промпта в конфигурацию. Прикладная логика живет не внутри запроса к модели, а рядом с ним.

Hermes Agent — один из наших внутренних контуров, построенный по тому же принципу. Точка входа — Telegram, вокруг модели — инструменты, навыки, постоянная память, подагенты и сохраненные процедуры. Сейчас он работает с открытыми моделями на нашем сервере, до этого те же задачи уходили во внешние API. Менялась модель — обвязка оставалась прежней. Другие процессы у нас устроены иначе по каналу и составу инструментов, но граница между моделью и системой в них проходит там же.

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

• канал и точка входа — через что задача приходит и куда возвращается результат;
• маршрутизация — какой класс задачи какой модели достается;
• контекст и память — что модель увидит в запросе и что сохранится между запусками;
• инструменты и права — что она может вызвать и с какими ограничениями;
• проверка результата — схема, программные проверки, подтверждение человеком для значимых действий;
• журнал и откат — версия модели, параметры, выполненные действия и возможность вернуться назад.

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

Цель такой конструкции формулируется просто: собрать у себя контур, в котором задача решается правильной обвязкой, а поставщика модели можно менять без потери качества на этой задаче. Тогда вопрос «на какой модели мы работаем» перестает быть стратегическим и становится настройкой маршрута.

На старте не обязательно добиваться независимости от всех поставщиков. Сильная модель помогает понять, какие инструкции работают, где нужны инструменты и какие ошибки повторяются. Последние сильные модели OpenAI и Claude от Anthropic можно использовать как точку отсчета, не встраивая особенности одного поставщика во все уровни системы.

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

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

Критерии успеха для такого класса задач:

• корректность полей;
• совпадение с решением специалиста;
• отсутствие запрещенных действий;
• допустимое время ответа.

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

Исходную модель сравнивают с выбранной версией Qwen или Kimi через внешний интерфейс либо на своей инфраструктуре, если это допускают лицензия и требования к оборудованию. Проверяют качество, задержку, стоимость, устойчивость формата и работу с инструментами. Успех в классификации не делает менее мощную модель равной сильной во всем — вывод действует только для проверенного класса.

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

Считать следует стоимость успешно выполненной задачи, а не токена. В затраты входят повторные попытки, инфраструктура, наблюдаемость, разработка, проверки и ручная доработка. Учитываются только результаты, прошедшие контроль.

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

Локальная модель не всегда дешевле облачного доступа: собственный запуск требует оборудования или аренды, программной среды, мониторинга, обновлений, резервирования и специалистов. При небольшой или нерегулярной нагрузке облачный интерфейс может оказаться выгоднее. Своя инфраструктура может быть оправдана устойчивой нагрузкой или требованиями к данным, но это должно быть подтверждено расчетом.

Локальный запуск помогает контролировать место обработки данных, но сам не гарантирует соответствие Федеральному закону № 152-ФЗ от 27.07.2006 «О персональных данных». Модель является лишь одним элементом. Правовую оценку проводят для всей схемы с учетом состава данных, целей обработки, ролей участников и требований организации.

Контур включает входной интерфейс, авторизацию, память, базы, журналы, резервные копии, внешние инструменты и исходящие соединения. Сообщение через Telegram проходит через внешнюю площадку. Вызов внешнего программного интерфейса из локальной системы также выводит часть данных за ее пределы, размещение модели на сервере компании этого не меняет.

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

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

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

Опаснее всего переносить задачи, в которых модель не пишет текст, а совершает действия. При смене модели поведение меняется в первую очередь именно здесь: формат вызова инструментов, полнота аргументов, готовность действовать без уточнения. Ошибочный текст можно исправить до отправки, а команду на удаленный объект или платеж вернуть сложнее. Поэтому агентные задачи переносят последними и с полным набором ограничений: минимально необходимые права, предварительный просмотр, журнал действий, защита секретов и подтверждение критичных операций. Для обратимых изменений заранее проектируют откат, для необратимых — повторное подтверждение и процедуру восстановления последствий. Публикации, изменение бюджета и финансово значимые действия подтверждает человек; одного запрета в инструкции недостаточно. Во время переноса и после него, наряду с доступностью и задержкой, отслеживают отклоненные результаты, ручные вмешательства, повторные вызовы и инциденты.

1. Провести инвентаризацию процессов, моделей, внешних интерфейсов, данных и последствий ошибки.
2. Выбрать один частый и хорошо проверяемый класс задач.
3. Зафиксировать критерии успеха и собрать контрольный набор для этого класса.
4. Отделить инструкции, память, форматы и проверки от интерфейса поставщика.
5. Ввести единый способ вызова моделей, журналирование версий и запасной сценарий.
6. Провести кандидата через контрольный набор, теневой режим и ограниченный запуск.
7. Принять решение о расширении по стоимости успешно выполненной задачи и качеству, а не по цене запроса.

Цель не в отказе от крупных поставщиков и не в обязательном переходе на свои серверы. ИТ-службе важнее управляемость: сильная модель обслуживает сложные случаи, а подходящие типовые операции можно передавать другим исполнителям. Тогда смена поставщика для проверенного класса задач становится изменением маршрута, а не пересборкой всей системы.