Архитектура в эпоху вероятности: почему наши старые чертежи больше не работают

Последние пару лет мы наблюдаем классическую ошибку выжившего на масштабе целой индустрии. Вендоры показывают нам синтетические бенчмарки, где AI пишет микросервис за три минуты, а продуктовые менеджеры требуют сократить time-to-market вдвое. Я руковожу архитектурной функцией достаточно давно, чтобы понимать, что написание кода никогда не было узким горлышком в энтерпрайзе. Узким горлышком всегда была интеграция нового куска логики в существующий ландшафт с его легаси, регуляторикой и ограничениями ИБ.

С приходом LLM-агентов и генеративного ИИ наша профессия не просто изменилась, а дала трещину по базовым абстракциям. Мы всю жизнь строили детерминированные системы, где одни и те же входные данные гарантируют один и тот же результат. А сегодня вынуждены встраивать в ядро банковских систем вероятностные компоненты, которые при каждом вызове могут вести себя немного иначе.

Ниже — детальный разбор того, что на самом деле происходит с разработкой, почему глобальные фреймворки разбиваются о нашу суверенную реальность и как именно мы перестраиваем процессы проектирования (Enterprise, Solution, Software) в 2026 году. Без футурологии. Только то, что работает и ломается на проде.

Когнитивный диссонанс продуктивности и архитектурный долг

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

Для нас сейчас важнее всего не маркетинговые отчеты Microsoft, а рандомизированный тест METR 2025 года. Опытных разработчиков заставили решать задачи на зрелых, сложных базах кода (тот самый brownfield, в котором мы все живем). Инженеры, использовавшие ИИ, затратили на задачи на 19% больше времени. При этом их субъективная оценка была обратной: они искренне считали, что ускорились на 20%.

Разрыв восприятия в 39 пунктов — это диагноз. Нейросеть великолепно снимает «страх чистого листа». Разработчик моментально получает кусок кода и испытывает дофаминовый всплеск. Но дальше начинается ад интеграции. Сгенерированный код выглядит синтаксически идеально, но часто семантически не учитывает неявные зависимости легаси-систем. В итоге инженер тратит часы на дебаг того, что выглядит как рабочий код, но падает в рантайме.

Данные GitClear за последние годы показывают катастрофическую динамику: объем скопированного кода превысил объем отрефакторенного, а churn rate (доля свежего кода, переписываемого вскоре после коммита) подскочил с 3,3% в эпоху до массового внедрения ИИ до 7,1%. DORA в своих отчетах фиксирует ту же аномалию: пропускная способность растет, но стабильность поставок деградирует. Код стал слишком дешевым в производстве.

Деградация кодовой базы переросла масштаб проблем тимлидов и стала системным архитектурным риском. Наш единственный выход — перестать верить людям на код-ревью и перенести вес на детерминированные сенсоры в пайплайнах. Архитектор сегодня обязан проектировать fitness functions, линтеры и контракты, которые физически не дадут слить галлюцинирующий или структурно кривой код в мастер. Мы перешли от написания архитектурных документов к написанию guardrails-as-code.

Регуляторная реальность: два разных глобуса

Читая западную аналитику, можно подумать, что индустрия получила передышку. EU AI Act Omnibus окончательно зафиксировал дедлайны: жесткие требования к системам высокого риска (Annex III — кредитный скоринг, антифрод) отложены до 2 декабря 2027 года. В США ФРС и FDIC выпустили SR 26-2, где прямым текстом вывели генеративный и агентный ИИ из-под действия стандартного Model Risk Management (MRM). Американские регуляторы посчитали, что LLM развиваются слишком хаотично, чтобы мерить их старыми лекалами валидации моделей, и решили строить параллельные контуры управления.

Для архитектора в российском банке эти новости не столь важны. Мы живём в другой парадигме, где архитектура диктуется не просто рисками галлюцинаций LLM, а еще и технологическим суверенитетом.

В России регуляторика накладывает на Enterprise-архитектора другие обязанности. Наш фундамент проектирования — это 187-ФЗ (КИИ) и 850-П (операционная надежность). Дедлайн по переводу значимых объектов КИИ на отечественный стек (базово — 1 января 2028 года) означает, что мы не можем полагаться на западные SaaS и облачные API для критичных узлов. EA стал арбитром технологического выбора: любое архитектурное решение проходит фильтр принадлежности к реестру российского ПО, оценки категории значимости объектов КИИ и локализации персональных данных по 152-ФЗ.

Отдельная история связана с Положением № 850-П, которое заменило Положение № 787-П и требует детального маппинга критичных бизнес-процессов на объекты информационной инфраструктуры. Владельцем этого маппинга теперь выступает архитектурная функция.

