После того как компании упираются в проблемы аудита и воспроизводимости, часто появляется ощущение, что решение очевидно. Нужно добавить оркестрацию. Разнести функции по агентам. Настроить пайплайн. Поставить мониторинг. Подключить RAG. Ввести валидацию.
Снаружи это выглядит как зрелая инженерия.
Но внутри часто сохраняется тот же фундаментальный дефект. Система по-прежнему строится вокруг генерации, а управление пытаются пристроить поверх. Именно поэтому многие проекты всё равно приходят к переписыванию, только позже и дороже.
Оркестрация управляет действиями, но не управляет правилами
Оркестратор решает важную задачу. Он координирует исполнителей.
Он определяет порядок шагов.
Он распределяет роли.
Он запускает инструменты.
Он управляет очередностью и зависимостями.
Это даёт структуру. Но не даёт нормативность.
Потому что главный вопрос enterprise звучит иначе. Не что система сделала, а почему она решила, что это допустимо.
Два проекта могут иметь одинаковую оркестрацию и одинаковые агенты, но принимать разные решения на одном и том же кейсе. Причина в том, что логика допустимости не формализована. Она растворена в промптах, в контексте, в retrieval, в вероятностном выводе модели.
В результате система может быть хорошо организована, но оставаться непредсказуемой.
Почему это проявляется именно при росте
Пока система маленькая, команда держит контекст в голове. Архитектор помнит ограничения. Техлид помнит, какие решения были приняты раньше. Риски компенсируются ручной проверкой.
Но по мере роста происходит неизбежное.
Сценариев становится больше.
Людей в проекте становится больше.
Интеграций становится больше.
Доменных правил становится больше.
И система сталкивается с проблемой, которую нельзя решить увеличением числа агентов.
Появляется конфликт норм.
Одни правила требуют безопасности.
Другие требуют скорости.
Третьи требуют соответствия регламенту.
Четвёртые требуют совместимости с legacy.
Если нет слоя, который управляет правилами как объектом архитектуры, эти конфликты решаются случайно. Иногда промптом. Иногда тем, какие документы попали в контекст. Иногда тем, как модель интерпретировала формулировку.
Это и есть причина, почему оркестрации недостаточно.
Аудит требует не логов, а воспроизводимой нормы
Компании часто думают, что аудит это логирование. Если мы записали запросы, ответы, промежуточные шаги и вызовы инструментов, значит мы готовы.
Но корпоративный аудит обычно требует другого.
Показать, какие правила действовали в момент решения.
Показать, что правила были неизменны в рамках процедуры.
Показать, что решение согласуется с этими правилами.
Показать, что та же процедура при тех же условиях даст тот же результат.
Логи фиксируют факт, но не фиксируют нормативную рамку.
Это ключевой разрыв.
Когда у компании возникает спорная ситуация, ей недостаточно знать, что агент сделал. Ей нужно доказать, что агент действовал допустимо.
И это невозможно без архитектуры правил.
Где именно прячется дефект
В большинстве современных AI-систем правила существуют, но не как архитектурный слой. Они размазаны по системе.
Часть правил живёт в промптах.
Часть правил живёт в подсказках оркестратора.
Часть правил живёт в документации и retrieval.
Часть правил живёт в человеческих ожиданиях команды.
Это удобно, пока система маленькая. Но в enterprise это превращается в источник риска.
Потому что такая конструкция не имеет чёткой границы. Нельзя сказать, где именно находится норма. Нельзя сказать, какая версия нормы применялась. Нельзя доказать неизменность нормы на протяжении процесса.
В результате воспроизводимость становится иллюзией.
Почему “добавим валидатор” не спасает
Следующая типовая идея. Если генерация ошибается, поставим валидатор. Пусть система проверяет результат.
Это полезно, но не решает корень проблемы.
Валидатор проверяет результат, но не управляет допустимыми траекториями решения.
Он может сказать, что выход некорректен. Но он не задаёт системную норму, внутри которой решение должно быть принято.
В итоге система начинает крутиться в циклах.
Сгенерировали.
Проверили.
Не прошло.
Сгенерировали ещё раз.
Проверили.
Это может улучшить качество, но ухудшает управляемость и экономику.
А главное, не решает вопрос ответственности.
Корпоративная среда не примет систему, где правильность получается случайной итерацией.
Экономика оркестрации без правил
С ростом сложности расходы начинают расти не на вычисления модели, а на координацию ошибок.
Становится больше проверок.
Становится больше исключений.
Становится больше ручного контроля.
Становится больше согласований между командами.
Оркестрация без архитектуры правил увеличивает число шагов, но не увеличивает степень доверия.
И в определённый момент компания понимает, что система стала сложной, дорогой и всё равно не проходит требования воспроизводимости.
Это тот момент, когда возникает переписывание.
Сдвиг парадигмы
Рынок привык думать, что зрелость AI это больше агентов и лучше оркестрация.
Но корпоративная зрелость измеряется иначе.
Зрелость это способность управлять нормой.
То есть иметь слой, который:
явно определяет правила принятия решений,
фиксирует их версионность,
ограничивает автономию внутри допустимых границ,
обеспечивает воспроизводимость результата во времени.
Это уже не “ещё один компонент”. Это архитектурный центр.
И именно здесь начинается новая парадигма. AI перестаёт быть инструментом генерации и становится слоем управления.
Вывод
Оркестрация важна. Но она не решает проблему корпоративной зрелости.
Потому что она управляет действиями, а не правилами.
Enterprise требует не просто правильных ответов. Он требует воспроизводимой нормы, внутри которой эти ответы получаются.
Компании, которые будут наращивать агентов и пайплайны без архитектуры правил, упрутся в потолок доверия. И будут вынуждены пересобирать фундамент.
В следующей статье я разберу, что означает архитектура правил на уровне системы, почему она должна быть версионной, и как именно она превращает автономию из риска в управляемый актив.