Арт. ALCYF
В автоматизации условие «пропустить дальше» задано при сборке сценария. В ИИ-конвейере за словом «сомнительный» должно стоять записанное правило. В статье таблица по пяти механизмам и три вопроса подрядчику до подписания.
У шага «пропустить дальше» всегда есть автор решения. Если вы заказываете автоматизацию или ИИ-конвейер, этого автора стоит знать до запуска: однажды его правило пропустит платёж или удаление сотрудника. В сценарии автоматизации правило записано при сборке, и его можно открыть. ИИ-конвейер, который строим мы, сомнительный документ отдаёт человеку. По какому правилу документ попал к проверяющему, просите записать словами — и нас, и любого другого подрядчика. Дальше покажу, как это сделано в «+Альянс Потоке» и у трёх чужих инструментов, и дам три вопроса, с которыми я бы шёл к подрядчику до договора.
Коротко
- В продукте «+Альянс Поток» решение продолжить сценарий опирается на заранее названное состояние: успешное завершение задачи или ответ согласующего.
- Список согласующих и правило кворума стоят в узле «Согласование» до запуска сценария.
- ИИ-конвейер в нашей услуге сомнительные случаи молча не проводит: они уходят человеку. На тесте с реальными данными мы настраиваем точки контроля человеком.
- В Claude Code и в OpenAI Responses API человек подтверждает действие по правилу, заданному заранее: его пишет разработчик или задаёт порогом вендор.
- До договора на ИИ-конвейер спросите три вещи: правило эскалации, кто им управляет и что пишется в журнал о документе, ушедшем к человеку. Нам эти вопросы задавайте тоже.
Что такое гейтинг и на каких шагах его ставят
Гейтинг — это шаг сценария, который держит процесс на месте, пока не выполнено условие. Слово нерусское, но короче я не подобрал.
Необратимое действие — то, у которого нет кнопки «назад»: удаление сотрудника из организации, платёж, запись документа в учётную систему без проверки. Гейт ставят перед такими шагами.
В сценарии автоматизации условие названо до запуска
В «+Альянс Потоке» гейтом перед удалением сотрудника служит узел резервного копирования. Ставит его автор сценария, и тогда удаление выполняется только после успешного завершения копирования. Это одна из гарантий надёжности продукта. Исхода два: копирование прошло успешно или нет. Условие оценивает статус задачи, а сами статусы названы до запуска. Для вас это значит простую вещь: пока такой узел в сценарии есть, без готовой копии до удаления дело не дойдёт. В готовом шаблоне «Увольнение сотрудника» он стоит. Сценарий, который собирают под вас, проверьте сами: откройте его и найдите этот узел перед удалением.
Входящий вебхук «+Альянс Потока» сценарий запускает, а не пропускает дальше: его легко спутать с гейтом. Ответ на вебхук означает, что сценарий запущен, и только это. Завершение — отдельное состояние: у сценария есть статусы завершения, среди них ошибка и успешная отработка.
Человек в таком сценарии стоит в списке, а не в догадке
В «+Альянс Потоке» человеческое решение ставят узлом «Согласование». Согласующий получает персональную ссылку: по почте, личным сообщением от бота в Яндекс Мессенджере или обоими путями сразу. По ссылке он утверждает или отклоняет. Пока решения нет, поток стоит.
Как считать голоса, выбирают в поле «КВОРУМ». При кворуме «Нужны все» любой отказ сразу уводит поток по ветке «Отклонено». При «Достаточно любого» первое одобрение ведёт поток по ветке «Согласовано», а в «Отклонено» он уходит, только если отказали все. Новых согласующих вносят кнопкой «+ Добавить согласующего». Всё это — список, кворум, канал — выбрано при сборке сценария.
У одного из наших заказчиков на «+Альянс Потоке» работает сценарий согласования документов в связке 1С — Яндекс 360. Назвать себя заказчик не готов.
Тот же тип ожидания у чужого движка
У движка автоматизации n8n ожиданием занимается Wait-нода. Она возобновляет воркфлоу по одному из четырёх событий: After Time Interval, At Specified Time, On Webhook Call, On Form Submitted. По-русски — через интервал, в назначенное время, по вызову вебхука, после отправки формы. Для режимов с вебхуком и формой есть опция Limit Wait Time: воркфлоу продолжится по истечении времени или к заданному моменту, даже если нужное событие не произошло. Каждый режим — заранее выбранное событие, и выбирает его автор воркфлоу.
Что меняется, когда входящий поток разбирает ИИ
У компании «+Альянс» есть услуга другого рода — создание ИИ-конвейеров обработки данных. Такой конвейер мы строим под входящий поток писем, счетов, накладных и заявок. ИИ достаёт из них данные и передаёт в 1С, CRM или Яндекс 360 — без ручного ввода. Цепочка такая: источник → распознавание и извлечение данных ИИ → проверка → запись в целевую систему. Сомнительный случай конвейер не проводит молча: отдаёт на проверку человеку.
В ИИ-конвейере из нашей услуги условие выглядит по-другому. В сценарии автоматизации им был статус задачи или ответ человека из списка. В конвейере условие — слово «сомнительный». За этим словом должно стоять правило: порог уверенности модели, проверка конкретного поля или что-то третье. Попросите подрядчика назвать его прямо.
Точки контроля человеком мы настраиваем на тесте ИИ-конвейера: прогоняем его на историческом потоке и сверяем результат с ручной обработкой. Тогда же я бы записывал словами правило сомнительного случая — и сразу смотрел, как оно срабатывает.
После запуска мы оставляем журнал выполнения конвейера: видно, какой документ когда обработан и куда записан.
Сценарии в Яндекс 360 в услуге создания ИИ-конвейеров мы строим на своём продукте — «+Альянс Потоке». Смежная тема — почему сценарий не разбирает счёт из письма.
У соседней услуги, разработки ИИ-ассистентов, своя развилка с человеком: сложные и нестандартные вопросы уходят живому сотруднику, а не в тупик. Спросить стоит то же, что и про конвейер: по какому признаку вопрос признан сложным.
Как подтверждение человеком устроено у вендоров ИИ-инструментов
В auto-режиме Claude Code действия вместо пользователя проверяет вторая модель, классификатор. Но порядок фиксированный. Сначала срабатывают явные правила разработчика: allow, ask и deny. Затем автоматически одобряются действия только на чтение и правки файлов в рабочей папке. Классификатору достаётся остальное. Если он блокирует действие три раза подряд или двадцать раз за сессию, auto-режим встаёт на паузу, и инструмент снова спрашивает пользователя. Эти пороги не настраиваются.
Для делового читателя важна одна деталь. Границы, которые пользователь назвал в переписке, классификатор учитывает, но правилом они не становятся. Документация Claude Code советует прямо: для твёрдой гарантии добавьте запрещающее правило («For a hard guarantee, add a deny rule instead»).
В OpenAI Responses API подтверждение перед вызовом внешнего инструмента задаёт параметр require_approval. Значение "always" требует одобрения перед каждым вызовом инструмента, "never" одобрение пропускает, и есть вариант со списком конкретных имён инструментов. Какое из них стоит, решает разработчик при настройке.
Вывод мой. Ни в Claude Code, ни в OpenAI Responses API подтверждение человеком не устроено как самооценка модели, которую пользователю показывают числом. В обоих инструментах это правило, заданное заранее. О других ИИ-инструментах я здесь не сужу.
Кто задаёт условие и что из этого видит заказчик
| Механизм | Что служит условием | Кто задал условие |
|---|---|---|
| Узел «Согласование» в «+Альянс Потоке» | ответ согласующего по персональной ссылке и правило кворума | выбрано при сборке сценария, до первого запуска |
| Wait-нода n8n | одно из четырёх событий возобновления | автор воркфлоу |
| auto-режим Claude Code | правила allow / ask / deny, затем вердикт классификатора; счётчик 3 подряд или 20 за сессию возвращает решение человеку | разработчик правил; пороги счётчика заданы вендором и не настраиваются |
| Подтверждение вызова инструмента в OpenAI Responses API | значение параметра require_approval |
разработчик при настройке |
| ИИ-конвейер обработки данных в услуге «+Альянса» | «сомнительность» случая | точки контроля человеком настраиваем на тесте; правило попросите записать словами |
Слева — сценарий автоматизации: вход, гейт по заранее названному состоянию, два исхода и плашка «Условие задал человек — и оно записано». Справа — ИИ-конвейер обработки данных из нашей услуги: вход «источник», цепочка из трёх звеньев и строка о сомнительных случаях, которые конвейер отдаёт человеку. Внизу — Wait-нода n8n и правила Claude Code и OpenAI Responses API.
В четырёх строках из пяти на вопрос «кто задал условие» отвечают коротко: тот, кто настраивал сценарий или инструмент, а у счётчика Claude Code — вендор. Пятая строка — про нашу услугу, и подрядчик в ней — мы. Заполнять её вам предстоит вместе с нами, и лучше до договора. Ради этой строки я и сел писать статью.
Чем компания платит за смену роли
На мой взгляд, когда решение принимает заранее написанное условие, у ответственности есть фамилия. Разбирать потом нечего — открываешь сценарий и видишь правило, которое сработало.
Я представляю это так: когда развилку определяет конвейер по ходу обработки, а правило нигде не записано, человеку приносят не вопрос «утвердить или отклонить», а документ с пометкой «разберитесь». Почему приехал именно этот документ, человек не знает.
Сколько таких документов будет у вас, покажет только ваш поток. Считайте их долю на пилоте с первого дня: от неё зависит, сколько рабочего времени уйдёт на проверку.
Обещание отдать сомнительное человеку описывает поведение конвейера. Спорить с его решением заказчик сможет, только когда правило записано, — отсюда и мои три вопроса.
Три вопроса подрядчику ИИ-конвейера
Вопросы мои. Задавать их стоит любому подрядчику до подписания.
- По какому правилу конвейер признаёт документ сомнительным и кто это правило записал? Ответ «модель сама понимает» не годится: просите проверку, названную словами.
- Вижу ли я это правило и могу ли изменить его сам после сдачи проекта? Если менять будет подрядчик — пусть срок стоит в договоре.
- Что попадает в журнал по документу, который ушёл к человеку, и что происходит, если никто не отреагировал?
Контраргумент против меня самого: правило на бумаге надо проверить на своих документах. Поэтому начинать я советую с малого — с пилотного конвейера на одном типе документов. Первый шаг за вами: выбрать этот тип и прийти к подрядчику с тремя вопросами из списка.
Частые вопросы
Гейтинг в сценарии автоматизации и проверка человеком в ИИ-конвейере — это про одно?
Про разные механизмы. Гейтинг держит поток до заранее названного состояния: пока задача не завершилась успешно, пока согласующий не ответил. Проверка человеком в ИИ-конвейере нашей услуги работает иначе: сомнительные случаи конвейер отдаёт человеку. Поэтому к конвейеру есть вопрос, которого к гейту нет: по какому правилу случай попал в сомнительные.
Значит, ИИ-конвейер нельзя ставить на необратимые действия?
Так я не говорю. Моя позиция: чем дороже ошибка на шаге, тем подробнее должно быть написано правило эскалации — до внедрения, а не после первого разбора.
Что говорит документация ИИ-вендоров про подтверждение человеком?
Claude Code в auto-режиме работает с классификатором: впереди явные правила разработчика, сзади ненастраиваемый счётчик блокировок, возвращающий решение человеку. В OpenAI Responses API одобрение включают параметром require_approval со значениями "always", "never" или списком инструментов. Оба факта — про инструменты вендоров, на услугу создания ИИ-конвейеров я их не переношу.
Есть ли в «+Альянс Потоке» защита от повторного запуска одного и того же сценария?
Ключа дедупликации в продукте нет: два запроса по одному сотруднику «+Альянс Поток» считает двумя независимыми запусками сценария. Поэтому настройте систему-источник так, чтобы запрос по сотруднику уходил один раз.
«+Альянс Поток» есть в реестре российского ПО?
Продукт «+Альянс Поток» в реестр российского ПО не внесён. Услуги направления «Внедрение ИИ» — это услуги, а не программное обеспечение, реестр к ним не применяется.
Александр Жогов, основатель компании «+Альянс».
