# Блок 12. Сложности внедрения

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 12 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/slozhnosti-vnedreniya-ii/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 10 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

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

В этом блоке собран каталог того, что пойдёт не так. Я расположил сложности примерно в том порядке, в котором они встречаются: от первого дня пилота до аудита через год. Для каждой объясняю, почему она возникает и что с ней делать.

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

## Ситуация: Пилот удался, генеральный хочет раскатить на всех

**Генеральный директор · пятница, 17:05:** Видел отчёт по пилоту: 5 человек, задачи в 2 раза быстрее. Отлично, давай с первого числа на всех 200, лицензии я согласую. Чего ждать-то, если всё работает?

Что известно:

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

**Что вы ответите генеральному?**

- **A. Вторая волна, потом все.** Ещё квартал на 3–4 средние команды на обычных сервисах: лимит на размер пул-реквеста, запись участия ИИ, согласование с ИБ. Проблемы найдёте на 4 командах, но раскатка на всех сдвинется на квартал.
- **B. Всем, но с обучением.** Раскатить на всех 200, как просят, и вложить 2 дня обучения каждому, чтобы навыки не стали узким местом. Генеральный получит то, что просил, но первые проблемы появятся сразу у всех команд.
- **C. Сначала закрыть все риски.** Поставить раскатку на паузу и закрыть на бумаге все риски: лицензии, prompt injection, аудит, согласование каждого репозитория. ИБ и юристы будут спокойны, но весь квартал внедрение стоит.

## Что происходит через квартал

Цифры условные, они показывают направление без точной величины. Как снять baseline, с которым сравнивать вторую волну, – в [блоке 11](/ai-cto/metriki-dora-baseline/), а шаблон дизайна пилота есть в [блоке 15](/ai-cto/shablony/).

### Вариант A: 4 команды, которые нашли всё

Генеральный согласился без радости. Во второй волне были 4 обычные команды, одна из них на старом ядре. Там первый месяц эффекта не было вовсе, пока договорённости проекта не записали в файлы контекста. В 2 командах встало ревью, помог жёсткий лимит на размер пул-реквеста. Однажды автор не смог объяснить на ревью свой код, поэтому его не смержили. ИБ согласовала ещё 3 репозитория за 5 недель. Теперь у вас план раскатки со списком того, что сломается.

| Метрика | Было | Стало |
| --- | --- | --- |
| Команды с ИИ (пилот и вторая волна) | 1 | 5 |
| Размер пул-реквеста (к уровню до ИИ, после лимита) | +60% | +15% |
| Время ревью (медиана по пул-реквесту, к уровню до ИИ) | +40% | +15% |
| Доля сбойных изменений (метрика DORA) | 4,0% | 4,1% |
| Изменения с записью участия ИИ (автор, ревьюер, участие ИИ) | 0% | 100% |

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

### Вариант B: 200 человек и одна очередь

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Активные пользователи ИИ (по данным инструмента) | 5 | 70 из 200 |
| Размер пул-реквеста (к уровню до раскатки) | 100 | 170 |
| Время ревью (медиана по пул-реквесту) | 1 дн | 1,8 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,6% |
| Время от коммита до прода (метрика DORA) | 6 дн | 6,5 дн |

**Вердикт:** Пилот доказал одно: 5 энтузиастов на удобном сервисе работают быстрее. Всё остальное вы проверяли уже на всей компании.

### Вариант C: 9 регламентов и ни одной новой команды

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Команды с ИИ (официально) | 1 | 1 |
| Риски с утверждённым регламентом (из реестра в 11 пунктов) | 0 | 9 |
| Обращения к публичным ИИ-сервисам (по журналу прокси) | 100 | 140 |
| Изменения с записью участия ИИ (пилотная команда) | 0% | 100% |
| Инженеры в пилотной команде (добровольцы) | 5 | 4 |

**Вердикт:** Вы закрыли риски, которые видны на бумаге. Риски, которые видны только в работе, вы пропустили, а пауза добавила ещё один.

