Внедрение ИИ проваливается без перестройки работы

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

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

Опросы говорят о разрыве в исполнении, а не об отсутствии интереса

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

Опрос McKinsey State of AI 2025 показал, что почти девять из десяти респондентов регулярно применяли ИИ в своих организациях, однако почти две трети еще не начали масштабировать его на всю компанию. Только 6 процентов попали в категорию лидеров по версии McKinsey: для этого требовались значимая отдача и не менее 5 процентов влияния ИИ на EBIT. Самое полезное здесь не сам процент. В более раннем исследовании McKinsey 2025 года коренная перестройка рабочих процессов сильнее всего из 25 проверенных организационных факторов была связана с влиянием на EBIT. В более позднем опросе лидеры почти втрое чаще остальных перестраивали рабочие процессы.

Опрос Deloitte State of AI in the Enterprise 2026 среди 3235 руководителей бизнеса и ИТ показал тот же разрыв. Около 60 процентов работников получили доступ к разрешенным инструментам ИИ, но только 30 процентов организаций перестраивали вокруг ИИ основные процессы. Еще 37 процентов сообщили о поверхностном применении почти без изменений в самих процессах. Доступ к инструментам расширялся быстрее, чем менялась работа.

KPMG в американском опросе AI Quarterly Pulse за второй квартал 2026 года показала финансовую сторону той же проблемы. Больше половины опрошенных организаций применяли ИИ-агентов, но лишь 26 процентов видели эксплуатационные расходы на ИИ в реальном времени. Только 18 процентов связывали нескольких агентов в сквозные процессы. Панель с числом пользователей не ответит, приносит ли рабочий процесс деньги.

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

Пилот может быть успешным, когда внедрение уже идет к провалу

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

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

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

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

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

Выбирайте процесс с владельцем и экономическими границами

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

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

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

Оценивайте кандидатов по данным, которые можно собрать, а не по восторгу руководителей:

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

Сначала перестройте работу, потом выбирайте набор технологий

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

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

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

Решение покупать или создавать свое принимают после такой схемы. Покупайте продукт, когда процесс типовой, поверхность интеграции стабильна, а средства контроля поставщика подходят вашим правилам. Самостоятельно создавайте слой, который отличает ваш бизнес, если преимущество дают ваши данные, решения или способ работы. Большинству компаний нужно и то и другое: покупные модели и приложения под тонким собственным слоем контекста, правил, оценки и наблюдения. Создавать все с нуля слишком долго; отдать поставщику логику решений значит потерять возможность объяснять и улучшать результат.

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

Готовность данных задается договором, а не генеральной уборкой

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

IBM в исследовании CEO Study 2025 выяснила, что 72 процента опрошенных генеральных директоров считали собственные данные главным источником отдачи от генеративного ИИ, а половина сообщила, что быстрые вложения привели к появлению разрозненных технологий. Акцент на собственных данных мне близок, но такая формулировка иногда заставляет команды думать, будто больше данных всегда лучше. Небольшой набор собственных источников с версиями и ясными правилами доступа полезнее огромного индекса документов, за который никто не отвечает.

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

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

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

Контроль должен быть встроен в выпуск

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

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

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

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

workflow: refund_recommendation
owner: support_operations
metric: cost_per_resolved_case
authorized_data:
  - order_status
  - payment_state
blocked_actions:
  - issue_payment
  - change_customer_tier
human_approval:
  required_above_usd: 100
evaluation:
  policy_accuracy_min: 0.98
  restricted_data_leaks_max: 0
rollback:
  mode: disable_agent_keep_queue
review_cycle_days: 30

Точные пороги зависят от бизнеса, но сама форма заставляет дать полезные ответы. У процесса есть владелец и показатель. Доступ к данным перечислен явно. Действия по умолчанию запрещены. Приемочные тесты проверяют вред, а не только среднее качество. При откате ручная очередь сохраняется. Файл можно проверять вместе с изменениями программы, поэтому ограничения меняются вместе с поведением и не уходят в отдельную презентацию.

