AI exception path: покажите, где подключается человек и почему

Почему большинство схем команды не работают

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

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

В AI-first процессе всё обычно ломается в грязной середине. Клиент отправляет файл не в том формате. Модель даёт ответ с низкой уверенностью. Две системы не согласны друг с другом. Какое-то поле пустое или, что хуже, заполнено чем-то, что выглядит правильно, но на самом деле неверно. Работа не останавливается. Она просто выходит за пределы схемы.

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

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

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

Вот почему AI exception path важнее, чем happy path. Гладкий поток показывает, что команда надеется увидеть. Путь исключений показывает, как работа выживает, когда AI застревает. Именно эта версия нужна людям, если они хотят понятную ответственность, более быстрые исправления и меньше сюрпризов в течение дня.

Что должен включать путь исключений

Полезный AI exception path отвечает на пять вопросов: что сломалось, кто за это отвечает, что он делает, как быстро он должен это сделать и чем работа заканчивается. Если хотя бы одного ответа нет, люди начинают гадать. А догадки — это начало задержек и плохих решений.

Начните с точного триггера, который выводит задачу из обычного потока. Не пишите «AI сломался» или «нужна проверка». Укажите условие, которое переводит задачу из автоматизации. Это может быть confidence score ниже заданного порога, отсутствующее поле в форме, сумма по биллингу, не совпадающая с заказом, или сообщение, затрагивающее политику, по которой модель не должна принимать решение сама.

Сделайте этот триггер видимым в AI operations diagram как чёткое событие, а не расплывчатую пометку. Если команда использует алерты, очереди или теги, назовите тот, который срабатывает. Человек должен посмотреть на схему и понять, почему кейс ушёл с обычного пути.

Следующий шаг должен назвать человека или роль, которая подхватывает задачу. Используйте реальную роль, а не туманную метку вроде «human review». «Support manager», «finance analyst» или «on-call engineer» дают команде настоящего владельца. Если днём кейсами занимается один человек, а ночью другой, укажите и это. Иначе работа зависает в неопределённости.

Затем покажите действие, которое этот человек выполняет, и срок. Действие должно быть глаголом: approve, reject, fix, request missing information или escalate. Срок нужно задавать числом: 15 минут, 4 часа, 1 business day. Без часов диаграмма выглядит завершённой, но никто не понимает, сколько может ждать клиент.

Короткий пример с возвратом денег помогает это увидеть. Допустим, AI-агент готовит ответ по refund, но заказ уже отправлен, а сумма выше вашего лимита на возврат. Путь исключений должен показать триггер, назначить кейс в поддержку, задать окно ответа и описать, что support делает дальше.

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

И последнее: отметьте, что видит клиент или пользователь, пока работа задерживается. Короткое статусное сообщение очень важно. «Мы проверяем одну деталь и ответим в течение 4 часов» уменьшает повторные сообщения и снижает раздражение. Тишина создаёт больше работы для всех.

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

Где должен подключаться человек

Человеку не нужно стоять в середине каждой AI-задачи. Он должен подключаться там, где неверный ответ стоит денег, доверия, безопасности или большого объёма переделок.

Низкая уверенность результата — самый очевидный старт. Если модель звучит неуверенно, даёт противоречивые ответы или опирается на слабые доказательства из грязных заметок, кто-то должен проверить результат до того, как на него начнут действовать. Это особенно важно, когда AI пишет ответы клиентам, краткие сводки по изменениям или код, который попадает в production.

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

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

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

Повторяющиеся исключения тоже заслуживают внимания. Именно здесь exception handling in AI перестаёт быть реактивным и начинает улучшать систему. Если один и тот же странный случай появляется каждую неделю, не гоняйте его по чату в надежде, что в следующий раз ответ будет лучше. Исправьте процесс. Добавьте обязательное поле. Введите правило. Измените промпт. Поставьте простой чек до запуска модели.

Хорошие команды делают это хорошо. Они оставляют AI основную массу работы, а людей ставят на несколько острых краёв, где по‑прежнему важны суждение и опыт. В этом разница между полезным human-in-the-loop workflow и расплывчатым обещанием, что «кто-нибудь проверит, если понадобится».

Как нарисовать диаграмму

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

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

1. Сначала нарисуйте обычный поток с несколькими простыми блоками. Используйте короткие подписи вроде «запрос поступает», «AI готовит ответ», «человек проверяет» и «отправить результат». Если блоков больше шести или семи, разделите процесс на две диаграммы.
2. Отметьте все места, где AI может догадаться, ждать или ошибиться. «Догадаться» значит принять решение на основе оценки. «Ждать» значит ему не хватает данных, одобрения или ответа системы. «Ошибиться» значит вернуть неверный формат, низкую уверенность или не вернуть результат вовсе.
3. Для каждой отмеченной точки добавьте четыре заметки: триггер, владелец, инструмент или очередь и временной лимит. «Confidence ниже 80%, support lead, help desk queue, 15 минут» — это уже достаточно конкретно, чтобы работать.
4. Нарисуйте следующий шаг после human review. Работа должна вернуться в основной поток, перейти в ручной маршрут или остановиться. Подпишите стрелки результатами вроде «approved», «fixed», «needs more data» или «closed without action».
5. Добавьте одно правило остановки. Если одно и то же исключение повторилось дважды или время вышло, работа не должна бесконечно прыгать туда-сюда. Отправьте её конкретному человеку, который может принять решение.

Одна маленькая деталь сильно снижает путаницу: подписывайте роли, а не отделы. «Ops» и «engineering» слишком широкие. «On-call engineer» или «billing manager» сразу говорят, кто именно действует.

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