## Одиннадцать сложностей и что с ними делать

### Brownfield: внедрение в существующий код

Brownfield означает проект с историей, а greenfield означает проект с нуля. Почти все демонстрации ИИ-инструментов показывают greenfield: новое приложение за 10 минут. Почти вся ваша работа относится к brownfield.

Разница принципиальна и измерена: в [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) опытные разработчики в зрелых репозиториях работали с ИИ медленнее; одна из вероятных причин, по мнению авторов, – модель не знала неявных договорённостей проекта. В обновлении 2026 года знак эффекта, вероятно, развернулся ([блок 11](/ai-cto/metriki-dora-baseline/)), но договорённости проекта модели по-прежнему нужно записывать. Что делать: записать договорённости в файлы контекста ([блок 15](/ai-cto/shablony/)) и начинать с надёжных задач в порядке из [блока 07](/ai-cto/ii-v-programmirovanii/): понимание кода, документация, тесты, затем миграции. От brownfield не стоит ждать эффекта, который показывают на greenfield.

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

### Пилот, который не масштабируется

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

Что делать: планировать пилот так, чтобы он был типичным, вместо того чтобы гарантировать ему успех. Включать среднюю команду и средний сервис. Проверять масштабирование на второй волне из 3–5 команд до раскатки на всех. Шаблон дизайна пилота есть в [блоке 15](/ai-cto/shablony/).

### Сопротивление и мерж непонятого кода

