Почему команды сопротивляются AI — и что с этим делать

Каждый месяц — один вопрос про AI в командах. Как меняются роли, где ломаются процессы и что с этим делать. Это The Human Loop.

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

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

Отсюда главный вопрос: почему одна команда превращает его в привычку, другая — в теневую практику, третья — в отчётный ритуал, четвёртая — в конфликт про ответственность?

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

За последний год я видел этот сценарий на нескольких десятках инженерных команд. Сначала компания выдаёт доступы, проводит обучение и начинает считать простые сигналы внедрения: кто зашёл в инструмент, кто прошёл курс, кто отметил задачу как сделанную с помощью AI. В отчётах активность растёт. Метрики доставки и потока — Lead Time (время от принятия задачи в работу до релиза в продакшен), Throughput (количество реализованных задач) и более широкий Time to Market (время от идеи до результата у пользователя) — меняются гораздо медленнее, а часто не меняются вовсе.

Снаружи всё это выглядит как внедрение AI. Внутри я вижу четыре разных сценария — подробнее эту логику я разбирал в тексте про Agentic Engineering и маршрут задачи до продакшена:

1. Привычка: ассистент стал частью обычного дня: набросать код, написать тесты, разобраться в легаси.
2. Обходной путь: люди по-тихому пользуются персональными подписками (вместо использования корпоративных ресурсов и моделей), потому что инструменты на работе медленные и «менее умные».
3. Ритуалы для отчетов: AI-инструментами «фиктивно пользуются» перед демо, чтобы от них отстали с отчётами по использованию инструментов.
4. Конфликты про роли и ответственность: бесконечные споры: кто отвечает за изменение, если агент предложил → человек принял → релиз упал → а клиент пришёл злой.

Людям, внедряющим AI, важно понимать, что происходит с самой работой: где AI становится привычкой, а где — вскрывает старые споры про качество, ответственность и поток. Это видно и в свежих исследованиях BCG: AI на работе — 2026, Microsoft: индекс рабочих трендов — 2026 и LexisNexis: отчёт о будущем работы — 2026.

Прогресс по внедрению AI важно измерять. Но это не самоцель

Когда компания вкладывается в AI, руководству нужно увидеть эффект. Логика понятна: закуплено железо и выстроена инфраструктура, оплачены подписки, сформирован бюджет на обучение — хочется видеть результат и хоть какую-то окупаемость. Доказанная окупаемость AI пока часто остаётся скорее вопросом, чем фактом — и об этом будет отдельный выпуск The Human Loop.

Самый простой способ увидеть прогресс во внедрении — показать цифры по тому:

• кто получил доступ;
• кто прошёл обучение;
• кто открывал инструмент;
• кто отметил задачу как выполненную с помощью AI;
• кто показал демо.

Prosci предлагает полезное различие: одно дело — активность вокруг инструмента, другое — изменение работы. Доступы, подписки, обучение и частота использования показывают, что люди соприкоснулись с AI. Но внедрение начинается только там, где меняется поведение: инструмент встроился в процесс, люди доверяют результату, понимают правила и видят связь с эффектом для бизнеса.

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

Люди открывают инструмент чаще, ставят в задачах пометку «сделано с помощью AI», показывают пару удачных сценариев на демо — и статистика внедрения AI выглядит всё лучше.

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

• Относительно простые сигналы о формировании привычки растут как положено: больше входов в инструменты, больше участников обучения, больше демо на встречах.
• Метрики доставки (Lead Time, Throughput) либо не сдвигались, либо изменения были несущественны.

При этом с ростом регулярности использования AI растет скрытая работа: по данным CodeRabbit, pull requests, написанные с участием AI, получают примерно в 1,7 раза больше замечаний, чем pull requests без участия AI. Платформа инженерной эффективности Harness (в исследовании State of Engineering Excellence — 2026) делится инсайтами: AI ускоряет часть разработки, но увеличиваются очереди и время на проверку, растет скрытая работа. А ещё инженеры отмечают повышенную когнитивную нагрузку и страх, что данные об активности в AI-инструментах попадут в оценку эффективности.

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

Поэтому полезно смотреть на несколько слоёв метрик:

1. Привычка работать с AI.
2. Проникновение AI в жизненный цикл разработки.
3. Доставка и поток.
4. Качество и защитные ограничения.
5. Стоимость, окупаемость и бизнес-результат.

