BCG в исследовании «The Widening AI Value Gap» (октябрь 2025) разделил 1250+ глобальных компаний на три когорты — группы компаний, выделенные по общему признаку, в данном случае по уровню внедрения AI. Только 5% («Future-built» — «выстроившие AI в фундамент бизнеса») извлекают реальную ценность. Ещё 35% «начинают генерировать ценность» через масштабирование. Оставшиеся 60% — отстающие, у которых при значимых инвестициях в AI выручка и затраты почти не сдвигаются. В этом и состоит типовая ловушка: деньги в AI уже тратятся, а ценности на выходе нет. Считают не то, тратят не на то, не доводят до результата.

AI-внедрение проваливается не из-за плохой модели. Оно проваливается, когда у проекта нет полной картины затрат, нет владельца, который доведёт пилот до продакшна (production — промышленная эксплуатация, работающая система, которой пользуются сотрудники), и нет процесса, который переживёт энтузиазм первых людей.

McKinsey в State of AI 2025 даёт сухие цифры: 88% организаций регулярно используют AI хотя бы в одной функции (год назад — 78%), но материальный эффект на EBIT (Earnings Before Interest and Taxes — прибыль до вычета процентов и налогов; ключевой финансовый показатель, на который смотрит руководство) видят только 39%. И даже у этих 39% речь почти всегда идёт о менее чем 5% EBIT. Gartner в 2024 году прогнозировал, что к концу 2025-го около 30% проектов в области генеративного AI будут заброшены после стадии пилота; отраслевые данные 2025-го подтверждают оценку как минимум по верхней границе. Причины провала — низкое качество данных, неясная бизнес-ценность и та самая неполная картина затрат.

Защищаемый проект отличается от провального набором обязательных элементов. До старта пилота у него есть ответ на пять вопросов о TCO (Total Cost of Ownership — полная стоимость владения, все расходы за жизненный цикл решения). Есть именной владелец процесса. Есть переработанный рабочий процесс. И есть метрика, по которой через 90 дней измерят успех.

ПОЛНАЯ КАРТИНА ЗАТРАТ: КАТЕГОРИИ TCO БЕЗ СЛЕПЫХ ЗОН

McKinsey указывает на ключевое отличие лидеров: фундаментальный редизайн рабочих процессов. Компании-лидеры в три раза чаще переделывают процессы целиком — а не «накладывают AI поверх» готового конвейера. Они же в три раза чаще имеют «ownership» AI на уровне старших руководителей (C-level — руководители уровня CEO, CFO, CTO и т. п., то есть топ-менеджмент), запускают вдвое больше рабочих сценариев (конкретных задач, для которых применяется AI) и направляют больше трети цифрового бюджета на AI. Это прямой намёк на скрытую статью TCO: деньги уходят не столько на лицензии, сколько на перестройку процессов, найм, обучение и потерю производительности в переходный период.

В практических разборах корпоративного генеративного AI сходятся на трёх скрытых категориях затрат, которые чаще всего не попадают в исходный бюджет: интеграция с существующими системами, подготовка и очистка данных, сопровождение и обновление модели после запуска. По разным оценкам, они добавляют 25–40% к стоимости лицензий и инференса (inference — работа модели по генерации ответа на запрос; счёт за такие «вызовы» модели выставляет провайдер). Нет в TCO отдельной строки «подготовка данных» и «сопровождение после запуска» — бюджет занижен как минимум на четверть. Ту же оценку 25–40% мы увидим дальше, в разделе про интеграцию.

КАТЕГОРИИ ЗАТРАТ В СТРУКТУРЕ TCO AI

1: Инфраструктура и оборудование. Графические процессоры, локальные или арендованные мощности, хранилище, сеть, охлаждение — это CAPEX (capital expenditure — капитальные, разовые вложения в железо) или OPEX (operational expenditure — ежемесячная аренда). «У нас же облако» — классическая отговорка. Облачные расходы быстро обгоняют собственный дата-центр (локальный сервер компании, в IT-жаргоне часто именуемый «ЦОД», центром обработки данных), как только нагрузка растёт.

2: Лицензии и подписки. Подписки на модели через API (application programming interface — программный интерфейс, через который приложения обмениваются данными с моделью), лицензии на платформы (Microsoft Copilot, Google Vertex, AWS Bedrock — облачные платформы Google и Amazon для запуска AI-моделей; в России чаще используются Yandex Cloud и SberCloud). Это операционные расходы. Демо-доступ бесплатный. Продакшн-тарифы — совсем другие.

3: Данные и подготовка. Очистка, разметка, построение пайплайнов, выгрузка из устаревших систем, синтетика, наборы для оценки. В компаниях эту работу списывают на «задачу IT», но IT не владеет предметной областью — и результат выходит формальный.

4: Интеграция. API-шлюзы (программы-посредники между вашими системами и моделью), доработки ERP (системы планирования ресурсов предприятия — 1C, SAP и т. п.), CRM (системы управления клиентами — Bitrix24, AmoCRM и т. п.), helpdesk (служба поддержки), единый вход (single sign-on, SSO — одна учётная запись для всех систем), аудит, логирование, шифрование. «Подключим через API» — любимая фраза, за которой живут 25–40% стоимости всего решения.

5: Сопровождение и MLOps. Мониторинг качества, переобучение, обновления, дрейф модели (постепенное снижение качества модели со временем), исправления, дежурный инженер. В пилоте этим занимается энтузиаст на общественных началах. В продакшне нужен выделенный инженер.

6: Безопасность, комплаенс (соответствие требованиям закона и регуляторов), юристы. Защита от утечек, оценка рисков, политика данных, регуляторика (GDPR — General Data Protection Regulation, Общий регламент ЕС по защите данных; отраслевые нормы), юридический review. Регуляторные требования в генеративном AI подскочили с 28% до 38% как основной барьер — за один год.

7: Люди, обучение, управление изменениями. Обучение пользователей, пересборка процессов, потеря продуктивности в переходный период, найм ролей. «Люди и так разберутся» — типовая причина провала пилотов.

ТОЧКА ПЕРЕЛОМА: ОБЛАКО ДОРОЖЕ СОБСТВЕННОГО СЕРВЕРА

Миф «облако всегда дешевле» держится ровно до пилота. Дальше начинается другая арифметика: по разным отраслевым оценкам, локальное решение при нагрузке от десятков миллионов токенов в месяц и выше обходится дешевле. (Токен — минимальная единица текста, на которую модель разбивает запрос; для английского языка 1 токен ≈ 0,75 слова, для русского обычно чуть меньше.) Этот переход нельзя проскочить мимо: пилот в облаке дал результат, нагрузка в продакшне вырастает — и счёт за API приходит заново согласовывать с финансовым директором.

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

ВОПРОСЫ ПЕРЕД ЗАЩИТОЙ ПРОЕКТА У РУКОВОДСТВА

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

1: Сколько стоит лицензия и инференс? Это то, что знает вендор.

2: Сколько стоит интеграция с нашими системами? Это оценивает наша IT-команда.

3: Сколько стоит подготовка данных? Это оценивает владелец процесса, не вендор.

4: Сколько стоит переходный период, когда сотрудники учатся? Часто 20–30% производительности в первые 3 месяца.

5: Сколько стоит поддержка после запуска? Это 15–25% от первоначальных затрат ежегодно.

На все пять вопросов есть ответ с цифрами — проект можно защищать. На один-два есть «ну, примерно» — это ещё не проект, а только надежда на него.

ПИЛОТНЫЙ ЗАПУСК: ЖИВОЙ ПРОЕКТ ПРОТИВ МЁРТВОГО

В IT-практике три термина часто смешивают, и от смешения расползается бюджет. Proof of concept (PoC) — проверка технической возможности: «можем ли мы вообще сделать такое решение». Занимает дни или недели. Измеряется просто: получилось или не получилось.

MVP (minimum viable product) — минимально работающий продукт, который уже можно дать реальному пользователю и собрать обратную связь. Это не эксперимент, а ранняя версия сервиса.

