Yan Lukashin

Системное мышление для внедрения ИИ: почему автоматизация хаоса даёт автоматизированный хаос

На потоке маркетолог из e-commerce рассказала, как они «внедрили ИИ». Её команда из четырёх человек тратила два дня на еженедельный отчёт по рекламным кампаниям. Подключили GPT — и время генерации отчёта упало с двух дней до двадцати минут.

Победа?

Нет. Потому что отчёт после этого лежал в почте руководителя от трёх до пяти дней. Потом — два дня на согласование правок. Потом — день на рассылку по отделам. Итого: процесс занимал 8-10 дней. Стал занимать 8-9 дней. Разница — в пределах погрешности.

Они ускорили двадцатиминутный кусок десятидневного процесса. И искренне не понимали, почему «ИИ не работает».

Знакомо?

Закон, которому 40 лет — и который все игнорируют

В 1984 году физик Элияху Голдратт написал бизнес-роман «Цель». Книгу про то, как завод выживает, сфокусировавшись на одном принципе: система работает со скоростью самого медленного элемента.

Это Theory of Constraints. Теория ограничений. Звучит скучно, но следим за руками.

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

Билл Гейтс сформулировал это проще: автоматизация эффективной операции усиливает эффективность. Автоматизация неэффективной — усиливает неэффективность.

А теперь наложите это на то, как большинство компаний «внедряют ИИ».

88% компаний в мире используют ИИ хотя бы в одной функции. Но только 6% видят реальный эффект на прибыль. Это данные McKinsey за 2025 год, почти две тысячи респондентов из 105 стран. BCG подтверждает независимо: 60% компаний не получают от ИИ никакой материальной ценности. Bain добавляет: без перестройки процессов прирост — 10-15%, и тот быстро выходит на плато.

Почему? Потому что 88 из 100 ускоряют не то место.

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

Узкое место — почти всегда кожаный мешок. Согласование, передача, ожидание решения.

Узлы и связи: на что смотрит архитектор

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

Пользователь на [уровне L1-L2] смотрит на узлы. «Какой инструмент лучше пишет тексты?» «Какая нейросеть точнее анализирует?» «Какой промпт даёт лучший результат?»

Архитектор [на L4] смотрит на связи. «Откуда берутся данные для этого текста?» «Куда уходит результат анализа?» «Кто ждёт этот отчёт и в каком виде?»

Данные подтверждают: в большинстве процессов только 5-10% времени — это собственно работа. Создание ценности. Остальные 90-95% — ожидание, передача, согласование, поиск информации. Это классика Lean Six Sigma, десятилетия замеров.

APQC опросили 982 специалиста: 25% рабочего времени теряется на трение. 3,6 часа в неделю — на внутренние коммуникации. 2,8 часа — на поиск информации. 2,2 часа — на ненужные встречи.

Если 90% времени процесса — не в узлах, а в связях, то оптимизировать узлы — это бить мимо цели. Не важно, как круто пишет ChatGPT. Важно — откуда он берёт данные и куда результат попадает автоматически.

Это и есть разница между оператором и архитектором. Оператор ускоряет узел. Архитектор перестраивает поток.

Генератор мусора: что бывает без обратной связи

Есть новое слово — workslop. Это AI-контент, который выглядит как работа, но по сути — мусор. Отчёт, который никто не читает. Письмо, которое всем очевидно написано нейросетью. Код, который проходит ревью только потому, что ревьюеру лень вчитываться.

BetterUp совместно со Стэнфордом опросили 1150 работников. 40% сталкиваются с workslop регулярно. На переделку каждого инцидента уходит в среднем почти два часа. 15% всего рабочего контента — workslop. Для компании на 10 тысяч человек это больше $9 миллионов в год.

Upwork выяснил ещё кое-что неприятное: 77% сотрудников говорят, что ИИ увеличил их нагрузку. Почему? 39% дополнительной работы — это ревью и проверка AI-контента. Человек стал тестировщиком у нейросети. Генерировать стало легко. Проверять — тяжело.

А вот что реально больно. Исследование METR — рандомизированный контролируемый эксперимент, не опрос. 16 опытных разработчиков, 246 задач на зрелых репозиториях. Результат: с AI-инструментами они работали на 19% медленнее. При этом сами оценивали свою скорость как на 20% выше. Разница между ощущением и реальностью — 39 процентных пунктов.

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

Система без петли обратной связи — генератор workslop. Точка.

Минимальная рабочая архитектура выглядит так:

1. Агент генерирует — текст, код, анализ, что угодно
2. Валидатор проверяет — другой LLM, скрипт, набор правил
3. Ошибка возвращается — не человеку в почту, а обратно в цикл
4. Человек смотрит результат — уже прошедший проверку

