ИИ-агент подготовил карточку клиента и сообщил, что задача выполнена. Но карточки в рабочей системе нет: запрос на сохранение завершился ошибкой или подтверждение потерялось. Если контролировать только доступность программы и ответы модели, команда узнает о проблеме от сотрудника или клиента.
Поэтому после запуска нужно наблюдать не только за сервером и моделью, но и за результатом каждой значимой операции. Для этого заранее определяют признаки успеха, источник проверки, ответственного и действие при сбое. Неизвестный результат нельзя автоматически считать ни успехом, ни отказом.
Четыре разных уровня успеха
У одной задачи может быть несколько технически успешных этапов:
- Программа доступна и принимает запросы.
- Модель сформировала ответ или подготовила данные.
- Подключённый инструмент принял команду.
- Рабочая система подтвердила нужное изменение.
Эти события не заменяют друг друга. Ответ модели «карточка создана» — это текст, а не подтверждение CRM. Успешная отправка запроса тоже не доказывает, что запись появилась с нужными полями. Для бизнес-процесса важен четвёртый уровень: сотрудник может найти результат и продолжить работу.
Признак результата зависит от задачи. Для ответа по документам это может быть проверяемая ссылка на разрешённый источник. Для обработки документа — заполненная строка реестра без придуманных значений. Для изменения записи — идентификатор объекта и подтверждённые поля в целевой системе.
ИИ-агент, бот и интеграция требуют разного контроля. Агент выбирает следующий шаг и разрешённый инструмент, поэтому нужно видеть его цепочку решений и действий. Бот может быть только интерфейсом, который принимает заявку и показывает статус. Обычная интеграция выполняет заранее заданную последовательность. Если форма всегда передаёт одни и те же поля в CRM, агент для этого не нужен, но результат записи всё равно нужно подтверждать.
Составьте паспорт контроля
Паспорт контроля связывает этап процесса с проверкой и реакцией. Без него журнал быстро превращается в набор технических сообщений, по которым непонятно, кто должен действовать.
| Этап | Признак успеха | Возможная проблема | Где проверить | Ответственный | Следующее действие |
|---|---|---|---|---|---|
| Приём задачи | Присвоен идентификатор, входные данные доступны | Задача потеряна или обязательных данных нет | Очередь или реестр задач | Владелец рабочего процесса | Уточнить данные или восстановить постановку |
| Подготовка результата | Получены поля, ответ или план действия | Модель не ответила, данные противоречат источнику | Журнал выполнения и исходные материалы | Сотрудник, который знает предмет задачи | Проверить пример и передать спорный случай человеку |
| Вызов инструмента | Система приняла запрос | Нет доступа, неверный формат, сервис недоступен | Ответ подключённой системы | Ответственный за подключение | Исправить причину или выбрать ручной маршрут |
| Рабочее действие | Создана или изменена нужная запись | Подтверждение не получено, создан дубль, поля не совпали | Целевая рабочая система | Владелец процесса | Найти результат по идентификатору, затем решить вопрос о повторе |
| Передача сотруднику | Человек получил результат и понятный статус | Уведомление не доставлено или скрывает неопределённость | Канал уведомлений и список задач | Руководитель или назначенный дежурный | Связаться с исполнителем и продолжить процесс вручную |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для каждого этапа полезно записать не только ошибку, но и способ доказать успех. Формулировка «запрос отправлен» недостаточна, если задача состоит в создании записи. Нужны идентификатор, фактический статус и возможность проверить объект в рабочей системе.
В журнале сохраняют сведения, необходимые для расследования: идентификатор задачи, время этапов, использованный сценарий, вызванный инструмент, код или тип ошибки, статус результата и принятые действия. Полный текст обращения, документы клиента, пароли и ключи не следует записывать без необходимости. Состав данных, сроки хранения и доступы определяют под конкретный процесс.
Само наличие журнала ничего не исправляет. В паспорте должен быть человек, который получает сигнал, умеет проверить результат и имеет право остановить или возобновить нужные действия.
Когда отправлять уведомление
Сигнал нужен там, где процесс не может безопасно продолжиться сам. К таким ситуациям относятся:
- ошибка подключённого инструмента;
- задача, которая не завершилась за ожидаемое для процесса время;
- необычное число повторных попыток;
- отсутствие записи или другого ожидаемого результата;
- расход ресурсов сверх согласованных для сценария границ;
- расхождение между ответом агента и состоянием рабочей системы.
Универсального числового порога нет. Для срочной заявки задержка в несколько минут может быть существенной, а пакетная обработка документов может выполняться дольше. Сначала команда определяет допустимый ход процесса, затем наблюдает за реальными задачами и уточняет пороги.
Полезное уведомление отвечает на четыре вопроса: что произошло, с какой задачей, что уже известно и какое действие требуется от получателя. Сообщение «ошибка агента» заставит человека заново искать весь контекст. Сообщение «по задаче 1842 нет подтверждения сохранения; проверьте запись по внешнему идентификатору перед повтором» задаёт следующий шаг.
Не каждое отклонение нужно немедленно отправлять руководителю. Часть событий можно собрать для планового разбора, а остановку процесса оставить для случаев с риском неверного действия, потери данных или дублей. Маршрут уведомлений зависит от роли: владелец процесса решает, как продолжить работу, а специалист по подключению разбирает техническую причину.
Учебный пример: подтверждение потерялось
Условная цепочка, не журнал реального инцидента.
Агент получил заявку, подготовил поля карточки и отправил команду на сохранение. Рабочая система могла создать запись, но её ответ потерялся. Агент не знает итог операции.
| Состояние | Что известно | Правильное действие |
|---|---|---|
| Вход принят | У задачи есть идентификатор, исходные данные сохранены | Перейти к подготовке полей |
| Подготовка успешна | Обязательные поля собраны, спорные значения отмечены | Отправить разрешённую команду сохранения |
| Сохранение неизвестно | Команда отправлена, подтверждения результата нет | Не сообщать об успехе и не повторять вслепую |
| Проверка результата | Ответственный ищет запись по идентификатору заявки | Сопоставить найденную запись с исходными полями |
| Подтверждение или исправление | Запись найдена либо доказано, что её нет | Подтвердить результат, исправить поля или разрешить повтор |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Статус «неизвестно» здесь точнее, чем «ошибка». Запись могла появиться, поэтому автоматический повтор способен создать дубль. Сначала ответственный ищет её по устойчивому идентификатору. Повтор разрешают только после проверки либо выполняют его по заранее согласованному правилу, которое не создаёт вторую запись.
Этот пример показывает разницу между восстановлением системы и восстановлением задачи. Подключение может снова отвечать, но заявка всё ещё останется без подтверждённого результата.
Как остановить процесс без новых проблем
До запуска определите, какие действия можно приостановить отдельно. Иногда достаточно запретить запись в рабочую систему, сохранив приём новых задач. В другом процессе безопаснее остановить всю цепочку и временно передать операции сотрудникам.
План остановки должен отвечать на вопросы:
- какие новые действия агент больше не выполняет;
- что происходит с уже принятыми задачами;
- где команда видит незавершённую очередь;
- кто переводит процесс на ручную работу;
- кто и после какой проверки разрешает возобновление.
Не стоит считать перезапуск программы восстановлением процесса. Сначала устраняют причину, затем отдельно разбирают накопившиеся задачи. Для каждой проверяют фактический результат, возможные дубли и необходимость повтора. После возобновления полезно пройти одну контрольную задачу от входа до подтверждённого бизнес-действия.
Автоматический повтор подходит только для заранее разобранных случаев. Команда должна знать, можно ли безопасно выполнить действие ещё раз, как распознать уже созданный объект и когда прекратить попытки. Если эти условия не определены, задачу лучше передать человеку с полным контекстом.
Проверяйте качество после запуска
Даже исправно работающий агент со временем может давать неподходящий результат. Причиной бывает изменение модели, документов, правил процесса или подключённого инструмента. Поэтому технический мониторинг дополняют выборочной проверкой реальных задач человеком.
Для проверки используют критерии, согласованные до запуска: правильный источник, заполненность обязательных полей, отсутствие выдуманных значений, соблюдение полномочий и подтверждение рабочего действия. Спорные примеры сохраняют без лишних клиентских данных и разбирают с владельцем процесса.
Оценка ответа другой моделью может быть дополнительным сигналом, но не доказательством результата. Если задача агента — создать запись, итог подтверждает рабочая система и человек, который понимает процесс. Если изменился важный источник, модель или инструмент, затронутые сценарии проходят повторную приёмку.
Что закрепить до передачи в эксплуатацию
Руководителю не обязательно выбирать конкретную систему наблюдаемости. Сначала важнее согласовать управленческие правила:
- Какие результаты агент обязан подтверждать.
- Какие промежуточные состояния нужно сохранять.
- Что считается неизвестным или ошибочным результатом.
- Кто получает уведомление и что делает дальше.
- Какие операции можно повторять автоматически.
- Как остановить действия и сохранить очередь.
- Кто проверяет восстановление и возобновляет процесс.
- Какие изменения требуют повторной приёмки.
Эти правила становятся частью требований, инструкций и передачи решения. Состав сопровождения и время реакции согласуют отдельно: сам факт разработки агента не означает круглосуточное наблюдение или установленный SLA.
Switch On AI помогает спроектировать и разработать ИИ-агента с проверяемыми результатами, журналом действий и границами полномочий в согласованном составе проекта. На разборе процесса определим, какие результаты нужно подтверждать, кому сообщать о сбоях и как восстанавливать незавершённые задачи. Чтобы обсудить свой процесс, опишите задачу и участвующие системы.
Вопросы по этой задаче
Достаточно ли проверять, что программа ИИ-агента доступна?
Нет. Доступность программы подтверждает только один технический этап. Нужно отдельно проверить ответ модели, выполнение вызванного инструмента и фактический результат в рабочей системе.
Кто должен получать сообщение об ошибке агента?
Получателя определяют по требуемому действию. Владелец процесса решает, как продолжить рабочую задачу, а ответственный за подключение разбирает техническую причину. Уведомление должно содержать идентификатор задачи, известный статус и следующий шаг.
Можно ли автоматически повторять неудачную операцию?
Только если заранее определено, что повтор безопасен, система умеет распознать уже выполненное действие и установлено условие прекращения попыток. При неизвестном результате сначала проверяют рабочую систему, иначе можно создать дубль.
Когда нужно пересматривать критерии контроля?
При изменении модели, источников данных, бизнес-правил, подключённых инструментов, полномочий или правил повторов. Затронутые сценарии следует снова проверить на согласованных примерах.