Пилот — пробное внедрение AI в одном процессе на 30–90 дней, с реальными пользователями, метрикой и владельцем. Пилот ближе к MVP, чем к PoC: его цель не «проверить технологию», а «проверить, работает ли решение в нашем контексте». На временной шкале PoC измеряют неделями, MVP — месяцами, пилот — 90 днями.

Если в вашей компании «пилотом» называют трёхдневный эксперимент в Jupyter-ноутбуке, это ещё не пилот по смыслу этой главы. Это PoC, и для него действуют другие правила.

ЛОВУШКА «ИСПОЛЬЗУЮТ, НО ДЕНЕГ НЕ ВИДЯТ»

McKinsey State of AI 2025 даёт цифру, к которой мы ещё вернёмся в этой главе (в разделах про быстрые победы и про масштабирование она играет ту же роль): 88% организаций регулярно используют AI хотя бы в одной функции, 64% говорят, что AI помогает инновациям, но материальный эффект на EBIT видят только 39%. И даже у этих 39% речь почти всегда о менее чем 5%. Компании тратят, внедряют, обучают людей — а финансовый итог статистическая погрешность.

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

Исследование MIT 2025 года показало ту же картину с другой стороны: 95% корпоративных AI-инициатив не превращаются в ощутимый возврат вложенных денег. Причина не в плохих моделях и не в слабых данных — в отсутствии AI Operating Model, то есть организационной способности довести пилот до результата. Нужны выделенная роль владельца, согласованный бюджет, регулярная обратная связь и эскалация. В компаниях есть энтузиазм, есть технологии, есть выделенный бюджет — но нет машины, которая превращает эксперимент в работающий процесс. Большая часть «использования» — десятки изолированных пилотов в карманах отделов, которые не складываются в общую картину. Почему они зависают — разберём в разделе «что делать, если пилот удался, а масштабирование буксует».

БОЛЬШОЙ ПИЛОТ ПЕРЕСТАЁТ БЫТЬ ПИЛОТОМ

Миф «пилот нужно делать большим» стоит развеять сразу. Большой пилот — это уже не пилот, а внедрение, и у него сразу все риски масштаба, но без владельца и метрик.

Правильный пилот маленький: один процесс, один отдел, 30–90 дней. С лояльным заказчиком (тем, кто лично заинтересован в результате). Измеримый: метрика зафиксирована до старта. Что отличает пилот, который становится продакшном, от пилота, который зависает через 90 дней, — четыре обязательных элемента:

1: Владелец, который отвечает за результат перед финансовым директором. Не «AI-команда» в вакууме, а конкретный человек с именем, должностью и бонусом, зависящим от результата.

2: Метрика успеха, измеренная до старта. Не «посмотрим, как пойдёт», а «к 90-му дню NPS (Net Promoter Score — индекс лояльности клиентов и пользователей, от −100 до +100) должен вырасти на 5 пунктов, иначе откатываемся». Базовый уровень метрик (исходное значение, отправная точка) должен быть зафиксирован до пилота, иначе «до/после» нечего сравнивать.

3: План отката. Не «успех или провал», а «успех → масштабирование; провал → откат за 2 недели с минимальными потерями».

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

ПРИЗНАКИ ЖИЗНЕСПОСОБНОГО ПИЛОТА

Заголовок обещает пять признаков — вот они как чек-лист для самопроверки перед стартом.

1: Именной владелец с C-level поддержкой (C-level — руководители уровня CEO, CFO, CTO и т. п., то есть топ-менеджмент). Не «команда», а конкретный вице-президент или директор по направлению, у которого AI-проект стоит в KPI (Key Performance Indicator — ключевой показатель эффективности), а не среди «личных инициатив».

2: Базовый уровень метрик зафиксирован до старта. Цель поставлена, погрешность обсуждена, источник данных для измерения понятен. Без базового уровня любой результат пилота — трактовка, а не измерение. Метрика может быть любой: NPS (Net Promoter Score — индекс лояльности клиентов и пользователей, от −100 до +100), время обработки, процент ошибок, конверсия воронки.

3: «Тест на 30 дней». Есть ответ на вопрос «что мы увидим через месяц, чтобы понять, работает ли». Без промежуточной точки пилот либо умирает на 90-м дне от нетерпения, либо продлевается бесконечно.

4: «Кожа в игре» у конечного пользователя. Он либо выигрывает от успеха пилота, либо проигрывает от его провала — и об этом знает. Без этого пользователь воспринимает AI как «ещё одну систему, которую спустили сверху».

5: Явные критерии остановки. При каких именно показателях мы говорим «не сработало» и откатываемся. Без явных критериев остановки пилот живёт вечно и сжигает деньги.

ШАГИ ЗАПУСКА ПИЛОТА

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

2: Назначить владельца с C-level поддержкой и бонусом, завязанным на результат. Здесь и решается, будет ли пилот жить.

3: Измерить базовый уровень метрик успеха — NPS, время обработки, конверсия, процент ошибок — до старта пилота.

4: Сформулировать гипотезу в формате «через 90 дней метрика X вырастет на Y, потому что AI берёт на себя задачу Z». Без такой формулировки пилот превращается в «попробуем и посмотрим» — и через 90 дней никто не понимает, что измерять.

5: Собрать команду из 3–5 человек — владелец процесса, AI-инженер, IT-специалист, юрист, конечный пользователь.

6: Запустить пилот на 90 дней с еженедельной синхронизацией и ежемесячным отчётом. (30 дней — контрольная точка «Тест на 30 дней», 90 — финальная.)

7: Принять решение на 90-й день — масштабировать, откатить или пилотировать дальше с новой гипотезой. Без этого шага пилот становится бессрочным экспериментом.

СИГНАЛ ОСТАНОВКИ ПИЛОТНОГО ПРОЕКТА

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

1: Метрика не сдвинулась за 90 дней. X не вырос на Y — гипотеза не подтвердилась. Точка.

2: Стоимость выше плана в 2 раза и больше. Что-то посчитано неправильно. В продакшне станет дороже, а не дешевле.

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

4: Юридические риски не закрыты. Юристы не могут дать ответ «это безопасно по GDPR или 152-ФЗ (152-ФЗ — российский Федеральный закон «О персональных данных»)» — пилот нельзя масштабировать, а иногда и запускать.

5: Нет владельца. За результат пилота никто не отвечает — у пилота нет шансов выйти в продакшн.

ПРИЗНАНИЕ ПРОВАЛА: КАК СВЕРНУТЬ ПРОЕКТ БЕЗ ПОТЕРЬ

«Свернуть» — не значит «провалиться». Это нормальное и регулярное решение: McKinsey отмечает, что в зрелых AI-программах честно закрытых пилотов не меньше, чем успешно масштабированных. Чек-лист сворачивания:

– Зафиксировать причину отказа в реестре проектов одной строкой. «Гипотеза не подтвердилась», «нет владельца», «юридический блок», «саботаж пользователей». Без записи через полгода получите тот же пилот от того же энтузиаста.

– Сохранить артефакты пилота — данные, метрики, наработки моделей. Свёрнутый пилот — не провал в мусор, а инвестиция в следующую попытку.

– Откатить процесс к состоянию «до пилота» за 2 недели. На это нужно больше — значит, в пилоте не было плана отката. Это его собственный урок.

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

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

БЫСТРЫЕ ПОБЕДЫ: ОКУПАЕМОСТЬ AI ЗА 30 ДНЕЙ

Не все AI-применения требуют многомесячного внедрения. Быстрая победа в AI-внедрении определяется тремя признаками: результат виден за 30–60 дней, метрика считается «до/после» в конкретных цифрах, цена ошибки ничтожна для бизнеса. Это и есть управляемый риск: компания ставит на кон репутацию AI-инициативы в зоне, где ошибка процесс не убьёт.

Когда быстрые победы подают как «сделаем побыстрее, а там разберёмся», они превращаются в любительские эксперименты. Когда их подают как «сделаем в зоне низкого риска с заранее известной метрикой» — они становятся фундаментом доверия к зрелым проектам.