Центральная команда управления должна отвечать за общие правила, уровни риска, одобренную основу и требования к подтверждениям. Предметные команды должны отвечать за поведение процесса и результат. Полная централизация превращает группу контроля в очередь заявок; полная децентрализация заставляет каждую команду заново изучать безопасность, конфиденциальность, закупки и оценку. Рабочий вариант сочетает жесткие общие рамки и внедрение внутри подразделения.

Экономику рабочей системы нужно видеть по каждому результату

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

Вывод KPMG за второй квартал 2026 года, что только 26 процентов опрошенных организаций видели расходы на ИИ в реальном времени, показывает предсказуемую управленческую ошибку. Компании утверждают годовой бюджет платформы, докладывают об активных пользователях, а потом обнаруживают, что никто не может отнести переменные расходы к клиенту, процессу или результату. К этому моменту команды защищают показатели активности, а финансовый отдел задает вопросы о счете.

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

Следите за четырьмя слоями, но не превращайте внедрение в отдельный проект по измерениям:

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

Заявление о росте производительности требует решения о высвободившейся мощности. Если процесс освобождает 400 рабочих часов в месяц, назовите их новое назначение: больший объем, более быстрый сервис, ранее отложенная работа, отказ от части подрядчиков или сокращение команды за счет естественного ухода. Без такого решения экономия останется расчетной. В своей компании я перевел операционную работу с 25 человек на двух инженеров, усиленных ИИ, и сохранил объем выпуска и стабильность систем. Для этого пришлось менять ответственность и убирать работу, а не раздавать запросы к модели по прежней оргструктуре.

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

Сотрудники меняют привычки, когда руководители меняют стандарт работы

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

Кадровую проблему часто объясняют сопротивлением или нехваткой навыков. В исследовании KPMG за второй квартал 2026 года сопротивление сотрудников выросло, причем доверие и этические опасения упоминались чаще пробелов в умениях. Если считать любое возражение страхом, можно пропустить полезный сигнал о работе. Сотрудники обычно раньше проектного офиса замечают потерянный контекст, дублирование, риск для клиента и неверные стимулы.

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

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

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

За внедрение должна отвечать небольшая межфункциональная группа

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

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

Для одного или двух процессов используйте последовательность на 90 дней:

1. В дни с 1-го по 15-й измерьте исходный процесс, назначьте владельца, выберите показатель результата, определите риск и соберите представительные случаи. Откажитесь от кандидата, если процессом не управляет один владелец.
2. В дни с 16-го по 35-й перестройте процесс, задайте договоры о данных и права, создайте набор оценки, согласуйте пороги качества и стоимости. Проверьте самое рискованное предположение до полировки интерфейса.
3. В дни с 36-го по 60-й подключите узкий рабочий маршрут, записывайте каждый запуск, проверьте откат и работайте с обученной группой на настоящей очереди. Не скрывайте исключения ручными исправлениями.
4. В дни с 61-го по 90-й сравните результат с исходной точкой, уберите устаревшие этапы, измените роли и мощность, соберите доказательства контроля и расширяйте систему только при выполнении условий. Иначе сократите объем или остановитесь.

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

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

Масштабирование повторяет контроль, а не копирует пилоты

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

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

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

Для основателей и небольших компаний правила те же, даже если документов меньше. Team & AI Audit на oleg.is помогает найти экономию и нужные изменения работы до того, как компания возьмется за крупную перестройку. Задача аудита в том, чтобы связать оргструктуру, рабочий процесс, инструменты и экономику в одном решении.

Вывод опросов 2026 года не в том, что корпоративный ИИ провалился. Устарел простой показатель внедрения. Лицензии, запросы и пилоты показывают активность. О внедрении говорит повторяемая система, которая меняет работу, сдерживает ошибки, показывает расходы и назначает ответственного. Компании с таким определением выпустят меньше экспериментов и больше работающих процессов.