По моему опыту, в метриках привычки использования AI важны как минимум две метрики: ежемесячная активность (MAU), а ещё MAU 10+ / W50 — доля людей, которые используют AI в 10+ рабочих дней в месяц, примерно в половине рабочих дней. В потоке — Lead Time, Throughput и Defect Rate. Эту рамку я подробно разбирал в статье «Как мы внедряли ИИ на 500 инженеров, а скорость не росла»: рост MAU сам по себе ещё не означает, что Lead Time или Throughput сдвинулись. В проникновении AI в жизненный цикл разработки — сколько задач агенты ведут сквозным образом и на скольких задачах участвуют хотя бы на одном этапе. Привычка работать с AI без изменения метрик потока — имитация внедрения.

«Сопротивление AI» — это фасад

«Сопротивление внедрению AI» — это фасад, за которым скрываются разные причины. Prosci: почему внедрение AI тормозит — 2026 в своём отчёте перечисляет основные:

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

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

63% сложностей AI-внедрения связаны с человеческими факторами, а не с техническими ограничениями. Самый крупный блок сложностей связан с уверенным владением инструментом: тут и недостаток знаний, и непонимание зачем этими инструментами пользоваться (ценность) и недостаточная практика (интеграция в решение рабочих задач).

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

Обучение помогает, когда не хватает навыка и практики. Если проблема в плохом инструменте, нечёткой ответственности или слишком большом объёме работы на проверку — тренинг не починит ни одну из этих причин. Prosci: почему внедрение AI тормозит — 2026 и Harness: состояние инженерной эффективности — 2026 сходятся в одном: AI-внедрение часто ломается на уровне системы работы вокруг инструмента.

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

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

Инструмент: Карта сопротивления AI

Карта сопротивления AI — рабочий шаблон для команды или нескольких команд. В этом выпуске она помогает перестать спорить с симптомом и увидеть, на что он указывает в системе работы.

Логика простая:

1. определить источник сопротивления;
2. понять позицию человека или группы;
3. выбрать действие, которое чинит реальную причину.

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

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

В полном шаблоне источники такие:

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

Нам важно увидеть проблему, которая прячется за симптомом (типичными фразами людей):

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

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

Важно различать скептика, ритуального пользователя и саботажника

Источник сопротивления и поведение человека — разные вещи. Один и тот же источник требует разных действий в зависимости от позиции человека.

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

Для карты сопротивления полезно различать пять позиций:

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

Самая важная граница здесь — между продуктивным скепсисом и саботажем.

Скептик может защищать качество, безопасность, владение результатом и развитие команды. Когда человек просит прояснить правила проверки, критерии качества и границы ответственности, он часто защищает систему от случайного ущерба. Сейчас начали появляться первые исследования, подтверждающие это: BCG: когда AI используют все — 2026 пишет о риске того, что массовое использование AI в погоне за метриками внедрения ослабляет критические навыки и снижает стабильность поддерживаемых систем. А California Management Review: от обучения к ответственности — 2026 утверждает, что для стабильной работы систем и корректного внедрения AI-инструментов в работу нужна система ответственности: критичный взгляд на все результаты работы агентов, а также как минимум два согласования перед отправкой в прод.

То есть скепсис сопротивляющихся нужно переводить в критерии, правила и эксперименты.

Саботаж требует другого разговора: явные ожидания, управленческая граница, последствия. Его нельзя прятать под словом «сопротивление» и лечить очередным тренингом.

Инженерный слой: кто владеет результатом

На карте это зона ответственности: кто владеет результатом и кто отвечает за последствия. В разработке при помощи AI-инструментов этот вопрос проявляется быстрее всего.

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

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

В таких случаях процесс код-ревью превращается в расследование чужого диалога с ассистентом. Ревьюеру нужно понять не только сам набор изменений, но и восстановить, какой контекст был у агента, какие ограничения ему дали, какие файлы он не видел, какие предположения он сделал. Подробно эту часть я разбирал во второй части Habr-серии про Agentic Engineering и AI-first команды.

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

Часто это запрос на рабочую договорённость:

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

Без этих правил AI ускоряет генерацию кода и одновременно увеличивает тревогу вокруг ответственности за итог.

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

Поток работы: локальная скорость упирается в систему

Проблема в потоке — слой, который почти не виден в цифрах внедрения.

