Vendor lock-in в AI-автоматизации: как чужой рубильник роняет ваших ботов

В феврале 2026 года поставщик API изменил схему биллинга ночью — без предупреждения, без письма, без периода миграции. К 8 утра следующего дня три клиентских бота перестали работать корректно. Они не крашились. Продолжали принимать сообщения — и отправляли клиентам сырые строки ошибок вместо ответов. Ровно то, что не должна делать никакая production-система.

Один из пострадавших — ассистент Соня, Telegram-бот московской клиники. Пациенты писали запросы на запись и получали: AuthorizationError: quota exceeded for plan Free. Upgrade at billing.example.com/upgrade. Восемь человек за три дня ушли, не записавшись. Узнал об этом владелец клиники сам — когда заметил, что запись встала. К тому моменту прошло 72 часа, и мы об инциденте не знали.

Это и есть vendor lock-in в AI-автоматизации. Не абстракция из архитектурных книг — конкретный ущерб от того, что чужой рубильник находится вне вашего контроля. В этой статье разбор трёх реальных инцидентов из системы 19 ботов — и три уровня защиты, которые мы внедрили после них.

Почему AI-боты уязвимы к vendor lock-in сильнее классического SaaS

В классическом SaaS vendor lock-in означает одно: трудно мигрировать на другое решение. Данные в проприетарном формате, нет нормального экспорта — неприятно, но не катастрофа за одну ночь. В AI-автоматизации проблема острее по трём причинам.

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

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

Ошибка мультиплицируется мгновенно. За 3 дня инцидента с Соней через бота прошло около 40 диалогов. Из них 8 завершились некорректно из-за ошибки авторизации. В обычном B2B-сервисе за 3 дня обычно успеваешь заметить проблему раньше. В боте без мониторинга — узнаёшь постфактум, от клиента, который уже разозлился.

К этому добавляется структурная проблема: большинство небольших студий автоматизации держат клиентов на своём аккаунте разработчика — ради удобства, скидки за объём или потому что «так было быстрее запустить». Это ставит агентство в позицию, где один сбой у поставщика или один инцидент с аккаунтом = одновременная проблема у всех клиентов сразу.

Важно понимать и природу самих инцидентов. Не все сбои выглядят как «провайдер упал». Биллинговые изменения — отдельная категория: токен остаётся технически валидным, но перестаёт авторизовывать запросы при превышении нового лимита. Ни 401 (Unauthorized), ни 403 (Forbidden) — просто 429 (Rate Limit) с нестандартной причиной. Большинство систем мониторинга настроены на 5xx, не на 429. Именно поэтому наши алерты не сработали в февральском инциденте: ошибка выглядела как «превышение квоты», а не «сервис недоступен».

Три инцидента, которые изменили архитектуру

Февраль 2026 — не первый звоночек. К тому моменту у нас уже было два инцидента, которые мы не приняли всерьёз. После третьего переделали всё.

Инцидент 1: контент-бот и JSON в YouTube-описаниях

Осень 2025. Контент-бот автоматически генерировал описания к видео и публиковал их через YouTube Data API. Воронка работала так: видео загружается в YouTube → вебхук триггерит бота → бот получает транскрипт → LLM генерирует описание с тегами → публикуется через YouTube Data API v3.

В ночь с пятницы на субботу произошёл сбой у LLM-провайдера — региональный, около 3 часов. Бот обрабатывал очередь из 4 видео. Обработчик ошибок в том варианте кода не перехватывал исключения LLM — просто пытался напрямую передать ответ в YouTube API. Все четыре описания опубликовались в виде JSON-объекта ошибки:

{"error": "service_unavailable", "code": 503, "message": "Model overloaded", "retry_after": 120}

Видео с такими описаниями пролежали в YouTube 11 часов до ручной правки в понедельник утром. За это время Google успел проиндексировать три из четырёх. Они отображались в сниппетах поиска как битый JSON — читаемый роботом, но не человеком. SEO-последствия разбирали две недели: гугловский кеш живёт дольше, чем хочется.

Инцидент 2: ассистент Соня и потерянные пациенты

Февраль 2026. Ассистент Соня — Telegram-бот московской клиники. Сценарий: пациент пишет запрос, бот задаёт уточняющие вопросы (симптомы, врач, удобное время), фиксирует запись в CRM и подтверждает. Бот запущен примерно за 4 месяца до инцидента, успел обработать около 600 диалогов без проблем.

