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

ИИ-агента сделали за неделю. До результата компания шла 60 недель.

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

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

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

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

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

Именно поэтому проект может технически состояться, но управленчески не прижиться.

Доступ к ИИ ещё не равен изменению работы

Разница между личным использованием и организационным внедрением принципиальна.

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

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

Полевой эксперимент с 7 137 работниками в 66 компаниях хорошо показывает эту границу. У активных пользователей ИИ сократилось время на электронную почту примерно на два часа в неделю. Но исследователи не обнаружили изменений в количестве или составе выполняемых задач от одного лишь предоставления инструмента.

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

Ниже — семь ошибок, из-за которых внедрение остаётся набором демонстраций, лицензий и отдельных подвигов.

Карта внедрения: пять контуров одной системы

ИИ-пилот полезно рассматривать не как один технологический проект, а как пять связанных контуров. Если один из них пуст, нагрузка обычно переезжает в соседний: слабый процесс пытаются компенсировать обучением, отсутствие владельца — проектным офисом, а неясную ценность — количеством лицензий.

Контур	Что нужно определить	Что происходит, если этого нет
Бизнес-результат	Какой показатель процесса должен измениться	Пилот демонстрирует возможности, но не создаёт ценности
Процесс и роли	Что делает ИИ, что делает человек, кто принимает исключения	ИИ ускоряет хаос или создаёт новый слой ручной проверки
Владелец изменения	Кто отвечает за результат и вправе менять правила	Проект передают между ИТ, бизнесом, HR и контрольными функциями
Риск и контроль	Какие данные допустимы, как проверяется результат, когда систему останавливают	Ограничения обнаруживаются после прототипа или ошибки остаются незаметными
Навыки и масштабирование	Как люди учатся на реальных задачах и по каким критериям пилот расширяют	Возникает разовый энтузиазм без устойчивой рабочей практики

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

Ошибка 1. Начать с инструмента, а не с бизнес-проблемы

Самый соблазнительный вопрос звучит так: «Где мы можем применить ИИ?»

Он почти гарантированно производит длинный список идей. Суммаризация, поиск, аналитика, чат-бот, помощник, агент — дальше по алфавиту. Но наличие списка ещё не объясняет, зачем компании менять привычную работу.

Полезнее начать иначе:

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

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

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

ИИ способен ускорить плохой процесс. Это не всегда тот эффект, который стоит масштабировать.

Российские данные показывают, что это не отвлечённая проблема. ИСИЭЗ НИУ ВШЭ проанализировал обследование более 15 тысяч крупных и средних организаций — пользователей ИИ. Сложность интеграции технологии в бизнес-процессы, ограничения, связанные с законодательством, а также качество и подготовка данных остались значимыми барьерами примерно для каждой пятой компании.

Ошибка 2. Не назначить владельца результата

У ИИ-проекта часто много участников и мало хозяев.

ИТ отвечает за доступ и интеграцию. Информационная безопасность — за допустимые способы работы с данными. Юристы — за правовые риски. HR — за обучение. Функциональное подразделение предоставляет экспертов. Проектный офис собирает статусы.

А кто отвечает за то, что конкретный бизнес-процесс действительно изменился?

Владелец внедрения должен иметь не только имя в презентации, но и полномочия:

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

Если такой роли нет, проект быстро превращается в эстафету. Каждый качественно выполняет свой участок, но разрыв между участками остаётся ничейным.

Ошибка 3. Автоматизировать старый процесс, не меняя его логику

До внедрения ИИ полезно нарисовать не только техническую схему, но и реальный путь работы:

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

После появления ИИ часть этих ответов должна измениться. Если модель делает первичный анализ, нужен ли прежний объём ручной проверки? Если она выделяет исключения, кто и за какое время их рассматривает? Если сотрудник всё равно перепроверяет каждую строку тем же способом, экономии может не возникнуть.

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

Организационный дизайн здесь важнее красивого интерфейса. Нужно заново определить границу между машиной и человеком, а также права на решение, маршруты эскалации и ответственность за последствия.

Ошибка 4. Поздно подключить тех, кто отвечает за ограничения

Информационную безопасность, юристов, владельцев данных, закупки и архитектуру нередко приглашают после того, как прототип уже понравился руководству.

В описанном выше кейсе именно так и произошло. ИИ-решение уже разработали, согласовали с руководством, внедрили и закрепили регламентом. Только после этого служба безопасности запретила работу: использование доступных внешних нейросетей сочли небезопасным, а закрытого корпоративного контура не было. На решение вопросов безопасности ушло ещё шесть недель — в шесть раз больше, чем на разработку самого ИИ-решения.

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

Для проектной команды это выглядит как сопротивление прогрессу: «Мы уже всё сделали, а они опять запрещают».

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

Обе стороны действуют предсказуемо. А проект теряет месяцы.

Подключать контрольные функции в начале — не значит отдать им управление инициативой. Это значит заранее определить:

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

В рамке управления рисками ИИ NIST ответственность руководства, ясные роли, человеческий контроль и регулярный пересмотр рисков рассматриваются как постоянная часть жизненного цикла, а не как финальная проверка перед запуском.

Ошибка 5. Учить промптам вместо новой работы

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

Сотруднику нужно научиться не только формулировать запрос. Ему нужно понимать:

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

Иными словами, обучение должно происходить вокруг реальной работы, а не вокруг универсального набора «волшебных формул».

