Что это решает
Внедрение ИИ-агентов упирается в стык с живым процессом: у процесса есть владелец, сроки, клиенты и цена ошибки. Пилот на демо-данных отвечает красиво, а в бою тот же агент пишет в чужой заказ, дублирует запись после таймаута или отвечает клиенту то, чего компания не обещает. Аккуратный ввод снимает ровно эту боль: даёт контролируемое расширение прав, точку отката и цифры «до и после» на одном и том же срезе. Побочный эффект — процесс приходится сначала описать, и половина находок обнаруживается до всякого агента.
Как устроено
Механика ввода — лестница прав. Ступеней пять, каждая следующая берётся после того, как предыдущая отработала на реальном потоке.
- Наблюдатель. Агент только читает и пишет свои выводы в отдельный канал: файл, колонку в таблице, тред в мессенджере. Процесс работает как раньше и агента не замечает.
- Теневой режим. Агент готовит решение по каждому реальному кейсу, человек решает сам. Обе версии складываются рядом, расхождения разбираются.
- Черновик с подтверждением. Агент формирует запись — ответ клиенту, карточку, платёжку — и останавливается на кнопке. Человек жмёт «применить» или правит.
- Автономия по классу операций. Обратимые действия агент делает сам, необратимые по-прежнему через подтверждение.
- Автономия с постмодерацией. Выборочная проверка части кейсов и разбор жалоб.
Поверх лестницы стоит контур, который делает откат возможным:
- Владелец процесса — конкретный человек, который разбирает расхождения и принимает решение о следующей ступени.
- Рубильник. Флаг в переменных окружения или отзыв ключа, выключающий агента за минуту, без выката кода.
- Журнал. Каждое действие с меткой времени, входом, выходом и идентификатором кейса.
- Канал эскалации. Куда агент пишет «не знаю» и кто это читает.
- Правила как код. Инструкция агента лежит в репозитории, меняется коммитом, проходит ревью. Правка промпта в чужом веб-интерфейсе без истории — источник необъяснимых регрессий.
Перед стартом шаги процесса размечаются на четыре типа: читать, решать, писать внутрь системы, общаться с внешним миром. Последний тип самый дорогой по цене ошибки и отдаётся последним.
Отдельная деталь, которая ломает внедрения тихо, — дубли. Сеть отвалилась после записи, но до ответа; агент повторил шаг; в системе два счёта. Лечится ключом идемпотентности: перед записью инструмент проверяет, нет ли уже операции с тем же ключом.
Правило: право на запись выдаётся только после того, как в теневом режиме предложения агента перестали расходиться с решениями человека.
Как подключить
Шаг 1. Выбрать процесс. Годится тот, у которого есть письменный след (тикеты, письма, строки в базе) и измеримый исход (закрыто/не закрыто, срок, сумма). Устные согласования агент не увидит.
Шаг 2. Записать процесс как есть. По шагам, с исполнителем и типичным временем. Достаточно таблицы на один экран.
Шаг 3. Разметить шаги по четырём типам и выбрать узкую полосу: один тип обращений, одна категория тикетов, один сегмент клиентов. Полоса должна давать поток каждый день, иначе проверять будет не на чем.
Шаг 4. Дать чтение. Подключить только читающие инструменты, ограничить выборку выбранной полосой, включить журнал. Пусть агент неделю пишет наблюдения в отдельный канал.
Шаг 5. Теневой прогон. Агент кладёт своё решение в поле agent_suggestion (отдельная колонка, комментарий, файл), человек работает как раньше. В конце периода строится сверка: совпало, разошлось, агент оказался прав.
Шаг 6. Разобрать расхождения по причинам. Каждое расхождение закрывается одним из трёх способов: правило в инструкции, новый или уточнённый инструмент, признание «этот класс кейсов агент не берёт». Третий вариант — нормальный исход, он сужает полосу.
Шаг 7. Порог перехода. Ступень 3 берётся, когда повторяющиеся причины расхождений закрыты и новые перестали появляться на свежих кейсах. Календарный срок здесь не критерий, критерий — исчерпание причин.
Шаг 8. Включить запись через подтверждение. Одна операция за раз. Кнопка отката рядом с кнопкой применения. Первые дни владелец смотрит каждый кейс.
Шаг 9. Снимать подтверждения по классам. Начиная с обратимых: поставить метку, перенести задачу, обновить служебное поле. Отправка наружу и деньги остаются с подтверждением, пока владелец сам не решит иначе.
Шаг 10. Тревоги по порогам. Уведомление приходит, когда доля эскалаций или число откатов выходит за границу, а не каждый день по расписанию. Ежедневная рассылка, которую никто не читает, равна отсутствию мониторинга.
Шаг 11. Ревизия. Раз в период — просмотр журнала: какие классы кейсов агент ведёт лучше человека, какие хуже, что можно передать дальше, что забрать обратно.
Полезные сценарии
- Первая линия поддержки: агент готовит ответ, оператор отправляет, доля правок падает — подтверждение снимается для типовых вопросов.
- Разбор входящих заявок: классификация и заполнение полей автоматически, решение по спорным — человеку.
- Регулярная сверка: агент каждое утро сравнивает данные двух систем и присылает только расхождения.
- Дежурство по ошибкам: группировка ночных сбоев, разбор повторяющихся, эскалация новых.
- Ведение трекера: перенос задач по правилам колонок, напоминания по зависшим, сбор сводки к планёрке.
- Подготовка документов по шаблону: черновик формируется агентом, подпись и отправка — за человеком.
Ограничения
Необратимые действия остаются за людьми: переводы денег, удаление данных, публикация вовне, юридически значимые ответы. Подтверждение здесь снимается только осознанным решением владельца по каждому классу отдельно.
Процесс без письменного следа не автоматизируется: если решение рождается в разговоре и нигде не фиксируется, у агента нет ни входа, ни эталона для сверки.
Отсутствие владельца убивает внедрение надёжнее плохой модели. Расхождения теневого режима некому разбирать, правила не пополняются, агент остаётся на первой ступени навсегда.
Персональные данные требуют отдельного решения до старта: что маскируется, что не покидает контур, кто отвечает за инцидент.
Редкие события проверить нечем: если кейс случается несколько раз в год, теневой период не наберёт статистики, и агент останется помощником-подсказчиком.
Команда, которая не читает уведомления, получит генератор шума. Каналы и пороги настраиваются до включения записи.
Стоимость растёт вместе с объёмом контекста и числом шагов, поэтому расширение полосы всегда проверяется по счётчику токенов из журнала.
Как проверить результат
Сверочный отчёт теневого периода — главный документ. Три колонки: совпало с человеком, разошлось, агент оказался прав. Динамика долей по неделям показывает, движется ли внедрение.
Дальше — цифры из журнала на одном и том же срезе до и после:
- доля кейсов, закрытых без вмешательства человека;
- время цикла от поступления до закрытия;
- число откатов и их причины;
- доля эскалаций «не знаю» — резкий рост означает, что полосу расширили слишком быстро;
- повторные обращения клиента по тому же вопросу — прокси качества ответов;
- расход токенов на один кейс.
Отдельно проверяется рубильник: выключить агента в рабочий день и убедиться, что процесс продолжает работать руками, а очередь не встаёт. Внедрение, которое нельзя выключить, ещё не закончено — его просто не проверяли на этом.