Почему AI-процесс нужно проектировать для нормы и исключений

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

На схеме всё выглядит логично и просто.

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

Именно такие ситуации часто определяют, насколько хорошо AI-система будет работать после запуска.

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

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

Автоматизированная система так сделать не может, если это заранее не предусмотрено её логикой.

Поэтому процесс нельзя проектировать только вокруг вопроса «что делать, если всё пошло по плану?». Не менее важен другой вопрос: что система должна сделать, если условия отличаются от ожидаемых?

Нестандартные ситуации появляются практически на любом этапе.

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

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

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

Если процесс рассчитан только на один формат, любое отклонение становится ошибкой.

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

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

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

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

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

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

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

Вместо понятной системы появляется набор заплаток.

Гораздо дешевле предусмотреть архитектуру обработки исключений ещё до запуска.

Не нужно пытаться заранее описать абсолютно всё. Это невозможно и только усложнит систему.

Гораздо практичнее разделить ситуации на несколько категорий.

Если отклонение не несёт серьёзного риска и имеет понятное правило обработки, AI может выполнить действие самостоятельно.

Например, классифицировать обращение или запросить недостающую информацию.

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

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

Есть ситуации, в которых продолжение работы опаснее, чем остановка.

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

При проектировании AI часто думают только о том, какие действия система должна выполнять.

Но у зрелой автоматизации есть ещё один важный навык — понимать границы собственной компетенции.

Если AI не уверен в результате, система должна уметь это определить. Если данных недостаточно, она должна запросить их. Если ситуация выходит за рамки установленных правил, задача должна перейти человеку.

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

На практике ответственность постепенно возвращается к сотрудникам.

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

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

В итоге часть экономического эффекта от автоматизации исчезает.

Перед внедрением полезно проверить не только основной сценарий, но и несколько реальных отклонений.

Стоит заранее ответить:

· Что произойдёт при отсутствии обязательных данных?

· Что система сделает при конфликте информации?

· Как она поймёт, что не может принять решение?

· В какой момент подключается сотрудник?

· Кто получает задачу после остановки автоматизации?

· Что происходит с ошибкой после её обнаружения?

Если на эти вопросы нет понятных ответов, процесс ещё рано считать полностью готовым к автоматизации.

Хорошая AI-система — это не та, которая пытается самостоятельно решить максимальное количество задач. Намного важнее, чтобы она правильно понимала границы автоматической работы.

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

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