Автоматизация бизнеса: какие задачи поручить ИИ, а какие правилам

Представим заявку, которая пришла по почте. Из письма нужно извлечь сведения, найти клиента в CRM, сверить сумму, назначить ответственного и подготовить ответ. Если поручить всё это одному ИИ-агенту, он получит сразу несколько разных задач и доступ к действиям с разными последствиями. Между тем для распределения сделок по региону достаточно известного условия, а для понимания нестандартной просьбы клиента может понадобиться языковая модель.

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

Четыре критерия выбора

Удобнее обсуждать технологию на конкретных примерах работы. Для каждого шага я проверяю четыре вещи.

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

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

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

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

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

Для распределения сделок в amoCRM или Битрикс24 по региону и сумме языковая модель обычно не нужна. Сверку суммы счёта с данными 1С тоже можно выполнить программно. Если нужное правило уже поддерживает используемая система, достаточно её настройки. Когда порядок работы ещё не определён и сотрудники каждый раз договариваются заново, полезнее сначала согласовать этот порядок.

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

Известная логика: автоматизация правил байеров

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

Условия могли учитывать географию, устройства, списки площадок и их сочетания. Большое число условий само по себе не требовало ИИ. Байеры знали, что делать, но не успевали достаточно часто применять свои решения ко всему объёму данных.

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

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

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

Неизвестная логика: исследование данных для антифрода

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

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

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

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

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

Разнообразный текст: языковая модель внутри процесса

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

Я выяснил требования, сделал прототип, затем самостоятельно разработал и запустил систему с несколькими этапами обработки. Сначала она собирает профильную аналитику через API и интерфейсы источников. Собственные алгоритмы структурируют сведения, после чего система определяет юридические лица. Далее веб-поиск и языковые модели помогают находить контакты, условия сотрудничества и партнёрские программы. Подходящие лиды записываются в Google-таблицу.

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

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

Когда разговор является частью продукта

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

В Telegram-боте для психологической самопомощи методику предоставил заказчик-психолог. Я выбрал языковую модель и разработал технические механизмы её применения. Инструкции учитывают методику, контекст и текущую задачу. Контроль состояния диалога помогает замечать отклонения и возвращать разговор к заданному подходу, в том числе при ошибках модели.

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

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

Внешние тексты и персональные данные

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

Если в материалах есть персональные данные, допустимые способы обработки и размещения нужно определить до разработки. Облачные GigaChat и YandexGPT, зарубежный API и модель на собственном сервере требуют разных технических решений. Российский провайдер или локальное размещение сами по себе не гарантируют соответствие 152-ФЗ. Оператор определяет обязанности с профильными специалистами, а инженер реализует согласованные требования. Практические варианты подробнее разобраны в статье об обработке документов с ИИ.

Права ИИ-агента в CRM нужно выдавать на отдельные операции

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

При проектировании стоит разделить доступ по последствиям ошибки:

• Чтение. Агент получает только нужные для задачи записи, историю общения и статусы, а не всю CRM.
• Подготовка предложения. Он составляет черновик или предлагает изменение. Рабочая запись и переписка с клиентом пока остаются без изменений.
• Ограниченные обратимые действия. Внутренние метки, приоритеты и назначение ответственного можно разрешать в согласованных пределах, если предусмотрены журнал и восстановление прежнего состояния.
• Важные и труднообратимые операции. Для сообщений клиентам, удаления, изменения сумм, возвратов и отмен заказов нужно отдельно определить допустимые сценарии. Рискованное действие сотрудник подтверждает с конкретными параметрами. Некоторые права агенту лучше вообще не выдавать.

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

Доступ и техническая поддержка

Агенту нужна отдельная корпоративная учётная запись с минимально необходимыми правами. Личный логин сотрудника смешивает действия человека и программы, а доступ администратора даёт лишние возможности. Отдельную запись проще отключить или ограничить, не мешая работе сотрудника. Ключи доступа к CRM и другим сервисам следует хранить вне исходного кода.

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

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

Запись действий и возможность восстановления

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

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

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

Проверка сотрудником должна помещаться в рабочий день

Фраза «человек проверит» ничего не говорит о том, сможет ли он это сделать. До запуска нужно оценить число подтверждений за день и среднее время одного разбора:

Ежедневная нагрузка на проверку = число случаев × среднее время разбора одного случая.

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

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

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

Как перейти к самостоятельным действиям

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

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

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

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

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