Миф «быстрые победы решают всё» так же опасен, как миф о большом пилоте. Быстрые победы финансируют зрелые проекты, но не заменяют их. Быстрая победа — вход в долгосрочное внедрение, а не его финальная форма. Она закрывает разрыв «мы что-то внедрили — и вот конкретная цифра, сколько это стоило и принесло». Без этой связки AI в компании превращается в инструмент энтузиастов, у которого нет защитников в коридорах власти.

Тот самый разрыв «88% используют — 39% видят EBIT», который мы зафиксировали в начале главы, и закрывается через быстрые победы. Каждая такая победа даёт руководству локальное доказательство, что AI окупается в конкретных цифрах.

Deloitte в State of Generative AI Q4 (опрос четвёртого квартала, 2773 респондента уровня директоров и C-level) пишет: 74% респондентов говорят, что их самая продвинутая инициатива в области генеративного AI «соответствует ожиданиям или превосходит их». Зрелые AI-проекты срабатывают чаще, чем проваливаются, — но только когда они доходят до зрелости. Быстрые победы и есть механизм, которым компания до зрелости доходит: они дают внутренние «истории успеха», из которых финансовый директор соглашается финансировать следующий шаг.

БЫСТРЫЕ ПОБЕДЫ С ОКУПАЕМОСТЬЮ ЗА МЕСЯЦ

Заголовок обещает пять побед — вот они в формате, который можно скопировать в план квартала.

1: AI-сводка почты. Включается в один клик в стандартных тарифах Gmail, Outlook или Яндекс Почты. Экономит 30 минут в день на сортировке входящих. Сотрудники видят выигрыш в первую неделю — и именно первая неделя формирует отношение к AI в команде.

2: AI-помощник во встречах. Granola, Otter, Microsoft Copilot или отечественные аналоги (например, Тинькофф AI, Yandex SpeechKit) записывают встречу, расшифровывают, делают саммари. Сотрудник, который раньше тратил 30 минут на протокол, теперь тратит 2 минуты на его проверку.

3: AI-помощник в написании. Claude, ChatGPT, Microsoft Copilot или GigaChat делают черновик письма, структуру документа, перевод, саммари длинного материала. Снимают «чистый лист» — автора не заменяют.

4: AI-классификация входящих запросов. Тикетов (заявок в системе поддержки), писем, заявок — сортирует 80%+ входящих автоматически. Запускается через платформы автоматизации без программирования: Zapier, Make (бывший Integromat) или Albato, n8n в российской среде.

5: AI-поиск по внутренней базе. RAG-бот (Retrieval-Augmented Generation — поиск по вашей базе знаний с генерацией ответа) подключается к Notion, Confluence, Google Drive или корпоративному wiki и отвечает на вопросы вида «где у нас политика по X». В России ту же роль играют поиск по корпоративному порталу на 1С-Битрикс или по базе в Яндекс Wiki.

ПЕРЕХОД БЫСТРОЙ ПОБЕДЫ В ДОЛГОСРОЧНЫЙ ЭФФЕКТ

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

1: Сотрудники сами просят больше. После первой недели приходят «а можно ещё AI для X» — это сигнал, что быстрая победа стала привычкой.

2: Метрика улучшилась и стабильна. NPS, время обработки заявки, процент ошибок, конверсия воронки — любая метрика, которая двигалась на пилоте и не падает обратно. Устойчива два месяца подряд — значит, это уже не «новизна», а процесс.

3: Появились «внутренние евангелисты». В команде 2–3 человека, которые обучают коллег и берут на себя роль «носителей метода». Без них эффект затухает, когда энтузиасты уезжают в отпуск.

4: Процесс задокументирован. «Как мы используем AI в этом процессе» записано в одном месте — wiki, инструкция, видео, — и новый сотрудник подхватывает практику за неделю. Без документации каждая ротация в команде обнуляет эффект.

5: Появились «гибридные» сценарии. Сотрудники сами нашли 2–3 новых использования AI, не запланированных изначально. Это признак, что AI-мышление привилось: люди видят процесс и сразу думают, какие его части можно отдать модели.

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

ЭТАПЫ СОЗДАНИЯ AI-АГЕНТА

McKinsey в State of AI 2025 фиксирует: 23% организаций масштабируют agentic AI (агентный AI — модели, которые не просто отвечают на запросы, а сами выбирают и выполняют цепочку действий: «запросить у системы X», «открыть файл Y», «отправить письмо Z») хотя бы в одной бизнес-функции, ещё 39% экспериментируют. Ни в одной отдельной функции доля масштабирующих не превышает 10%. Агентный AI находится в той же точке, где в 2023-м были чат-боты: масса экспериментов, мало внедрения. Процесс создания агента нужен именно затем, чтобы перевести эксперимент в масштабируемое решение. Без процесса каждый агент — ручная работа, и компания упирается в потолок «сколько рук хватит».

LangChain — популярный фреймворк с открытым исходным кодом для разработки AI-агентов — в документации по жизненному циклу агента формулирует центральную мысль: разница между одноразовыми демо агентов и повторяемой практикой — наличие жизненного цикла разработки. McKinsey в Superagency 2025 подчёркивает то же, что мы уже видели в разделе про TCO: компании-лидеры не «накладывают AI поверх», а переделывают процессы с нуля. Самый сильный вклад в создание ценности — переделка рабочего процесса, а не выбор модели. Самые успешные AI-инициативы начинаются с процесса, не с модели.

ШАГИ ПРОЦЕССА СОЗДАНИЯ АГЕНТА

Этап 1. Процесс и метрики. Описываем процесс, который отдаём агенту, считаем метрики, согласовываем владельца. На выходе: описание процесса, 2–3 KPI, именной владелец. Типовая ловушка — пропустить этап и сразу перейти к выбору модели: в продакшне выясняется, что решали не ту задачу.

Этап 2. Границы возможностей. Решаем, что агент делает сам, что не делает, куда обращается за человеком. На выходе: контракт «внутри / снаружи» с зоной автоматизации, зоной human-in-the-loop (шагов, где человек обязательно подтверждает решение агента), жёстким запретом и контуром данных. Если границы слишком широкие, один из десяти случаев даёт дорогой промах, и весь проект получает ярлык «опасный».

Этап 3. Мультимодельность. Выбираем модели по задачам, потому что одна универсальная модель для всего — это переплата в 5–10 раз. Минимальная раскладка:

Если гоните весь трафик через одну топовую модель, платите в 5–10 раз больше, чем нужно.

Этап 4. Память и контекст. Проектируем, что агент помнит между сессиями и в рамках одной задачи. Уровни памяти:

– Системный промпт (роль, правила, ограничения) — загружается на каждый запрос.

– Краткосрочная память — текущий диалог.

– Долгосрочная память — профиль пользователя, история взаимодействий.

– Внешние знания — документы, к которым агент обращается через RAG.

– Код и инструменты — то, что агент вызывает сам через function calling (механизм, при котором модель не просто генерирует текст, а возвращает структурированный вызов внешней функции: «открой файл», «запроси данные у CRM», «отправь письмо»).

Anthropic (компания-разработчик модели Claude) в материале про Agent Skills формулирует принцип progressive disclosure (постепенной загрузки): на старте агент видит только метаданные доступных навыков (скиллов), полное тело скилла подгружается, когда агент понимает его релевантность задаче, дополнительные файлы — по запросу. Контекст фактически безграничен, если правильно его структурировать. Если загрузить в контекст всё подряд, качество падает, задержка растёт, стоимость улетает.

Этап 5. Запуск и обратная связь. Развёртываем агент с мониторингом качества и механизмом коррекции. Что мониторим: задержку ответа (latency — время между запросом и ответом), процент ошибок, процент автозавершений, качество ответов через оценочный набор (тестовый набор запросов с эталонными ответами), пользовательский опыт, стоимость, безопасность через DLP (Data Loss Prevention — система предотвращения утечек данных, ловит попытки отправить наружу персональные данные или коммерческую тайну) и audit log (журнал аудита — кто, когда, что запросил, какой ответ получил). На выходе: агент в продакшне, панель мониторинга с ключевыми метриками, цикл улучшений. Агент, которого «запустили и забыли», деградирует за 2–3 месяца, данные уезжают, привычки пользователей меняются, модель устаревает.

