сначала сжатый ответ, потом разбор. шесть ошибок первого ии-проекта, отсортированные по частоте в моей практике: 1) начать с самого большого и сложного процесса вместо маленького и проверяемого; 2) не назначить владельца — агент ничей, метрики никто не смотрит; 3) автоматизировать процесс, который и руками-то не работает; 4) ждать полной автономности с первого дня и разочароваться в проверке человеком; 5) сэкономить на тестах с реальными данными и выйти на клиентов с демо-версией; 6) делать проект «потому что у всех ии», без записанного критерия успеха. любая из шести способна похоронить проект в одиночку, а ходят они обычно парами. теперь по одной, с признаками и рецептами.

ошибка 1: начать с главного процесса

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

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

признак «это про нас»: в описании первого проекта есть слова «ключевой», «стратегический» или сумма с шестью нулями.

как правильно: первый проект — маленький, частый, проверяемый: подтверждение записей, квалификация заявок, разбор входящей почты. запуск за 2–4 недели, цифры через месяц, команда научилась — теперь можно к ядру. как выбирать — отдельная статья с пятью фильтрами.

ошибка 2: агент без владельца

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

признак: на вопрос «кто будет раз в неделю смотреть метрики агента» отвечают «ну, посмотрим» или называют человека, который об этом не знает.

как правильно: владелец назначается до старта, поимённо, с 2–4 часами в неделю в календаре. это не «технический специалист» — это человек, который знает процесс и имеет право сказать «здесь отвечаем иначе». без владельца я пилоты не начинаю — проверено, что деньги заказчика умрут через два месяца.

ошибка 3: автоматизировать хаос

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

признак: на просьбу показать 20 примеров «как правильно» команда собирает их неделю и спорит о половине.

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

ошибка 4: ждать автономности с первого дня

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

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

признак: фраза «а зачем нам ии, если всё равно человек проверяет» звучит как аргумент против пилота.

как правильно: относиться к проверке как к этапу техпроцесса с датой окончания: две-три недели, по метрикам качества доля проверки снижается — сначала до спорных случаев, потом до выборочной. проверка — не костыль, а мост.

ошибка 5: сэкономить на тестах

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

тесты на реальных данных — это 20% бюджета пилота, которые проверяют не «работает ли модель» (работает), а «как агент ведёт себя на ваших исключениях». исключения — половина любого процесса, и о них узнаёшь только из реальных примеров.

признак: в кп подрядчика нет строки про тесты, или вы сами попросили её убрать ради цены.

как правильно: прогон на 30–50 исторических примерах до боевого запуска + тихий запуск на части потока. в моём пилоте за 200 000 ₽ фикс это не опция, а обязательная часть — именно потому, что видел, как без неё.

ошибка 6: проект без критерия успеха

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

признак: на вопрос «какая цифра должна измениться и на сколько, чтобы вы сказали „да“» нет ответа за одну минуту.

как правильно: до старта записать одну строку: «пилот успешен, если [метрика] изменится с [текущее] до [целевое] за [срок]». например: «время первого ответа на заявку — с 3 часов до 5 минут, доля обработанных без человека — не меньше 60%, за месяц боевого режима». и честное следствие: «не взлетело» по записанному критерию — тоже нормальный результат пилота. это данные, купленные за 200к вместо 500к+ на внедрении, — подробнее о том, как устроена честная проверка гипотез, в статье про стоимость внедрения.

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

мы уже наступили на половину из этого. проект спасаем или закрываем?

чаще спасаем: назначить владельца, записать критерий успеха задним числом, вернуть проверку человеком на пару недель и починить по метрикам — обычно месяц работы. закрывать имеет смысл, когда под агентом нет процесса (ошибка 3) — тогда сначала процесс, потом реанимация.

сколько ошибок можно себе позволить?

по опыту — ни одной из списка 2, 3 и 5: без владельца, на хаосе или без тестов проект умирает независимо от остального. ошибки 1, 4 и 6 болезненны, но лечатся на ходу.

подрядчик должен уберечь от этих ошибок или это наша зона?

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