Корпоративная архитектура и AI‑агенты: шесть ошибок, которые не видны в репозитории

Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про шесть ошибок, из‑за которых AI‑агенты живут в компании мимо архитектурного репозитория. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

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

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

По опросу Cloud Security Alliance и Strata Identity, опубликованному в феврале 2026 года, реестр агентов в реальном времени ведёт только 21% организаций.

В апрельском опросе того же CSA 82% респондентов сказали, что за последний год находили у себя агентов, о которых раньше не знали, а у 41% это случалось не раз. Ниже разберу шесть ошибок, которые к этому приводят, и покажу их на эксперименте, который можно повторить у себя за минуту.

Как я это проверял

Опросы показывают масштаб, но не механику, поэтому я собрал синтетическую компанию и прогнал по ней сверку.

Репозиторий у неё образцовый: 36 приложений, у 35 из них заполнен бизнес‑владелец, все 41 интеграция идёт по утверждённым каналам, элементов с типом «AI‑агент» ноль. Агентов скрипт ищет по двум источникам:

• MCP‑конфиги команд (MCP, Model Context Protocol, — протокол взаимодействия AI‑приложений с MCP‑серверами, которые дают инструменты и данные): какие инструменты подключены и по какому адресу;

• журнал LLM‑шлюза (шлюза к большим языковым моделям) за 90 дней: какой агент, под какой учёткой и сколько запросов к модели отправил.

Третий источник, выгрузка учётных записей из IAM (системы управления идентификацией и доступом), агентов не находит, а дополняет найденных: чья учётка, включена ли, какие права. Конфиг показывает, что агент описан, журнал подтверждает, что он обращался к модели. Агента без MCP, идущего к модели мимо шлюза, такая сверка не увидит.

Как устроена сверка, показано на схеме:

Главная мысль схемы: репозиторий здесь не отправная точка, а один из входов. Если начинать с него, агентов не найти по определению: проверять нечего, всё зелёное.

Итог прогона на 31.10.2026:

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

Ошибка 1. Агента нет в репозитории, или он записан как приложение

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

• Неверное объяснение. «Агенты — это эксперименты команд, в ландшафт им рано». Через полгода эксперимент обрабатывает обращения клиентов.

• Настоящая причина. У агента нет точки входа в процесс регистрации. Приложение попадает в репозиторий через закупку или проект, а агента команда собирает за день на уже оплаченной платформе. В октябрьском обзоре Srikanth Devarakonda по 25 рецензируемым работам вывод тот же: существующие фреймворки корпоративной архитектуры пока не считают агентов управляемыми сущностями первого класса. Четыре агента попали в репозиторий с типом «приложение», без модели, инструментов и учётки.

• Чем грозит. Анализ влияния врёт. Выводите кадровую систему из эксплуатации и не знаете, что на неё завязаны три агента.

Как исправить. Завести в метамодели отдельный тип элемента и обязательные поля: ключ корреляции со следами, модель, список MCP‑серверов, учётная запись, владелец. Ключ корреляции — не идентичность: у агента бывают развёртывания в разных средах, а учётка в IAM — отдельная сущность. В репозитории ссылки на них, но не токены.

{
  "id": "agt-hr-01",
  "name": "Чат-бот кадровых вопросов",
  "type": "application",
  "capability": "CAP-12",
  "business_owner": null,
  "runtime_key": "agt-hr-01"
}

Это запись из синтетического набора, и она пригодится дальше: этот агент соберёт три ошибки из шести.

Ошибка 2. У агента нет бизнес‑владельца

• Симптом. У 18 агентов из 34 бизнес‑владельца нет ни в репозитории, ни в MCP‑конфиге команды, хотя у всех 33 агентов из конфигов записан технический владелец, руководитель команды. Кадровый бот из примера выше записан, но поле владельца пустое.

• Неверное объяснение. «Владелец есть, это руководитель команды, которая его сделала». Команда отвечает за код, а не за то, имеет ли бот право отвечать сотрудникам про отпускные.

• Настоящая причина. Агента заказывает не бизнес, его предлагает сама команда, поэтому заказчика у него нет с первого дня. По апрельскому исследованию CSA, только 15% организаций сказали, что владелец определён у 76–100% их агентов.