ПОРЯДОК ВНЕДРЕНИЯ: ПРОЦЕСС ИЛИ МОДЕЛЬ

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

ЗНАЧЕНИЕ ПРАВИЛЬНОГО ПОРЯДКА ВНЕДРЕНИЯ

Пять этапов создания AI-агента — последовательность, а не чек-лист альтернатив. Сначала решаем, что готовим (процесс и метрики). Потом — что агент делает сам, а что нет (границы). Потом — какие модели под какие шаги (мультимодельность). Потом — как агент хранит контекст (память). Потом — как запускаем и пробуем (запуск). Большинство провалов в AI-кухне — попытка смешать специи, не зная, что готовишь. Рецепт первичен, ингредиенты вторичны.

Без ADKAR (модели изменений, которая подробно разобрана далее в этой главе) технически работающий агент умирает от сопротивления. С ADKAR — обрастает амбассадорами. До запуска нужно рассказать, что агент появится и зачем. Показать, что он снимает рутину, а не отбирает работу. Обучить, как с ним разговаривать и что ему можно отдавать. Дать время и поддержку, чтобы люди привыкли. Показывать эффект и хвалить тех, кто пользуется. Пятиэтапная цепочка без ADKAR делает продукт, который никто не открывает.

Рецепт первичен, ингредиенты вторичны. И в процессах, и в изменениях.

УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ: ЛЮДИ КАК ГЛАВНЫЙ РИСК AI-ВНЕДРЕНИЯ

Prosci (компания-разработчик методологии управления изменениями, основанная Джеффом Хиаттом в 1994 году) в декабре 2024-го опросил 1107 профессионалов и сформулировал ключевой вывод: AI-внедрение проваливается не на технологии, а на людях. 63% организаций называют человеческие факторы основной причиной сложностей при запуске AI, и эта цифра перевешивает любой технический аргумент. Самые тяжёлые узлы — недостаточная спонсорская поддержка со стороны первых лиц (43% респондентов), отсутствие обучения (38%) и страх потери работы, который никуда не девается, если его не называть вслух.

Любопытна структура страхов. 65% опрошенных верят, что генеративный AI повысит их личный успех, 73% ждут, что организация в целом станет успешнее — и при этом 22% признаются, что обучение AI «повесило» на них кривую входа, с которой они не справились. Этот разрыв между «я верю в эффект» и «я не справляюсь с кривой» и есть зона работы менеджера изменений (специалиста по управлению изменениями). На стороне заказчика это значит, что управление изменениями — не вспомогательная услуга, а одна из трёх опор проекта наряду с моделью и инфраструктурой.

ADKAR: МОДЕЛЬ, НАЧИНАЮЩАЯСЯ С ОДНОГО ЧЕЛОВЕКА

ADKAR — пятибуквенная модель изменений, которую Джефф Хиатт (Jeff Hiatt) — основатель компании Prosci и её методологии управления изменениями — вместе с командой Prosci оттачивали с 1990-х годов. Буквы означают пять стадий: осознание необходимости (Awareness), желание участвовать (Desire), знание (Knowledge), способность применить (Ability), закрепление нового поведения (Reinforcement).

Особенность модели — она работает на индивидуальном уровне. Миф «ADKAR — это про HR, не про AI» не выдерживает проверки: ADKAR про изменения вообще, и AI здесь только самое свежее из того, что меняется в организациях. Тот же фреймворк работает для внедрения CRM, перехода на новую ERP, переезда в новый офис — везде, где у людей меняется привычка. AI не делает ADKAR «про HR», а делает его центральным для любого технологического внедрения.

«Команда приняла AI» — фикция, потому что принятие происходит по одному человеку, а командный эффект возникает потом как сумма индивидуальных. Когда руководитель говорит «мы внедрили», я переспрашиваю: «А конкретно Маша из бухгалтерии — она вчера открыла ChatGPT по рабочей задаче?» Если ответ «нет» — значит, внедрения ещё нет, есть только запись в реестре проектов.

В AI-проекте ADKAR раскладывается на конкретные действия.

На стадии Awareness лидер говорит сотрудникам, что происходит в отрасли и какие потери несёт статус-кво (текущее положение дел). На языке их повседневной работы, а не на языке презентации для совета директоров.

На стадии Desire менеджер разговаривает лично с каждым ключевым сотрудником и отвечает на вопрос «а что со мной будет» не шаблоном, а фактом.

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

На стадии Ability сотрудник пробует на своей задаче под присмотром более опытного коллеги.

На стадии Reinforcement новое поведение закреплено средой: KPI пересмотрены, регламент упоминает AI, история успеха видна коллегам.

Эти пять стадий идут последовательно: нельзя пройти Knowledge, минуя Awareness, — иначе обучение ляжет в голову мёртвым грузом. McKinsey в январском 2025 отчёте Superagency in the Workplace подчёркивает: большинство организаций застревает на Awareness и Desire, потому что лидеры стесняются вести эмоциональный разговор с командой. Это и есть типовая причина провала — не нехватка денег, а нежелание руководителя выглядеть «слишком человечным».

У каждой стадии ADKAR есть свой индикатор провала. На Awareness провальный ответ на вопрос «зачем нам AI» — «ну, приказ». На Desire индикатор хуже: HR-отдел пишет «AI — это возможность для всех», а люди слышат «нас будут сокращать». Желание проверяется не словами, а действием: открыл ли человек чат в рабочее время хотя бы раз, без принуждения, на своей задаче. На Knowledge провальный признак — каждый пишет промпты по-своему, нет общей библиотеки, юристы узнают о рабочих сценариях последними. На Ability — после обучения прошло два месяца, а инструмент не используется в реальных задачах. На Reinforcement — через квартал после успешного пилота команда вернулась к старым регламентам, потому что KPI не были пересмотрены.

BANI: ПРИЧИНА, ПО КОТОРОЙ ПЛАНЫ ПЕРЕСТАЮТ РАБОТАТЬ

В 2018 году исследователь будущего (футуролог) Жаме Касио (Jamais Cascio) предложил заменить привычную аббревиатуру VUCA (Volatility, Uncertainty, Complexity, Ambiguity — нестабильность, неопределённость, сложность, неоднозначность) на BANI: Brittle, Anxious, Non-linear, Incomprehensible — хрупкость, тревожность, нелинейность, непонятность. Логика смены простая: VUCA предполагал, что с неопределённостью можно справиться, подождав; BANI говорит, что ждать нечего — события приходят быстрее, чем мы их осмыляем. Хрупкий мир не качается, как маятник. Он трескается, как старая высохшая кость: снаружи кажется прочным, но один излом — и вся конструкция рассыпается. AI-проект ломается так же: снаружи всё выглядит надёжным, но один излом — отозванный API-ключ, изменение регламента, перевод ключевого сотрудника — и пилот встаёт.

Лучшая иллюстрация BANI для AI-проекта — не землетрясение в Японии, остановившее конвейеры в Детройте, а более привычная ситуация: вендор (поставщик решения) отзывает API-ключ (секретный идентификатор доступа к API), и пилот, который работал три месяца, встаёт за один день. План, который писался полгода, к моменту запуска устарел. Сотрудник, который неделю назад считал AI перспективным, сегодня тревожится из-за слухов о сокращениях. Маленький пилот в одном отделе, который прекрасно работал, ломается при переносе в другой — между отделами есть невидимая связь, как в цепочке поставок.

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

СОПРОТИВЛЕНИЕ СОТРУДНИКОВ: СИМПТОМ, А НЕ САБОТАЖ

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

1: Человек не понимает, что с ним будет дальше — и сопротивляется, чтобы не оказаться в ловушке.