Но самое интересное произошло в июне 2026 года с выходом 3-МР Банка России. Пункт 2.5 этого документа прямо рекомендует внедрять обязательное подтверждение операции сотрудником с возможностью их изменения, если ИИ используется в критически важных процессах (например, в платежах) и риски информационной безопасности оцениваются как высокие. Для нас это императив. Паттерн human-in-the-loop стал обязательным архитектурным слоем, который мы должны закладывать в дизайн любой ИИ-системы, допущенной до финансовых транзакций. Мы физически проектируем точки перехвата управления.

Закон об ИИ (243-ФЗ) закрепил понятия «суверенных» и «национальных» моделей. Пока обязательные ограничения на их использование не детализированы, но это уже стоит учитывать в архитектуре. Поэтому мы заранее закладываем абстракцию над LLM (роутеры), чтобы при изменении регуляторных требований переход с одной модели на другую не парализовал банк.

Анатомия ИИ-интеграций: где рвутся шаблоны

Когда мы спускаемся на уровень Solution-архитектуры, старые методы выявления рисков не работают. Мы пересобрали процесс ревью вокруг трех критических узлов.

1. Уровни риска ИИ-компонентов

В августе 2026 года OWASP выпустил обновленный топ рисков и разделил его на две ветки. Теперь любое дизайн-ревью начинается с вопроса: «Модель — это компонент или актор?».

Если модель заперта в песочнице приложения, анализирует входящий текст и отдает ответ на экран (чат-бот поддержки) — это компонент. Мы защищаем его от промпт-инъекций и утечек по стандартному OWASP GenAI LLM Top 10.

Но если у модели есть память, доступ к API, возможность строить планы и вызывать функции — это актор. Риск Excessive Agency (избыточная агентность) здесь взлетает на третье место. Актор требует применения OWASP Agentic Top 10 и совершенно иного уровня изоляции. Мы выстраиваем песочницы для исполнения кода, ставим жесткие лимиты на вызовы инструментов и отрезаем ему прямой доступ к базам данных.

2. Идентичность агентов и кризис авторизации

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

Если вы дадите агенту статический API-ключ с широкими правами, вы откроете дверь для атаки confused-deputy. Злоумышленник через хитрый промпт заставит легитимно авторизованного агента выполнить вредоносное действие с максимальными привилегиями.

Сейчас архитектурный стандарт требует, чтобы каждый агент получал собственную независимую идентичность. Но права на конкретные действия выдаются исключительно через короткоживущие токены делегирования (per-invocation delegation tokens), которые содержат контекст конкретной задачи и предоставляют агенту лишь необходимые для её выполнения полномочия пользователя. В логах аудита должна быть идеальная трассировка: где кнопка была нажата человеком, а где решение принял агент от лица этого человека. Перед выполнением запроса или выдачей ответа обязательно проверяется, имеет ли пользователь право на доступ к запрашиваемым данным. Без этого безопасность не подпишет ни один акт о вводе в пром.

3. Наследуемый ИИ (Vendor-Inherited AI)

Огромная часть ИИ проникает в инфраструктуру незаметно. Вендоры SaaS-, ERP- и ITSM-систем каждую неделю выкатывают обновления, активирующие встроенные Copilot-ы. Включенная вендором функция может без предупреждения изменить карту потоков данных, отправив чувствительные данные на обработку во внешнюю инфраструктуру. Это не просто угроза нарушения 152-ФЗ, но и риск утечки. Для банковских систем к этому добавляются требования по сохранению банковской тайны (ст. 26 закона «О банках и банковской деятельности» и ст. 857 ГК РФ).

Решение — жесткая политика на уровне Enterprise: Default-off для любых внешних ИИ-функций. Активация вендорского ИИ приравнивается к мажорному архитектурному изменению и проходит полный цикл согласования. EA ведет отдельный реестр наследуемого ИИ для оценки реального масштаба угроз.

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

Инструментарий, Git и смерть ARB

В западный EA-инструментарий сейчас активно встраивают Model Context Protocol (MCP). SAP LeanIX и Bizzdesign позволяют ИИ-агентам напрямую читать архитектурные схемы и репозитории как контекст для генерации кода.

Российские компании отрезаны от этого стека. Вся регуляторная база, маппинг 850-П и реестры КИИ ведутся в самописных системах или системах из реестра российского ПО. А архитектурная документация (ADR, C4-схемы, описания API) живет как код в Git (Markdown, PlantUML, Structurizr). LLM-агенты читают сырой текст в Git намного лучше, чем выгрузки из проприетарных систем. Мы просто пишем файлы контекста (RULES.md, ARCHITECTURE.md), и агент-разработчик автоматически понимает локальные конвенции нашего домена. Для этого мы написали свой внутренний слой абстракции над репозиториями с поддержкой MCP, но это окупилось сторицей. Документация снова обрела ценность. Теперь она пишется не для ARB, а для машин.

