Как внедрить ИИ в бизнес-процессы и не сломать операционку

Коротко

• Не автоматизируйте весь процесс сразу. Возьмите один узкий кусок с понятным результатом.
• Разделяйте два типа действий: читать/предлагать (можно отдать ИИ почти сразу) и менять/отправлять/списывать (только через подтверждение человека на старте).
• Логируйте каждое действие агента: вход, что он решил, что сделал, кто подтвердил. Без логов вы не отладите и не докажете, что произошло.
• Давайте агенту минимум прав. Отдельный доступ, только нужные поля, только нужные действия.
• Заложите откат заранее: как выключить агента за 10 секунд и как вернуть процесс на людей.
• Считайте не «вау-эффект», а сэкономленные часы и число ошибок до/после. Если не считаете — вы не внедряете, а играетесь.

Почему «просто подключить ИИ» ломает процессы

Живой процесс — это не только шаги. Это ещё и негласные исключения, которые держатся на людях. Менеджер знает, что этому клиенту скидку согласовывают отдельно. Оператор поддержки чувствует, когда вопрос надо эскалировать, а не отвечать из базы. Кладовщик видит, что «минус 3 на остатке» — это пересорт, а не реальная отгрузка.

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

Вторая причина поломок — «большой скачок». Компания решает автоматизировать сразу всю поддержку или всю обработку заявок. Радиус поражения при ошибке — весь поток клиентов. Отладить такое невозможно: слишком много переменных меняется одновременно.

Правильная логика обратная: минимальный кусок, максимальный контроль, потом расширение. Если вы уже поняли, что процесс в принципе пора автоматизировать (об этом — отдельная статья), дальше вопрос не «внедрять или нет», а «как внедрить, чтобы было не страшно».

Workflow: как внедрять по шагам

Шаг 1. Выберите один процесс и один его узкий участок

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

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

Шаг 2. Разделите действия на «безопасные» и «опасные»

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

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

Опасные — агент меняет данные в CRM, отправляет сообщение клиенту, меняет цену или остаток, создаёт документ, тратит рекламный бюджет. Здесь на старте обязательно подтверждение человека (human-in-the-loop): агент готовит действие, человек жмёт «отправить».

Пример на заявках: агент сам квалифицирует лид и заполняет черновик карточки в CRM (безопасно), но статус «горячий» и назначение на менеджера подтверждает человек одним кликом (опасно → через подтверждение). Через пару недель, когда видно, что классификация стабильна, часть подтверждений снимаете.

Шаг 3. Поставьте человека в правильную точку

Human-in-the-loop — это не «человек перепроверяет всё подряд». Так вы просто добавили работу. Смысл в том, чтобы человек стоял ровно на опасных действиях и на неуверенности агента.

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

Шаг 4. Включите логирование до, а не после

Логи — это не «потом посмотрим». Без них вы не поймёте, почему агент повёл себя странно, и не докажете клиенту или руководителю, что произошло. Минимум, что должно писаться по каждому действию:

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

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

Шаг 5. Урежьте права доступа

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

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

Шаг 6. Заложите откат заранее

До запуска ответьте на два вопроса. Первый: как выключить агента за 10 секунд, если он поехал? Должен быть один тумблер, а не «звоним разработчику». Второй: как процесс продолжит жить на людях, пока агент выключен? Если ответа нет — вы построили систему, которую нельзя остановить, а это опаснее ручной рутины.

ROI: как считать, что это вообще окупается

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

Простой пример. Поддержка обрабатывает 120 обращений в день, на разбор и первый ответ уходит в среднем 6 минут. Агент готовит черновик классификации и ответа, человек проверяет и отправляет — выходит 2 минуты на обращение. Это 8 часов в день против 12: минус треть нагрузки, которую можно направить на сложные кейсы, а не нанимать ещё человека.

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

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

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

Риски и что с ними делать

Галлюцинации. Агент уверенно выдумывает факт, цену, условие. Лечится тем, что фактические данные (цена, остаток, статус заказа) агент берёт из системы, а не «из головы», а спорные ответы уходят человеку.

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

Автоматизация хаоса. Если данные в CRM грязные и дублируются, ИИ поверх этого сделает быстрый хаос. Сначала наведите минимальный порядок в том куске, который автоматизируете, — не во всей системе, а именно в нём.

Расползание прав. Со временем агенту «на всякий случай» добавляют доступы. Через полгода он умеет слишком много. Раз в квартал проверяйте, что права всё ещё соответствуют задаче.

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

Реалистичный план внедрения на 4–6 недель

Не пытайтесь сделать всё сразу. Рабочий ритм для SMB выглядит так:

1. Неделя 1. Выбрали один процесс и узкий участок. Разметили действия на безопасные и опасные. Зафиксировали базовые метрики (объём, минуты, ошибки).
2. Неделя 2. Запустили агента только на безопасных шагах — черновики, классификация. Пока ничего никуда не уходит без человека. Настроили логи.
3. Неделя 3–4. Смотрим логи каждый день. Где агент ошибается — правим промпт, помечаем версию. Где он «не уверен» — там пусть передаёт человеку.
4. Неделя 5–6. Убеждаемся, что безопасная часть стабильна. Осторожно снимаем часть подтверждений на самых предсказуемых опасных действиях. Права всё так же урезаны, тумблер выключения на месте.

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

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

FAQ

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

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

Что писать в логи? Вход, решение агента и его уверенность, реальное действие, кто подтвердил, версию промпта и модели. Этого хватает, чтобы отладить поведение и восстановить любую спорную ситуацию.

Можно ли отдать ИИ работу с Wildberries и Ozon? Частично. Черновики ответов на отзывы, подготовку текстов карточек, аналитику — да, через проверку человеком. Публикацию, изменение цен и остатков без подтверждения на старте отдавать не стоит: цена ошибки прямая.

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

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

No-code, скрипт или кастомная разработка? Для теста гипотезы на узком участке хватает простого решения. Но как только появляются права доступа, логи, версии промптов и подтверждения — нужна нормальная архитектура, иначе контроль держится на честном слове.

Что делать дальше

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

Если хотите понять, что автоматизировать именно у вас и с чего безопасно начать, — напишите Дмитрию в Telegram @dmkosik или опишите свой процесс на диагностику Paramiko. Разберём ваш конкретный поток заявок, поддержки или маркетплейса и подскажем, где ИИ даст эффект без риска для операционки. Без давления — иногда честный ответ «здесь пока рано» тоже результат.