Когда поставщик API изменил биллинг ночью, токен не был заблокирован — он перестал проходить авторизацию при превышении нового лимита плана. Бот продолжал принимать сообщения и обрабатывал первые шаги диалога (они не требовали LLM). На шаге, где нужно генерировать ответ с LLM — получал ошибку авторизации и выплёвывал её напрямую в чат пациенту.

8 пациентов за три дня не записались. Сколько из них позвонили потом по телефону, а сколько ушли к конкуренту — неизвестно. «Зачем мне бот, который пугает пациентов кодами ошибок?» — прямая цитата владельца клиники на разборе инцидента.

Инцидент 3: бот мониторинга и 2 дня слепоты

Февраль 2026, параллельно с Соней. Бот мониторил цены конкурентов на Airbnb и Booking.com для клиента с арендным бизнесом. Раз в сутки парсил актуальные цены, анализировал через LLM (сравнение с нашими тарифами, рекомендации по ценообразованию) и отправлял сводку владельцу в Telegram.

При сбое бот не падал — молча пропускал LLM-шаг, логировал ошибку в файл (который никто не читал), и cron перезапускал его каждые 30 минут. Итог за 2 дня: 96 лишних запусков, 96 retry-попыток впустую, ни одной успешной сводки. Владелец не получил данные 2 дня и не знал об этом — алерта не существовало. Обнаружили только когда он написал сам: «где сводка за эти дни?»

В период активного спроса 2 дня без аналитики цен конкурентов — это потенциально проданные ночи по неоптимальной цене. Точную стоимость упущенного не посчитать, но даже одна ночь в вилле на Бали по ставке на 30 USD ниже рыночной — это реальные потери.

Первая защита: изоляция аккаунтов

После этих трёх инцидентов первое и самое важное изменение — каждый клиент получил собственный аккаунт у поставщика AI.

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

Практически переход занял 2 рабочих дня. Что сделали:

1. Написали onboarding-чеклист: зарегистрировать аккаунт у провайдера, создать API-ключ, передать через зашифрованный канал.
2. Провели каждого клиента через чеклист — 15 минут до 1 часа на клиента.
3. Заменили токены в конфигах. Конфигурация ботов хранится в YAML-файлах, один файл на клиента. Замена — 3 строки в файле.
4. Проверили изолированную работу каждого бота на новом токене тестовым запуском.

Самое важное в этом переходе — не технические изменения, а изменение договорённостей с клиентами. Теперь при старте любого проекта в онбординге явно прописано: «вы создаёте собственный аккаунт у провайдера, мы настраиваем ботов на него». Клиенты в большинстве случаев не против — им даже проще: прямой контроль над своими данными и своим биллингом.

Для Solar внутри — аналогичная структура. Клуб «Solar — внутрянка», контент-боты, мониторинг инфраструктуры — три отдельных аккаунта у провайдеров. Даже внутри одной компании изоляция по функциям: если контент-боты «съедят» квоту на генерацию — боты клуба не пострадают.

Изоляция аккаунтов не защищает от падения самого провайдера. Она защищает от инцидентов на уровне аккаунта — биллинг, лимиты, блокировки. Для защиты от падения провайдера нужен следующий уровень.

Вторая защита: запасной LLM-провайдер

В марте 2025 один из крупных LLM-провайдеров лежал 4 часа в прайм-тайм — региональный сбой, затронувший Европу и часть Азии. У нас работало 6 автономных ботов — все встали. Это был урок ещё до февральского инцидента. Мы не внедрили fallback тогда. В марте 2025 это стоило 4 часа простоя. В феврале 2026 — 3 дня у трёх клиентов.

Fallback LLM — резервный провайдер, который берёт задачу при недоступности основного. Архитектура для каждого бота:

1. Отправить запрос основному LLM. Таймаут — 5 секунд на первый ответ, 30 секунд на полный response.
2. Ошибка авторизации, 5xx, таймаут или rate limit → автоматически переключиться на резервный LLM.
3. Резервный тоже недоступен → graceful fallback (следующий уровень).

Ключевое правило выбора резервного провайдера: другая компания, другая инфраструктура. Если основной — Claude (Anthropic, AWS), резервный не должен быть тоже на AWS. В нашей системе пары выглядят так:

• Клиентские боты общения: основной Claude 3.5 Haiku → резерв Gemini 2.0 Flash
• Аналитические задачи: основной GPT-4o → резерв Claude 3.5 Sonnet
• Контент-генерация: основной Claude 3.5 Sonnet → резерв GPT-4o

Дополнительная стоимость двойного стека — около 15–20% к API-расходам, потому что резервный endpoint расходуется только при реальных сбоях. При среднем боте с расходами 3 000–5 000 рублей в месяц это 450–1 000 рублей страховки.

Технически это реализуется через единый LLM-gateway в каждом боте — абстракция, которая принимает промпт и модель, делает запрос с retry-логикой, и автоматически переключается на fallback при ошибке. Написали один раз, переиспользуем во всех новых ботах. В gateway два класса: PrimaryLLM и FallbackLLM, оба реализуют один интерфейс ask(prompt, context). Вызывающий код не знает, какой из них ответил — только получает результат или исключение AllProvidersUnavailable, которое уже обрабатывается на уровне graceful fallback. Реализация — около 80 строк Python.

После написания gateway на новый проект добавить fallback занимает около часа: настроить аккаунты у обоих провайдеров, прописать конфигурацию в YAML, подключить gateway вместо прямого вызова SDK.

Третья защита: graceful fallback вместо сырой ошибки

Первые два уровня защиты — превентивные. Третий — последняя линия обороны, когда всё вышестоящее не сработало. Клиент не должен получать строку ошибки никогда — вне зависимости от того, что произошло внутри системы.

Graceful fallback в двух вариантах по типу бота:

Для клиентских ботов — мягкий отказ с переводом на человека

При любой необработанной ошибке, которая дошла до этого уровня, бот отвечает пользователю понятным сообщением:

«Сейчас не могу обработать ваш запрос автоматически. Передаю менеджеру — он ответит в течение 15 минут. Или позвоните напрямую: [номер].»

Одновременно — алерт в служебный Telegram-чат команды с полным контекстом: имя бота, Telegram ID пользователя, тип ошибки, timestamp, ссылка на диалог. Менеджер видит алерт, открывает диалог, подключается.

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

Для фоновых ботов — тихий пропуск с уведомлением

Мониторинг, генерация контента, аналитика, отчёты. При ошибке задача помечается как failed с причиной и timestamp, пропускается (не уходит в бесконечный retry), в служебный чат летит сообщение:

«Задача [название], запущена [время], статус FAILED. Причина: [тип ошибки]. Следующий плановый запуск: [timestamp].»

Бот не зависает, cron не зациклен, разработчик знает о проблеме через 5–15 минут — не через 2 дня, как в случае с ботом мониторинга цен.

Переход на graceful fallback для парка из 19 ботов занял 3 дня. Большую часть работы — написание общего error handler, интеграция с Telegram-алертами, тестирование — сделали один раз как отдельную библиотеку. На каждый новый бот теперь только подключить готовый обработчик и настроить канал для алертов: 2 строки в конфиге.

Важный нюанс: текст graceful-сообщения нельзя делать слишком техническим. «Временные технические работы» звучит профессионально. «Ошибка подключения к серверу» — уже хуже, вызывает вопросы. «AuthorizationError: quota exceeded» — именно то, чего нельзя показывать клиенту никогда.

Бонус: финансовый мониторинг выявил утечку в 30 раз

Разбирая биллинг после февральского инцидента, нашли кое-что неожиданное. Один из ботов мониторинга камер в нескольких объектах работал в режиме непрерывной Vision API трансляции вместо режима «скриншот раз в 30 секунд». Разница: 4 800 рублей в месяц против 160 рублей — в 30 раз дороже нужного.

Нашли за 4 замера: сравнили недельный биллинг за 4 недели, выявили аномальный рост, вычислили источник (Vision API запросы), проверили конфиг. Причина — единственная строка stream=True там где должно быть stream=False. Исправление — 1 минута. Экономия — 4 640 рублей в месяц, 55 680 рублей в год.

Такие утечки не видны, пока не смотришь на биллинг системно. В системе из 19 ботов с суммарными API-расходами в несколько десятков тысяч рублей в месяц — потенциал для аномалий есть у каждого бота. Конфигурационная ошибка в одном параметре может стоить в 30 раз дороже за всё время работы.