2: Человек пробовал и обжёгся, а ему никто не помог — и он заранее не верит, что вторая попытка будет другой.

3: Человек видит, что его роль меняется, и никто не предложил ему новую — и он защищает старую, потому что больше нечего защищать.

Deloitte в четвёртом издании State of AI in the Enterprise (2024) зафиксировал парадокс, который переворачивает стандартный ход мысли: организации с лучшими результатами по AI сообщают о страхе сотрудников в два раза чаще, чем аутсайдеры. Бина Амманат (Beena Ammanath), автор исследования и руководитель Deloitte AI Institute, объясняет: страх в этих компаниях сочетается с доверием и поддержкой, и это работает. Страх — признак сильного видения. Проблема не в страхе, а в отсутствии поддерживающих действий рядом с ним. Там, где страх остаётся один, он превращается в саботаж. Там, где рядом со страхом есть обучение, прозрачность и ясные «красные линии» про роли, страх становится топливом для изменений.

Самый опасный слой сопротивления — не явный, а молчаливый. Тим Кризи (Tim Creasey), директор по инновациям Prosci, работает в управлении изменениями 25 лет и снова и снова получает один и тот же результат: предиктор успешного изменения — не методология, не инструмент, не бюджет, а активное и видимое спонсорство.

Спонсор в AI-проекте — руководитель, который сам открыто пользуется AI на совещаниях и в рабочей переписке. Не тот, кто подписал указ о внедрении и вернулся к операционке (операционным задачам и управлению текущими процессами). Если спонсор не появляется в эфире, его команда считывает сигнал «AI — для пролетариев, а я как-нибудь переживу».

Следующий опасный слой — менеджеры среднего звена. Свежие данные Gartner (2024) показывают, что они сопротивляются чаще, чем линейные сотрудники: у линейных нет рычагов, чтобы блокировать, а у мидл-менеджера (менеджера среднего звена) рычаг есть — он решает, давать ли подчинённому время на эксперимент или нет. Если мидл-менеджер не вовлечён, проект умирает в его календаре.

Спонсор должен быть видимым. Мидл-менеджер — вовлечённым. Без этого нет внедрения, есть только реестр проектов.

ПРАВИЛО 10-20-70: БЮДЖЕТ КАК РЕШАЮЩИЙ ФАКТОР

BCG в октябре 2024 года выпустил отчёт Where’s the Value in AI и сформулировал правило 10–20–70: 10% успеха приходит из алгоритмов, 20% — из данных и технологий, 70% — из людей и процессов. Эта пропорция противоречит интуиции технических специалистов, которые по привычке вкладываются в модели и GPU. Она же объясняет, почему пилоты работают, а масштабирование нет: на пилоте есть энтузиазм первых людей, на масштабе — рутина второй сотни сотрудников. McKinsey в Superagency in the Workplace 2025 подтвердил: компании, в которых AI-инструмент становится частью повседневной работы, в 3,4 раза чаще получают материальный эффект на уровне P&L (отчёт о прибылях и убытках), чем компании, где AI «доступен, но не используется».

Практический вывод простой: бюджет проекта должен распределяться в той же пропорции 10–20–70. 80% бюджета ушло на модели, лицензии и инфраструктуру, а 20% — на обучение, коммуникации и управление изменениями? Проект покажет блестящий пилот и мёртвое внедрение. Это не вопрос «софт-скиллов», это вопрос распределения денег. Deloitte добавляет важную цифру: компании, инвестирующие в управление изменениями, в 1,6 раза чаще сообщают, что AI-инициативы превзошли ожидания. Для разговора с финансовым директором этого достаточно: управление изменениями — не гуманитарная помощь команде, а инвестиция с измеримой отдачей.

Деньги решают. Куда они идут — туда и проект.

ОБУЧЕНИЕ ПРОМПТАМ ВНУТРИ МОДЕЛИ ADKAR

Когда обучение промптам выносят в отдельный двухчасовой вебинар и закрывают тикеты (заявки в системе поддержки) в Jira (система управления задачами, используемая в IT-командах), через полгода отдел получает 15 личных «лучших практик» внутри одной команды и ноль общих — между отделами. Правильный подход встраивает промпт-обучение в стадии Knowledge и Ability модели ADKAR. Knowledge — не список приёмов, а общий словарь команды: что считаем контекстом, что — критерием качества, как формулируем ограничения по данным и конфиденциальности. Ability — регулярная сессия разбора реальных кейсов, где люди показывают, что у них не получилось, и разбирают вместе с более опытным коллегой.

Microsoft и LinkedIn в майском 2024 Work Trend Index (ежегодный отчёт Microsoft и LinkedIn о трендах рабочего места) опросили 31 000 человек в 31 стране и зафиксировали разрыв: 75% знаниевых работников уже пользуются AI, но только 39% получили обучение от работодателя. 78% AI-пользователей приносят инструменты на работу сами — явление, которое в отчёте называется BYOAI (Bring Your Own AI, «принеси свой AI на работу»), — а 52% стесняются признаться, что используют AI для важных задач, и 53% опасаются, что AI в важной работе делает их «заменимыми» в глазах руководства. Эти цифры объясняют, почему нельзя отдавать обучение на откуп сотруднику: он уже учится сам, но в режиме скрытности и стресса, что хуже, чем не учиться вообще. В 2024–2025 году на рынке появились готовые программы: Google выпустил бесплатный курс Prompting Essentials («Основы промптинга») на Coursera, Anthropic открыл Academy с интерактивным туториалом, OpenAI в марте 2025 запустил OpenAI Academy с 80+ курсами. Инструменты есть, осталось привязать их к процессу изменений, а не считать курсы ради курсов.

РОССИЙСКАЯ СПЕЦИФИКА УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ

Российская корпоративная культура отличается от западной тремя вещами, которые ломают стандартные рецепты управления изменениями. Первая — глубина иерархии. В средней российской компании с 500+ сотрудников решения о новых инструментах согласуются по цепочке из 3–5 уровней, и AI-пилот без визы генерального директора воспринимается как самодеятельность. Это удлиняет Awareness-фазу, но и даёт ей вес: когда виза получена, сотрудники не сомневаются в серьёзности намерений, что сокращает время на Desire-фазе.

Вторая — культ согласований. В BANI-мире, где API-ключ могут отозвать завтра, классический российский регламент «согласовать с юристами, безопасниками, ИТ и операционкой (операционным отделом)» делает проект нежизнеспособным. Пока идёт согласование, условия рынка меняются. Работающая практика — выделить «доверенный контур» для AI-пилотов (узкий круг данных, узкий круг сценариев, узкий круг согласующих) и не согласовывать его как полноценный продукт.

Третья — низкий риск-аппетит к AI на уровне топ-менеджмента при высоком интересе на уровне линейных сотрудников. Российские руководители опасаются двух вещей: утечки данных через зарубежные сервисы (особенно после 2022 года) и публичного скандала с «AI заменил людей». Это значит, что внутрикорпоративная коммуникация должна заранее, до запуска пилота, закрывать эти два страха конкретными мерами: список разрешённых сервисов, политика по чувствительным данным, публичные «красные линии» про роли, которые точно остаются у человека.

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

Т-Банк ещё в 2023–2024 годах запустил массовое внутреннее обучение сотрудников промпт-инжинирингу, а к 2025-му встроил AI-инструменты в ежедневные процессы колл-центра, разработки и маркетинга. Ключевая деталь, на которую ссылаются внутренние спикеры Т-Банка на профильных конференциях, — модель «снизу вверх, а не сверху вниз»: в каждом департаменте назначен «амбассадор AI», который прошёл углублённое обучение и помогает коллегам.

Сбер действует по противоположной модели. AI-трансформация спонсируется первыми лицами, через CDTO (Chief Digital Transformation Officer — директор по цифровой трансформации), с публичной отчётностью по метрикам. На конференции AI Journey в 2024 году Сбер показал сборник из 39 кейсов в области ESG (Environmental, Social, Governance — экологические, социальные и управленческие стандарты), и в большинстве из них фигурирует централизованный подход с сильной ролью спонсора.