• Чем грозит. Некому решить, что делать при инциденте, и некому подписать вывод из эксплуатации. Агент без владельца не умирает, он просто никому не принадлежит.

Как исправить. Владелец — обязательное поле при регистрации, а не при ревизии. Я бы предложил правило: нет бизнес‑владельца — нет сервисной учётной записи. Тогда поле заполняют до запуска, потому что без него агент не стартует.

Ошибка 3. Агент работает под учётной записью человека

• Симптом. 14 агентов из 34 работают под user:.... Сравниваются учётка из конфига и учётки из журнала шлюза: они могут не совпасть. Неизвестную в IAM учётку проверка тоже считает нарушением, это закрыто тестом.

• Неверное объяснение. «Так быстрее: у сотрудника уже есть доступ, заявку на сервисную учётку ждать неделю».

• Настоящая причина. Агент не считается отдельным субъектом доступа. По отчёту Gravitee «State of AI Agent Security», полностью самостоятельными сущностями со своей идентичностью агентов считают 21,9% опрошенных, частично — ещё 20,7%. Ещё 6,5% используют учётки людей или сервисные вместо собственной идентичности агента.

Мне попадалась история, которая хорошо показывает цену. В апреле 2026 года основатель PocketOS рассказал, как агент в Cursor, работая в тестовой среде, нашёл в файле API‑токен Railway.

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

По словам основателя, на это ушло девять секунд. Учётные данные, выданные под одну задачу, действовали на всё.

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

Как исправить. У каждого развёртывания агента своя машинная учётка с короткоживущими токенами и правами под его инструменты. Если агент действует от имени сотрудника, это делегирование, а не вход под его паролем: в журнале видны и агент, и пользователь.

Ошибка 4. MCP подключён напрямую, мимо шлюза

• Симптом. В репозитории все 41 интеграция идёт по стандарту. При этом 7 агентов держат 9 прямых подключений к 7 системам, мимо MCP‑шлюза.

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

• Настоящая причина. Совет согласует интеграции между приложениями. Подключение MCP‑сервера к агенту — это строка в конфиге, и интеграцией её никто не считает. Вот как это выглядит у агента той же кадровой команды:

{
  "key": "agt-hr-03",
  "purpose": "кадровые справки",
  "account": "user:hr-56",
  "servers": [
    {"name": "hr-core", "url": "http://hr-core.corp.local:8080/mcp"},
    {"name": "hr-portal", "url": "http://hr-portal.corp.local:8080/mcp"}
  ]
}

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

• Чем грозит. Шлюз не видит этих запросов и не может их ограничить, записать или отключить. Карта интеграций в репозитории описывает систему, которой уже нет.

Как исправить. Подключение MCP‑сервера — такая же интеграция, как вызов API. В эксперименте это статическая проверка конфига удалённых серверов: HTTPS, хост шлюза и порт 443. Она ловит явный обход, но маршрут трафика подтверждают только сетевые правила и журнал MCP‑шлюза. Это другая граница, чем LLM‑шлюз: тот следит за вызовами модели, этот за инструментами.

Ошибка 5. Агенты разных команд, возможно, делают одно и то же

• Симптом. Отчётность для руководства собирают агенты трёх команд, ответы клиентам готовят агенты двух.

Так это выглядит в выводе сверки:

Ошибка 5. Возможное пересечение, одну возможность закрывают агенты разных команд: возможностей 4, агентов в них 19
    CAP-01 Обработка обращений клиентов: sales, support
    CAP-08 Договорная работа: legal, procurement
    CAP-10 Отчётность и аналитика: finance, marketing, sales
    CAP-11 Управление знаниями: itops, support

• Неверное объяснение. «Каждой команде нужны свои особенности».

• Настоящая причина. Агенты не привязаны к карте бизнес‑возможностей, поэтому совпадения никто не видит. В BCG в августовском разборе описали тот же механизм: агента, сделанного под одну задачу, забирает другая команда, и он получает в наследство права, которые никто не проверял.

• Чем грозит. Три агента считают одну и ту же выручку тремя способами, и руководство получает три цифры. Плюс лишние расходы на модели и три набора доступов к хранилищу данных.

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

Ошибка 6. Агент молчит в LLM‑шлюзе, а учётка не отключена