Кстати, про ARB (Architecture Review Boards). Мы их распустили. Этот бюрократический механизм стал несовместим со скоростью рынка. Мы перешли на architecture advice process в рамках федеративной модели. Решение принимает тот Solution-архитектор, который физически сидит в домене и пилит продукт. Он обязан запросить экспертизу гильдии, но финальная ответственность на нем. Исключение составляют регуляторные ограничения (контуры ИБ, реестр ПО). Они остаются обязательными guardrails, но не исключают гибкости в выборе архитектурных решений.

Операционная модель работает через три линии защиты (3LoD). Архитекторы (1LoD) строят границы, рисковики (2LoD) обеспечивают «эффективный вызов» решений, а аудит (3LoD) проверяет работоспособность контролей.

В наши шаблоны ADR (Architecture Decision Records) добавились новые тяжелые блоки:

• Четкая фиксация границы между детерминированной логикой (которая не должна меняться никогда) и вероятностным выводом LLM.

• Топология потоков данных и подтверждение того, что обработка выполняется в контуре банка.

• Триггеры для перехвата управления человеком (human-in-the-loop).

• Стратегия выхода (exit path), если выбранный вендор модели деградирует или изменит лицензию.

Нефункциональные требования (NFR) тоже мутировали. Как вы опишете SLA для сервиса, который может непредсказуемо галлюцинировать? Мы ввели метрики refusal/abstention behavior (поведение при отказе). Нам важно знать, как ведет себя система, когда модель не уверена в ответе. Для банка «правильный отказ» в сто раз ценнее рискованной галлюцинации.

Мы жестко лимитируем FinOps, устанавливая предел стоимости в токенах на каждую бизнес-транзакцию, и измеряем latency для всего цикла, а не только для отдельного запроса к LLM, с учётом обращений агента к внешним системам (tool calling).

Вопросы, которые сломают нас завтра

Дисциплина сейчас переизобретает саму себя, и у нас больше вопросов, чем ответов.

Например, что делать с метамоделями? Тот же ArchiMate физически не способен адекватно описать промпт, порог валидации, толерантность к галлюцинациям или динамическую цепочку делегирования агента. Мы пытаемся расширять нотацию костылями, но индустрии нужен новый язык визуализации вероятностных систем.

Что будет с размером сервисов? Микросервисы расцвели потому, что человек физически не мог удержать в голове огромный монолит. Но LLM прекрасно переваривает гигантские объемы контекста. Значит ли это, что модульные монолиты вернутся? С другой стороны, генерация кода стала такой дешевой, что мы рискуем получить беспрецедентный взрыв «микросервисного спама», который убьет любую инфраструктуру.

Чертеж, ограда и доказательство

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

Чертеж — это обещание, что система сделает вот так. Вероятностный компонент таких обещаний не дает. Посмотрите на всё, что мы построили выше. Fitness functions описывают то, что не попадет в мастер, а токены делегирования — то, чего агент не сможет сделать сверх задачи пользователя. Default-off, точки перехвата человеком, поведение при отказе, лимит токенов, exit path — каждый пункт очерчивает границу, а не маршрут. Архитектура переходит от описания того, как система должна работать, к описанию того, как она не должна работать и что произойдет, когда она всё же сделает именно это. Мы стелем настил поверх подводных камней, не зная, где ударит волна.

Но одной границы недостаточно. Она должна работать на трех горизонтах: заранее (ограничить), в момент действия (перехватить) и после него (доказать). Третий слой мы долго недооценивали. Если агент ошибается, вопрос «почему он так решил» может не иметь честного ответа. И остается другой: «Что он видел, на каком основании, с чьими полномочиями действовал и кто подтвердил его действия?». Не случайно Банк России уже говорит о том, что предметом регулирования может стать не сама модель, а архитектура данных, на основании которой она принимает решения. Регулятор и архитектор подходят к одной точке с двух сторон: раз модель непрозрачна, контролировать нужно то, что вокруг нее.

Меняется и сам архитектурный артефакт. У чертежа нет срока годности, пока не изменилась система. У решения о вероятностном компоненте он есть: модель дрейфует, вендор меняет лицензию, внешний Copilot включается очередным обновлением. ADR без даты и триггеров пересмотра — это снимок, а не решение. Факт и решение теперь хранятся вместе с источником, уровнем доверия и сроком годности.

Остается то, что не снимает автоматизация. Система может быть вероятностной, но ответственность остается вполне определенной. Паспорт модели, токен делегирования и точка подтверждения человеком отвечают на один и тот же вопрос: «Кто отвечает, если ошибка случится?». Архитектор теперь проектирует не только поведение системы, но и место, где ответственность за дальнейшее решение переходит от машины к человеку.

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

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