Самый дорогой проект с ИИ — тот, которому не нужно было начинаться: он не просто не окупается, а надолго закрывает в компании тему автоматизации. Модель, поставленная туда, где хватило бы фильтра в таблице, приводит к одному финалу — недовольный заказчик, счёт за токены и вывод «AI не работает». Мы внедряем ИИ и зарабатываем на этом, и именно поэтому говорить, когда AI не нужен, нам выгодно: неудачный проект вредит обеим сторонам. Ниже — пять признаков таких задач, что поставить вместо модели и как отказаться от идеи, не потеряв лица.
Задача, в которой AI не нужен, — это задача, которую дешевле и надёжнее решить правилом, шаблоном, настройкой существующей системы или управленческим решением, чем вероятностной моделью. Признаков у неё пять, и достаточно двух-трёх совпадений, чтобы отложить внедрение.
Если все ветвления помещаются на лист бумаги, это код, а не модель
Если процесс раскладывается на конечный список условий и эти условия стабильны, модель здесь лишняя. Распределение заявок по регионам, расчёт скидки по объёму, проверка заполненности полей — всё это решается обычной логикой: быстрее, дешевле и с гарантированно одинаковым результатом.
Критерий на практике: если вы способны за час описать все ветвления на листе бумаги и за последний год они не менялись, — это код. Модель оправдана там, где перечислить все варианты входа невозможно: свободная речь клиента, письмо в произвольной форме, документ, который каждый контрагент оформляет по-своему.
Почему тогда такие задачи всё равно приходят с формулировкой «сделайте на нейросети»? Потому что слово «ИИ» проще согласовать с руководством, чем слово «доработка CRM». Это понятная мотивация, но платить за неё будет компания — и в деньгах, и в непредсказуемости результата.
Правдоподобная ошибка без проверяющего дороже ручной работы
Модель отвечает вероятностно и ошибается правдоподобно — именно поэтому ошибку легко пропустить. Там, где неверный результат приводит к потерям и при этом никто не перепроверяет вывод, автоматизация через ИИ создаёт риск вместо экономии. Почему модели ошибаются уверенно, разобрано в статье о том, почему нейросеть выдумывает.
Это не значит «нельзя». Это значит, что в проект придётся заложить контрольный слой: выборочную проверку человеком, автоматические правила-ограничители, сценарий отката. Если на такой слой нет ресурса — задачу лучше не отдавать модели вовсе.
Без исходной цифры внедрение превращается в спор об ощущениях
Если в компании не считают конверсию, не хранят записи разговоров, не фиксируют сроки — измерить эффект будет нечем, и через три месяца обсуждение сведётся к «вроде стало лучше» против «ничего не изменилось». Выиграет в этом споре тот, кто громче, а не тот, кто прав.
Правильный порядок обратный: сначала наладить измерение, потом внедрять. Что именно должно быть в компании до старта, разобрано в статье про данные, которые нужны для запуска AI.
Малый объём не окупит даже удачную настройку
Любое внедрение — это стоимость проекта плюс стоимость эксплуатации. На малом объёме первое не окупается: разобрать двадцать обращений в месяц человек успеет между делом, а система потребует настройки, поддержки и внимания.
Хорошая аналогия — станок с ЧПУ в столярной мастерской, которая делает пять заказных шкафов в месяц. Станок точнее и быстрее мастера, но пока его программируют под каждый уникальный шкаф, мастер успевает закончить работу руками. Станок окупается на серии, а не на штучной работе. С ИИ так же: он выигрывает на тысячах однотипных операций, а не на десятках.
Порог считается арифметикой, а не верой: сколько времени тратится сейчас, сколько это стоит в деньгах, сколько стоит внедрение и обслуживание. Мой ориентир: если срок окупаемости выходит за два года, отвечать обычно нужно «нет» — за это время успеют поменяться и процесс, и сами модели.
Инструмент не заставит перезванивать тех, кому никто не велел
Этот признак коварнее остальных, потому что запрос звучит технически. Менеджеры не перезванивают по заявкам — и просьба звучит как «поставьте AI, чтобы он контролировал». Но если раньше не перезванивали, потому что заявки некому распределять, а руководитель не смотрит отчёты, — после внедрения не будут перезванивать ровно так же, только теперь об этом будет знать система.
ИИ показывает проблему и снимает рутину. Он не заставляет людей работать по-другому — это делает управленческое решение. Если такого решения нет, внедрение станет дорогим способом подтвердить то, что и так было известно.
Как проверить себя за пятнадцать минут
Короткий тест, который можно пройти до разговора с любым подрядчиком. Ответьте письменно на пять вопросов.
- Какую цифру мы хотим изменить и какая она сейчас? Если текущего значения нет, внедрять рано — измерять эффект будет не с чем.
- Сколько раз в месяц выполняется процесс? Десятки — почти наверняка не окупится, тысячи — есть о чём говорить.
- Кто заметит ошибку и как быстро? Если ответ «никто», нужен контрольный слой, и его стоимость входит в проект.
- Что мешает решить это правилами? Если ничего — берите код, он дешевле и предсказуемее.
- Какое управленческое решение мы примем по результату? Если никакого, система станет ещё одним отчётом, который не читают.
Три ответа «не знаю» из пяти — сигнал, что первый шаг не внедрение, а наведение порядка в измерениях. Это дешевле, быстрее и нередко даёт часть эффекта без всякой автоматизации: процесс, который начали измерять, уже начинает меняться.
Что делать вместо: четыре дешёвых замены
Отказ от модели не означает, что задача остаётся нерешённой. Обычно у неё есть решение заметно дешевле, просто оно выглядит скромнее и хуже звучит на совещании.
Первое — правило в системе, которая уже есть. Фильтр, автоматическое поле, условие в CRM. Работает мгновенно, почти ничего не стоит и не деградирует. Второе — шаблон. Многие задачи на «сгенерировать текст» — подтверждение записи, напоминание об оплате, ответ на типовой вопрос — закрываются несколькими заготовками с подстановкой, и результат стабильнее.
Третье — чек-лист для человека. Там, где проблема в том, что шаг забывают, напоминание в интерфейсе решает вопрос надёжнее модели. Четвёртое — изменение самого процесса: убрать шаг, объединить два в один, поменять порядок. Самое дешёвое из всех решений и самое редко рассматриваемое.
Как отличить организационную проблему от технической
Формулировка запроса почти всегда техническая, потому что так проще: инструмент можно купить, а разговор с командой — нет. Различить помогают три вопроса, и все они про то, что происходит сейчас.
Существует ли правило, которое нарушается? Если менеджеры не перезванивают, записано ли где-нибудь, за какой срок они обязаны это делать? Знает ли кто-то, что оно нарушается? Если нарушение никем не замечается, проблема в отсутствии контроля, а не в отсутствии инструмента. Что происходит с тем, кто нарушил? Если ничего, то и после внедрения ничего не будет происходить, только теперь об этом будут знать точнее.
Если хотя бы на один вопрос ответ отрицательный, автоматизация даст видимость решения. Она честно покажет масштаб проблемы, и на этом всё закончится: смотреть на цифру и не менять поведение люди умеют долго.
Возражение: пока мы проверяем, конкуренты уже внедряют
У осторожности есть серьёзный оппонент, и его стоит выслушать всерьёз. Технология быстро дешевеет, конкуренты пробуют, команда, которая уже прошла первый проект, учится быстрее той, что только собирается. Разве отложить внедрение — не значит отдать фору?
В этом аргументе верно главное: опыт работы с ИИ накапливается, и компания, которая ни разу ничего не пробовала, действительно проигрывает в скорости следующих решений. Но из этого следует не «внедрять что угодно», а «выбрать задачу, где эффект можно измерить». Неудачный проект на неподходящей задаче не даёт опыта — он даёт аргумент против всех следующих проектов.
К тому же «конкуренты внедрили» почти всегда известно по пресс-релизам и выступлениям, а не по цифрам. Что именно у них изменилось в деньгах, снаружи не видно. Сравнивать себя с чужим объявлением — плохая основа для решения, особенно когда своя задача не проходит проверку на пять признаков выше.
Компромисс, который я считаю честным, — маленький пилот на подходящей задаче с заранее записанным условием остановки. Он даёт опыт и не закрывает тему, если не сработал.
Когда AI не нужен сейчас, но понадобится позже
Часть отказов правильнее формулировать как «пока рано», и это не вежливая форма отказа, а рабочий ответ с конкретным условием возврата.
Типичные случаи. Объём растёт, но пока не дотягивает до окупаемости — вернуться стоит, когда поток удвоится. Процесс меняется каждый месяц — вернуться, когда устоится. Нет данных — вернуться через квартал после того, как начали их собирать.
Практический приём: записать условие возврата прямо в решении об отказе. «Возвращаемся к вопросу, когда число обращений превысит столько-то» — строка, которая экономит повторное обсуждение через полгода и не даёт теме зависнуть в статусе «мы это уже обсуждали».
Решение «сейчас не нужно» часто приходится защищать не от технологии, а от мифов вокруг неё — «конкуренты уже внедрили», «это дёшево и за неделю», «ИИ сам разберётся». Самые живучие из них собраны в статье о мифах об ИИ в продажах.
Как отказаться от идеи, не потеряв лицо
У отказа есть внутриполитическая сторона, о которой не принято говорить: инициатор потратил время, защитил идею перед руководством и теперь должен объявить, что не надо. Это неприятно, и часто именно поэтому проекты доводят до конца вопреки очевидному.
Помогает разделение решения и человека. Не «идея оказалась плохой», а «проверили, и вот что выяснилось» — с конкретными числами. Проверка, которая сэкономила компании неудачный проект, — это результат, а не провал, и подавать её стоит именно так.
И полезно фиксировать, что было получено попутно. Замер потерь, описание процесса, понимание, где данных не хватает — всё это остаётся и пригодится. Отказ, из которого компания вынесла три полезные вещи, обсуждается совсем иначе, чем отказ, после которого не осталось ничего.
Моя ставка: честный отказ — такая же работа агентства, как внедрение
На такие запросы мы отказываем и объясняем почему. Это не благотворительность: проект, который не должен был начинаться, заканчивается плохим результатом для обеих сторон — заказчик платит и не получает эффекта, подрядчик получает кейс, который нельзя показать.
Причины отказа 404ai записаны открыто на странице о подходе: некому вести изменения со стороны клиента; объём не окупит внедрение — при паре звонков в день автоматизация не вернёт вложенного; нет доступа к записям звонков и CRM; нет готовности менять скрипт и процесс по итогам аналитики. Все четыре перекликаются с признаками из этой статьи, и это не случайно: метод «Цель → метрика» начинается с вопроса, какая цифра должна измениться, и на этом вопросе неподходящая задача обычно видна сразу.
Моя позиция шире одного агентства: рынку ИИ-внедрений нужно больше подрядчиков, которые говорят «не надо». Каждый проект, сделанный ради слова «ИИ» в отчёте, делает следующий разговор о действительно полезном проекте тяжелее — в этой компании и у всех, кто о нём услышит. Подрядчик, у которого подходит всё, в итоге продаёт разочарование.
Что решить до того, как звать подрядчика
Из всего сказанного следует, что главный вопрос перед внедрением — не «какой ИИ выбрать», а «какую цифру мы меняем и почему не правилом». Ответ на него компания может получить сама, без подрядчика и без бюджета.
Запишите цифру, которую хотите изменить, и её текущее значение. Если значения нет, первый проект — измерение.
Проверьте задачу на пять признаков. Два-три совпадения — повод отложить или выбрать другую задачу, а не искать подрядчика, который согласится на эту.
Если задача проходит, договоритесь об условии остановки заранее: какой результат через месяц пилота на ваших данных будет означать «продолжаем», а какой — «закрываем без сожалений».
Если после этого теста задача всё-таки подходит, следующий вопрос — с какого процесса начинать: об этом отдельный разбор. А если не подходит, вы только что сэкономили бюджет проекта и год, который ушёл бы на доказательство того, что «ИИ не работает».
