Компания формулирует задачу: «хотим ИИ-агента, который отвечает клиентам». Через два месяца выясняется, что данные не структурированы, API внутренних систем не задокументированы, а критерии приёмки не зафиксированы. Бюджет потрачен, результат — демо без production-пути.
Проблема не в технологии. Проблема в отсутствии явной границы между тем, что входит в MVP, и тем, что остаётся за его рамками. В этой статье разберём, как выстроить пилот ИИ-продукта так, чтобы он давал измеримый ответ на конкретную гипотезу — и не превращался в бесконечную доработку.
Что такое MVP ИИ-продукта и чем он отличается от обычного MVP
В классическом продуктовом подходе MVP — минимальный набор функций, достаточный для проверки ценности. В ИИ-продукте добавляется второе измерение: качество модели. Можно запустить продукт с правильными функциями, но с моделью, которая даёт нерелевантные ответы на 40% запросов. Это не MVP — это технический долг, замаскированный под релиз.
Поэтому MVP ИИ-продукта имеет два явных ограничения:
- Функциональная граница — что агент делает, а что явно не делает (и передаёт человеку).
- Качественная граница — при каком минимальном уровне точности и покрытия пилот считается успешным.
Без обоих ограничений команда не может принять решение: масштабировать, переделать или остановить.
Проверка спроса до написания первой строки кода
Гипотеза ИИ-продукта должна опираться на данные, которые уже есть в компании. Демонстрационный сценарий: дистрибьютор получает 200–400 однотипных входящих запросов в день — наличие товара, сроки поставки, статус заказа. Менеджеры тратят значительную часть рабочего времени на ответы, которые в 80% случаев можно получить из ERP или CRM без участия человека.
Перед тем как проектировать агента, нужно ответить на три вопроса:
- Какой процент запросов покрывается данными, которые уже доступны через API или экспорт?
- Какой процент требует интерпретации или суждения, которое нельзя формализовать?
- Что происходит, если агент ошибается — каков операционный риск?
Ответы на эти вопросы определяют, стоит ли вообще строить ИИ-продукт или достаточно автоматизации без ML-компонента. Это честный баланс роста и безопасности: не каждая задача требует языковой модели.
Границы функций: что входит в первую версию
Типичная ошибка при постановке задачи — описывать желаемое поведение агента через «он должен уметь всё, что умеет менеджер». Это не граница — это размытый скоуп, который невозможно принять или отклонить.
Вместо этого MVP описывается через явный список сценариев с бинарным статусом: входит / не входит.
| Сценарий | Входит в MVP | Примечание |
|---|---|---|
| Ответ на вопрос о наличии по артикулу | Да | Данные из API склада |
| Статус заказа по номеру | Да | Данные из CRM через webhook |
| Расчёт индивидуальной скидки | Нет | Требует бизнес-логики вне API |
| Обработка претензий и возвратов | Нет | Передаётся человеку с контекстом |
| Консультация по техническим характеристикам | Частично | Только по структурированным атрибутам каталога |
Такая таблица — не просто документация. Это контракт между заказчиком и командой разработки, который фиксирует, что именно проверяется в пилоте.
Роль человека: где агент останавливается
Один из ключевых архитектурных решений MVP — механизм передачи диалога человеку. Это не fallback на случай ошибки. Это осознанная граница, которая защищает и клиента, и компанию.
В демонстрационном сценарии агент передаёт диалог менеджеру в трёх случаях:
- Запрос не покрывается ни одним из подключённых источников данных.
- Уверенность модели в ответе ниже установленного порога (например, score < 0.7 — конкретный порог определяется в процессе калибровки на реальных данных компании).
- Клиент явно запрашивает разговор с человеком.
Передача должна включать контекст: что спрашивал клиент, какие данные агент уже получил, почему передаётся. Без этого менеджер начинает разговор с нуля — и ценность автоматизации обнуляется.
Это и есть баланс роста и безопасности в операционном смысле: агент берёт на себя то, что можно формализовать, и не претендует на то, где нужно суждение.
Исходные данные: что нужно до начала разработки
Пилот ИИ-агента не начинается с модели. Он начинается с инвентаризации данных. Без этого этапа невозможно оценить реалистичность гипотезы.
Минимальный набор для старта:
- Документация API внутренних систем (CRM, ERP, склад) — или хотя бы описание доступных эндпоинтов и форматов ответа.
- Лог реальных запросов — 500–1000 примеров входящих обращений с разметкой: что спрашивали, что ответили, сколько времени заняло.
- Структура данных каталога — если агент работает с товарными данными, нужно понимать полноту атрибутов. Неструктурированный каталог — отдельная задача, которую стоит решить до или параллельно с пилотом. Подробнее об этом — в материале ИИ для каталога: описания, атрибуты, поиск и качество данных.
- Описание бизнес-правил передачи — кому, в каком формате и с каким приоритетом передаётся диалог.
Если API нет или он не задокументирован — это не блокер, но это отдельный этап работы, который влияет на сроки и бюджет пилота.
Архитектура пилота: три слоя
В демонстрационном сценарии пилот ИИ-агента для обработки входящих запросов строится из трёх функциональных слоёв.
Слой данных
Подключение к источникам через API или синхронизацию: склад, CRM, каталог. На этом этапе важно зафиксировать latency каждого источника — агент не должен отвечать медленнее, чем это приемлемо для канала коммуникации. Для чата это обычно 2–4 секунды на полный ответ.
Слой логики агента
Классификация запроса, выбор источника данных, формирование ответа. На MVP этот слой намеренно упрощён: лучше покрыть 60% запросов надёжно, чем 90% с нестабильным качеством. Это прямое следствие принципа баланса роста и безопасности — расширение покрытия происходит после валидации базового сценария.
Слой передачи и логирования
Механизм эскалации к человеку с передачей контекста. Полный лог всех взаимодействий — не для отчётности, а для последующей калибровки модели. Каждый случай передачи диалога — это обучающий пример для следующей итерации.
Интеграция этих слоёв с существующей инфраструктурой компании — отдельная инженерная задача. Подробнее о том, как организовать обмен данными между системами без хаоса, — в материале Архитектурный обзор обменов, каталогов и CRM-сценариев: поэтапное внедрение с фокусом на MVP.
Критерии приёмки пилота
Пилот завершается не тогда, когда агент «работает», а когда команда может ответить на вопрос: подтверждена гипотеза или нет? Для этого критерии приёмки фиксируются до начала разработки.
| Метрика | Что измеряем | Как фиксируем |
|---|---|---|
| Покрытие запросов | Доля запросов, на которые агент ответил самостоятельно | Лог взаимодействий за период пилота |
| Точность ответов | Доля корректных ответов от числа обработанных агентом | Выборочная ручная проверка (20–30 случаев) |
| Частота эскалации | Процент диалогов, переданных человеку | Автоматически из лога |
| Время ответа | Медианное и p95 время от запроса до ответа агента | Таймстампы в логе |
| Удовлетворённость | Опциональный сигнал от пользователя (если канал позволяет) | Простая реакция или оценка |
Важно: целевые значения метрик — не универсальные. Они определяются исходя из текущего baseline: сколько времени тратится сейчас, какой процент запросов обрабатывается в течение SLA. Пилот сравнивается с этим baseline, а не с абстрактным «идеальным агентом».
Контроль качества во время пилота
Пилот — это не production. Это контролируемый эксперимент с ограниченным трафиком и активным мониторингом. Несколько практических правил:
- Теневой режим на старте. Первые 1–2 недели агент работает параллельно с людьми: его ответы логируются, но не отправляются клиентам. Это позволяет выявить систематические ошибки до того, как они дойдут до клиента.
- Постепенное расширение трафика. После теневого режима агент обрабатывает 10–20% реального трафика. Расширение происходит только после подтверждения метрик на текущем уровне.
- Ручной разбор ошибок. Каждый случай некорректного ответа разбирается командой: это ошибка данных, ошибка логики агента или граничный случай, который нужно добавить в список явных исключений?
Такой подход медленнее, чем «запустить и посмотреть». Зато он даёт чистые данные для решения о масштабировании.
Масштабирование: что происходит после пилота
Если пилот подтвердил гипотезу, следующий шаг — не «добавить больше функций», а укрепить то, что уже работает. Это означает:
- Перевод в production с полноценным мониторингом и алертами.
- Расширение покрытия за счёт дополнительных источников данных или сценариев — по одному за итерацию.
- Накопление размеченных данных для дообучения или тонкой настройки модели под специфику компании.
- Формализация SLA: при каких условиях агент считается деградировавшим и требует вмешательства.
Если пилот не подтвердил гипотезу — это тоже результат. Он показывает, что либо данные не готовы, либо задача требует другого подхода. Это дешевле, чем узнать то же самое после полноценной разработки.
Экономика пилота: как оценивать без обещаний
Условный расчёт для демонстрации логики: если агент самостоятельно обрабатывает X% входящих запросов, а каждый запрос занимал у менеджера T минут, то высвобождается X × T минут рабочего времени в день. Умножьте на стоимость часа работы менеджера — получите верхнюю оценку операционного эффекта. Реальная цифра будет ниже: часть времени уйдёт на разбор ошибок агента и обслуживание системы.
Это не обещание окупаемости — это формула для принятия решения. Подставьте свои данные и оцените, оправдывает ли потенциальный эффект стоимость разработки и поддержки.
Как PORTcore помогает запустить пилот
Мы проектируем и разрабатываем ИИ-агентов под конкретные бизнес-процессы — от классификации входящих обращений до интеграции с внутренними API и CRM. Наш подход к пилоту включает фиксацию границ функций, критериев приёмки и механизма передачи диалога человеку до начала разработки.
Если задача связана с обработкой входящих запросов, AI-модерация входящих обращений — это отправная точка: классификация, приоритизация и маршрутизация без перегрузки команды. Для более сложных сценариев с интеграцией в несколько систем подходит интеграция AI-микросервисов — подключение ИИ-компонентов к существующей архитектуре с контролем качества на каждом слое.
Если вы готовы зафиксировать гипотезу и обсудить границы пилота — опишите задачу на странице услуг. Начнём с инвентаризации данных и оценки реалистичности сценария.
Связанные материалы
Подходящие офферы
Если статья попала в вашу задачу, вот два оффера, с которых можно перейти к внедрению без лишнего discovery.
Release-readiness аудит перед запуском
Проверяем, насколько продукт или сайт реально готов к запуску, чтобы релиз не стал лотереей для команды и бизнеса.
Аудит обмена остатками и ценами
Проверяем, где ломается обмен остатками и ценами между 1С, сайтом, CRM и внешними каналами.