AI может ускорить локальный участок работы, но общий Time to Market останется почти прежним. В тексте про маршрут задачи до продакшена я отдельно развожу «пользователь AI стал быстрее» и «задача стала быстрее проходить систему».

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

Сквозная доставка не ускорилась пропорционально.

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

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

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

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

Если эти границы не перестроены, локальная скорость превращается в очередь на следующем этапе.

BCG: AI на работе — 2026 формулирует это прямо: стратегия важнее инструментов. Ценность появляется там, где компании перестраивают работу вокруг AI, а не просто раздают доступы. Microsoft: индекс рабочих трендов — 2026 описывает похожий сдвиг: работа пересобирается вокруг людей и агентов, меняются роли автора, редактора, директора и координатора; в блоке Transformation Paradox они отдельно показывают, как давление текущих целей конкурирует с пересборкой работы.

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

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

Организационный слой

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

В организациях побольше нужны условия для внедрения AI в работу:

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

LexisNexis: отчёт о будущем работы — 2026 фиксирует проблему в правилах работы: использование AI растёт быстрее, чем внутренние политики, обучение и понимание процессов с участием агентов. Отсюда риск: теневое использование AI появляется там, где нет доступных инструментов, понятных правил и собранного контура управления.

Люди чаще обходят процесс из-за неудобного официального пути, а не из вредности.

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

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

Что делать с сопротивлением

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

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

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

В докладе по AI на People Sense я пришёл к простой рабочей связке: за каждой формой сопротивления стоит свой тип недостающей поддержки.

• Нет «зачем» → показать личную рабочую пользу. Нужен конкретный выигрыш в работе человека: быстрее разобрать легаси, собрать тест-кейсы, подготовить черновик документа или снять рутину с повторяющейся задачи. Общая стратегия компании здесь работает хуже. Пока человек не видит личный смысл, он слушает про трансформацию как про чужой проект.
• Страшно выглядеть некомпетентным → начать с малой безопасной группы. Большие вебинары плохо работают для первого опыта: люди кивают, смотрят демо, а потом остаются одни перед терминалом и не знают, с чего начать.
• Не знают как → дать реальную задачу и эксперта рядом. Лучше сработал формат на 1,5 часа: настройка окружения, задача из рабочего бэклога, участник за рулём, эксперт рядом как штурман. В логике ADKAR это соединяет Knowledge и Ability: человек не только понял инструмент, он впервые применил его в своих условиях.
• «Нас не спросили» → дать людям участвовать в проектировании практики. QA, аналитики, разработчики и DevOps по-разному используют AI и по-разному проверяют качество. Когда представители роли участвуют в рабочей сессии, появляются артефакты, которые можно переиспользовать: шаблоны, правила безопасного использования, примеры задач, критерии проверки, подсказки для агентов.

Короче: сопротивление часто снижается после первого безопасного опыта на своей задаче. Одного убеждения для этого мало.

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

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

А что не работает во внедрении?

Из опыта последнего года я бы вынес то, что выглядит логично, но слабо меняет поведение:

• рассылки и большие вебинары дают осведомлённость, но редко создают привычку;
• реестр инструментов сам по себе не приводит людей к использованию;
• демо «смотрите, как агент ведёт задачу и отправляет изменения в репозиторий» вызывает интерес, но не снимает проблему чистого листа;
• требование «используйте AI» быстро превращает внедрение в отчётный ритуал;
• обучение без лидеров не закрепляется в командной норме.

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

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

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

Практический артефакт

В практическом формате Карта сопротивления AI превращает диагностику в командные договорённости по работе с AI. Карта работает как вход в эти договорённости: сначала команда видит повторяющиеся проблемы в системе работы, затем переводит их в правила и эксперименты. В минимальной версии шаблон состоит из групп проблематики. На рабочей сессии команда выбирает 1–3 красные зоны. Если делает это впервые — начинает с одной. Дальше команда собирает черновик правил:

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

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

Финал

AI быстро проявляет суть того, как в команде устроена работа.

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

Сопротивление AI в этом смысле полезно. Оно показывает место, где команда ещё не договорилась.

Практический первый шаг на следующий спринт:

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

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

Связанные материалы

• Диагностика AI-сопротивления — 12 вопросов, чтобы понять, какие зоны горят в команде.
• Чеклист внедрения AI — как пройти от доступа к инструментам до изменения работы.
• Agentic Engineering — это про маршрут задачи до продакшена — большой разбор про метрики, поток и агентную разработку.