LLM-as-judge — это не экзотика. Модели согласуются с человеческими оценками на ~80%. Это уровень согласия между двумя людьми. Не идеально, но достаточно для первого фильтра.

Человек не должен быть QA-инженером у нейросети. Это дорого, медленно и — как показывает METR — создаёт иллюзию контроля.

Человек в цикле: где резать

Ок, если человек — бутылочное горлышко, значит ли это, что его нужно убрать?

Нет. Это значит, что его нужно поставить в правильное место.

Тренд 2025 года в AI-инженерии — переход от HITL (human-in-the-loop) к HOTL (human-on-the-loop). Разница принципиальная:

HITL: AI генерирует → человек проверяет каждый output → дальше по процессу. Человек — узел в конвейере.

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

Где человек реально нужен:

- Стратегические решения. Запускать продукт или нет. Выходить на рынок или ждать. Нанимать или автоматизировать.
- Высокорисковые операции. Подпись контракта. Публикация от лица компании. Всё, где ошибка стоит дорого.
- Исключения. Нестандартные кейсы, которые система не видела. Конфликты. Эскалации.

Где человека нужно безжалостно выпиливать из конвейера:

- Рутинная валидация. Если вы ревьюите каждое письмо, каждый отчёт, каждый кусок кода вручную — вы бутылочное горлышко. Автоматизируйте проверку.
- Передача данных. Если человек копирует результат из одной системы в другую — это не работа, это протез отсутствующей интеграции.
- Согласования ради согласований. Если подпись руководителя нужна «потому что так было всегда» — проверьте, не является ли это тем самым узким местом, о котором говорил Голдратт.

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

От промптов к пайплайнам

Давайте зафиксируем.

Автоматизация хаоса даёт автоматизированный хаос. Это не метафора — это инженерный факт. McKinsey, BCG и Bain — три конкурирующие консалтинговые фирмы — сходятся в одном: компании, которые перестраивают процессы под AI, получают в 2-3 раза больше отдачи, чем те, которые просто подключают инструменты.

Формула простая:

L1-L2 (оператор): «Какой промпт написать, чтобы получить хороший результат?»

L3 (делегатор): «Как поставить задачу, чтобы AI сделал крупный блок работы?»

L4 (архитектор): «Как спроектировать систему, которая работает без моего постоянного участия?»

Переход L2 → L4 — это не про новые инструменты. Это про другой тип мышления. Системный. Где ты смотришь не на узлы, а на связи. Не на скорость генерации, а на скорость потока. Не на качество промпта, а на архитектуру пайплайна.

Три вопроса, с которых начинается этот переход:

1. Где в моём процессе узкое место? (Подсказка: скорее всего это не генерация контента.)
2. Что происходит с результатом после того, как AI его выдал? (Если ответ «лежит в чате» — у вас нет системы.)
3. Есть ли петля обратной связи? (Если нет — вы строите генератор workslop.)

На курсе [AI Architect] мы берём один реальный процесс и проходим этот путь от начала до конца. Не «как промптить лучше» — а как спроектировать workflow, который работает. Вход → обработка → валидация → выход. С метриками. С обратной связью. Без вас в роли тестировщика.

Хватит ускорять узлы. Пора перестраивать поток.

Фигачим 🔥

Источники и данные

- Goldratt, "The Goal", 1984 — Theory of Constraints
- McKinsey, "The State of AI 2025" — 1 993 респондента, 105 стран. 88% adoption, 6% high performers, workflow redesign = #1 предиктор EBIT
- BCG, "The Widening AI Value Gap", сентябрь 2025 — 60% компаний без материальной ценности от AI
- Bain, "Technology Report 2025" — 25-30% прирост с перестройкой процессов vs 10-15% без
- Не вендорное: METR, "AI-Experienced Open-Source Developer Study", 2025 (arXiv:2507.09089) — RCT, 16 разработчиков, 246 задач. AI = минус 19% скорости
- Не вендорное: APQC, "Knowledge Workers' Time Lost", 2021 — 982 респондента, 25% рабочего времени на трение
- Lean Six Sigma PCE — 5-10% value-added time в типичных процессах
- BetterUp + Stanford, "Workslop Report", 2025 — 40% работников сталкиваются, ~2ч переделки на инцидент
- *Vendor research:* Upwork, 2024 — 77% сотрудников: AI увеличил нагрузку
- Google DORA Report 2025 — больше кода, та же скорость доставки
- Авторские модели: [Эволюция специалиста L0-L6], [Эволюция компаний C0-C5]

Исследования AI Architect

Актуальные исследования внедрения ИИ в процессы бизнеса и отдельно человека
Хочешь разобраться системно?
AI Architect — программа менторства для тех, кто строит ИИ-системы, а не промпты. От индивидуального использования к институциональному внедрению.
Made on
Tilda