М.Видео и X5 Retail Group (ритейлер, управляющий сетями «Пятёрочка» и «Перекрёсток») пошли третьим путём: точечные пилоты в логистике и клиентском сервисе без публичной «AI-стратегии», с упором на измеримую экономию.

Все три модели работают, но требуют разного типа менеджера изменений: в Т-Банке — фасилитатор сообщества, в Сбере — руководитель программы, в ритейле — узкий интегратор на стыке бизнеса и ИТ.

РАССЛОЕНИЕ ВОСПРИЯТИЯ AI ВНУТРИ КОМАНДЫ

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

По возрасту разрыв умеренный. Microsoft и LinkedIn в Work Trend Index 2024 показали, что BYOAI практикуют Gen Z (рождённые после 1996 года, «зумеры») — 85%, Millennials (1981–1996, «миллениалы») — 78%, Gen X (1965–1980, «поколение X») — 76%, Boomers+ (старше 1964 года, бэби-бумеры и старше) — 73%. Разница между Gen Z и Boomers+ — всего 12 процентных пунктов, не разлом, а плавный спуск. Это первый миф, который нужно сломать: «молодёжь впереди, старики позади» — картина для лекции, не для офиса. Важнее другое: 52% AI-пользователей скрывают это на важных задачах, 53% боятся выглядеть заменимыми. Эти две цифры не зависят от возраста, они зависят от культуры. В одной и той же команде молодой аналитик и 55-летний руководитель могут скрывать AI по одной и той же причине — и скрывать одинаково успешно. Стратегия «обучим молодёжь, она заразит остальных» не работает, потому что молодёжь скрывает, а не делится.

По должности разрыв жёсткий. BCG в AI at Work 2025 выявил «кремниевый потолок» — по аналогии со «стеклянным потолком», невидимый барьер, ограничивающий использование AI: 75%+ руководителей и менеджеров используют генеративный AI несколько раз в неделю, а среди линейных сотрудников тот же показатель — 51%, и он застрял. Это не поколенческий разлом, а иерархический. Внутри одного возраста разрыв между руководителем и подчинённым больше, чем между поколениями. Руководитель использует AI, чтобы быстрее готовить решения; подчинённый — чтобы быстрее выполнять задачи, и если задачи не пересмотрены, ускорение ему не нужно. BCG также показал, что сотрудники, получающие поддержку руководителя, демонстрируют позитив по отношению к генеративному AI на уровне 55%; без поддержки — 15%. Этот разрыв в 40 процентных пунктов — прямой вызов мифу «AI захотят все сами». Не захотят. Захотят те, у кого руководитель показывает, что пользоваться AI — норма, а не подозрительное отклонение.

По глубине использования картина перевёрнута по сравнению с шириной. Анализ данных McKinsey State of AI 2025 показывает: 62% миллениалов (35–44 года) называют себя «экспертами в AI», 50% Gen Z дают ту же самооценку, и только 22% бумеров (бэби-бумеров). Это контринтуитивно: в популярной картинке Gen Z — цифровые аборигены, которые щёлкают AI-инструменты как орешки, а миллениалы — осторожные пользователи. McKinsey показывает обратное. У миллениалов больше рабочего контекста, в который AI можно приложить, поэтому они видят результат и оценивают себя выше. Gen Z часто пользуется AI в личных сценариях, но не умеет переносить навык на рабочие задачи — и честно ставит себе 50%.

Microsoft в Work Trend Index 2025 добавляет ещё одно измерение: сотрудники младше 40 активнее используют AI для создания нового контента и brainstorming, сотрудники старше 40 — для проверки и редактирования уже готового материала. Молодёжь берёт AI как генератор идей, опытные — как критический фильтр. Когда компания внедряет единый шаблон промпта, она часто навязывает либо первый стиль (молодёжь чувствует себя обесцененной), либо второй (опытные чувствуют, что им предлагают костыль).

ГРУППЫ ВОСПРИЯТИЯ AI ВНУТРИ ОДНОЙ КОМАНДЫ

Молодёжь (до 30). Ширина охвата очень высокая, глубина низкая: часто пробуют, не доводят до результата. Мотив — любопытство и FOMO (Fear of Missing Out — страх упустить важное), страх — выглядеть поверхностным. С ними работают через «быстрые победы» с метрикой и приглашение демонстрировать коллегам.

Миллениалы (30–45). Ширина высокая, глубина средняя: освоили рабочие сценарии. Мотив — профессиональное развитие и страх отстать от рынка. С ними работают через назначение амбассадорами пилотов и истории успеха.

Опытные (45–60). Ширина средняя, глубина высокая: точечно, для проверки и оптимизации. Мотив — снижение рутины и удержание экспертизы, страх — потерять уникальность. С ними работают через роль «критического фильтра», подчёркивая их роль.

Руководители. Ширина очень высокая, глубина средняя (часто делегируют). Мотив — скорость решений и статус, страх — выглядеть отставшим перед молодыми. С ними работают через публичное использование AI на совещаниях.

Линейные сотрудники. Ширина низкая, глубина низкая. Мотив — гипотетически, сохранить работу и доход; страх — увольнение. С ними начинают с показа, что задачи останутся у человека.

ВОПРОСЫ ДЛЯ ИНТЕРВЬЮ ПЕРЕД ЗАПУСКОМ AI-ПРОЕКТА

Пять вопросов, которые дают картину, которой не дают ни опросы, ни метрики использования: реальный разрыв между «AI не для меня» и «AI не для нас». Эти пять вопросов работают только в доверительной обстановке — задавайте их один на один, без HR и без протокола.

1: Какие задачи вы делаете вручную, хотя знаете, что их можно отдать AI?

2: Где вы пробовали AI и перестали — почему остановились?

3: Что вы боитесь потерять, если AI станет частью работы?

4: Какие ошибки AI вы уже видели и что вы делали в этот момент?

5: Кого в команде вы считаете «экспертом» по AI, к кому пошли бы спросить?

Практическое следствие: не «AI для всех» в одной комплектации, а три параллельных трека с разными точками входа. Взять 3–5 миллениалов с подтверждённым опытом и сделать их амбассадорами первого пилота — у них одновременно высокая мотивация и рабочий контекст. Не делать Gen Z голосом проекта; использовать их для демонстрации «смелых» сценариев, но не для методологии. Поручить опытным сотрудникам роль «критического фильтра» — пусть они проверяют то, что выдаёт AI, и их экспертиза оцифровывается. Руководителям выдать отдельный мини-курс про то, как они сами могут использовать AI на совещаниях и в решениях. Линейных сотрудников не обучать «вообще», а подселить к пилоту в их рабочем процессе и снять KPI-страх отдельной беседой.

РОЛИ ВНЕДРЕНИЯ: СОСТАВ КОМАНДЫ И МОМЕНТ ПОДКЛЮЧЕНИЯ

Внедрение AI — не задача одного человека. McKinsey в «Rewired» (2023) и обновлениях выделяет пять ключевых ролей, которые нужны в AI-команде.

Миф «внедрение AI — это проект IT-отдела» мешает правильно распределить ответственность: AI-внедрение живёт на стороне бизнеса, а IT участвует в нём как одна из функций. Это мы уже видели в начале этой главы и в разделе про ADKAR — пилот умирает в момент смены приоритетов. Не все пять ролей требуют полной занятости, но каждая роль должна быть закрыта. Gartner в мае 2024 года зафиксировал, что помимо классических инженера данных, дата-сайентиста и ML-инженера, в AI-проектах появляются четыре новые роли. За полтора года — с 2024-го по середину 2025-го — они переместились из категории «становящиеся» в категорию «обязательные». Компания, которая строит AI-проект сегодня по ролевой модели 2022 года (разработчик + аналитик + менеджер), пропускает критические функции.

РОЛИ ВНЕДРЕНИЯ И КРИТЕРИИ ИХ ОТБОРА

