Когда останавливать AI-агента в финансах, медицине, праве
Когда останавливать AI-агента: разберем признаки риска в финансах, медицине и праве и покажем, где агент должен передать задачу человеку.

Почему автопилот ломается в критичных задачах
Автопилот терпим там, где ошибка только раздражает. Если агент неверно расставил теги в письмах или предложил слабый черновик ответа, человек это заметит и быстро поправит. Время потеряно, но ущерб обычно небольшой.
В критичных задачах все иначе. Здесь ответ модели не заканчивается текстом на экране. Он двигает деньги, влияет на лечение или меняет правовой статус человека.
Разница между подсказкой и действием кажется простой, но команды часто ее размывают. Фраза "этот платеж выглядит необычно" еще остается подсказкой. Блокировка счета, отправка денег, назначение дозировки, подача жалобы или выбор типа договора - это уже действие с последствиями.
Цена ошибки тоже меняется. В финансах агент может сорвать выплату, заморозить операцию или пропустить мошенничество. В медицине ошибка может задержать помощь или подтолкнуть к опасному решению. В праве один неверный шаг меняет срок подачи, размер штрафа или позицию человека в споре.
Где совет становится решением
Граница проходит не по форме ответа, а по тому, что происходит после него. Пока агент собирает факты, делает сводку, готовит черновик или просит уточнение, риск обычно ниже. Он помогает человеку думать, но не решает за него.
Риск резко растет, когда система сама выбирает один вариант и запускает следующий шаг без паузы на проверку. Если после ответа меняется баланс, статус заявки, схема лечения или юридический документ, в процессе нужен человек.
Для быстрой оценки полезно разделить задачи на две группы. К низкому риску обычно относятся черновик письма, краткая сводка договора, сортировка обращений и поиск похожих случаев. К высокому - перевод денег, отказ в услуге, рекомендация лекарства и подача документа от имени клиента.
Простой пример: агент банка пишет, что операция похожа на мошенническую. Это еще помощь. Но если он сам блокирует карту клиента ночью без проверки, совет уже стал решением.
Если действие трудно отменить, дорого исправить или оно влияет на права и здоровье, автопилот нельзя оставлять одного даже при высокой точности модели.
Какие действия сразу передавать человеку
Есть решения, где ошибка стоит слишком дорого, а отменить ее потом трудно или невозможно. В таких местах агенту лучше оставить сбор данных, черновик ответа и подготовку вариантов, а последнее слово отдать человеку.
В финансах это любые действия с деньгами и доступом к ним: платеж, перевод, списание, изменение лимита, выпуск реквизитов, смена получателя, закрытие счета. Даже если агент верно понимает запрос в 99 случаях из 100, одного промаха хватит для потери денег, спора с клиентом и долгой проверки.
В медицине граница еще жестче. Агент может помочь собрать жалобы, напомнить о режиме приема или разложить информацию по полям. Но вопросы о симптомах, дозировках, совместимости препаратов, срочности обращения и выборе лечения должен решать врач. Если человек пишет "болит грудь", "температура держится третий день" или "можно ли удвоить дозу", агент не должен угадывать.
В праве логика та же. Договоры, претензии, сроки подачи, штрафы, отказ от прав, согласие с условиями и любая финальная формулировка обязательств идут к юристу. Агент может найти похожий пункт или собрать черновик письма, но он не должен принимать риск за компанию или за клиента.
Удобный тест простой. Передавайте человеку все, что меняет деньги, права, сроки или медицинские решения, создает обязательство от имени клиента, требует согласия на условия, которые потом трудно оспорить, или не отменяется безопасно за пару минут.
Отдельное правило касается действий от имени клиента. Агент не должен нажимать "подтвердить", отправлять согласие, принимать оферту или менять настройки без явного подтверждения. Нужна не галочка по умолчанию и не молчаливое согласие, а понятное "да" на конкретное действие.
Даже если команда использует единый шлюз вроде AI Router и меняет модели без переделки кода, граница ответственности не сдвигается. Быстрый ответ модели не дает права списать деньги, дать медицинский совет или принять условия договора.
По каким признакам агент дошел до границы риска
Понять момент остановки проще не по ощущению, а по явным сигналам. Если отметить их заранее в сценарии, агент не уйдет слишком далеко и не успеет сделать дорогую ошибку.
Первый сигнал самый очевидный: агент хочет получить доступ к деньгам, персональным данным или праву что-то подтвердить от имени человека. Перевод средств, смена реквизитов, запрос паспорта, ИИН, номера карты, медицинской истории или текста договора без проверки человеком - это уже точка остановки.
Часто граница риска появляется не из-за самого действия, а из-за качества входных данных. Если агент видит старую выписку, неполную анкету, спорные документы или противоречия между полями, он не должен додумывать ответ. Он должен остановиться и передать случай сотруднику.
Полезно заранее отметить пять сигналов:
- агент просит доступ к оплате, переводу, возврату или изменению реквизитов;
- в данных есть пробелы, устаревшие записи или конфликт между источниками;
- случай не похож на обычный поток и не проходит по известному шаблону;
- даже одна ошибка меняет платеж, запись на прием, срок подачи или текст документа;
- пользователь пишет в стрессе, торопит, давит или резко меняет требования.
Последний пункт часто недооценивают. Когда человек нервничает, он чаще пишет обрывками, путает даты и просит "сделать прямо сейчас". В такой момент агент выглядит быстрым помощником, но именно тогда растет цена ошибки.
Пример простой. Клиент пишет в чат банка: "Срочно переведите деньги на новый счет, старый заблокирован". Если агент не видит подтверждения через второй канал, не сверяет историю и все равно готовит перевод, процесс нужно останавливать сразу.
То же самое в медицине и праве. Если запись к врачу зависит от симптомов, которые пользователь описал смутно, нужен человек. Если правовой ответ меняет срок, обязательство или формулировку в документе, человек тоже нужен.
Хорошо, когда эти сигналы связаны с правилами остановки в логике агента и в аудит-логах. Тогда команда видит не только ошибку после факта, но и момент, когда агент должен был остановиться.
Как поставить точку остановки
Точку остановки лучше ставить раньше, чем кажется. Если цена ошибки заметна, агент не должен сам отправлять деньги, менять лечение или запускать юридическое действие. Его роль до этой точки проста: собрать данные, сделать расчет, подготовить черновик и остановиться.
Такой подход убирает самый опасный разрыв. Агент помогает быстро, но человек все еще принимает решение там, где есть риск для денег, здоровья или права. Короткое правило звучит так: агент останавливается до любого шага, который что-то меняет во внешнем мире.
Обычно хватает трех фильтров:
- сумма выше заданного порога;
- срочность высокая, и ошибка дорого обойдется;
- тип дела относится к финансам, медицине, праву или персональным данным.
Порог не должен быть абстрактным. Для одной команды это платеж выше 100 000 тенге, для другой - любое изменение лимита клиента даже на меньшую сумму. В клинике стоп можно ставить на жалобах с красными флагами: боль в груди, потеря сознания, риск аллергии. У юристов правило еще проще: агент не отправляет документы и не дает финальную формулировку без проверки.
Совет, расчет и исполнение лучше разделить не только в политике, но и в интерфейсе. Пусть агент показывает вариант ответа, считает сумму и отмечает риск. Но действие вроде "отправить", "подписать", "назначить" или "списать" должно жить в другой зоне и требовать явного решения человека.
Если человек подключается, ему нельзя показывать только итог. Он должен сразу видеть, что сказал пользователь, на каких данных агент опирался и почему система остановилась. На хорошем экране проверки обычно хватает пяти вещей: краткого черновика, истории диалога, источника данных, сработавшего правила и действия, которое агент собирался предложить.
Что должен сделать человек
У проверяющего должно быть три варианта без лишней путаницы: одобрить, отклонить или вернуть на доработку.
"Одобрить" подходит, когда данные полные и риск понятен. "Отклонить" нужно, если агент ошибся по сути. "Вернуть на доработку" экономит время, когда черновик почти годится, но не хватает одного документа, уточнения по сумме или более аккуратной формулировки.
Такой стоп не тормозит работу. Он убирает ложную автоматизацию, где агент выглядит уверенно, а команда потом разбирает дорогую ошибку.
Что человек проверяет за две минуты
Двух минут обычно хватает, если человек не перечитывает весь диалог, а смотрит на места, где ошибка стоит дорого. Решение принимают не по общему впечатлению, а по нескольким вопросам: кто клиент, что именно агент собирается сделать, на каких данных он это решил и что случится после подтверждения.
Сначала сверяют факты: имя клиента, сумму, дату, номер документа, срок действия, адресата и вложения. В финансах одна лишняя цифра меняет платеж. В медицине одна дата меняет окно для анализа или приема. В праве старая версия документа может испортить весь следующий шаг.
Потом человек ищет дыры в логике. Агент мог сослаться на один документ, а вывод сделать по другому. Мог пропустить исключение в договоре, не заметить конфликт дат или выдать слишком уверенную фразу там, где в данных есть пробел. Спорные формулировки тоже проверяют руками: "согласен", "подтверждаю", "ознакомлен" звучат похоже, но смысл у них разный.
Короткий чек за две минуты выглядит так:
- сходятся ли имя, суммы, даты и версия документов;
- есть ли пропуски, конфликт фактов или двусмысленные слова;
- понял ли клиент цену решения, сроки и возможный отказ;
- хватает ли одного ревью или нужен второй специалист;
- записана ли причина решения в журнале.
Отдельно смотрят на согласие клиента. Если агент предлагает списание, изменение лечения, подачу жалобы или отказ от права, человек должен видеть, что клиент понял последствия. Недостаточно того, что клиент просто нажал кнопку. Нужно понимать, сколько спишут, что изменится, что он теряет и какие есть другие варианты.
Если остается хотя бы один спорный момент, человек не правит ответ по мелочи и не отправляет его сразу. Он задает один уточняющий вопрос или зовет второго специалиста. Это дешевле, чем потом разбирать жалобу, отменять платеж или объяснять, почему система "не так поняла".
Последний шаг часто забывают: решение фиксируют вместе с причиной. Короткой записи достаточно: "сумма не совпала с договором", "клиент не подтвердил последствия", "нужен юрист по исключению в оферте". Если команда работает через AI Router, такую отметку удобно привязать к аудит-логу и кейсу, чтобы потом увидеть, где агент ошибается чаще.
Три коротких случая из практики
Когда команда решает, где ставить стоп, лучше смотреть не на отрасль, а на цену ошибки. Если действие меняет деньги, лечение или договор, агенту нельзя отдавать последний шаг без человека.
Финансы. Агент видит просрочку по счету и предлагает автоматически списать штраф. На первый взгляд все логично: срок вышел, правило есть, сумма посчитана. Но человек быстро замечает, что источник данных неполный. Платеж мог зависнуть в банке, клиент мог получить отсрочку, а в договоре мог быть льготный период. Агент может подготовить расчет, собрать историю платежей и показать правило, по которому появился штраф. Само списание он должен оставить на одобрение.
Медицина. Бот получает жалобы на похожие симптомы и предлагает дозировку, потому что она подошла в похожем случае раньше. Это опасный момент. Похожие симптомы не значат одинаковый диагноз, а дозировка зависит от возраста, веса, анализов и уже принятых препаратов. Человек смотрит, откуда бот взял рекомендацию, есть ли свежие данные по пациенту и давал ли пациент согласие на такой формат помощи. Агент может собрать карточку, вынести возможные варианты и отметить, чего не хватает. Назначение дозы врач берет на себя.
Право. Ассистент читает новый пункт договора и советует принять его без проверки, потому что формулировка кажется стандартной. На деле один абзац может сдвинуть срок оплаты, расширить штрафы или дать второй стороне право менять условия в одностороннем порядке. Человек открывает источник, сверяет редакцию, оценивает последствия и проверяет, кто вообще может дать согласие на такой риск. Агенту можно поручить сравнить версии договора и пометить спорные места. Решение о принятии пункта остается у юриста или ответственного менеджера.
Во всех трех случаях граница простая. Агент готовит черновик решения, собирает факты и показывает пробелы. Человек проверяет, на каких данных все построено, что случится после подтверждения и есть ли право и согласие на действие. Если агент не может ясно ответить хотя бы на один из этих вопросов, автопилот нужно выключать сразу.
Где команды чаще ошибаются
Первая ошибка случается рано: команда дает агенту право не только советовать, но и нажимать кнопку. Пока агент ищет черновик платежа или собирает выписку, риск умеренный. Когда он сам отправляет перевод, меняет лимит, записывает диагноз в карту или правит текст договора, цена ошибки растет резко.
На практике граница между "подсказал" и "сделал" часто размыта. Внутри системы это может выглядеть как один и тот же вызов API, но для бизнеса это разные уровни ответственности. Если человек не подтверждает последнее действие явно, агент рано или поздно пройдет дальше, чем ему стоило.
Еще одна частая ошибка - один и тот же порог риска для всех случаев. Это удобно в настройке, но работает плохо. Возврат денег постоянному клиенту на маленькую сумму, назначение лекарства, ответ на претензию и согласование пункта в договоре нельзя мерить одной шкалой. У отделов разные потери, сроки и правила.
Другая проблема выглядит менее заметной, но мешает не меньше. Человек получает задачу "проверь", но не видит, на чем агент построил решение. Без исходных данных, истории сообщений, найденных документов и причины выбора сотрудник не проверяет, а гадает. На это уходит больше времени, и люди начинают одобрять действия по привычке.
Плохая передача человеку ломает даже осторожный процесс. Если сотруднику нужно открыть три окна, заново искать клиента и вручную собирать контекст, он будет откладывать проверку или жать "подтвердить" слишком быстро. Нормальная передача занимает минуты: один экран, краткое резюме, исходные данные и понятные варианты действий.
Есть и совсем приземленная ошибка, но она бьет больнее всего. После спорного случая команда чинит частный баг и идет дальше. Она не разбирает, почему агент вообще решил действовать уверенно, где система скрыла сомнение и какой сигнал человек пропустил. Поэтому похожая ошибка возвращается через неделю, только уже в другом отделе.
Если вопрос об остановке агента возникает после первого инцидента, команда уже опоздала. Точку остановки, роль человека и разбор спорных случаев лучше задать до запуска. Тогда агент помогает работе, а не создает новую очередь из чужих ошибок.
Быстрые проверки перед запуском
Один удачный демо-прогон почти ничего не значит. Перед запуском дайте агенту то, на чем он обычно спотыкается: неполные формы, противоречия в данных и резкую смену контекста посреди задачи.
Хороший минимум - руками пройти десять спорных сценариев. Не берите только чистые кейсы. Добавьте случаи, где у клиента пустое поле в анкете, в системе расходятся суммы, в медкарте есть старый диагноз, а в юридическом документе не хватает даты или полномочия.
Такие прогоны быстро показывают реальную картину. Агент может выглядеть уверенно даже там, где ему уже нужен человек.
Проверьте хотя бы такие ситуации:
- пустое обязательное поле;
- два источника дают разные данные;
- пользователь внезапно меняет тему или цель запроса;
- документ выглядит неполным, но агент все равно хочет продолжить;
- агент предлагает действие с деньгами, лечением или правовым эффектом.
Смотрите не только на то, остановился ли агент. Проверяйте, написал ли он понятную причину остановки в аудит-лог. Запись вроде "low confidence" мало помогает. Нужна простая причина: "не совпала сумма в двух системах" или "нет согласия на обработку персональных данных".
Отдельно проверьте доступы. Команды часто хорошо тестируют саму логику и почти не смотрят, кто видит персональные данные и кто может нажать кнопку одобрения. Это опасный перекос. Если агент работает с финансами, медициной или правом, у роли наблюдателя, оператора и одобряющего должны быть разные права.
Если вы используете внутреннюю платформу или шлюз вроде AI Router на airouter.kz, проверьте не только ответ модели, но и служебный след: аудит-логи, маскирование PII и ограничения на уровне ключа. Эти вещи редко замечают на демо, но именно они помогают в спорной ситуации.
Еще одна простая проверка - замерить передачу человеку по времени. Поставьте секундомер и посмотрите, сколько занимает путь от сигнала "стоп" до решения оператора. Если уходит 12 минут, а клиент ждет ответ в чате, схема не готова. Для многих команд разумный ориентир - уложиться в 1-2 минуты хотя бы на типовых кейсах.
Если один и тот же спорный сценарий проходит по-разному у двух операторов, проблема не в агенте. Значит, правило остановки пока слишком расплывчатое.
Что делать дальше
Спор о том, где останавливать агента, лучше закончить не презентацией, а маленьким пилотом. Возьмите один процесс, где цена ошибки понятна заранее: например, возврат платежа выше заданной суммы, ответ пациенту с советом по лечению или подготовку письма с правовой позицией. На одном таком процессе команда быстро увидит, где агент помогает, а где ему нужен стоп-сигнал.
Дальше нужен не большой регламент, а короткие правила на обычном языке. Если сотрудник не может прочитать правило за полминуты и понять, что делать, правило не сработает.
Начать можно с пяти шагов:
- выбрать один сценарий и описать, какое решение агент может принять сам, а какое должен передать человеку;
- записать 5-7 правил остановки простыми фразами;
- проверить путь данных: где они хранятся, кто их видит, что попадает в логи и как маскируются ИИН, телефоны и адреса;
- собрать маршрутизацию, контроль и аудит-логи в одном месте, если используются несколько моделей и провайдеров;
- раз в месяц разбирать спорные случаи и править слабые правила, пороги и промпты.
Часто команды пропускают именно проверку данных и логов. Агент может отвечать неплохо, но проблема начинается позже: данные ушли не туда, логов нет, спорный ответ нельзя восстановить по шагам. Тогда даже хороший результат трудно защитить перед службой безопасности, юристами или внутренним аудитом.
Рабочий цикл обычно выглядит просто. Команда запускает пилот, собирает 20-30 спорных эпизодов, правит правила остановки и снова проверяет. Через пару итераций становится видно, какие задачи можно оставить агенту, а какие всегда должен смотреть человек.
Если нужен быстрый старт, возьмите один поток согласований с понятным лимитом риска и поставьте одну точку остановки. Этого достаточно, чтобы перестать спорить в общем и начать решать проблему по фактам.
Часто задаваемые вопросы
Как понять, что агент уже решает сам, а не просто помогает?
Смотрите не на форму ответа, а на результат после него. Если после реплики агента меняется баланс, статус заявки, схема лечения или текст документа без паузы на проверку, он уже принимает решение, а не просто помогает.
Какие финансовые действия нельзя пускать на автопилот?
Не оставляйте агенту переводы, списания, возвраты, смену реквизитов, изменение лимитов и закрытие счета. Он может собрать данные, посчитать сумму и подготовить черновик, но последнее подтверждение должен дать сотрудник.
Можно ли доверить агенту советы по лечению?
Для медицины агенту лучше дать сбор жалоб, напоминания и заполнение полей. Дозировку, срочность обращения, совместимость препаратов и выбор лечения должен смотреть врач, потому что ошибка тут бьет слишком сильно.
Что в юридических задачах всегда отдают человеку?
В праве человек должен проверять сроки, штрафы, согласие с условиями, отказ от прав и финальные формулировки обязательств. Агент пусть сравнивает версии, ищет похожие пункты и готовит черновик, но риск за компанию или клиента он брать не должен.
Какие сигналы риска должны сразу включать стоп?
Останавливайте сценарий сразу, если агент просит доступ к деньгам, персональным данным или праву подтвердить что-то от имени клиента. Стоп нужен и тогда, когда в данных есть пробелы, источники спорят друг с другом, случай выбивается из обычного потока или пользователь давит и торопит.
Нужно ли брать отдельное согласие клиента перед действием?
Да, нужно явное подтверждение на конкретный шаг. Нельзя считать согласием молчание, галочку по умолчанию или общий разговор в чате, если агент собирается списать деньги, принять оферту или поменять настройки.
Что человек должен проверить за две минуты?
Сначала человек сверяет имя, сумму, даты, адресата, версию документа и источник данных. Потом он смотрит, нет ли пропусков, конфликта фактов и двусмысленных слов, и решает, можно одобрить сейчас или лучше вернуть кейс на доработку.
Где лучше ставить точку остановки?
Ставьте точку остановки до любого шага, который меняет что-то во внешнем мире. На практике хватает простого правила: агент готовит вариант, а кнопку вроде "отправить", "подписать" или "списать" нажимает человек после проверки.
Зачем писать причину остановки в аудит-лог?
Короткая и ясная причина в логе помогает понять, почему система остановилась и что чинить дальше. Запись вроде "не совпала сумма в двух системах" полезнее, чем расплывчатое "низкая уверенность", потому что команда сразу видит слабое место.
Если я меняю модель через один API, можно ли сильнее автоматизировать рискованные шаги?
Нет, смена модели или шлюза не меняет границу ответственности. Даже если команда работает через единый API и быстро переключает модели, деньги, лечение и правовые действия все равно требуют тех же стоп-правил и проверки человеком.