Как запустить ИИ-пилот и понять, стоит ли продолжать

Тим Зинин ИИ-инженер · Зинин × Штурбин LinkedIn ↗

2 июня 2026

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

Что такое ИИ-пилот и зачем он нужен

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

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

Что подготовить до запуска: процесс, критерий, метрики, бюджет

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

Критерий успеха записывают одной строкой и кладут туда одну метрику с порогом, иначе финал расплывётся на множество мнений. Хороший критерий звучит так: за срок пилота доля черновиков ответов, которые менеджер отправляет без правок, поднимается выше выбранного порога, и среднее время на один ответ падает. Цифры порога подбирайте под свой процесс честно, без гиперболы. Лучше скромный порог, который вы готовы защищать перед командой, чем красивая цель, в которую сами слабо верите.

Пошаговый запуск пилота

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

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

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

Метрики качества, человек в контуре и бюджет на токены

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

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

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

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

Точка решения go или kill и что делать дальше

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

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

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

Частые вопросы

← Все статьи