Черновик и действие в AI-процессе: как ставить барьер

Почему модели нельзя менять записи самой

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

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

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

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

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

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

Даже если команда работает через единый LLM-шлюз вроде AI Router, правило не меняется. Удобный доступ к моделям не должен означать удобный доступ к записи в продакшене.

Где заканчивается черновик и начинается действие

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

Из этого следует простое правило: у модели одна роль - подготовить предложение. Она может заполнить поля, собрать короткое объяснение и отметить сомнительные места. Но запись в систему должна ждать отдельного шага.

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

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

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

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

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

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

Как собрать поток в два шага

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

Если клиент пишет: "Закройте заявку 1845, вопрос решен", модель не закрывает ее. Она готовит предложение: статус сейчас "В работе", новый статус "Закрыта", причина - "вопрос решен", источник - текст клиента. Так команда видит не догадку модели, а конкретный проект изменения.

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

Такой экран убирает частую ошибку: сотрудник не ищет разницу по вкладкам и не подтверждает действие вслепую. Он сразу видит, что меняется и почему.

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

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

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

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

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

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

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

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

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

Создание, объединение и удаление клиентских записей тоже нужно проводить через подтверждение. Модель может перепутать двух людей с похожими именами, склеить дубли не туда или удалить карточку, которую надо было просто пометить.

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

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

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

Пример со статусом заявки

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

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

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

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

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

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

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

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

В этом и есть разделение черновика и действия. AI не меняет статус заявки сам. Он предлагает вариант, а система пропускает действие только после проверки и явного подтверждения.

Где команды ошибаются чаще всего

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

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

Вторая ошибка опаснее: модели дают право вызвать метод в системе сразу после ответа. Если вызов инструмента запускает update_status, change_limit или create_record без отдельного экрана проверки, черновик уже стал действием. Тогда любая неточность в промпте превращается в запись в базе.

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

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

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

Признак сырого процесса простой. Если сотрудник не может за 5 секунд ответить на три вопроса - что изменится, откуда взяли текущее значение и кто подтверждает шаг, - барьер еще слабый. В таком потоке AI лучше оставить роль помощника, а не исполнителя.

Быстрая проверка перед запуском

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

Безопасная схема выглядит так: модель предлагает, правила проверяют, человек подтверждает, сервис применяет изменение.

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

Перед запуском полезно пройти короткий список:

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

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

Хороший тест выглядит так: модель предлагает перевести заявку из "На проверке" в "Одобрено". Оператор видит оба статуса, причину изменения и поля, которые еще надо заполнить. Если хотя бы одного обязательного поля нет, система не дает подтвердить действие. Если все в порядке, оператор нажимает отдельное подтверждение, и только после этого сервис меняет запись.

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

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

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

Кто подтверждает и что хранить в логе

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

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

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

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

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

Отметку о подтверждении нужно привязывать к человеку или к сервису с понятной ролью. Запись вроде "изменение применено" почти бесполезна. Нужна запись уровня: "подтвердил: id сотрудника 4821, роль: оператор второй линии".

Тестовые и боевые журналы лучше разделять жестко. Когда все события лежат вперемешку, команда быстро теряет доверие к логам. В тесте можно хранить больше отладочных данных, а в бою - только то, что нужно для аудита, расследования и отката.

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

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

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

На одном таком примере проще проверить, где у вас заканчивается черновик и начинается действие. Если команда не может провести эту границу на одном кейсе, на десяти она точно запутается.

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

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

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

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

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