Если хотите проверить схему, прогоните через неё одну недавнюю задачу и засеките каждую передачу. Если кто-то спрашивает: «Кто теперь этим занимается?» или «Сколько мы ждём?», значит, в диаграмме всё ещё есть пробел.

Простой пример из поддержки

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

Когда приходит новое письмо, AI читает сообщение, проверяет статус аккаунта и сортирует запрос. Он ставит теги для типовых проблем: сброс пароля, проблемы с входом, вопрос по биллингу, баг-репорт или «неясно». Этот первый проход быстрый и обычно достаточно точный, чтобы сильно сократить ручной triage.

Большинству проблем с паролем человек не нужен. Если аккаунт совпадает с обычным сценарием сброса, система отправляет шаги self-service, просит пользователя подтвердить адрес электронной почты и направляет его к потоку сброса. Такие тикеты закрываются сами и в загруженные дни могут экономить команде 15–20 минут каждый час.

Более сложные кейсы начинаются со споров по биллингу. Если клиент говорит, что его списали дважды, отменил подписку, но деньги всё равно списали, или не узнаёт продление, AI останавливается. В хорошем AI exception path эта остановка — часть дизайна, а не ошибка.

Вместо ответа наугад система открывает human review и передаёт короткое резюме. Сотрудник поддержки видит историю счета, дату продления, статус оплаты и последние изменения в аккаунте. Потом он проверяет, была ли сумма списана дважды или просто с задержкой, была ли отмена до продления, есть ли признаки fraud или account sharing, и что делать дальше — refund, credit или объяснение.

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

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

Если support-команда видит один и тот же биллинговый кейс каждую неделю, правило нужно обновить. Возможно, AI нужен более точный триггер для дублей списаний. Возможно, ему нужен ещё один field из billing system. А может, первый ответ клиенту слишком расплывчатый, поэтому люди продолжают писать снова. Именно так human-in-the-loop workflow становится полезным. Команда не просто выживает при исключениях. Она учится на них и делает следующий проход чище.

Частые ошибки, которые всех путают

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

Следующая проблема — расплывающаяся ответственность. Блок с надписью «human review» слишком неопределённый. Какой именно человек? Руководитель поддержки, дежурный инженер, финансовый менеджер? Если у передачи нет владельца, все думают, что её подхватит кто-то другой. Тогда кейс ждёт в очереди или, что хуже, лежит в чате, где его часами никто не замечает.

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

Временные правила тоже важны. Если AI отправил кейс человеку, как долго он может ждать? Что происходит через 15 минут, 2 часа или к концу дня? Без чёткого лимита «посмотрим позже» превращается в «забыли». Без правила эскалации срочные и обычные кейсы сваливаются в одну кучу.

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

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

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

Проблемы при запуске редко возникают из основного потока. Они начинаются с первой непонятной передачи, первого алерта, за который никто не отвечает, или первого сообщения пользователя: «Почему это зависло?»

Перед запуском AI-first team process поместите диаграмму на один экран и попросите нового для команды человека прочитать её без подсказок. Если ему нужен длинный разбор, схема всё ещё скрывает часть работы.

Хороший AI exception path проходит несколько простых проверок. Новый коллега может менее чем за минуту назвать следующего владельца. У каждого блока исключения указано, что его запускает и сколько у команды есть времени на реакцию. На схеме показан fallback на случай, если никто не отвечает. Пользователь видит какой-то статус во время задержки. И команда может посчитать, как часто возникает каждое исключение.

Эту пользовательскую часть постоянно упускают. Внутри команды все знают, что подключится инженер, reviewer или founder. Пользователь видит тишину. И часто именно этот разрыв создаёт больше поддержки, чем сама первоначальная ошибка.

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

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

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

Диаграмма полезна только тогда, когда она соответствует тому, что команда делала на прошлой неделе, а не тому, как вам хотелось бы. Начните с двух или трёх недавних инцидентов. Возьмите одну проблему, видимую клиенту, одну внутреннюю задержку и один случай, когда человеку пришлось override AI. Если схема не может ясно объяснить эти моменты, она всё ещё слишком аккуратная.

Затем отслеживайте исключения в течение одного месяца. Большое исследование не нужно. Достаточно простого подсчёта: неверный результат, недостаток контекста, policy risk, неясный запрос, сбой инструмента и необходимость одобрения. Через несколько недель обычно быстро проявляются закономерности. Одна команда может обнаружить, что половина задержек связана с неясными входными данными. Другая — что люди слишком много времени тратят на перепроверку работы, которую модель в большинстве случаев и так делает правильно.

Используйте этот подсчёт, чтобы очистить путь. Уберите передачи, которые просто перекидывают работу от одного человека к другому без решения. Оставьте контрольные точки там, где человек защищает пользователей, деньги, compliance или брендовый риск. Сведите дублирующиеся проверки в одну, если два человека проверяют одно и то же по одной и той же причине. Запишите, кто подключается, что он проверяет и как работа возвращается в AI-поток. Задайте временной лимит для каждого человеческого шага, чтобы исключения не зависали в очереди весь день.

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

Хороший AI exception path должен без колебаний отвечать на три вопроса: что сломалось, кто за это отвечает и что происходит дальше. Если хотя бы один из ответов расплывчатый, команда начнёт импровизировать под давлением. А это уже рост затрат и падение доверия.

Сторонний взгляд помогает, когда команда слишком близка к своим привычкам. Oleg Sotnikov, через oleg.is, консультирует стартапы и небольшие компании по AI-first workflows, lean operations и работе в формате Fractional CTO. Быстрый разбор от человека, который строил и запускал lean AI-augmented systems, помогает сделать точки передачи понятнее и экономит недели проб и ошибок.

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