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