«Когда у тебя 19 ботов, финансовый мониторинг — обязательный инструмент, такой же как логи. Без него узнаёшь о проблеме от клиента или от счёта в конце месяца» — Юрий Солар, Solar OS.

После этого внедрили еженедельный финансовый отчёт: расход каждого бота за неделю, базовая линия (среднее за 4 предыдущих недели), автоматический флаг при отклонении +30% и выше. Отчёт формируется скриптом, летит в служебный чат каждый понедельник. Написание скрипта — 4 часа. Польза — системная видимость того, что происходит с каждым ботом в продакшне.

Что мониторить после запуска: минимальный чеклист

Три уровня защиты работают только если их дополняет постоянный мониторинг. Архитектурные решения при запуске + еженедельный аудит состояния — вот полная картина устойчивой системы.

Четыре метрики, которые нужно смотреть еженедельно по каждому боту:

• Процент успешных LLM-запросов. Если ниже 95% за неделю — что-то не так: либо провайдер даёт нестабильный сервис, либо prompts генерируют слишком длинные контексты, либо есть системная проблема с токеном. Алерт при падении ниже 90% за 24 часа.
• Среднее время ответа LLM. Резкий рост latency часто предшествует сбою на стороне провайдера — это ранний сигнал. Если P95 latency вырос в 2 раза по сравнению с базовой линией — стоит проверить статус провайдера.
• Число активаций fallback LLM. В штатном режиме — ноль или единицы. Больше 5 за день — провайдер нестабилен, стоит рассмотреть смену основного или обновление тарифного плана.
• Количество graceful fallback ответов клиентам. В норме — ноль. Любой graceful fallback означает, что клиент получил не то, что ожидал. Каждый такой случай должен разбираться вручную.

Всё это собирается в структурированные логи каждого бота и агрегируется еженедельным скриптом. Общее время на настройку такого мониторинга для нового бота — 1 час. Возврат — системная видимость вместо «узнали от клиента».

Итог: три уровня защиты и что они дают на практике

Vendor lock-in в AI-автоматизации не исчезнет. Поставщики будут менять тарифы, падать, блокировать аккаунты — это нормальная часть рынка зрелеющего инструмента. За 2025–2026 годы каждый крупный LLM-провайдер хотя бы раз изменил тарифную политику в одностороннем порядке. Это не исключение — это норма.

Вопрос не в том, как избежать зависимости (это невозможно), а в том, насколько эта зависимость управляема и насколько быстро система восстанавливается при инциденте.

Три уровня, которые теперь ставим на все проекты с первого дня:

• Изоляция аккаунтов. У каждого клиента свой токен у провайдера. Срок внедрения: 1–2 дня. Защищает от инцидентов на уровне аккаунта — биллинг, блокировки, квоты. Не защищает от полного падения провайдера.
• Fallback LLM. При сбое основного — автоматическое переключение на резервный от другой компании. Срок внедрения: 1–3 дня на бот после написания gateway (потом — часы). Стоимость страховки: +15–20% к API-расходам. Защищает от падений провайдера и региональных сбоев.
• Graceful fallback. Клиент никогда не видит строку ошибки. Либо мягкий отказ с переводом на человека, либо тихий пропуск с алертом в служебный чат. Срок внедрения: 3 дня на парк ботов (потом — 2 строки в конфиге). Защищает от репутационного ущерба при любом сбое.

После внедрения всех трёх уровней у нас произошло ещё три инцидента у провайдеров (один из них — 6 часов подряд). Ни один клиент не получил строку ошибки в ответ. Все боты либо переключились на fallback, либо корректно передали диалог на ручное управление. Алерты сработали в течение 10–15 минут после начала каждого сбоя.

Разница между «автоматизация, которая работает» и «автоматизация, которая иногда пугает клиентов JSON-ошибками» — в архитектурных решениях, которые принимаются при запуске, а не во время инцидента. Когда инцидент уже происходит — поздно думать об изоляции аккаунтов и graceful fallback. Они должны быть в системе с первого коммита.

Если интересно, как конкретно устроены AGENTS.md, конфиги LLM-gateway, шаблоны error handler и финансового мониторинга в реальной системе из 19 ботов — всё это в клубе «Solar — внутрянка». Не как «обучение», а как рабочие артефакты из продакшна: код, YAML-конфиги, промпты. Бери и адаптируй: https://4bos.ru/inside/

— Solar OS.