MVP — это самая узкая работающая версия решения, которую отдают настоящим пользователям, чтобы узнать, станут ли они ею пользоваться. Пилот — это полноценная технология, запущенная на ограниченном срезе ваших данных или подразделений, чтобы узнать, справляется ли она с вашей спецификой. Первое проверяет спрос, второе — пригодность.
Офисная аналогия — новая кофемашина. Пилот: поставили одну на неделю и смотрим, тянет ли она 90 чашек в день и хватает ли давления воды на этаже — вопрос к технике. MVP: поставили одну и смотрим, перестали ли сотрудники ходить в кофейню напротив — вопрос к людям. Машина может прекрасно работать и при этом стоять без дела, а может нравиться всем и ломаться каждый четверг. Это два независимых риска, и снимаются они разными проверками.
Дальше — таблица различий, устройство критерия выхода и модельный расчёт по состоянию на сентябрь 2026 года. Примеры взяты у одной компании: оптовик стройматериалов, 140 человек, 26 прорабов-заказчиков на регулярной отгрузке и юридический отдел с архивом на 6 400 договоров. Ставка инженера — 3 000 ₽/час, полная стоимость часа рядового сотрудника — 700 ₽.
Два слова, которые отвечают на разные вопросы
Минимальная версия решения, у которой работает один сценарий целиком и нет ничего сверх него. Отдаётся реальным пользователям на реальном потоке, чтобы измерить поведение, а не мнение. В смете — отдельный короткий этап на 3–4 недели. Проверочный вопрос подрядчику: какое число мы посмотрим через месяц и что сделаем, если оно окажется вдвое ниже.
Проверка технологии на ограниченном срезе данных или в одном подразделении при полной, а не урезанной функциональности. Отвечает на вопрос пригодности: выдержит ли модель наши сканы, наши формулировки, наш объём. В смете — этап с фиксированной ценой, размеченной выборкой и замером до и после. Проверочный вопрос: на какой выборке будет финальный замер и показывали ли её при настройке.
| Что сравниваем | MVP | Пилот |
|---|---|---|
| Главный вопрос | Будут ли этим пользоваться | Справится ли технология с нашими данными |
| Что ограничивают | Функциональность: один сценарий из десяти | Объём: один отдел или срез данных из архива |
| Кто участвует | Настоящие пользователи на настоящем потоке | Профильные специалисты и размеченная выборка |
| Что измеряют | Поведение: доля обращений через новый канал | Качество: точность, полнота, доля ручных правок |
| Провал означает | Сценарий не нужен либо выбран не тот | Технология не тянет данные в текущем виде |
| Типовой срок и цена | 3–4 недели, 150 000–200 000 ₽ | 4–6 недель, от 290 000 ₽ и выше по объёму |
На практике путаница выглядит так: компания заказывает «пилот бота», получает демонстрацию на трёх подготовленных вопросах и делает вывод о спросе. Ни одного из двух вопросов при этом не закрыто — ни про технологию, ни про людей. Как отличить проверку от продажи и что должно быть в договоре на такой этап, разобрано в материале про пробный этап с подрядчиком.
Две вертикальные колонки. Левая озаглавлена «MVP — будут ли пользоваться», правая «Пилот — справится ли технология». Шесть парных строк с подписями: «Ограничиваем функциональность / Ограничиваем объём», «Настоящие пользователи / Размеченная выборка», «Мерим поведение / Мерим качество», «Провал: сценарий не нужен / Провал: технология не тянет данные», «3–4 недели / 4–6 недель», «150 000–200 000 ₽ / от 290 000 ₽». Под левой колонкой мелкая пиктограмма одной узкой полосы, под правой — стопки листов. Тонкие чертёжные линии, подписи по-русски.
Критерий выхода: число, срок и решение
Критерий выхода пишется до начала работ и состоит из трёх частей. Без первой нельзя измерить, без второй можно мерить бесконечно, без третьей отрицательный результат превращается в предложение продлить. Третью забывают чаще всего.
Дальше — примеры из двух наших моделей. Первая: MVP бота приёма заявок на отгрузку в мессенджере MAX для 26 прорабов — 3 недели и 165 000 ₽, поток около 345 заявок за 15 рабочих дней. Вторая: пилот поиска по архиву из 6 400 договоров — 4 недели и 290 000 ₽, контрольная выборка 120 документов.
- 1Число
Конкретный порог, а не направление. Для MVP бота приёма заявок: не менее 190 из 345 заявок за период приходят через бота, то есть 55 %. Для пилота поиска по договорам: нужный документ в первых трёх результатах не реже чем в 102 случаях из 120 контрольной выборки — 85 %.
- 2Срок наблюдения
Отрезок, на котором число считается, и он не равен сроку проекта. Первые дни всегда искажены новизной: люди пробуют инструмент из любопытства. Рабочий минимум — 15 рабочих дней после того, как перестали править настройки, и считается только этот отрезок.
- 3Решение при недостижении
Что произойдёт, если число не набралось: закрываем направление, меняем сценарий и повторяем один раз за такую-то сумму, переходим к другому подрядчику. Формулировка «будем смотреть по ситуации» означает, что решения не будет — будет продление.
Отдельно стоит договориться, кто именно принимает решение по числу. Не «руководство», а имя и должность: тот, кто подпишет либо переход к внедрению, либо закрытие направления. Как формулировать такие договорённости до старта, разобрано в статье про метрики, о которых договариваются заранее.
Схема одного листа с тремя горизонтальными полями сверху вниз. Поле 1 «Число» с примером «190 из 345 заявок через бота, 55 %». Поле 2 «Срок наблюдения» с примером «15 рабочих дней после последней правки настроек». Поле 3 «Решение при недостижении» с примером «закрываем направление либо один повтор за 90 000 ₽» и подписью-выноской «поле, которое чаще всего оставляют пустым». Внизу строка «Решение принимает: должность и фамилия». Тонкие чертёжные линии, подписи по-русски.
Ловушка вечного пилота
Отраслевые наблюдения 2026 года устойчиво показывают одно и то же: значительная часть ИИ-проектов останавливается между демонстрацией и эксплуатацией. Причина редко техническая. Проект застревает там, где проверка удалась технически, но никто не обязан на её основании принять решение — и продолжение проверки оказывается для всех участников комфортнее решения. Механику этого застревания мы разбирали в материале про то, почему ИИ-проекты не доходят до эксплуатации.
Модельный пример: пилот поиска по архиву из 6 400 договоров, согласованная смета 290 000 ₽ на четыре недели. Критерия выхода в договоре не было — была формулировка «оценим результаты и примем решение».
Каждое продление по отдельности выглядело разумно, и в этом вся ловушка: обсуждался объём проверки, а не решение по ней. Стоило записать в договор одну строку — «при результате ниже 85 % на контрольной выборке направление закрывается либо повторяется один раз за 90 000 ₽» — и разговор шёл бы про 380 000 ₽ максимум, а не про 640 400 ₽.
Ступенчатый накопительный график по неделям от 0 до 12. Первая ступень до 4-й недели — 290 000 ₽ с подписью «пилот по смете». Далее три ступени: до 7-й недели +120 000 ₽, до 10-й +105 000 ₽, до 12-й +75 000 ₽, плюс тонкая надстройка +50 400 ₽ с подписью «время заказчика». Финальная отметка 640 400 ₽. Горизонтальная штриховая линия на отметке 850 000 ₽ с подписью «полное внедрение». Ось X — недели, ось Y — рубли. Тонкие чертёжные линии, подписи по-русски.
Что обязано быть в проверке, чтобы она что-то значила
Четыре условия, при отсутствии любого из которых результат нельзя переносить на эксплуатацию. Они одинаковы и для MVP, и для пилота, различается только объект замера.
- Реальные данные заказчика, а не подготовленные примеры. Для пилота по договорам это означает сканы с печатями, кривые страницы и правки от руки — то, что реально лежит в архиве. Демонстрация на чистых образцах не говорит ни о чём.
- Участие тех сотрудников, которые будут работать после запуска. Не ИТ-специалиста и не руководителя проекта. В нашем MVP бота заявки писали те же 26 прорабов, а не сотрудники отдела продаж «за них».
- Замер до и после по одной методике. Если до проверки никто не знал, сколько заявок приходит звонком и сколько времени уходит на поиск договора, сравнивать будет не с чем. Что и как замерять до старта — в материале про данные перед внедрением.
- План перехода в эксплуатацию, написанный до начала. Хотя бы на страницу: что дособираем, сколько это стоит, кто администрирует систему дальше. Без него положительный результат тоже остаётся без продолжения — просто по другой причине.
Если подрядчик настраивал систему на тех же документах, на которых потом её проверяет, вы измеряете не качество, а подгонку. Правило простое: контрольная выборка откладывается до начала работ и не участвует в настройке. В нашем пилоте это 120 договоров из 6 400 — примерно 2 % архива, отобранные так, чтобы попали все типы документов и все качества сканов.
Сколько это стоит по рынку
Ориентиры на сентябрь 2026 года. Базовый агент с поиском по базе знаний — 150 000–200 000 ₽ и 3–8 недель; в эту же вилку укладывается большинство MVP на один сценарий. Пилот распознавания или поиска на объёме около 50 000 документов — от 500 000 ₽ и 4–6 недель. Наш модельный пилот на 6 400 договорах дешевле — 290 000 ₽, потому что объём разметки на порядок меньше, но короче четырёх недель он не становится: время съедают не документы, а два круга разбора ошибок.
Отдельно уточняйте, входит ли стоимость проверки в стоимость внедрения. Возможны оба варианта, и оба честные: зачёт полностью, зачёт частично или отдельная оплата. Нечестен только третий сценарий, при котором вопрос не обсуждался, а на этапе договора выясняется, что деньги за пилот не учитываются. Полный разбор состава сметы такой проверки — в статье про пилот и MVP в автоматизации.
Когда не нужны ни пилот, ни MVP
Проверка — это отдельные деньги и отдельные недели, и есть задачи, где она не окупается.
- Задача решается настройкой коробочного продукта. Воронка в CRM, права доступа, шаблоны документов — здесь нечего проверять: функциональность задана вендором и известна заранее. Пилот тут превращается в платное знакомство с интерфейсом.
- Стоимость проверки сопоставима со стоимостью решения целиком. Если полный проект стоит 300 000 ₽, а проверка — 200 000 ₽, дешевле сделать проект с правом остановиться после первого этапа. Как устроен такой поэтапный вход, описано в материале про техническое задание.
- Никто не готов принять отрицательный результат. Если заранее известно, что направление продолжат в любом случае, проверка становится ритуалом: вы платите 290 000 ₽ за подтверждение уже принятого решения. Честнее сразу идти во внедрение с ограниченным первым этапом.
- Нет данных, на которых проверять. Архив не оцифрован, обращения нигде не фиксировались, поток заявок не считался. Сначала собирают данные и налаживают учёт, и только потом проверяют технологию на них.
Пилот без записанного заранее решения при недостижении — это не проверка гипотезы, а способ отложить выбор за счёт бюджета.