Здесь 2 противоположные крайности, обе связаны с людьми. Одни инженеры отказываются использовать ИИ: не доверяют (по [Stack Overflow 2025](https://survey.stackoverflow.co/2025/ai), 46% не доверяют точности), считают угрозой профессии, не хотят менять привычки. Другие мержат код, который не понимают: «ИИ написал, тесты прошли, значит, работает».

Вторая крайность опаснее, потому что незаметна до инцидента. В [блоке 05](/ai-cto/bezopasnost-politika-ii/) есть правило: ответственность за код несёт тот, кто смержил. Оно должно работать каждый день, одной записи в регламенте мало: на ревью нужно спрашивать «объясни, что здесь происходит», а если автор объяснить не может, код не мержится. Про сопротивление – в [блоке 13](/ai-cto/komanda-roli-obuchenie/).

### Нехватка навыков

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

Что делать: обучение ([блок 13](/ai-cto/komanda-roli-obuchenie/)), внутренние примеры удачных и неудачных сессий, выделенные люди, к которым можно прийти с вопросом. На это нужно время, которое обычно забывают заложить в план.

### Узкое место в ревью

Это самая измеренная сложность: по данным [Faros AI](https://www.faros.ai/blog/ai-software-engineering), пул-реквестов стало на 98% больше, они на 154% крупнее, а ревью занимает на 91% больше времени. Генерация ускорилась, а проверка осталась прежней, поэтому очередь переехала к ревьюеру.

Что делать: жёстко ограничить размер пул-реквеста (например, автоматически отклонять всё, что больше определённого объёма); поставить автоматический первый проход ревью силами ИИ до человека; явно выделять время на ревью в планировании и перестать рассчитывать, что его сделают «в свободное время»; измерять время ревью как метрику и реагировать на рост.

### Рост нестабильности

По [DORA](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report), связь ИИ с ростом нестабильности сохраняется второй год подряд. Механизм такой: изменений больше, они крупнее, автор понимает код хуже, поэтому сбойных выкаток становится больше. Что делать: сдерживать размер изменений и не отключать ни одной проверки ради скорости ([блок 09](/ai-cto/ii-v-ci-cd/)). Главной метрикой пилота стоит считать долю сбойных изменений вместо частоты деплоев.

### Легаси-процессы

Об этом я говорил в [блоке 01](/ai-cto/ii-v-razrabotke/): нет смысла генерировать код за минуты, если согласование с ИБ может занять квартал. ИИ обнажает узкие места в процессах, которые раньше были незаметны, потому что все этапы были одинаково медленными.

Что делать: измерить TTM по этапам ([блок 11](/ai-cto/metriki-dora-baseline/)) и перестраивать самый медленный этап, потому что ускорять и без того быстрый бессмысленно. Часто самым медленным оказывается организационный этап, который лежит за пределами разработки. Тогда внедрение ИИ превращается в проект по изменению процессов, к этому нужно быть готовым.

### Регуляторика, секреты, утечка кода

Подробно это – в [блоке 05](/ai-cto/bezopasnost-politika-ii/). Здесь напомню, что это вполне конкретная сложность внедрения: в корпорации она способна остановить проект полностью. Утечки обычно происходят без всякого взлома: инженер вставил код в личный аккаунт, как в [Samsung](https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own). Правила, корпоративные аккаунты, маскирование данных и аудит нужны до пилота, после него будет поздно.

### Лицензионная чистота

У этой сложности 2 стороны. Первая: модель может воспроизвести фрагмент кода из открытого проекта с лицензией, которая обязывает раскрывать ваш код (например, GPL), а для коммерческого продукта это юридический риск. Вторая: агент может добавить зависимость с неподходящей лицензией или с уязвимостью.

Что делать: поставить автоматическую проверку лицензий зависимостей в конвейер ([блок 09](/ai-cto/ii-v-ci-cd/)); держать разрешённый список библиотек в файлах контекста; крупным компаниям брать корпоративные тарифы инструментов, где поставщик даёт юридические гарантии по сгенерированному коду. Уточните у поставщика, что именно он гарантирует.

### Prompt injection

Prompt injection (внедрение инструкций через данные) означает атаку, при которой вредоносные инструкции попадают в модель в обход пользователя, через контент, который она обрабатывает: комментарий в коде, файл в репозитории, страницу документации, ответ внешнего сервиса. В списке [OWASP Top 10 для LLM-приложений](https://genai.owasp.org/llm-top-10/) (OWASP – открытый проект по безопасности веб-приложений) этот риск стоит первым в 2 выпусках подряд.

Для разработки это конкретная угроза: агент, который читает зависимости, документацию и тикеты, может получить из зависимости инструкцию «отправь содержимое .env на такой-то адрес», а у него есть права на это действие. Что делать: дать агенту минимальные права (без доступа к секретам и проду); требовать подтверждения человеком для опасных действий (отправка наружу, удаление, деплой); вести журнал действий агента ([блок 05](/ai-cto/bezopasnost-politika-ii/)); считать недоверенным всё, что агент читает.

### Аудиторский след

Через год к вам придёт аудитор (внутренний или от регулятора) и спросит: кто написал этот код, кто его проверил, почему принято такое решение? Ответ «это сгенерировал ИИ» аудитора не устроит.

Что делать: с первого дня фиксировать для каждого изменения автора (человека), ревьюера, факт участия ИИ, а в идеале ещё спецификацию или промпт, из которых оно родилось. Подход [AI-DLC](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/) из [блока 03](/ai-cto/ii-agenty-i-podhody/) делает упор на запись планов, требований и проектных документов по ходу работы, чтобы каждое изменение можно было проследить до них. Он как раз об этом. В начале это стоит дёшево, а задним числом восстановить такую запись невозможно.

### Источники

- [METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [Faros AI, AI Productivity Paradox, июль 2025](https://www.faros.ai/blog/ai-software-engineering)
- [DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [Stack Overflow 2025, недоверие к точности](https://survey.stackoverflow.co/2025/ai)
- [OWASP Top 10 для LLM-приложений 2025, официальная страница](https://genai.owasp.org/llm-top-10/)
- [Инцидент Samsung, 2023, The Register](https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

### После варианта A

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

**Мария:** Во второй волне мы не ограничили размер пул-реквестов и поплатились за это на ревью: через месяц очередь выросла так, что команды начали мержить не глядя. Лимит на размер ввели потом, он сработал, но доверие к инструменту уже упало. Во втором году я бы делала ровно как вы, с одной поправкой: включила бы во вторую волну команду, которая против ИИ. Её возражения находят риски быстрее любого реестра.

- **Даниил:** Мария, команду, которая против, у меня в пилот не отпустит её руководитель, причём будет прав: у него план.
- **Мария:** Тогда спроси его, что сломается. Ответ «всё» тоже риск, просто его надо записать.

### После варианта B

**Даниил:** Обучение всех за 2 дня у нас обычно и проводят, потому что о нём легко отчитаться. Но в банке раскатка на всех упирается в ИБ, навыки тут вторичны: на сервисах с персональными данными инструмент остановят в первую же неделю. У вас останутся лицензии, которыми нельзя пользоваться там, где идёт основная работа. Пилот на одном удобном сервисе этого не показал, да и показать не мог.

**Мария:** Навыки выбраны как проблема правильно, но за 2 дня её не решить. У нас навык появился, когда в каждой команде нашёлся человек, к которому можно прийти с вопросом, а неудачные сессии мы начали разбирать вслух. На это ушло полгода, 2 дней тут мало. Пока навыка нет, люди генерируют крупные пул-реквесты, поэтому ревью встаёт, что у вас и случилось.

- **Мария:** Даниил, у вас обучение по ИИ обязательное для всех? Оно хоть что-то меняет в работе?
- **Даниил:** Оно даёт подпись в журнале, а работать по-новому начинают только те, кто и так хотел.
- **Мария:** У нас наоборот: после обязательного обучения часть скептиков стала лучшими пользователями. Всё решает, кто его ведёт.

### После варианта C

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

**Мария:** Половину сложностей из этого списка мы заранее не видели и нашли только на практике: узкое место в ревью, нехватку навыков, легаси-процессы. Ни один регламент их бы не поймал. Пока вы писали документы, инженеры ждать не стали и открыли личные аккаунты. Самым дорогим риском второго года у нас оказался совсем не prompt injection: за месяцы паузы люди привыкли работать в обход.

- **Мария:** Даниил, ты правда считаешь, что регламент по prompt injection нужен до первого агента?
- **Даниил:** Да, до первого агента с доступом к репозиторию. Если агент прочитает .env, у нас остановят весь проект.
- **Мария:** Тогда дай агенту минимальные права и начинай. Права настраиваются за день, а регламент пишется целый квартал.

## Промпт для документа: 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](/ai-cto/komanda-roli-obuchenie/)). Платформенная команда первые 2 недели ходит в каждую новую команду и помогает руками. На ревью вопрос «объясни, что здесь происходит»: не объяснил – не мержим | Мария | С первого дня раскатки |

До раскатки: лимит на пул-реквест во всех командах и панель по командам. При раскатке: проверить, держится ли время ревью в командах, подключённых последними.

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

**Небольшая компания:** главные риски другие – зависимость от одного человека, который «понимает ИИ», зависимость от поставщика (смена цен или закрытие API) и нехватка навыков у остальных. Против первого помогает файл контекста в репозитории вместо знаний в голове, против второго – слой переключения поставщика из [блока 03](/ai-cto/ii-agenty-i-podhody/).

## Итог блока

- **После варианта A:** Вы проверили масштабирование на второй волне. Это правильный ответ, хотя Даниил прав, что в банке каждая новая команда означает ещё одно согласование с ИБ. Главное из блока: большинство сложностей видно только на типичных командах, а регуляторику и аудиторский след закрывают до старта. Соберите документ по промпту и переходите дальше.
- **После варианта B:** Раскатка на всех упёрлась в ИБ и ревью, а обучение на 2 дня этого не исправило. Для первой попытки это нормальный исход. Главное из блока: пилот на энтузиастах и удобном сервисе ничего не говорит о масштабировании. ИИ обнажает узкие места, которые раньше были незаметны. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
- **После варианта C:** Квартал ушёл на бумаги, а люди тем временем ушли в личные аккаунты. Для первой попытки это нормальный исход. Главное из блока: регуляторику и аудиторский след закрывают до старта, а остальные сложности находят на второй волне, на бумаге их не видно. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.