Выбор партнера для разработки ИИ-агентов: вопросы, выходящие за рамки демо-версии.

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

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

Что изменилось к 2026 году

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

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

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

Кто будет владеть агентом после запуска?

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

Начните с рабочего процесса

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

Перед началом разработки команда должна определить следующее.

• Триггер, запускающий рабочий процесс.
• Информация, необходимая для выполнения процесса.
• Системы, с которыми он связан.
• Моменты, когда принимаются решения.
• Допустимые действия.
• Необходимые формы одобрения.
• Условия, которые считаются сбоем.
• Критерии завершения.

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

Интеграции важнее, чем чат-окно

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

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

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

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

Права доступа показывают, как подходят к управлению рисками

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

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

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

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

Надежные знания

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

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

Множество агентов не всегда лучше

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

Несколько агентов оправданы, когда у задачи действительно есть разные функции, например:

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

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

Обработка сбоев

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

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

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

Развертывание — это не просто хостинг

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

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

Проверка человеком, соответствующая последствиям

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

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

Ответственность после запуска

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

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

Вопросы, которые следует задать перед выбором

Качество презентации должно иметь меньшее значение, чем ответы на несколько конкретных вопросов.

• Как поставщик планирует адаптировать существующий рабочий процесс и почему для этого требуется агент?
• Какие системы будут затронуты, и как будут передаваться права пользователей в эти системы?
• Что предотвращает двойное выполнение одной и той же операции, и что происходит, если инструмент выходит из строя?
• Где необходимо подпись человека?
• Как обеспечивается актуальность базы знаний?
• Как измеряется производительность в реальном времени и кто обеспечивает поддержку после запуска системы?
• Можно ли отследить любые изменения и отменить их?

Хороший поставщик отвечает простым языком и связывает каждый технический выбор с предложенным рабочим процессом.

Основная идея

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