Как понять, что процесс готов к ИИ-агенту: чек-лист из 15 вопросов

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

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

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

Короткий ответ: три состояния процесса

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

Сначала решите, действительно ли нужен ИИ-агент

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

Anthropic формулирует похожий принцип: начинать с минимально сложной системы и добавлять агентность только тогда, когда простого вызова модели или заранее заданного workflow недостаточно. Это полезная проверка против соблазна строить «команду агентов» раньше, чем доказана ценность одной роли.

Поэтому перед чек-листом задайте нулевой вопрос: система должна самостоятельно выбирать следующий шаг и использовать инструменты — или ей достаточно выполнить заранее заданную последовательность? Во втором случае начните со скрипта, интеграции, RPA или LLM-цепочки. Агент нужен там, где путь зависит от контекста и меняется по ходу работы.

Как пользоваться чек-листом

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

Для каждого вопроса поставьте:

• 2 балла — ответ есть, он подтверждён документом, данными или ответственным человеком;
• 1 балл — ответ частичный, есть пробелы или договорённость пока не закреплена;
• 0 баллов — ответа нет либо условие явно не выполняется.

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

1. Какой конкретный результат должен выдавать процесс?

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

Если результат звучит как «помогать команде» или «ускорить работу», поставить критерии приёмки будет невозможно. Нужны формат, обязательные поля, срок и правило, по которому результат можно принять или отклонить.

2. Какую бизнес-проблему решает автоматизация?

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

Сильная гипотеза связывает действие агента с одним наблюдаемым эффектом. Без этого пилот легко превратится в демонстрацию возможностей без решения о дальнейшем внедрении.

3. Есть ли исходная метрика до внедрения?

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

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

4. Повторяется ли маршрут достаточно регулярно?

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

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

5. Можно ли разложить процесс на шаги и точки решения?

Запишите путь от входа до результата: что поступает, что проверяется, какое решение принимается, к какому инструменту обращается система и при каком условии работа останавливается.

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

6. Известны ли типовые исключения?

Проверьте не только счастливый путь. Что происходит, если не хватает данных, документ противоречит базе, API не отвечает, клиент просит исключение, результат не проходит проверку или действие запрещено политикой?

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

7. Доступны ли входные данные в цифровом виде?

Агенту нужны реальные входы: документы, записи CRM, письма, формы, таблицы, расшифровки, сообщения или API. Фраза «сотрудник обычно понимает по ситуации» означает, что важная часть контекста пока не собрана.

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

8. Есть ли владелец данных и правило актуальности?

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

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

9. Можно ли подключить нужные системы без хрупких обходов?

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

Чем больше ручных входов, нестабильных интерфейсов и неописанных прав, тем дороже поддержка. Иногда лучший первый пилот — не весь маршрут, а один участок с надёжными данными и понятным API.

10. Можно ли автоматически проверить результат?

Проверка должна быть конкретнее фразы «выглядит нормально». Это может быть наличие обязательных полей, соответствие формату, ссылка на использованный документ, отсутствие запрещённых обещаний, допустимый диапазон значений или сравнение с эталонным набором.

Если результат полностью субъективен, агент может готовить черновик, но финальное решение останется у человека. Это тоже полезная автоматизация — просто не автономная.

11. Какова цена ошибки и можно ли отменить действие?

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

Чем выше цена ошибки, тем уже должна быть автономия. Агент может собирать факты, предлагать решение и готовить действие, но финальное подтверждение остаётся у ответственного сотрудника.

12. Где находится обязательная точка человеческого контроля?

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

Хорошая точка контроля стоит перед рискованным действием, а не после него. При этом человек получает достаточно контекста: входные данные, предлагаемое решение, причины, ссылки на документы и понятные варианты — подтвердить, вернуть или остановить.

13. Кто владеет процессом после запуска?

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

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

14. Есть ли набор реальных примеров для теста?

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

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

15. Сформулированы ли условия «продолжить, изменить или остановить»?

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

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

Как интерпретировать результат

Сложите баллы по 15 вопросам. Максимум — 30.

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

Матрица выбора: эффект и готовность

После чек-листа сравните кандидатов по двум осям: ожидаемый эффект и готовность к пилоту.

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

Когда процесс точно не стоит отдавать агенту целиком

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

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

Чек-лист не заменяет аудит процесса

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

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

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

FAQ

Можно ли начинать, если процесс пока не описан?

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

Что выбрать: обычную автоматизацию или ИИ-агента?

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

Сколько примеров нужно для пилота?

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

Можно ли автоматизировать процесс с высокой ценой ошибки?

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

Что подготовить перед обсуждением внедрения?

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

Вывод

Готовность процесса к ИИ-агенту определяется не интересом к технологии. Она видна по пяти вещам: измеримый результат, повторяемый маршрут, доступные данные, управляемый риск и ответственный владелец.

Короче говоря, сначала подтвердите, что процесс стоит автоматизировать. Затем закройте пробелы в данных и контроле. И только после этого проектируйте пилот. Так вы покупаете не «ИИ ради ИИ», а проверяемое изменение конкретной работы.