Как контролировать AI-агента после запуска

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

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

Почему успешного пилота недостаточно

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

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

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

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

Четыре уровня контроля AI-агента

Наблюдение удобно разделить на четыре уровня. Каждый отвечает на свой вопрос, и ни один не заменяет остальные.

Техническая работоспособность

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

Качество результата

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

Результат процесса

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

Ресурсы и стоимость

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

Описание сопровождения и разделения дефектов и новых функций есть на странице сопровождения AI-систем. Восстановить сломанную интеграцию и добавить новый сценарий — разные работы с разными приоритетами.

Что записывать в журнал действий

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

Для каждого обращения полезно сохранять:

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

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

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

Как проверять качество на реальном потоке

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

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

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

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

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

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

Какие алерты действительно полезны

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

Полезные категории алертов:

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

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

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

Как разбирать инциденты

Инцидент с AI-агентом важно разбирать как сбой системы, а не как абстрактную «галлюцинацию». Сначала ограничивают последствия, затем восстанавливают цепочку событий и только после этого выбирают исправление.

Практический порядок:

1. остановить или сузить проблемный сценарий, сохранив безопасные функции;
2. определить затронутые обращения и действия по журналу;
3. проверить доступность и версии источников;
4. воспроизвести случай на конфигурации, где возникла ошибка;
5. найти класс причины: данные, инструкция, интеграция, права, модель или правило процесса;
6. добавить случай в проверочный набор;
7. внести минимальное исправление и повторить связанные проверки;
8. вернуть сценарий под усиленным наблюдением.

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

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

Как безопасно выпускать изменения

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

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

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

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

Кто отвечает за эксплуатацию

У работающего агента должно быть как минимум три роли, даже если их совмещают несколько человек.

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

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

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

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

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

Признаки, что контур пора пересмотреть

Повторяющиеся симптомы говорят о системной проблеме:

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

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

Критерии подходящего сценария можно сверить со статьёй о первом AI-агенте. Иногда повторная диагностика полезнее очередного обновления модели.

Короткий чек-лист перед эксплуатацией

Перед переводом агента из пилота в постоянную работу проверьте:

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

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

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