ИИ-агент запущен: кто отвечает за сбои после сдачи

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

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

«Вызов прошёл» и «заявка обработана» — разные проверки

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

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

В нашем примере request_id=TRAIN-017 появился во входящей очереди. Агент завершил обработку, запись CRM-204 создана, но поле ответственного пустое. Сигналом станет не «агент упал», а «к согласованному времени у TRAIN-017 нет назначенного сотрудника и нет статуса ручной обработки». Само время реакции здесь не задаём: его вместе с допустимыми исключениями определяет заказчик для своего процесса.

Документация платформ помогает увидеть технический слой. Например, OpenAI Agents SDK описывает трассировку шагов выполнения, а Amazon Bedrock Agents публикует в CloudWatch метрики вызовов, ошибок клиента и сервера, времени обработки. Эти возможности относятся к указанным платформам; они не появляются у любого агента автоматически. В OpenAI Agents SDK запись входов и выходов модели и вызовов функций в трассах включена по умолчанию (trace_include_sensitive_data=True); эти данные могут быть чувствительными, поэтому настройки записи и доступ к трассам проверяют до включения наблюдения. Ни трасса без ошибки, ни счётчик вызовов сами по себе не подтверждают назначение в CRM.

Карточка сопровождения: один пропуск от сигнала до возобновления

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

В рабочем контуре кнопку «остановить» ещё нужно реализовать и испытать. Иногда безопаснее отключить только создание записей, продолжая принимать обращения в отдельную очередь; в другой архитектуре потребуется иной способ. Проверьте, что происходит с заданиями, которые уже выполняются, и не создаст ли повторный запуск дубль. Если заранее не предусмотрены управляемая пауза и ручной маршрут, строка карточки не превращает их в готовую функцию.

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

Эта схема показывает, кто принимает решение о процессе и кто выполняет техническую работу, но не назначает стороны договора. NIST AI Risk Management Framework предлагает после внедрения наблюдать за системой, получать обратную связь, предусматривать вмешательство человека, реагирование и восстановление. Это добровольная рамка, которую адаптируют к условиям применения, а не обязательный российский стандарт или готовый SLA. Отдельный исследовательский отчёт NIST о наблюдении за развёрнутыми системами ИИ объясняет, почему проверок в контролируемых условиях недостаточно для всех ситуаций после запуска. Ни один из этих источников не назначит за вас дежурного, канал связи и право на паузу.

Проведите одну репетицию до передачи

1. Задайте ожидаемый исход. Создайте тестовое обращение TRAIN-017: вход должен получить ответственного либо попасть в ручную очередь. Запишите безопасный ID и ожидаемый статус, чтобы потом проверить конкретную запись, а не только число обработанных вызовов.
2. Вызовите пропуск только в тестовом контуре. Измените формат условного поля так, чтобы учебная запись осталась без владельца. Проверьте, дошёл ли сигнал до указанного в карточке человека. Если сигнала нет, передавать процесс рано: поправьте контроль результата и повторите пробу. Не удаляйте реальные обращения и не отключайте рабочую интеграцию ради учения.
3. Пройдите путь восстановления. Уполномоченный человек ограничивает согласованное автодействие, дежурный закрывает пропуск вручную, интегратор исправляет правило. Затем подайте проблемный и обычный тестовые входы, проверьте назначение и отсутствие дублей. Запишите, кто разрешил возобновление. Если уже запущенные задачи нельзя безопасно учесть, оставьте ручной маршрут до отдельного решения.

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

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

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