Почему не работает внедрение ИИ — этот вопрос мне задают уже после пилота, а не до. Сначала компания что-то запускает, получает работающую штуку, а через квартал смотрит на показатели и не видит движения. Дальше выбирают из двух объяснений: «технология сырая» или «нам не подошло».
Оба обычно неверные. Есть третье, и я вижу его чаще остальных: пилот проверял не то, что бизнес собирался улучшить. А ответственность за результат в этот момент перестала быть чьей-то конкретно.
Почему не работает внедрение ИИ: пилот доказал работоспособность, а не эффект
Пилот почти всегда получается. Бот отвечает, отчёт собирается, документ разбирается, демо проходит, все довольны. Это проверка того, что технология работает.
Бизнес ждал другого: что упадёт нагрузка, сократится срок, вырастет конверсия. Две разные проверки. Вторую обычно не проводит никто.
Пример из самых частых. Бот закрывает 80% обращений — цифра красивая, её приятно показать. Нагрузка на поддержку при этом не упала: операторы перечитывают каждый ответ, потому что им не сказали, где можно не перечитывать. Технология работает. Процесс не изменился. В отчёте успех, в расходах плюс.
Поэтому первый вопрос перед стартом звучит скучно: какой показатель сдвинется, на сколько и чему он равен сегодня. Если сегодняшнего значения нет, сравнивать через квартал будет не с чем, и разговор про эффект превратится в обмен впечатлениями. Обычно в таком разговоре побеждает тот, кто громче.
Где теряется ответственность за результат
Между «система работает» и «в компании что-то изменилось» нет владельца.
Подрядчик отвечает за первое: сдал, показал, закрыл акт. Заказчик выделил бюджет «попробовать» и считает, что попробовал. За второе не отвечает никто. Это не злой умысел ни с одной стороны — это дырка в постановке, которую легко не заметить, потому что формально все свои обязательства выполнили.
Выглядит это всегда одинаково. У пилота нет человека со стороны заказчика, который раз в неделю открывает реальный выход системы и говорит «вот это не то». Есть согласующий, который подписывает этапы. Роли разные: про эксперта заказчика я писал отдельно, без него мы построим технически чистую вещь, которая не нужна в таком виде.
Час в неделю. Это вся нагрузка на такого человека, и это единственное место в проекте, где я прошу заказчика не экономить.
Первые две недели все проверяют, потом перестают
Дальше включается механизм, который я долго считал своей личной особенностью, пока не полез в исследования.
На старте команда в режиме обсуждения: спорит, задаёт вопросы, тыкает в странные ответы. Вопрос здесь — цель, всем интересно, как эта штука себя поведёт. Потом проект переходит в режим выдачи результата, и вопросы начинают мешать. Каждое «а почему так?» — лишняя задержка между человеком и закрытой задачей. Их постепенно перестают задавать.
Переключение никто не объявляет. Оно утекает по чуть-чуть: сначала перестают перечитывать длинные ответы, потом доверяют выводам не глядя, потом отдают модели уже не работу, а само суждение — решение о том, туда ли всё идёт.
Это измерено. Microsoft Research вместе с Carnegie Mellon опросили 319 специалистов и разобрали 936 реальных случаев работы с ИИ. Результат прямой: чем выше доверие человека к ИИ на конкретной задаче, тем меньше он включает критическое мышление. А чем выше уверенность в собственной способности оценить ответ — тем больше.
Для руководителя отсюда практический вывод. Провал внимания на третьей неделе пилота — не разгильдяйство конкретных людей, а предсказуемое поведение. Планировать надо так, будто он обязательно случится.
Что автоматика ловит, а что нет
Автоматические проверки ловят поломки и не ловят ошибку решения. Это вторая по частоте причина, почему не работает внедрение ИИ: контур контроля построен вокруг работоспособности, а замысел не проверяет никто.
У нас на проектах стоит приличный обвес: одна модель проверяет другую, специально из разных семейств, сверху сквозные и обычные тесты. Как устроена проверка качества моделью-судьёй, я разбирал отдельно — механика там честная и работает.
И вот случай, из-за которого я вообще полез в эту тему. Месяц назад я делал очередного ассистента по продажам. Поток задач, отлаженный процесс, всё шло гладко — и я поймал себя на том, что просто жму «дальше». Перестал читать, что пишет модель: пробегал начало и выводы. Когда зашёл проверить накопившееся, увидел кашу. Формально всё зелёное, тесты прошли, перекрёстная проверка молчит. Ноль ошибок. При этом построено аккуратно и не то.
Ни одна автопроверка не спросила, зачем мы это делаем и туда ли идём. Это должен был спросить я.
Есть и прямое измерение того же эффекта. Исследователи Стэнфорда сравнили код, который люди пишут с ИИ-ассистентом и без: с ассистентом код выходил менее безопасным, а уверенность авторов в его безопасности — выше. Гладкий ответ маскирует ровно те дефекты, которые дороже всего ловить.
Моя личная самая частая боль даже не безопасность, а дубли. Модель не проверяет, есть ли уже готовая реализация, и лепит новую с нуля. В работе ИИ-команды это ловится на ревью, но только если ревьюер не в режиме «дальше».
Чем надёжнее система, тем тише контролёр
Логика подсказывает, что с сильной моделью должно быть легче. На практике наоборот, и это описано задолго до нейросетей.
Называется «ирония автоматизации», статья Лизанны Бейнбридж 1983 года. Чем надёжнее система, тем реже человек вмешивается, тем хуже держит навык вмешательства. А вмешиваться приходится в редких и самых сложных случаях — как раз тогда, когда навык уже просел. Самой надёжной автоматике нужен самый подготовленный оператор, который к этому моменту меньше всего практиковался.
Наложите сюда данные Microsoft и CMU: доверие к инструменту глушит критическое мышление. Чем сильнее модель, тем выше доверие, тем тише контролёр. Соблазн нажать «дальше» растёт вместе со способностями модели.
И отдельно — про то, почему нельзя опираться на ощущения участников. В эксперименте METR шестнадцать опытных разработчиков работали на своих же зрелых проектах. Они ожидали ускорения на 24%, по факту оказались на 19% медленнее и после замера всё равно были уверены, что ускорились на 20%. Оговорюсь: это инструменты начала 2025 года и очень специфическая выборка, сама METR называет результат снимком и в 2026-м получила обратный сигнал. Но интересна здесь не цифра, а разрыв между ощущением и замером. Если у пилота нет замера, вы получите ощущение.
Что зафиксировать до старта пилота
Если свести всё сказанное к списку, получится шесть пунктов. Их отсутствие и есть ответ на вопрос, почему не работает внедрение ИИ у большинства компаний, которые приходят ко мне после неудачного пилота. Все шесть умещаются на полстраницы и пишутся до первой строчки кода.
- Какой показатель меняем и чему он равен сегодня. Без сегодняшнего значения эффекта не будет видно, даже если он есть.
- Кто со стороны заказчика раз в неделю смотрит на выход и имеет право сказать «не то». Имя, не должность.
- Что мы делаем, если показатель не сдвинулся. Ответ пишется до старта, иначе пилот будут продлевать вместо того, чтобы закрыть.
- Где человек перестаёт перепроверять. Пока это не сказано вслух, люди перепроверяют всё, и экономии не возникает.
- Что происходит при ошибке модели и сколько она стоит. Ошибка в черновике письма и ошибка в цене — разные вещи, и контроль у них разный.
- Кто отвечает за процесс после пилота. Технология без владельца процесса тихо умирает через квартал.
Что мы отдаём модели, а что нет
Граница проходит не по сложности задачи, а по цене ошибки и по тому, кто её заметит.
| Отдаём и не проверяем каждый шаг | Не отдаём без человека |
|---|---|
| Черновики типовых документов | Решение, нужен ли этот процесс вообще |
| Разбор входящих по понятным правилам | Ответ клиенту, который создаёт обязательство |
| Первичная сортировка и разметка | Оценка стоимости и сроков |
| Сводка для человека, который примет решение | Всё, где ошибка стоит денег или репутации |
Левая колонка — то, где ошибка дешёвая и её видно сразу. Правая — то, где ошибку заметят через месяц и в чужом кабинете. Приблизительно так же мы разводим задачи внутри своей команды, когда собираем систему для клиента: бот отвечает на типовое сам, а всё, что похоже на торг или обещание, уходит человеку.
Почему не работает внедрение ИИ: короткий ответ
Дело не в том, что технология слабая. Пилот доказал работоспособность, а не эффект, и не нашлось человека, который отвечает за второе.
Лечится это до старта и стоит один разговор: показатель с сегодняшним значением, имя владельца результата, записанный заранее ответ на «что если не сработает». Дальше можно спокойно выбирать модель, подрядчика и архитектуру — эти решения важные, но они вторые.
А про инженерную сторону — какие прогоны мой собственный контроль качества пропустил и какими вопросами я вытаскиваю себя из режима «дальше-дальше» — пишу в канале @maslennikovigor. Там же выкладываю разборы неудачных запусков, которые в статьи не попадают.