Почему ИИ-проект не взлетает: пять ошибок руководителя при работе с данными

ИИ-проект может остановиться не потому, что выбранная модель недостаточно точна. Часто причина появляется раньше — на уровне постановки задачи, ответственности и ожиданий. Если компания начинает с формулировки «внедрить ИИ», не определив, какое решение должно измениться и какой эффект считается достаточным, проект быстро превращается в набор разрозненных экспериментов.

Ниже — пять управленческих ошибок, которые стоит проверить до того, как проект потребует дополнительных ресурсов.

1. Проект начинается с технологии, а не с бизнес-задачи

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

Как распознать проблему

• цель описывают словами «автоматизировать», «ускорить» или «использовать ИИ» без уточнения процесса;

• не определён сотрудник или подразделение, которое будет применять результат;

• отсутствует исходная точка для сравнения: сколько времени, денег или ресурсов требует процесс сейчас;

• успех проекта оценивают по факту появления прототипа, а не по изменению рабочего процесса.

Как исправить

Сначала нужно сформулировать бизнес-задачу, а уже затем обсуждать технологию. Полезно зафиксировать четыре элемента:

1. Процесс: что именно должно измениться.

2. Пользователь: кто будет принимать решение или выполнять действие на основе результата системы.

3. Ожидаемый эффект: например, сокращение времени обработки, снижение числа ошибок или уменьшение объёма ручной работы.

4. Граница проекта: что не входит в первый этап.

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

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

2. Разрозненные источники принимают за готовые данные

Наличие большого объёма информации ещё не означает, что её можно использовать для ИИ-проекта. Данные могут находиться в разных системах, иметь несовместимые форматы, дублироваться, содержать пропуски или описывать один и тот же объект по-разному.

Проблема становится заметной, когда команда уже пытается обучать или тестировать модель, а затем выясняет, что нужные сведения нельзя стабильно извлечь или сопоставить.

Что проверить до разработки

• где физически находятся необходимые данные;

• кто имеет к ним доступ и на каких основаниях;

• в каком формате они хранятся;

• насколько регулярно обновляются;

• есть ли единые идентификаторы для сопоставления записей;

• как обрабатываются пропуски, дубли и противоречия;

• можно ли использовать данные с учётом требований безопасности и внутренних правил.

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

Как исправить

Составьте карту источников и проведите небольшой аудит на реальном фрагменте данных. Для каждого источника зафиксируйте назначение, формат, период обновления, качество, ограничения доступа и ответственного. Затем проверьте, можно ли связать источники между собой и получить минимальный набор, необходимый для пилота.

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

3. За данные никто не отвечает

В проекте могут участвовать ИТ-специалисты, аналитики, юристы и представители бизнеса, но это не означает, что у данных есть владелец. Без такой роли непонятно, кто устанавливает правила использования, согласует изменения и принимает решения, если данные неполные или противоречивые.

Техническая команда может обнаружить проблему, но не всегда имеет полномочия определить, какое значение считать правильным. Бизнес-подразделение, в свою очередь, может знать контекст, но не отвечать за доступность и структуру источника. В результате вопросы переходят от одной команды к другой, а сроки проекта растут.

Как распознать проблему

• никто не может быстро ответить, кто отвечает за конкретный набор данных;

• правила доступа существуют только в виде устных договорённостей;

• неизвестно, кто утверждает изменения в справочниках и форматах;

• ошибки обнаруживаются, но не имеют назначенного владельца и срока исправления;

• проект зависит от одного сотрудника, который хранит знания неформально.

Как исправить

Для каждого критичного источника назначьте владельца данных. Это не обязательно человек, который ежедневно работает с системой. Владелец должен иметь полномочия устанавливать правила, согласовывать доступ, определять требования к качеству и организовывать исправление проблем.

Полезно разделить роли:

• владелец данных отвечает за смысл, правила использования и приоритеты;

• технический ответственный обеспечивает доступность, интеграцию и защиту;

• пользователь процесса проверяет, пригоден ли результат для работы;

• команда проекта фиксирует требования, ограничения и обнаруженные дефекты.

Такое распределение не заменяет внутренние политики безопасности и юридическую проверку. Оно лишь делает понятным, кто принимает решение на каждом этапе.

4. Ожидания не сопоставляют с возможностями данных и модели

Руководство может ожидать почти полностью автоматизированного результата, хотя данные подходят только для подсказок или сортировки. Команда может обещать универсальное решение, хотя проверяла один узкий сценарий. Ещё одна распространённая проблема — считать демонстрацию на подготовленных примерах доказательством готовности к работе в реальных условиях.

Завышенные ожидания создают давление на проект: ограничения начинают восприниматься как временные недоработки, а не как характеристики выбранного подхода.

Как исправить

До разработки зафиксируйте ограничения в явном виде:

• какие типы задач система решает, а какие — нет;

• на каких данных и сценариях она проверяется;

• какие ошибки наиболее критичны;

• где требуется обязательная проверка сотрудником;

• какие требования к скорости, доступности и конфиденциальности являются обязательными;

• при каких результатах пилот нужно изменить или остановить.

Начинать лучше с ограниченного сценария, где можно сравнить работу системы с действующим процессом. Пилот должен проверять не абстрактную «способность ИИ», а конкретную гипотезу: может ли решение дать приемлемый результат при заданных ограничениях и встроиться в работу сотрудников.

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

5. Проект запускают без метрик

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

Какие метрики нужны

Набор показателей должен соответствовать сценарию, но обычно стоит рассмотреть несколько уровней.

Качество результата:

• точность или полнота ответа;

• доля ошибок критического типа;

• стабильность результата на разных категориях данных;

• доля случаев, требующих ручной проверки.

Влияние на процесс:

• время выполнения операции;

• количество обработанных случаев;

• доля операций, которые удалось выполнить без повторной работы;

• изменение нагрузки на сотрудников.

Экономика и риски:

• стоимость обработки одного случая;

• расходы на интеграцию и поддержку;

• влияние ошибок на клиентов или внутренние операции;

• соблюдение требований безопасности и правил доступа.

Принятие решения пользователями:

• как часто сотрудники используют результат системы;

• сколько рекомендаций принимают, исправляют или отклоняют;

• какие причины мешают включить решение в повседневный процесс.

Метрики нужно определить до запуска, чтобы не выбирать удобные показатели постфактум. При этом не стоит обещать эффект, который пока не подтверждён. На раннем этапе корректнее говорить о проверяемой гипотезе и диапазоне ожидаемых результатов, а не о гарантированной экономии.

Чек-лист ранней диагностики

Перед выделением дополнительных ресурсов проверьте проект по шести вопросам:

1. Цель: какую конкретную бизнес-задачу решает проект?

2. Источники: доступны ли необходимые данные, достаточно ли они качественны и совместимы?

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

4. Ограничения: что система не будет делать, где нужен контроль сотрудника и когда пилот следует остановить?

5. Метрики: как измеряются качество, влияние на процесс, затраты и риски?

6. Следующее решение: какие результаты приведут к масштабированию, пересмотру сценария или завершению проекта?

Если на несколько вопросов нет ответа, проблема, вероятно, находится не в нехватке дополнительных ресурсов для разработки. Сначала нужно устранить управленческую неопределённость. ИИ-проект получает больше шансов на результат, когда его начинают не с обещания «внедрить ИИ», а с проверяемой задачи, понятных данных, назначенной ответственности и заранее определённых критериев успеха.