Владелец AI — отвечает за то, что AI продолжает работать через 6 и 12 месяцев после пилота. Не CIO (Chief Information Officer — директор по информационным технологиям), не CDO (Chief Data Officer — директор по данным), не менеджер продукта. Человек с правом тратить деньги на данные и с ответственностью за то, что модель продолжает работать через полгода. Обычно это операционный директор, финансовый директор или руководитель ключевого процесса (продажи, поддержка, логистика), в зависимости от того, где живёт AI. Без владельца пилот умирает в момент смены приоритетов.

Промпт-инженер / носитель метода — переводчик между задачей человека и логикой модели. В IT-проекте аналог — аналитик, но аналитик переводит между заказчиком и разработчиком, а промпт-инженер — между заказчиком и обученной нейросетью, и его работа продолжается после внедрения. В 2024 году эта роль была самой горячей вакансией, в 2025 году профильное сообщество Gartner Peer Community зафиксировало разворот: выделенный промпт-инженер «не оправдал ожиданий», организации возвращаются к распределённой ответственности. Роль не умерла — она переместилась: вместо одной «шапки» на всю компанию — навык, встроенный в каждую функциональную роль. Я рекомендую клиентам не нанимать «главного промпт-инженера», а вложиться в двухнедельную программу для пяти-семи человек из разных отделов, которые становятся «носителями метода». Их задача — не писать промпты за всех, а обучать коллег, разбирать сложные случаи и собирать лучшие практики в общую библиотеку.

Специалист по оценке (валидатор модели) — проверяет не баги, а качество и дрейф модели (постепенное снижение качества модели со временем). В IT-проекте QA-инженер ищет дефекты, у AI-валидатора задача другая: замерить, остаётся ли модель полезной со временем. Сосредоточен на бизнес-метрике, а не только на метриках машинного обучения. Без него бизнес не доверяет модели и откатывается на ручной процесс.

Интегратор — встраивает модель в процессы и регламенты заказчика. В IT-проекте DevOps (методология объединения разработки и эксплуатации, в которой инженер отвечает и за код, и за его работу на сервере) решает инфраструктурные вопросы, а интегратор AI — обучает людей, переписывает инструкции, договаривается с безопасностью. Это редкий навык, и его часто закрывают фрилансеры — что для долгосрочного проекта плохо.

Продакт-менеджер AI — фокус не на фичах, а на эффекте для бизнеса. В IT-проекте продакт-менеджер думает о списке невыполненных задач (backlog) и выпусках готовой версии продукта (релизах), а продакт-менеджер AI — о метриках процесса и поведении людей. Его работа — разбивать задачи на шаги и взаимодействовать с владельцем AI, чтобы каждый релиз сдвигал бизнес-метрику, а не только закрывал тикеты в бэклоге.

ОБЪЕДИНЕНИЕ РОЛЕЙ В МАЛЕНЬКОЙ КОМАНДЕ

Один человек закрывает не больше 2,5 ролей — это эмпирический потолок, проверенный McKinsey на десятках проектов. Дальше качество резко падает: человек перестаёт успевать переключаться между разными типами задач (технические, продуктовые, измененческие). Свыше 2,5 ролей на человека — сигнал, что проекту не хватает людей, а не что человек эффективен.

Бизнес-роль и техническая роль объединяются легче, чем две технические: у них разный язык и разные KPI. Владелец AI — всегда отдельный человек, не совмещённый с тех-лидом; иначе через 3 месяца проект становится техническим упражнением. Специалист по оценке не совмещается с инженером данных, потому что он должен спорить с инженером. Продакт-менеджер AI и промпт-инженер могут совмещаться, если продакт имеет технический бэкграунд; иначе они говорят на разных языках.

McKinsey в State of AI 2024 зафиксировал, что 76% крупных компаний назвали нехватку AI-специалистов серьёзным барьером. Это значит, что компании, рассчитывающие купить все роли на рынке, проиграют компаниям, которые выращивают свои роли. PwC в июне 2025 года выпустил 2025 Global AI Jobs Barometer: 56% wage premium (надбавки к зарплате) для сотрудников с AI-навыками, рост с 25% годом ранее. Дополнительный сигнал: навыки в AI-профессиях обновляются в 2,5 раза чаще, чем в других, — 66% AI-специалистов меняют ключевые навыки ежегодно против 25% в других профессиях год назад. Любая роль, связанная с AI, устаревает за 12–18 месяцев, и бюджет на обучение ролей должен быть в плане, а не «по остаточному принципу».

СИГНАЛЫ РАЗМЫТОСТИ РОЛЕЙ

Пять типовых признаков, по которым видно, что ролевая модель в проекте не работает:

1: Один человек готовит данные, обучает модель, проверяет результат и пишет пользователям инструкции. Через 3 месяца он выгорает. Проект встаёт.

2: На совещании статуса никто не может ответить «где сейчас проект» в одном предложении. Все отвечают про свой кусок.

3: Бизнес не знает, кто отвечает за эффект, а ИТ не знает, кто отвечает за модель.

4: Решение «делаем или не делаем» ждёт согласования 2 недели, потому что неясно, кто его принимает.

5: После пилота никто не берёт на себя ответственность за промышленную эксплуатацию.

Пять ролей, отличия от IT-проекта: владелец AI отвечает не за внедрение, а за продолжение работы модели через 6 и 12 месяцев; промпт-инженер переводит между заказчиком и моделью, его работа продолжается после внедрения; специалист по оценке проверяет не баги, а качество и дрейф; интегратор встраивает модель в процессы и регламенты; продакт-менеджер AI фокусируется на эффекте для бизнеса, а не на фичах. Пилот делает «AI-команда», но ни один из владельцев процессов не вовлечён — проект умрёт в его календаре. Это не ошибка «про данные», а ошибка распределения ответственности.

ПИЛОТ УДАЛСЯ, МАСШТАБИРОВАНИЕ БУКСУЕТ: ЧТО ДЕЛАТЬ

«Pilot purgatory» — состояние, которое в деловом обиходе называют «чистилищем пилотов». Это положение, в котором компания провела десятки пилотов, но ни один не вышел в полноценный продакшн. В 2024–2025 годах этот термин подтверждается в каждом крупном исследовании.

MIT в 2025 году выпустил отчёт, согласно которому 95% корпоративных AI-пилотов не приносят значимого результата. McKinsey State of AI 2025: 88% компаний регулярно используют AI хотя бы в одной функции — та же цифра, с которой мы начали главу, — но только около 33% начали масштабирование по всей компании. (Заметьте: это не «39% видят EBIT» из начала главы, а другая метрика — «доля тех, кто начал масштабировать». 39% видят эффект на EBIT, 33% масштабируют; группы частично пересекаются, но не совпадают.) Остальные сидят в зоне «все попробовали, никто не выкатил». Это означает две вещи. Первая: пилот в одной команде не даёт пропуска в масштаб. Вторая: масштабирование живёт по другим правилам, и его нельзя свести к «продолжению пилота». Слово «масштаб» обманчиво: оно создаёт иллюзию, что достаточно умножить на N. На практике это другая задача, с другими людьми, с другими рисками и с другими метриками.

BCG в октябре 2024 года выпустил отчёт Where’s the Value in AI с цифрой, которая перевернула дискуссию: только 26% компаний вышли за пределы пилотов и показывают измеримую отдачу от AI. Остальные 74% застряли. Эти 26% — AI-лидеры — обходят остальных по выручке в 1,5 раза, по доходности акционеров в 1,6 раза, по ROI (Return on Investment — возврат инвестиций) на инвестированный капитал в 1,4 раза. Цифры не оставляют пространства для оптимизма: разрыв между лидерами и остальными — разрыв в 3–4 раза по эффективности AI-проектов.

BCG объясняет разрыв шестью характеристиками лидеров, и каждая из них относится не к технологии, а к организации: фокус на ключевых процессах, более амбициозные цели, интеграция AI в расходы и доходы, фокус на малых приоритетах, приоритет людей над алгоритмами (правило 10–20–70), быстрое движение по проектам в области генеративного AI.

