Как подготовить ИТ-ландшафт к внедрению агентной архитектуры

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

Классическая автоматизация выполняет заранее описанный сценарий: если совпадает условие, система делает шаг А, иначе она делает шаг Б. Любое отклонение требует правки сценария разработчиком. ИИ-агент работает иначе: получает цель, выбирает действия, оценивает результат и сам определяет следующий шаг.

Для ИТ-ландшафта из этого можно сделать три вывода:

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

Ставки высоки. Аналитики Gartner прогнозируют, что к концу 2027 г. более 40% проектов с агентным ИИ закроют из-за стоимости, неясной ценности или слабого контроля рисков. Большинство причин лежит не в модели, а в среде, куда агента встраивают.

Первым шагом обычно оказывается составление карты имеющегося ИТ-ландшафта: какие системы существуют, кто за них отвечает, какие процессы и данные через них проходят. Формальные описания процессов, по оценке интеграторов, покрывают лишь 10−20% реальной работы, поэтому карту составляют вместе с владельцами процессов.

В карту стоит включить:

• системы и их владельцев
• интерфейсы: API, файловый обмен, базы данных
• процессы и точки ручной работы
• источники данных и частоту их обновления
• действующие права доступа

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

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

IDP (Intelligent Document Processing, интеллектуальная обработка документов) — технология, которая распознает документы, определяет их тип и извлекает данные в структурированном виде. Чтобы агент работал с документами, распознавание должно быть частью его контура, а не отдельным этапом с ручной передачей данных. Поэтому ряд платформ агентной автоматизации объединяет в одном решении ИИ-агентов, RPA (Robotic Process Automation, роботизацию процессов) и IDP: извлеченные данные сразу попадают в сценарий агента и корпоративные системы.

Признаки готовых данных:

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

В агентной архитектуре агент действует через инструменты: интерфейсы к файлам, базам данных, системам заявок. Среди них API (Application Programming Interface, программный интерфейс приложения). Подключение стандартизирует открытый протокол MCP (Model Context Protocol, протокол контекста модели), но готовых коннекторов для российских систем пока не так много, эта часть в процессе активного развития.

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

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

Роли разделяют: один агент собирает данные, другой анализирует, третий действует, чтобы ошибка одного не перетекала в соседние участкиё

Минимальный набор мер ИБ:

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

Обычный мониторинг систем показывает их доступность и скорость работы. Для агентной архитектуры кроме этого важно видеть, почему агент принял решение и улучшается ли его логика со временем. Такую задачу описывает подход AgentOps: контроль версий, защитные ограничения, возможность отката.

Управление включает промпты, рабочие процессы, права на инструменты, память и логику оркестрации. Добавляются защитные ограничения во время работы, контроль версий и возможность отката. Начать стоит с единого реестра с перечнем владельцев агентов, мест работы агентов и подключений к системам. Без этого агенты быстро выходят из-под контроля, к тому же реестр дает и основу для аудита: по нему проверяют, кто и что запускал.

Что фиксировать в журнале:

• какой агент вызвал какой инструмент
• с какими параметрами
• какой результат получил
• кто подтвердил действие
• какие изменения внесены

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

1. Чтение: агент собирает данные и формулирует гипотезы, ничего не меняя
2. Согласование: агент предлагает действия, человек подтверждает каждое
3. Ограниченная автономия: узкий набор обратимых операций с условиями остановки

Переход к следующему режиму оправдан, когда точность достигает определенного порога, а человек остается в контуре, пока точность работы агентов не достигнет 85−90%.

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