Большинство неудачных ИИ-проектов срывается не по техническим причинам, а из-за решений, принятых заказчиком ещё до начала разработки. Двенадцать ошибок ниже сгруппированы по этапам, и общее у них одно: каждая обнаруживается значительно позже, чем совершается, и тем дороже, чем позже. Ошибки, относящиеся конкретно к ИИ-агентам, разобраны отдельно — в статье «Типичные ошибки при внедрении ИИ-агентов».
На этапе выбора процесса
1. Начали с ключевого процесса
Логика понятна: автоматизировать то, что важнее всего. Проблема в том, что у ключевого процесса максимальны и цена ошибки, и видимость провала.
Провал первого проекта редко воспринимается как «неудачно выбрали процесс» — его воспринимают как «ИИ у нас не работает», и следующую попытку откладывают на годы. Ключевой процесс — цель для третьего-четвёртого проекта, когда накоплен опыт.
2. Взяли несколько процессов сразу
Универсальное решение, закрывающее три задачи, кажется экономным. На деле оно дольше разрабатывается, сложнее принимается и рискованнее: провал любой из частей ставит под сомнение целое.
Один узкий сценарий даёт результат быстрее и служит основой для расширения по подтверждённому эффекту. Критерии отбора — в статье «Как выбрать процесс для первого ИИ-проекта».
3. Не зафиксировали показатель «до»
Самая дешёвая по стоимости и самая обидная по последствиям ошибка. Замер занимает немного времени, а без него эффект невозможно доказать: сравнивать не с чем, и спор о результате становится неразрешимым.
Показатель фиксируется до начала работ — потом восстановить его по памяти не получится, потому что память участников системно искажена в сторону их позиции. Подробнее — «Как измерить эффект от внедрения ИИ».
На этапе подготовки
4. Поверили опросу вместо проверки на выборке
На вопрос «в порядке ли у нас документы» почти всегда отвечают утвердительно. Это не обман: руководитель описывает то, как система задумана, а не то, чем она стала за годы.
Реальное состояние выясняется только на случайной выборке материалов — и обычно оказывается, что регламенты существуют в нескольких редакциях, а часть расходится с практикой. Проверка занимает часы, см. «Готовность данных к внедрению ИИ».
5. Пропустили проверку достижимости
Разработка началась до того, как выяснилось, получается ли нужное качество на ваших данных. Достижимая точность — свойство ваших материалов, а не мастерства подрядчика, и определить её обсуждением нельзя.
Пропуск этапа не отменяет вопроса, а переносит ответ на момент, когда деньги уже потрачены. Как устроена проверка — «PoC в ИИ-проекте».
6. Проверяли на идеальных данных
Выборку собрали из показательных примеров. Такая проверка всегда успешна и не говорит ни о чём: реальный поток отличается от отобранного не количеством, а составом — в нём есть плохие сканы, нестандартные формулировки и случаи, которых никто не предусмотрел. Именно на них решение и ломается.
На этапе разработки
7. Написали ТЗ через перечень функций
Классическое ТЗ построено на допущении, что функция либо работает, либо нет. ИИ-решение вероятностное: оно отвечает правильно на какую-то долю запросов, и эта доля — единственное, что имеет значение.
В результате документ детально описывает интерфейс и молчит о качестве ответов, то есть о том, ради чего проект затевался. Что фиксировать вместо функций — «Нужно ли ТЗ для ИИ-проекта».
8. Приняли работу по демонстрации
Приёмка прошла на показе, где система отвечала на вопросы, подобранные исполнителем. Это проверка не решения, а презентации.
Предметом приёмки должна быть доля правильных ответов на выборке, которую составил заказчик, с эталонными ответами от своего эксперта. Тот, кто делает систему, не должен определять экзамен для неё.
9. Не определили поведение при неуверенности
Вопрос, который пропускают чаще всего, а он важнее среднего процента точности. Система, честно отвечающая «не знаю» и передающая случай человеку, безопаснее системы с более высокой точностью, которая уверенно ошибается: первая ошибка видна, вторая — нет.
Механика уверенных ошибок разобрана в статье «Почему нейросеть выдумывает ответы».
На этапе запуска и эксплуатации
10. Не назначили внутреннего владельца
Подрядчик сделал, передать некому. Решение технически исправно и никем не используется, потому что нет человека, который определил бы новый порядок работы и добился перехода на него.
Владелец — не ИТ-специалист, а руководитель процесса: у него совпадают знание процесса, заинтересованность и полномочия. Подробнее — «Кто ведёт ИИ-проект внутри компании».
11. Не посчитали стоимость эксплуатации
У ИИ-решения переменная стоимость: каждое обращение стоит денег, и расходы растут пропорционально объёму. Прототип на десяти запросах ничего не говорит о счёте на тысячах.
Классический сценарий — решение технически успешно и экономически бессмысленно, потому что счёт сопоставим с зарплатой сотрудника, которого оно разгружало. Методика расчёта — «Сколько стоит эксплуатация ИИ-решения».
12. Запустили и оставили
ИИ-решение — не программа, которую один раз написали и забыли. Документы меняются, приходят новые типы обращений, модели снимаются с поддержки.
Коварство в том, что деградация незаметна: система продолжает отвечать уверенно, просто ответы постепенно перестают быть верными. Обнаруживается это обычно по жалобе клиента — см. «Сопровождение ИИ-решений».
Когда обнаруживается и во что обходится
| Ошибка | Когда всплывает | Цена |
|---|---|---|
| Начали с ключевого процесса | На запуске | Тема закрыта внутри компании надолго |
| Взяли несколько процессов | В середине разработки | Сроки и бюджет кратно вырастают |
| Не зафиксировали «до» | При отчёте о результатах | Эффект есть, финансирования продолжения нет |
| Поверили опросу | На подготовке данных | Смета по ключевой статье оказалась выдуманной |
| Пропустили проверку | После разработки | Стоимость всего проекта |
| Проверяли на идеальных данных | На пилоте | Повторная разработка |
| ТЗ через функции | На приёмке | Спор без разрешения |
| Приняли по демонстрации | Через месяц эксплуатации | Доработки за свой счёт |
| Не определили поведение при неуверенности | Когда ошибка дошла до клиента | Репутационный ущерб |
| Нет владельца | После передачи | Решением не пользуются |
| Не посчитали эксплуатацию | Первый счёт | Проект закрывают как нерентабельный |
| Запустили и оставили | Через полгода | Тихая деградация качества |
Закономерность видна: чем раньше по списку ошибка, тем позже она обнаруживается и тем дороже обходится. Именно поэтому этапность в ИИ-проектах существует не ради формальности — каждый этап это точка, где ошибку ещё можно поймать дёшево.
Частые вопросы
Какая ошибка при внедрении ИИ самая дорогая?
Пропуск проверки достижимости на реальных данных. Она обходится в стоимость всего проекта, потому что обнаруживается после разработки: выясняется, что нужного качества на этих материалах получить нельзя, и деньги уже потрачены. Сама проверка стоит несопоставимо меньше и защищает именно от этого сценария.
Правда ли, что большинство ИИ-проектов проваливается из-за технологий?
Нет, технологическая часть чаще всего работает. Срывы происходят на решениях заказчика: неудачно выбран процесс, не проверены данные, не назначен владелец, не посчитана эксплуатация, приёмка прошла по демонстрации. Это управленческие ошибки, и исправляются они управленческими средствами, а не сменой модели.
Можно ли исправить ошибку, если проект уже идёт?
Зависит от этапа. Не зафиксированный показатель «до» иногда восстанавливается по журналам систем; отсутствие владельца исправляется назначением; непосчитанная эксплуатация считается в любой момент. Труднее всего с непроверенной достижимостью и неудачно выбранным процессом — здесь честнее приостановиться и вернуться на шаг назад, чем достраивать решение, которое не даст результата.
С чего начать, чтобы не наступить на эти грабли?
С двух дешёвых действий: зафиксировать показатель «до» и проверить состояние данных на случайной выборке реальных материалов. Оба занимают часы, не требуют подрядчика и снимают значительную часть перечисленных рисков. Уже после этого имеет смысл разговаривать с исполнителями.
Наш подрядчик готов начать разработку сразу — это плохо?
Обычно да. Готовность приступить без проверки достижимости на ваших данных означает не расторопность, а перенос риска на вас: если качества не получится, потрачен будет ваш бюджет. Здоровая схема — отдельный оплачиваемый этап проверки с правом не продолжать. Отказ исполнителя от такой схемы сам по себе информативен.
Что дальше
Правильный порядок работ, снимающий большую часть этих ошибок, — «Этапы внедрения ИИ в компании». Что делать, если решение уже внедрено и не работает, — «Что делать, если ИИ-решение не работает». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Проверка процесса и данных до начала разработки — это аудит процессов, с которого начинается работа по разработке и внедрению ИИ.