Лидеры выигрывают не моделью, а организацией. Эти шесть характеристик — не про GPU, а про то, как люди принимают решения.

ПРИЧИНЫ ПРОВАЛА МАСШТАБИРОВАНИЯ

Причина №1: пилот держался на одном человеке. Это самая частая ситуация. Чемпион-энтузиаст лично собирал данные, лично настраивал модель, лично показывал результат. Когда чемпион уходит в отпуск, переводится или меняет работу, пилот умирает. В масштабе один человек не может быть «приложением ко всем процессам». Решение на этапе пилота: сразу документировать и передавать знания, иметь двух «наследников» чемпионства.

Причина №2: данные в новых отделах оказались другими. Пилот работал на чистых, подготовленных данных одного отдела. В новых отделах данные собираются иначе, обновляются иначе, имеют другую структуру. Модель, обученная на одних данных, в других показывает мусор. Решение на этапе пилота: проверить модель на данных из 2–3 разных источников, не только из «дружественного» отдела.

Причина №3: процесс в новых отделах не вписывается в предположения модели. Пилот встроен в процесс отдела-пилота: ручные проверки, локальные регламенты, привычные обходные пути. В другом отделе процесс другой, и модель требует ручной работы, которая в пилоте делалась энтузиастом. Решение на этапе пилота: явно прописать, какие шаги процесса модель предполагает, и проверить, есть ли эти шаги в других отделах.

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

Причина №5: владелец AI на стороне бизнеса — тот же, кто запускал пилот, и в масштабе у него нет ни времени, ни полномочий. В пилоте владелец — операционный директор, который нашёл на это время. В масштабе ему нужно управлять пятью отделами, и пилот для него перестаёт быть приоритетом. Решение на этапе пилота: с самого начала искать владельца, для которого AI-проект — часть KPI, а не дополнительная нагрузка.

ОТ БЕТЫ К GA: ЭТАПЫ ВЗРОСЛЕНИЯ ПРОДУКТА

Пилот — это бета (открытая пробная версия для ограниченного круга пользователей, в которой баги и шероховатости ожидаемы и допустимы). В бете можно показывать баги (ошибки в программе), можно объяснять, почему кнопка не там, можно лично поддерживать пользователя. Масштаб — GA (General Availability — общедоступная версия, в которой каждый сбой становится инцидентом, а не «шероховатостью бета-версии»). В GA каждый баг становится инцидентом. AI-пилот, который в бете выдавал 80% точности, в GA выдаёт 80% инцидентов. Поэтому на этапе пилота нельзя довольствоваться «уже работает» — нужно целиться в качество GA с самого начала. Иначе компания получает пилот, который красиво смотрится в презентации и ломается в продакшне через неделю.

McKinsey State of AI 2025 даёт подсказку в цифрах масштабирования: среди компаний с выручкой больше 5 млрд долларов около 50% начали масштабирование, среди компаний меньше 100 млн долларов — только 29%. Разрыв объясняется не бюджетом, а сложностью. Большие компании имеют больше функций, и пилот, который сработал в одной, статистически хуже переносится на другие. McKinsey фиксирует, что компании-лидеры используют AI в среднем в большем количестве функций и в 3 раза чаще переделывают процессы целиком — эту же закономерность мы видели в разделе про TCO. Вывод: масштаб — не «тот же пилот в 5 отделах», а «5 переделанных процессов с одной общей моделью». Модель может быть одна, но способ её применения в каждом отделе свой. Если компания не готова к переделке пяти процессов, лучше сократить амбицию и оставить пилот в одном отделе, чем размазать его на пять.

СЦЕНАРИИ ВЫХОДА ИЗ «PILOT PURGATORY»

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

1: Свернуть проект. Честный ответ «не взлетело» лучше вечного пилота. Решение принимается, если после 3 месяцев пилота ROI не виден и в масштабе он не появится.

2: Урезать амбицию. Оставить проект в одном отделе, признать его локальной историей. Экономит 6–12 месяцев попыток масштаба.

3: Сменить владельца. Найти человека, для которого AI — часть KPI. Часто это перезапускает проект, потому что меняется приоритет.

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

МАЛЫЙ БИЗНЕС: СВОЯ ЛОГИКА ВНЕДРЕНИЯ НА 3–10 ЧЕЛОВЕК

Отдельный повод для оговорки: всё, что описано выше в этой главе, написано для компании со штатом от 50 человек и выше. Владелец малого бизнеса с 3–10 сотрудниками смотрит на главу и справедливо говорит: «У меня нет C-level, нет владельца процесса, нет бюджета на пять ролей, нет юриста в штате — что делать?»

Для такого бизнеса инструкция другая и проще:

1: Не стройте ролевую модель. Один человек — основатель или его первый заместитель — закрывает все пять ролей AI-проекта одновременно. Это нормально, потому что проект маленький.

2: Стартуйте с быстрой победы за 1–2 недели, не с пилота на 90 дней. Сводка почты, AI-помощник в написании, RAG-бот по вашей собственной базе знаний — всё это окупается в первый месяц, не требует C-level и встаёт за вечер.

3: Не согласовывайте с юристами, безопасниками, ИТ. Их в вашей компании нет. Используйте только сервисы, которые не отправляют ваши данные наружу (Yandex Cloud, GigaChat API, локальный Ollama на вашем ноутбуке). Не используйте чужие облака с бесплатным тарифом для задач с персональными данными.

4: Не пишите «AI-стратегию». У вас нет стратегии цифровизации — и не надо. У вас есть две-три задачи, которые вы хотите ускорить. Этого достаточно.

5: Считайте экономию времени, не EBIT. Метрика «30 минут в день на письма» понятна и измерима. Метрика «вклад в EBIT» для бизнеса на 10 человек — попытка измерить микроскопом температуру.

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

ПУТЬ ПРОЕКТА ОТ ПИЛОТА ДО МАСШТАБА В ОДНОЙ ТАБЛИЦЕ

Глава обещала пошаговый план внедрения — от выбора пилота до масштабирования. Вот он в формате, который можно скопировать в план проекта или повесить на стену.

РЕЗЮМЕ

Лицензия и инференс — четверть реальной стоимости AI-внедрения. Остальное уходит на интеграцию, данные, сопровождение, безопасность, людей. Пилот выживает при именном владельце с C-level поддержкой, метрике до старта, плане отката и пользователе с «кожей в игре».

Быстрая победа окупается за 30–60 дней при трёх признаках: результат виден в цифрах, цена ошибки ничтожна, метрика считается «до/после». Пять этапов создания AI-агента ставят процесс первым — без переделки рабочего процесса модель не приносит ценности.

ADKAR работает по одному человеку: «команда приняла AI» — фикция, принятие происходит персонально. BANI требует самовосстанавливающегося регламента и короткого цикла обратной связи.

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

Бюджет распределяется по правилу 10–20–70: 70% идёт на людей и процессы. Пилот должен сразу целиться в качество GA, а не оставаться в режиме беты. Когда масштабирование буксует, выбор из четырёх сценариев выхода — иначе проект остаётся в чистилище пилотов.

Внедрение AI — не разовая акция, а новая операционная дисциплина компании. Пока мы обсуждали пилоты, роли, бюджеты и управление изменениями, индустрия сдвинулась сразу в нескольких направлениях: агентный AI (agentic AI — системы, которые сами планируют и исполняют цепочки действий) вышел из лабораторий, edge AI (модели, работающие прямо на устройстве — ноутбуке, телефоне, edge-сервере, без отправки данных в облако) появился в ноутбуках, мультимодальность (модели, которые одновременно работают с текстом, изображениями, аудио и видео) стала стандартом. Рынок труда уже перераспределяется между профессиями, а долгосрочные рамки 2026–2028 задают горизонт, в который стоит смотреть бизнесу. Следующая глава разберёт, что из этого структурный сдвиг, а что маркетинговый пузырь, и куда всё это движется в ближайшие годы.