• Симптом. 10 агентов из 34 не отправили ни одного запроса больше 30 дней, а их учётные записи включены. Кадровый бот из первой ошибки замолчал 16 сентября, его учётка с правом отправлять почту работает до сих пор. А кадровые справки теперь готовит agt-hr-03 из четвёртой ошибки.

• Неверное объяснение. «Он никому не мешает».

• Настоящая причина. У агента нет процедуры вывода из эксплуатации. В апрельском отчёте CSA это названо «retirement debt»: агенты живут дольше своей задачи и сохраняют права. Формальный процесс вывода там есть только у 21% респондентов.

• Чем грозит. Забытая учётка с правами — готовая точка входа, и про неё никто не вспомнит при разборе инцидента.

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

border = (AUDIT_DATE - timedelta(days=ZOMBIE_DAYS)).isoformat()
zombie = "" < agent["last_call"] < border and any(acc["enabled"] != "no" for acc in accs)

Нашли — уведомление владельцу, затем проверка расписания и зависимостей, и только потом отзыв прав. Запись в репозитории не удаляется, а переводится в статус «выведен»: она нужна для аудита и анализа влияния.

Сводная таблица

Как агент должен попадать в ландшафт

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

Главная мысль: сверка не заменяет регистрацию, а ловит то, что прошло мимо неё. В BCG это называют «golden path»: готовый шаблон агента, в который уже встроены регистрация, машинная учётка, мониторинг и применение политик. Правильный путь должен быть и самым быстрым, иначе его обойдут.

Где это не сработает

Данные синтетические, в реальной компании следы другие: каталог MCP‑серверов, IAM, счета провайдеров, сетевые журналы. Агента, идущего к модели с ноутбука сотрудника, найдут только сетевые правила.

У локального MCP‑сервера через стандартный ввод‑вывод адреса нет: сверка его пропускает, а контролировать нужно разрешённые программы и права процесса. Проверка учёток смотрит только тип: общую сервисную учётку на несколько агентов и лишние права она не ловит.

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

Чек‑лист

• в метамодели репозитория есть тип «AI‑агент» с ключом среды выполнения;

• агент без бизнес‑владельца не получает сервисную учётку, и руководитель команды им не считается;

• ни один агент не работает под учётной записью человека, а учётка из журнала шлюза совпадает с заявленной;

• удалённые MCP‑серверы подключены только через шлюз, и это проверяется автоматически, а локальные контролируются отдельно;

• каждый агент привязан к бизнес‑возможности, дубли видны на совете;

• агент без вызовов 30 дней уходит владельцу на решение, запись при выводе сохраняется;

• раз в неделю список агентов по следам сверяется с репозиторием.

Что на самом деле проверяет эта группа ошибок

Не знание TOGAF и не умение рисовать в ArchiMate. Она проверяет, умеет ли архитектор видеть ландшафт по фактам, а не по документам. Агенты просто первыми показали разницу: они появляются быстрее, чем любой процесс согласования. Мой вариант простой: репозиторий отвечает на вопрос «что должно быть», следы — «что есть», а работа архитектора — держать расхождение между ними близким к нулю.

Ссылка на мой репозиторий с экспериментом

Начать стоит с expected.txt: там вся сводка, на которую опирается статья. Как считается каждая из шести ошибок, видно в audit.py, команда python3 audit.py --details печатает строку на каждого агента, а исходные следы лежат в data/runtime/.

Пограничные случаи, которых нет в данных (учётка человека только в журнале шлюза, неизвестная учётка, шлюз на чужом порту), проверяет test_audit.py.

AI-агенты появляются быстрее, чем обновляется архитектурный репозиторий. Как выявлять такие расхождения, выстраивать контроль и управлять ИТ-ландшафтом на уровне всего предприятия? Разобраться в подходах и инструментах можно на курсе «Корпоративный архитектор / Enterprise Architect».

А начать знакомство с темой — на бесплатных открытых уроках:

• 18 ноября в 19:00. «Цикл зрелости Gartner для корпоративной архитектуры 2026: Навигация в эпоху ИИ-трансформации и бизнес-гибкости». Записаться.

• 23 ноября в 19:00. «От отдельных ИТ-систем к архитектуре предприятия: как мыслит корпоративный архитектор». Записаться.

Больше мероприятий для ИТ-специалистов — в дайджесте открытых уроков ноября.