Планёрка в понедельник. Генеральный показывает скриншот новости про конкурента, который «уже внедрил ИИ во все процессы», и заканчивает фразой: «Через квартал у нас это должно работать. Иначе отстанем». Ты руководишь направлением, и задача теперь твоя. У неё есть срок и есть угроза. У неё нет объекта, критерия и бюджета. И где-то под рёбрами уже сидит знакомое: «я в этом не разбираюсь, а отвечать буду я».

Запрос «как внедрить ИИ в компанию» люди ищут именно из этой точки. Сначала стоит разобрать саму точку, а потом уже выбирать инструменты.

Что тебе на самом деле поручили

Разбери фразу «внедряй ИИ, иначе отстанем» на составные части. В ней три разных вещи, и только одна из них задача.

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

Вторая часть, «конкурент уже внедрил», это чужая витрина. Из пресс-релиза виден анонс. Не видно, что там работает в проде, что свернули через месяц, сколько людей чинят ошибки за моделью. Кэл Ньюпорт в разборе «On AI Coding and Its Discontents» описывает ровно эту динамику у инженеров: сначала восторженные посты о том, как инструмент «за одну ночь изменил работу», потом, уже без постов, падения продукта из-за сгенерированного кода и признание, что таких проблем с качеством у человека не было за всю карьеру. Публичный слой и рабочий слой расходятся, и снаружи виден только первый.

Третья часть, «иначе отстанем», это срок, поставленный тревогой. Отстанем от кого, в чём, к какой дате и что тогда произойдёт? Если на эти вопросы нет ответа, дедлайн назначило состояние того, кто прочитал новость.

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

Что подвластно, что нет

Дихотомия контроля в этой ситуации режет очень чётко.

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

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

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

Достройки, которые превращают задачу в панику

Задача с объектом и критерием тревоги не вызывает. Тревогу вызывают достройки поверх неё.

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

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

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

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

Как внедрить ИИ в компанию, чтобы это не стало театром

Дальше уже про действия. Порядок важен.

  • Выбери один процесс с измеримой болью. Критерий выбора: где у нас очередь, ручная рутина или ошибки, и мы это уже измеряем. Вопрос «где ещё можно применить ИИ» отложи, он порождает список, а не пилот. Процесс, у которого нет текущей метрики, для пилота не годится: результат будет не с чем сравнить, и выгоду придётся объявлять, а не показывать.
  • Задай критерии до старта, и критерий остановки тоже. Что должно произойти, чтобы ты сказал «масштабируем», и что должно произойти, чтобы ты сказал «сворачиваем». Второй критерий важнее: без него пилот не заканчивается никогда и превращается в бессрочную демонстрацию активности.
  • Проиграй провал заранее. Стоическая premeditatio malorum здесь работает как инженерная практика. Модель ошибётся в фактах, сотрудник перестанет проверять за ней, клиентские данные попытаются отправить во внешний сервис. Каждый сценарий получает заранее назначенное действие. У Ньюпорта инженер, обжёгшись на качестве, пришёл к правилу «свой код пишу сам, модели отдаю узкие и раздражающие задачи». Такое правило можно принять до аварии, а не после.
  • Отдельно реши про данные. Что из внутреннего и клиентского уходит во внешнюю модель и на каких условиях. Это решение принимается один раз, письменно, до пилота. Принятое «по ходу» оно принимается по умолчанию, то есть в пользу удобства.
  • Назначь владельцем человека из процесса. Внедрение держится на человеке, которому нужен результат в его процессе. Энтузиаст технологии без процесса даст красивую демонстрацию и тихо потеряет интерес.
  • Не вводи метрику «доля сотрудников, использующих ИИ». Она измеряет театр и провоцирует его же. Единственная метрика внедрения лежит в процессе: время цикла, доля ошибок, объём ручной работы, всё, что ты и так измерял до ИИ.

Разговор с тем, кто требует

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

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

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

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

Что сделать на этой неделе

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