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