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