Plan B для AI в компании: когда облачный API подорожал, а бизнес уже на нейросети
«Мы встроили AI в поддержку, CRM и отчёты — работает. Потом пришёл счёт: в три раза больше прошлого квартала. Отключать нельзя, платить больно. Что делать?»
Это уже не про «какую модель выбрать в leaderboard». Это про деньги, риски и управляемость. Ниже — где утекает бюджет, три рабочих Plan B и чеклист, который можно переслать CFO.

Почему тема всплыла именно сейчас
Типичный сценарий за последний год:
- Быстро подключили облачный LLM к чату, почте и базе знаний.
- Добавили сценарии: суммаризация тикетов, черновики КП, поиск по документам.
- Объём запросов вырос быстрее, чем успели поставить лимиты и метрики.
- Провайдер пересмотрел тарифы — и рост OPEX попал на стол CFO.
Параллельно усилились вопросы 152-ФЗ и периметра: персональные данные и переписка клиентов в публичном API без прозрачного DPA — риск, который раньше откладывали.
Plan B — не отказ от AI. Это вторая схема поставки, когда основной канал (платный API на каждый запрос) становится слишком дорогим или неприемлемым по compliance.
Где утекают деньги
| Паттерн | Что происходит | Эффект |
|---|---|---|
| Чат без потолка | Один вопрос гоняют в 5 формулировках | Счёт растёт с «любопытством» |
| RAG «на всякий случай» | В контекст — десятки страниц | Платите за входные токены |
| Агент без лимита шагов | Циклы «попробуй ещё» | Сотни вызовов на один сбой |
| Три интеграции к одной базе | CRM, поддержка, портал | Тройной OPEX и риск утечки |
| Нет кэша | Одинаковые FAQ каждый раз в LLM | 30–60% запросов лишние |
Если нет стоимости типового запроса и топ-5 сценариев по объёму — Plan B выбирают вслепую.
Оценка за 20 минут
Запросов в месяц: N × токенов на запрос: T × цена за 1M токенов: P ≈ месячный счёт.
Пример: 80 000 × 8 000 токенов × $3/1M ≈ ~$1 900/мес на один сценарий — без пиков и без команды.
Три рабочих Plan B
1. Управляемый облачный контур
API остаётся, появляются правила:
- лимиты на пользователя, отдел, сценарий (cap в ₽);
- маршрутизация: черновик — дешевая модель, финал — дорогая;
- кэш типовых ответов (TTL 24–72 ч);
- сжатие контекста, запрет «тащить всю базу» в каждый запрос.
Срок: 1–2 недели. Эффект: часто −40–70% счёта без смены продукта.
2. Модель внутри периметра
Self-hosted или частное облако (VPC, on-prem, российский хостинг):
- ПДн и договоры не уходят в публичный API;
- OPEX смещается с «за токен» на «железо + админку» — при стабильном объёме иногда выгоднее за 6–12 месяцев.
Когда: госконтур, финтех, жёсткий NDA, > 500k запросов/мес на одном контуре. Нужны: SRE/MLOps и контроль качества.
3. AI в приложении, а не чат «на всё»
| В чате | В приложении |
| «Сделай отчёт по продажам» | Кнопка → отчёт из БД / дашборд |
| «Найди договор» | Поиск в CRM с ролями и аудитом |
| «Согласуй заявку» | Workflow со статусами и SLA |
LLM — где нужна вариативность языка. Повторяемое — код и процессы. Это зона разработки внутренних систем, а не бесконечного корпоративного чата.
Какой Plan B выбрать
| Ситуация | Рекомендация |
|---|---|
| Счёт ×2 за квартал, данные не критичны | Лимиты + маршрутизация + кэш |
| Данные только в РФ / без US API | Свой контур или гибрид |
| 80% запросов — одни и те же операции | Автоматизация в приложении |
| Маленькая команда, нет DevOps | Не self-hosted; контуры 1 и 3 |
| «Хотим как в Twitter» | Сначала метрики, потом инфра |
Чеклист для CTO
- Дашборд: запросы/день, ₽/день, топ сценариев
- Утверждённый потолок расхода на AI
- Список полей, которые нельзя в публичный API
- Кэш и повторное использование эмбеддингов
- Лимит шагов у агентов (
max_steps) - Fallback при недоступности API 24 ч
- План: какие сценарии за квартал → кнопка в системе
Антипаттерны
- «Одна нейросеть на всё» без владельца бюджета.
- Промпты с клиентскими данными из интернета.
- Смена модели каждую неделю — метрики несопоставимы.
- Self-hosted «бесплатно» без учёта железа и людей.
Главное
Подорожание API — сигнал зрелости. Зрелая компания отвечает: где AI даёт маржу, где хватит кода, какой запасной контур включится при тарифе ×2 или сбое.
Часто быстрее всего не менять модель, а убрать лишние вызовы и вынести повторяемые процессы в приложение.
Мы в NineLab помогаем пройти этот переход: аудит сценариев AI, оценка стоимости запроса, проектирование внутренних систем и high-load, где нагрузка уже измерима. Первая консультация — бесплатно: ninelab.ru/contacts, Telegram @MozziDev.
Сервисы и материалы по теме
Частые вопросы по теме
Фокус на инженерных метриках и стеке: API, БД, CDN и код — не только на текстах и мета-тегах.
Желательны метрики и логи; для БД часто достаточно read-only или стенда с репликой данных.
Оба: лаборатория даёт воспроизводимость, RUM — реальные устройства и сети; вместе они объясняют расхождения.
Приоритизировать по impact/effort, закрепить метрики «после» и повторить замер; тяжёлые правки можно вынести в отдельный этап.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Все материалы: Аудит и тестирование
Как провести стресс-тест сайта?
Стресс- и нагрузочное тестирование перед распродажами и рекламными пиками: сценарии, метрики, типичные узкие места и как встроить проверки в регулярный цикл разработки.
Читать статью5 признаков, что ваш сайт скоро упадет
Пять признаков, что сайт или API близки к сбою: на что смотреть владельцу продукта и маркетингу до пиков трафика и как вовремя инициировать инженерный аудит.
Читать статью