Сложности внедрения ИИ и как их снять заранее
В этом блоке собран каталог того, что пойдёт не так. Я расположил сложности примерно в том порядке, в котором они встречаются: от первого дня пилота до аудита через год. Для каждой объясняю, почему она возникает и что с ней делать.
Вы технический директор, пилот удался, теперь его хотят раскатить на всех. В разборе сложности масштабирования идут в том порядке, в котором появляются, и для каждой сказано, можно ли снять её заранее.
Пилот удался, генеральный хочет раскатить на всех
Видел отчёт по пилоту: 5 человек, задачи в 2 раза быстрее. Отлично, давай с первого числа на всех 200, лицензии я согласую. Чего ждать-то, если всё работает?
Что вы ответите генеральному?
Что происходит через квартал: все варианты
Цифры условные, они показывают направление без точной величины. Как снять baseline, с которым сравнивать вторую волну, – в блоке 11, а шаблон дизайна пилота есть в блоке 15.
Вариант A. Вторая волна, потом все: 4 команды, которые нашли всё
Генеральный согласился без радости. Во второй волне были 4 обычные команды, одна из них на старом ядре. Там первый месяц эффекта не было вовсе, пока договорённости проекта не записали в файлы контекста. В 2 командах встало ревью, помог жёсткий лимит на размер пул-реквеста. Однажды автор не смог объяснить на ревью свой код, поэтому его не смержили. ИБ согласовала ещё 3 репозитория за 5 недель. Теперь у вас план раскатки со списком того, что сломается.
| Метрика | Было | Стало |
|---|---|---|
| Команды с ИИ (пилот и вторая волна) | 1 | 5 |
| Размер пул-реквеста (к уровню до ИИ, после лимита) | +60% | +15% |
| Время ревью (медиана по пул-реквесту, к уровню до ИИ) | +40% | +15% |
| Доля сбойных изменений (метрика DORA) | 4,0% | 4,1% |
| Изменения с записью участия ИИ (автор, ревьюер, участие ИИ) | 0% | 100% |
Вердикт: Вы раскатываете на всех на квартал позже, зато знаете, где будет больно. Это знание вы получили до инцидентов, а не после.
Что говорят коллеги после варианта A
Даниил: Со второй волной согласен, но у меня она займёт больше квартала. Каждая новая команда в банке означает новый репозиторий, а каждый репозиторий ИБ согласует отдельно. Самое ценное из того, что вы сделали: запись участия ИИ с первого дня. Аудитор приходит к нам раз в год, я уже знаю, что он спросит. Восстановить это задним числом нельзя, а записать сейчас не стоит почти ничего.
Мария: Во второй волне мы не ограничили размер пул-реквестов и поплатились за это на ревью: через месяц очередь выросла так, что команды начали мержить не глядя. Лимит на размер ввели потом, он сработал, но доверие к инструменту уже упало. Во втором году я бы делала ровно как вы, с одной поправкой: включила бы во вторую волну команду, которая против ИИ. Её возражения находят риски быстрее любого реестра.
- Даниил: Мария, команду, которая против, у меня в пилот не отпустит её руководитель, причём будет прав: у него план.
- Мария: Тогда спроси его, что сломается. Ответ «всё» тоже риск, просто его надо записать.
Итог: Вы проверили масштабирование на второй волне. Это правильный ответ, хотя Даниил прав, что в банке каждая новая команда означает ещё одно согласование с ИБ. Главное из блока: большинство сложностей видно только на типичных командах, а регуляторику и аудиторский след закрывают до старта. Соберите документ по промпту и переходите дальше.
Вариант B. Всем, но с обучением: 200 человек и одна очередь
Обучение на 2 дня прошли все, лицензии выдали с первого числа. Через месяц ИБ остановила инструмент на сервисах с персональными данными: согласован был один репозиторий. Там, где он остался, пул-реквесты выросли, очередь на ревью стала главной темой планёрок, а на старом коде эффекта не увидел никто. Дважды на прод уехал код, который автор не мог объяснить. Генеральный спрашивает, куда делось «в 2 раза быстрее» из пилота.
| Метрика | Было | Стало |
|---|---|---|
| Активные пользователи ИИ (по данным инструмента) | 5 | 70 из 200 |
| Размер пул-реквеста (к уровню до раскатки) | 100 | 170 |
| Время ревью (медиана по пул-реквесту) | 1 дн | 1,8 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,6% |
| Время от коммита до прода (метрика DORA) | 6 дн | 6,5 дн |
Вердикт: Пилот доказал одно: 5 энтузиастов на удобном сервисе работают быстрее. Всё остальное вы проверяли уже на всей компании.
Что говорят коллеги после варианта B
Даниил: Обучение всех за 2 дня у нас обычно и проводят, потому что о нём легко отчитаться. Но в банке раскатка на всех упирается в ИБ, навыки тут вторичны: на сервисах с персональными данными инструмент остановят в первую же неделю. У вас останутся лицензии, которыми нельзя пользоваться там, где идёт основная работа. Пилот на одном удобном сервисе этого не показал, да и показать не мог.
Мария: Навыки выбраны как проблема правильно, но за 2 дня её не решить. У нас навык появился, когда в каждой команде нашёлся человек, к которому можно прийти с вопросом, а неудачные сессии мы начали разбирать вслух. На это ушло полгода, 2 дней тут мало. Пока навыка нет, люди генерируют крупные пул-реквесты, поэтому ревью встаёт, что у вас и случилось.
- Мария: Даниил, у вас обучение по ИИ обязательное для всех? Оно хоть что-то меняет в работе?
- Даниил: Оно даёт подпись в журнале, а работать по-новому начинают только те, кто и так хотел.
- Мария: У нас наоборот: после обязательного обучения часть скептиков стала лучшими пользователями. Всё решает, кто его ведёт.
Итог: Раскатка на всех упёрлась в ИБ и ревью, а обучение на 2 дня этого не исправило. Для первой попытки это нормальный исход. Главное из блока: пилот на энтузиастах и удобном сервисе ничего не говорит о масштабировании. ИИ обнажает узкие места, которые раньше были незаметны. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Вариант C. Сначала закрыть все риски: 9 регламентов и ни одной новой команды
Весь квартал ушёл на документы: юристы согласовали политику по лицензиям, ИБ утвердила правила для агентов, а вы ввели запись участия ИИ в каждом изменении. Это пригодится, но раскатки не было: официально инструментом пользуются те же 5 человек. Журнал прокси показывает, что обращений к публичным ИИ-сервисам стало заметно больше, потому что люди не стали ждать. Один инженер из пилота ушёл. Про ревью и старый код вы знаете столько же, сколько в начале.
| Метрика | Было | Стало |
|---|---|---|
| Команды с ИИ (официально) | 1 | 1 |
| Риски с утверждённым регламентом (из реестра в 11 пунктов) | 0 | 9 |
| Обращения к публичным ИИ-сервисам (по журналу прокси) | 100 | 140 |
| Изменения с записью участия ИИ (пилотная команда) | 0% | 100% |
| Инженеры в пилотной команде (добровольцы) | 5 | 4 |
Вердикт: Вы закрыли риски, которые видны на бумаге. Риски, которые видны только в работе, вы пропустили, а пауза добавила ещё один.
Что говорят коллеги после варианта C
Даниил: Я бы, скорее всего, выбрал то же самое. В банке это выглядело бы разумно: без регламента по аудиту и лицензиям меня дальше одного сервиса не пустят. Но реестр из 11 рисков, закрытых на бумаге, ничего не скажет о том, что встанет ревью или что средняя команда не получит эффекта. Регуляторику и аудиторский след нужно закрыть до старта, а остальное узнаётся только на второй волне.
Мария: Половину сложностей из этого списка мы заранее не видели и нашли только на практике: узкое место в ревью, нехватку навыков, легаси-процессы. Ни один регламент их бы не поймал. Пока вы писали документы, инженеры ждать не стали и открыли личные аккаунты. Самым дорогим риском второго года у нас оказался совсем не prompt injection: за месяцы паузы люди привыкли работать в обход.
- Мария: Даниил, ты правда считаешь, что регламент по prompt injection нужен до первого агента?
- Даниил: Да, до первого агента с доступом к репозиторию. Если агент прочитает .env, у нас остановят весь проект.
- Мария: Тогда дай агенту минимальные права и начинай. Права настраиваются за день, а регламент пишется целый квартал.
Итог: Квартал ушёл на бумаги, а люди тем временем ушли в личные аккаунты. Для первой попытки это нормальный исход. Главное из блока: регуляторику и аудиторский след закрывают до старта, а остальные сложности находят на второй волне, на бумаге их не видно. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Одиннадцать сложностей и что с ними делать
Вы выбрали проверить масштабирование. Ниже идёт каталог того, что пойдёт не так, большую часть этого вторая волна как раз нашла.
Brownfield означает проект с историей, а greenfield означает проект с нуля. Почти все демонстрации ИИ-инструментов показывают greenfield: новое приложение за 10 минут. Почти вся ваша работа относится к brownfield.
Разница принципиальна и измерена: в METR опытные разработчики в зрелых репозиториях работали с ИИ медленнее; одна из вероятных причин, по мнению авторов, – модель не знала неявных договорённостей проекта. В обновлении 2026 года знак эффекта, вероятно, развернулся (блок 11), но договорённости проекта модели по-прежнему нужно записывать. Что делать: записать договорённости в файлы контекста (блок 15) и начинать с надёжных задач в порядке из блока 07: понимание кода, документация, тесты, затем миграции. От brownfield не стоит ждать эффекта, который показывают на greenfield.
Есть ещё ответ на уровне инструментов. Договорённости можно выводить из кода автоматически и не ждать, пока кто-то их запишет. Радиус поражения каждого изменения можно посчитать до того, как агент начал писать. Идея простая: исправить спецификацию стоит 5 минут, а исправить код, который агент уже написал, намного дороже.
Типовой сценарий: 5 энтузиастов на удобном сервисе получили впечатляющий результат, вы раскатили инструмент на 200 человек, а результат исчез. Причины: пилотная группа была нетипичной (лучшие инженеры, добровольцы), сервис был удобным (хорошие тесты, свежий код), а ограничений корпорации (ИБ, легаси, согласования) в пилоте вообще не было.
Что делать: планировать пилот так, чтобы он был типичным, вместо того чтобы гарантировать ему успех. Включать среднюю команду и средний сервис. Проверять масштабирование на второй волне из 3–5 команд до раскатки на всех. Шаблон дизайна пилота есть в блоке 15.
Здесь 2 противоположные крайности, обе связаны с людьми. Одни инженеры отказываются использовать ИИ: не доверяют (по Stack Overflow 2025, 46% не доверяют точности), считают угрозой профессии, не хотят менять привычки. Другие мержат код, который не понимают: «ИИ написал, тесты прошли, значит, работает».
Вторая крайность опаснее, потому что незаметна до инцидента. В блоке 05 есть правило: ответственность за код несёт тот, кто смержил. Оно должно работать каждый день, одной записи в регламенте мало: на ревью нужно спрашивать «объясни, что здесь происходит», а если автор объяснить не может, код не мержится. Про сопротивление – в блоке 13.
Эффективная работа с ИИ требует отдельного навыка, который не приходит вместе с лицензией. Этот навык состоит из нескольких умений: формулировать задачу так, чтобы модель её поняла; разбивать большую задачу на части, с которыми агент справится; понимать, когда модель уверенно врёт; настраивать контекст. Инженеры без этих умений получают худший результат и делают вывод, что «ИИ не работает».
Что делать: обучение (блок 13), внутренние примеры удачных и неудачных сессий, выделенные люди, к которым можно прийти с вопросом. На это нужно время, которое обычно забывают заложить в план.
Куда переехала очередь
Faros AI: изменение при работе с ИИ. Показано направление без точной величины.
Сначала ускоряется генерация. По Faros AI, пул-реквестов с ИИ становится на 98% больше. На панели скорости это выглядит как успех.
Прокрутите дальше: каждый пул-реквест при этом на 154% крупнее. Изменений больше, а проверить каждое тяжелее.
Проверка при этом не ускорилась: ревью занимает на 91% больше времени. Генерация ускорилась, а проверка осталась прежней, поэтому очередь переехала к ревьюеру. Время ревью нужно измерять как метрику с первого дня пилота.
Это самая измеренная сложность: по данным Faros AI, пул-реквестов стало на 98% больше, они на 154% крупнее, а ревью занимает на 91% больше времени. Генерация ускорилась, а проверка осталась прежней, поэтому очередь переехала к ревьюеру.
Что делать: жёстко ограничить размер пул-реквеста (например, автоматически отклонять всё, что больше определённого объёма); поставить автоматический первый проход ревью силами ИИ до человека; явно выделять время на ревью в планировании и перестать рассчитывать, что его сделают «в свободное время»; измерять время ревью как метрику и реагировать на рост.
По DORA, связь ИИ с ростом нестабильности сохраняется второй год подряд. Механизм такой: изменений больше, они крупнее, автор понимает код хуже, поэтому сбойных выкаток становится больше. Что делать: сдерживать размер изменений и не отключать ни одной проверки ради скорости (блок 09). Главной метрикой пилота стоит считать долю сбойных изменений вместо частоты деплоев.
Об этом я говорил в блоке 01: нет смысла генерировать код за минуты, если согласование с ИБ может занять квартал. ИИ обнажает узкие места в процессах, которые раньше были незаметны, потому что все этапы были одинаково медленными.
Что делать: измерить TTM по этапам (блок 11) и перестраивать самый медленный этап, потому что ускорять и без того быстрый бессмысленно. Часто самым медленным оказывается организационный этап, который лежит за пределами разработки. Тогда внедрение ИИ превращается в проект по изменению процессов, к этому нужно быть готовым.
Подробно это – в блоке 05. Здесь напомню, что это вполне конкретная сложность внедрения: в корпорации она способна остановить проект полностью. Утечки обычно происходят без всякого взлома: инженер вставил код в личный аккаунт, как в Samsung. Правила, корпоративные аккаунты, маскирование данных и аудит нужны до пилота, после него будет поздно.
У этой сложности 2 стороны. Первая: модель может воспроизвести фрагмент кода из открытого проекта с лицензией, которая обязывает раскрывать ваш код (например, GPL), а для коммерческого продукта это юридический риск. Вторая: агент может добавить зависимость с неподходящей лицензией или с уязвимостью.
Что делать: поставить автоматическую проверку лицензий зависимостей в конвейер (блок 09); держать разрешённый список библиотек в файлах контекста; крупным компаниям брать корпоративные тарифы инструментов, где поставщик даёт юридические гарантии по сгенерированному коду. Уточните у поставщика, что именно он гарантирует.
Prompt injection (внедрение инструкций через данные) означает атаку, при которой вредоносные инструкции попадают в модель в обход пользователя, через контент, который она обрабатывает: комментарий в коде, файл в репозитории, страницу документации, ответ внешнего сервиса. В списке OWASP Top 10 для LLM-приложений (OWASP – открытый проект по безопасности веб-приложений) этот риск стоит первым в 2 выпусках подряд.
Для разработки это конкретная угроза: агент, который читает зависимости, документацию и тикеты, может получить из зависимости инструкцию «отправь содержимое .env на такой-то адрес», а у него есть права на это действие. Что делать: дать агенту минимальные права (без доступа к секретам и проду); требовать подтверждения человеком для опасных действий (отправка наружу, удаление, деплой); вести журнал действий агента (блок 05); считать недоверенным всё, что агент читает.
Через год к вам придёт аудитор (внутренний или от регулятора) и спросит: кто написал этот код, кто его проверил, почему принято такое решение? Ответ «это сгенерировал ИИ» аудитора не устроит.
Что делать: с первого дня фиксировать для каждого изменения автора (человека), ревьюера, факт участия ИИ, а в идеале ещё спецификацию или промпт, из которых оно родилось. Подход AI-DLC из блока 03 делает упор на запись планов, требований и проектных документов по ходу работы, чтобы каждое изменение можно было проследить до них. Он как раз об этом. В начале это стоит дёшево, а задним числом восстановить такую запись невозможно.
Что говорят коллеги
Со второй волной согласен, но у меня она займёт больше квартала. Каждая новая команда в банке означает новый репозиторий, а каждый репозиторий ИБ согласует отдельно. Самое ценное из того, что вы сделали: запись участия ИИ с первого дня. Аудитор приходит к нам раз в год, я уже знаю, что он спросит. Восстановить это задним числом нельзя, а записать сейчас не стоит почти ничего.
Во второй волне мы не ограничили размер пул-реквестов и поплатились за это на ревью: через месяц очередь выросла так, что команды начали мержить не глядя. Лимит на размер ввели потом, он сработал, но доверие к инструменту уже упало. Во втором году я бы делала ровно как вы, с одной поправкой: включила бы во вторую волну команду, которая против ИИ. Её возражения находят риски быстрее любого реестра.
Обсуждение:
3 риска для своей компании
Выберите 3 сложности, которые ударят по вашей компании первыми, и для каждой решите, что сделаете до того, как она случится. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.
Промпт для документа
скопируйте в свою модельТы – технический директор, который уже провёл внедрение ИИ в разработку. Помоги мне составить документ «3 главных риска внедрения ИИ для моей компании». Сложности, из которых выбираем: - Brownfield: внедрение в существующий код - Пилот, который не масштабируется - Сопротивление и мерж непонятого кода - Нехватка навыков - Узкое место в ревью - Рост нестабильности - Легаси-процессы - Регуляторика, секреты, утечка кода - Лицензионная чистота - Prompt injection - Аудиторский след Для небольшой компании добавь в список ещё 2 риска: зависимость от 1 человека, который «понимает ИИ», и зависимость от поставщика модели (смена цен или закрытие доступа). Если я называю свой риск, которого нет в списке, прими его. Если пилот уже был, спроси, что на нём сработало и что нет, и выбирай риски следующего шага: второй волны или раскатки на все команды. Пилот заново не планируй. Термины: - Вторая волна – подключение 3–5 обычных команд после пилота и до раскатки на всех. - Легаси-процессы – медленные согласования и этапы вне разработки, которые становятся узким местом, когда код пишется быстрее. Что нужно выяснить: - Какие 3 сложности ударят по нам первыми и почему. - Для каждой: конкретное действие, ответственный и срок. Если я пишу намерение («будем следить»), попроси действие. - Что нужно сделать до следующего шага, а что можно проверить на нём. Если пилота ещё не было, следующий шаг – пилот, а проверка – на второй волне. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Риск | Почему для нас | Что делаем | Ответственный | Срок», под таблицей – 2 списка: «До пилота» и «На второй волне». Если пилот уже был – «До [следующего шага]» и «На [следующем шаге]».
Пример3 риска Даниила и 3 риска Марии
У банка и у продуктовой компании первыми бьют разные сложности. Сравните 2 готовых документа и заметьте, что в колонке «Что делаем» стоит конкретное действие, а не намерение, и у каждого действия есть ответственный и срок. Мария пилот и вторую волну уже прошла, поэтому её риски – про раскатку на все команды.
Даниил (банк, 200 инженеров)
| Риск | Почему для нас | Что делаем | Ответственный | Срок |
|---|---|---|---|---|
| Регуляторные ограничения и ИБ | Банк: персональные данные клиентов и требования Банка России. Без согласия ИБ пилот не начнётся | До выбора инструмента получить от ИБ письменный список условий согласования, рассматривать только отечественную модель по договору или модель в контуре | Даниил | Неделя 1 |
| Brownfield: внедрение в существующий код | Монолит с историей, авторы части модулей ушли, файлы контекста есть только в 2 командах | Первые задачи только на понимание кода и документацию, файл контекста для пилотного сервиса пишет старший инженер с 10 годами работы в модуле | Лид пилотной команды | Неделя 2 |
| Нехватка навыков | Средние инженеры пилотной команды ИИ раньше не пользовались или пользовались случайно | 2 занятия по 3 часа на реальных задачах из бэклога, ведёт внешний практик, 4 часа в спринте на человека заложены в план | Лид пилотной команды | Дни 10–13 подготовки |
До пилота: условия ИБ и файл контекста. На второй волне: проверить, хватило ли 2 занятий или нужен наставник в каждой команде.
Мария (продукт, 60 инженеров, раскатка на все команды)
| Риск | Почему для нас | Что делаем | Ответственный | Срок |
|---|---|---|---|---|
| Узкое место в ревью | Во второй волне без лимита на размер пул-реквестов очередь на ревью выросла за месяц. Новые команды придут со старым процессом ревью | Лимит 400 строк на пул-реквест и предварительный разбор моделью включаем в каждой команде до её подключения, а не после; дежурный ревьюер в каждой команде | Лид платформенной команды | До раскатки на все команды |
| Рост нестабильности | Доля принятых предложений у нас росла вместе с дефектами | Доля сбойных изменений на панели еженедельно, отдельно по каждой новой команде; при росте больше чем на 3 процентных пункта – разбор причин на ближайшей встрече | Мария | С первой недели раскатки |
| Сопротивление и мерж непонятого кода | Во второй волне под очередью на ревью команды начали мержить не глядя, а те, кто не открыл инструмент, сопротивлялись сильнее всех | Право не пользоваться ИИ, если человек объяснил почему (блок 13). Платформенная команда первые 2 недели ходит в каждую новую команду и помогает руками. На ревью вопрос «объясни, что здесь происходит»: не объяснил – не мержим | Мария | С первого дня раскатки |
До раскатки: лимит на пул-реквест во всех командах и панель по командам. При раскатке: проверить, держится ли время ревью в командах, подключённых последними.
первыми бьют регуляторные ограничения, brownfield и нехватка навыков; узкое место в ревью и пилот, который не масштабируется, – следом.
главные риски другие – зависимость от одного человека, который «понимает ИИ», зависимость от поставщика (смена цен или закрытие API) и нехватка навыков у остальных. Против первого помогает файл контекста в репозитории вместо знаний в голове, против второго – слой переключения поставщика из блока 03.
Вы проверили масштабирование на второй волне. Это правильный ответ, хотя Даниил прав, что в банке каждая новая команда означает ещё одно согласование с ИБ. Главное из блока: большинство сложностей видно только на типичных командах, а регуляторику и аудиторский след закрывают до старта. Соберите документ по промпту и переходите дальше.
Дальше блок 13 «Люди»: Всё предыдущее (инструменты, процессы, метрики) не работает, если не работают люди.