Создание ИИ-агента начинается с проверки готовности бизнес-процесса

Что именно создают для бизнеса

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

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

Проверить, подходит ли процесс

Начните с одной операции, а не с формулировки «автоматизировать весь отдел». Опишите её в четырёх строках:

• что запускает работу;
• какие данные получает исполнитель;
• какой результат должен появиться;
• кто принимает решение в нестандартном случае.

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

Если процесс постоянно меняется, результат нельзя проверить или владелец не определён, сначала уточните сам процесс.

Составить паспорт будущего сценария

Составьте паспорт сценария до выбора модели и инструментов.

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

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

Правила. Зафиксируйте разрешённые источники, обязательные проверки и условия остановки.

Исключения. Опишите реакцию на пропущенное поле, противоречивые сведения, неизвестный тип запроса и недоступный источник.

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

Определить границы действий и роль человека

Разделите будущие действия на три уровня:

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

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

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

Подготовить данные и интеграции

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

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

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

На первом этапе ограничьте доступ чтением или черновиками, если это соответствует задаче.

Проверить готовность на примерах

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

Для каждого примера заранее определите:

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

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

Задать критерии приёмки

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

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

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

Решить, переходить ли к пилоту

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

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

Paramiko предлагает помочь описать один процесс, согласовать доступы и участие сотрудников, спроектировать сценарий интеграции и проверить ограниченный пилот на примерах заказчика. Это предложение подхода, а не подтверждение готовой интеграции, выполненного проекта, сроков или гарантированного результата.