Исследование OECD среди малых и средних компаний в семи странах показывает разрыв между использованием и организационной готовностью: не более трети компаний, уже использующих генеративный ИИ, обучают сотрудников, вводят внутренние правила или изучают правовые и регуляторные вопросы. Внутренние правила были у 28,6% опрошенных пользователей ИИ.

Эти цифры нельзя автоматически переносить на любую страну и крупный бизнес. Но сам разрыв узнаваем: инструмент в компании уже есть, а общая практика работы ещё не сложилась.

Ошибка 6. Измерять активность вместо результата

Количество выданных лицензий, проведённых обучений и созданных прототипов удобно показывать на слайде. Но это показатели активности, а не ценности.

Для пилота лучше выбрать один процесс и заранее зафиксировать несколько разных типов показателей.

Результат процесса: время цикла, стоимость операции, доля возвратов, качество решения, удовлетворённость внутреннего или внешнего клиента.

Фактическое использование: в какой доле подходящих случаев сотрудники применили новый способ работы, а не просто один раз открыли инструмент.

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

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

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

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

Ошибка 7. Масштабировать решение до того, как организация научилась на пилоте

Успешная демонстрация создаёт опасное желание сразу «раскатать на всех».

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

• достаточно ли качественны исходные данные;
• понятны ли новые роли;
• выдерживает ли процесс реальные исключения;
• могут ли сотрудники проверить результат;
• не возникает ли скрытая дополнительная работа;
• согласованы ли правила с контрольными функциями;
• подтверждается ли эффект на повторяющихся задачах.

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

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

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

Минимальный паспорт ИИ-пилота

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

1. Какую проблему бизнеса мы решаем? Не «использовать ИИ», а изменить конкретный результат процесса.
2. Что именно делает ИИ, а что остаётся человеку? Где подготовка, где рекомендация, где решение и где контроль.
3. Кто владеет результатом? У кого есть полномочия менять процесс и договариваться между функциями.
4. Что изменится в ролях и правилах работы? Кто проверяет, принимает исключения, отвечает за ошибку и улучшает практику.
5. Какие ограничения известны до старта? Данные, безопасность, право, качество, интеграция и цена сопровождения.
6. Чему и на каких задачах учатся сотрудники? Не только запросу к модели, но и профессиональной проверке ответа.
7. Как мы поймём, что пилот стоит масштабировать? Исходная точка, целевой показатель, срок наблюдения и критерий остановки.

Если на половину вопросов пока нет ответа, это не повод отменять эксперимент. Это повод не называть его внедрением.

Практический инструмент: экспресс-аудит ИИ-пилота

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

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

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

Сначала попроси меня кратко описать:
1) бизнес-проблему и текущий процесс;
2) предполагаемую роль ИИ;
3) участников и владельца результата;
4) доступные данные, разрешённый технический контур и ограничения;
5) ожидаемый эффект и способ его измерения.

Затем задавай по одному уточняющему вопросу за раз, но не более семи.
Не додумывай отсутствующие факты: помечай их как «неизвестно».

После моих ответов подготовь таблицу из пяти строк:
- бизнес-результат;
- процесс и роли;
- владелец изменения;
- риск и контроль;
- навыки и масштабирование.

Для каждого контура укажи:
- что уже определено;
- главный пробел;
- возможное последствие;
- один следующий шаг до запуска пилота.

В конце сформулируй:
1) три наиболее опасных допущения проекта;
2) минимальный безопасный объём пилота;
3) критерии продолжения, остановки или переработки пилота.

Не оценивай проект как «хороший» или «плохой» без данных.
Отделяй факты, предположения и рекомендации.

Лучше запускать такой разбор дважды: сначала индивидуально, а затем на встрече владельца процесса, пользователей, ИТ и контрольных функций. Разница в ответах часто полезнее самого отчёта нейросети: она показывает, где участники считают целью разные результаты или по-разному понимают границы ответственности.

ИИ проявляет устройство организации

В проектах изменений технология часто работает как рентген.

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

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

Хорошая новость в том, что руководителю не нужно ждать идеальной готовности всей компании. Можно выбрать один значимый, но ограниченный процесс; собрать владельца, пользователей и контрольные функции; договориться о границах; провести честный пилот; измерить результат и только потом масштабировать.

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

И это не досадная задержка на пути к внедрению. Это и есть внедрение.

Полезные ссылки с дополнительной информацией

На русском языке

• ИСИЭЗ НИУ ВШЭ: «Применение искусственного интеллекта в российских компаниях» — данные обследования более 15 тысяч крупных и средних организаций, использующих ИИ.
• Банк России: «Итоги заседания Экспертного совета по управлению модельными и ИИ-рисками» — о жизненном цикле моделей, качестве данных, распределении ответственности и взаимодействии функций.
• Банк России: «Кодекс этики в сфере разработки и применения искусственного интеллекта на финансовом рынке» — отраслевая, но практически полезная рамка по качеству, контролю, конфиденциальности и управлению рисками.

Исследования и международные рамки

• Shifting Work Patterns with Generative AI — полевой эксперимент NBER.
• Generative AI and the SME Workforce — исследование OECD.
• NIST AI Risk Management Framework Core.
• NIST Generative AI Profile.

Больше материалов об ИИ, управлении и организационном развитии — в моём Telegram-канале «Мария Арманд ⚜️ Управление Оргразвитие ИИ».