Следующий пользователь вашего ПО — ИИ-агент. Готова ли ваша архитектура?

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

Впечатляет. А теперь попросите его действительно оформить компенсацию.

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

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

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

Мы годами модернизировали корпоративное ПО для людей, которые им пользуются. Теперь нужно модернизировать его для агентов, которым все чаще предстоит с ним работать.

Пользовательский интерфейс — это далеко не весь продукт

Подумайте, как сегодня работает корпоративное ПО. Люди открывают приложения, перемещаются по панелям управления, принимают решения и переносят работу из одной системы в другую. Пользовательский интерфейс — это способ взаимодействия с бизнесом.

Агенту не обязательно нужны эти экраны. Он может получать информацию и запускать действия через API, серверы Model Context Protocol (MCP) и другие программные интерфейсы. Это часть перехода к архитектуре без пользовательского интерфейса.

Но отсутствие интерфейса не означает, что приложение исчезает. Его данные, бизнес-правила, разрешения и требования к соблюдению нормативов по-прежнему важны. Я бы сказал, что они стали еще важнее.

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

Есть и коммерческие последствия: к 2030 году под угрозой дестабилизирующего воздействия агентного ИИ могут оказаться расходы на корпоративные приложения в размере до 234 млрд долларов. Речь идет о расходах, которым грозит изменение, а не о расходах, которые гарантированно исчезнут. Кроме того, когда агенты выполняют работу, прежде делавшуюся людьми в панелях управления, модели оплаты за каждого пользователя, вероятно, будут все чаще уступать место моделям, основанным на использовании, действиях или результатах.

Для поставщиков ПО это вызов их бизнес-модели. Для компаний, зависящих от этих приложений, — вызов архитектуре.

Мы модернизировали отдельные компоненты, но не рабочий процесс

Большинство компаний занимается модернизацией уже много лет. Одна команда обновляет устаревшие приложения. Другая объединяет разрозненные данные на современной платформе. Третья создает интеграции или просто обновляет пользовательский интерфейс.

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

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

В обоих случаях мы модернизировали отдельные элементы технологии, но не саму работу.

Агентному ИИ не важно, какой проект модернизации оказался успешным. Важно, работает ли весь процесс целиком.

Вот как это выглядит на практике. Одному клиенту нужно было ускорить подготовку смет на сложный ремонт двигателей: контракты определяли, какие детали можно отремонтировать, заменить или восстановить. Подготовка каждой сметы требовала нескольких дней, а иногда и недель ручного изучения контрактов и руководств по техническому обслуживанию. Клиент уже модернизировал свою платформу данных, но сметы по-прежнему готовились не быстрее, потому что узким местом были вовсе не данные. Им было исследование. Мы перестроили этот рабочий процесс на основе набора исследовательских агентов, сократили время на исследование на 80%, и подготовка смет пошла совсем другими темпами.

Поэтому модернизацию приложений и данных нельзя планировать как два независимых направления работы. Архитектура должна обеспечивать достижение конечного бизнес-результата.

Одного API недостаточно, чтобы система была готова к работе с агентами

Может возникнуть соблазн решить, что все просто: открыть конечные точки, подключить агента — и дело сделано.

Хотелось бы, чтобы все было так просто.

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

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

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

Может ли агент получать достоверные данные из авторитетных источников? Чётко ли сформулированы бизнес-правила и последовательно ли они применяются? Может ли агент рекомендовать действие, но выполнять только те действия, на выполнение которых у него есть полномочия? Если что-то пойдёт не так, сможем ли мы отследить действие, обработать исключение и, если возможно, отменить его?

Эти проблемы не решить одним лишь улучшением модели. Речь идёт о рабочих процессах, проектировании приложений, архитектуре данных, интеграции и управлении. И на все эти вопросы нужно ответить в комплексе.

Начните с рабочих процессов, а не с технологий

С чего же начать?

Я бы не стал переводить каждое приложение на безголовую архитектуру или открывать доступ ко всем существующим API. Я бы начал с одного значимого бизнес-процесса.

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

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

И оценивайте результаты соответствующим образом. Не по числу открытых API и не по объёму перенесённых данных, а по тому, насколько надёжно завершается рабочий процесс, как устраняются исключения и улучшаются ли бизнес-результаты.

Цель не в том, чтобы повсюду внедрить автономность. Важно обеспечить надёжное и заслуживающее доверия выполнение задач, оставляя место для человеческого суждения там, где оно необходимо.

Перемены куда масштабнее, чем переход к безголовой архитектуре

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

Но этого не добиться, просто добавив агента поверх архитектуры, которая изначально для него не предназначалась.

Новое поколение корпоративного программного обеспечения будет определяться не только тем, что оно позволяет видеть людям. Оно будет определяться и тем, что оно позволяет агентам делать — надёжно и ответственно.