Если ИИ-агент начал связывать обращения не с теми карточками, отправлять неверные сообщения или выполнять необъяснимые действия, недостаточно просто «выключить ИИ». Команде нужно запретить опасные операции, продолжить принимать входящие задачи и выяснить, какие действия уже успели выполнить внешние системы.
Аварийный режим стоит проектировать до запуска агента. Тогда сотрудник знает, что именно остановить, где найти новые обращения и кто разрешит вернуть автоматические действия.
Здесь ИИ-агент — система, которая выбирает следующее действие и может обращаться к разрешённым инструментам. Чат-бот обозначает диалоговый интерфейс, а обычная интеграция выполняет заранее заданную последовательность. Аварийный режим нужен именно для тех полномочий и внешних действий, которые получил агент.
Что означает аварийный режим ИИ-агента
Аварийный режим — заранее описанное состояние рабочего процесса, а не универсальная кнопка платформы. В этом состоянии команда ограничивает действия агента, но сохраняет управляемый путь для входящих задач и ручной работы.
Сначала разделите части процесса:
- приём события из формы, почты или другого канала;
- обработку данных моделью;
- вызов разрешённого инструмента;
- изменение записи во внешней системе;
- отправку сообщения;
- фоновую или отложенную операцию.
Для каждого действия составьте карту. Критичность определяет владелец конкретного процесса — универсальной шкалы здесь нет.
| Действие | Возможное последствие | Точка запрета | Состояние текущей операции | Ответственный |
|---|---|---|---|---|
| Прочитать карточку | Агент получит сведения | Ограничение доступа на чтение | Не начата, выполняется или завершена | Владелец доступа |
| Изменить карточку | Данные в CRM изменятся | Право записи или вызов инструмента | Результат подтверждён, отсутствует или неизвестен | Владелец процесса |
| Отправить ответ | Получатель увидит сообщение | Инструмент отправки | Отправлено, не отправлено или требует сверки | Ответственный за коммуникацию |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Такая карта показывает, почему остановка модели и остановка внешнего действия — не одно и то же.
Как выбрать границу остановки
Границу выбирают по фактическим полномочиям агента и обратимости операций. Возможны четыре проектных варианта:
- запретить одно изменяющее действие, например запись в CRM;
- перевести выбранные инструменты на подтверждение человеком;
- отключить все внешние действия агента, сохранив приём обращений;
- остановить весь контур, если последствия нельзя изолировать.
Это варианты архитектуры, а не функции, которые обязательно есть в любой платформе.
В документации n8n описана проверка человеком перед вызовом выбранного инструмента. Workflow приостанавливается и ждёт решения; при отказе ожидающий вызов отменяется и не выполняется. Этот механизм относится к инструментам, подключённым к human review. Он не доказывает возможность аварийно остановить уже начатую внешнюю операцию, другие workflow или ожидающие запуски.
Поэтому предварительное подтверждение полезно для постоянного контроля рискованных действий, но не заменяет полный аварийный режим.
Как принимать входящие задачи во время остановки
Отделите приём и сохранение события от агентной обработки. Если один выключатель прекращает и опасные действия, и поступление обращений, команда может устранить одну проблему и одновременно потерять новые задачи.
Для будущего решения определите, где хранить:
- устойчивый идентификатор события;
- исходные данные и время поступления;
- статус обработки;
- известные результаты действий;
- подтверждения внешних систем;
- причину аварийного режима;
- назначенного сотрудника.
Возможная модель статусов: «ожидает ручной обработки», «в работе», «требует сверки», «закрыто». Её нужно адаптировать к реальному процессу.
Наличие очереди, журнала, защиты от дублей и сохранение каждого события нельзя предполагать по умолчанию. Поведение формы, почты, мессенджера и других каналов проектируют и испытывают отдельно.
Как передать работу сотруднику
Сотруднику нужна не общая тревога, а рабочая карточка задачи. Передайте ему:
- исходный запрос;
- проверенные сведения;
- подготовленный черновик, если он есть;
- уже выполненные действия;
- операции с неизвестным результатом;
- допустимые следующие шаги;
- ссылку на рабочую запись.
В опубликованном примере n8n workflow отправляет сообщение в Slack человеку, когда ИИ не может ответить. Это подтверждает пример маршрута к человеку, но не аварийную остановку, сохранение входящей очереди или работу такого маршрута в конкретной системе.
В проекте запрет опасного действия не должен зависеть от успешной доставки уведомления. Если канал передачи сотруднику недоступен, задача должна остаться в предусмотренном месте хранения и получить понятного ответственного. Такое поведение требуется реализовать и проверить для выбранных каналов.
Что делать с уже начатыми операциями
После переключения разделите операции на три группы:
| Состояние | Что известно | Следующее действие |
|---|---|---|
| Подтверждённо завершена | Целевая система вернула проверяемый результат | Признать результат и не повторять действие вслепую |
| Подтверждённо не выполнена | Есть достоверное подтверждение отсутствия результата | Решить, допустим ли безопасный повтор |
| Результат неизвестен | Запрос мог попасть во внешнюю систему, но подтверждения нет | Сверить операцию до повтора или отмены |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Запрет новых вызовов не отменяет запрос, который внешняя система уже приняла. Для неопределённого результата сотрудник сверяет идентификатор операции, доступный журнал и состояние целевой системы.
После сверки он фиксирует одно решение: признать результат, безопасно повторить действие, выполнить доступную отмену или передать случай на отдельный разбор. Универсального отката нет: возможность отмены зависит от инструмента, стадии операции и внешней системы.
Кто вводит аварийный режим и кто возвращает автоматизацию
Заранее распределите роли по полномочиям:
- сотрудник обнаруживает наблюдаемое отклонение;
- владелец процесса принимает бизнес-решение об остановке;
- технический ответственный выполняет переключение;
- назначенная группа обслуживает входящие задачи;
- ответственный за сверку проверяет последствия;
- владелец решения разрешает возобновление.
Один человек может совмещать несколько ролей, если это допустимо в организации. Универсального числа согласующих и общего срока реакции нет.
Карточка события должна содержать наблюдаемое поведение, время обнаружения, выбранную границу остановки, затронутые действия, состояние входящих задач, ответственных и основание для возврата автоматизации.
Какие функции платформы не заменяют аварийный режим
Важно разделять три механизма:
| Механизм | Что решает | Чего сам по себе не доказывает |
|---|---|---|
| Human review перед инструментом | Задерживает выбранный вызов до решения человека | Остановку уже начатой операции и всего агентного контура |
| Маршрут запроса к человеку | Передаёт вопрос или задачу сотруднику | Сохранность входящих событий и запрет опасных действий |
| Постоянное ограничение узлов | Ограничивает доступность определённых возможностей | Мгновенную остановку активного выполнения и отмену внешнего действия |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для self-hosted n8n документация описывает переменную NODES_EXCLUDE: она запрещает пользователям доступ к перечисленным узлам и не загружает их. Этот фрагмент документации не подтверждает мгновенную остановку активного выполнения, отмену принятого внешней системой действия или сохранение ожидающих запусков и входящих данных. Поэтому NODES_EXCLUDE нельзя представлять как готовую команду аварийного отключения.
Для конкретного проекта способ переключения, порядок изменения конфигурации и судьбу активных операций устанавливают по документации используемой версии и проверяют в контролируемой среде.
Как проверить проектируемый режим и возобновить работу
Проверяйте не название выключателя, а поведение всего процесса. Для каждой ситуации сохраните вход, ожидаемое состояние, фактический результат, доступные следы и решение ответственного.
| Проверочная ситуация | Что должно быть определено до проверки |
|---|---|
| Новое опасное действие после переключения | Где оно блокируется и какой след остаётся |
| Операция началась до переключения | Как установить её фактический результат |
| Пришло новое входящее событие | Где оно сохраняется и кто его увидит |
| Канал передачи человеку недоступен | Где остаётся задача и кто отвечает за неё |
| Событие поступило повторно | По какому признаку обнаруживается повтор |
| Результат внешней операции неизвестен | Как проходит сверка до следующего действия |
| Исправление готово к проверке | Как выполнить контролируемый запуск без необратимого действия |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Возвращайте автоматизацию, когда команда установила причину отклонения, проверила изменение, подтвердила запрет нежелательного действия, получила доступ ко всем сохранённым задачам и исключила слепые повторы. Ручной маршрут при этом должен оставаться доступным.
Если архитектура позволяет, сначала проверьте контур без необратимых внешних действий. Затем возвращайте разрешения поэтапно и сохраняйте возможность снова перейти в ручной режим.
Учебный пример: обращения с сайта и запись в CRM
Ниже — синтетический проектный пример. Это не клиентский кейс Switch On AI и не результат выполненного теста.
ИИ-агент разбирает обращения с сайта, создаёт карточки в CRM и готовит ответы. Сотрудник замечает, что новые обращения связываются с неверными карточками.
По заранее спроектированному сценарию команда запрещает новые операции записи, а приём обращений переводит на независимый маршрут хранения. Каждое событие получает устойчивый идентификатор. Сотрудник видит исходное обращение, время поступления, известные результаты действий и причину переключения.
| Событие | Известный результат | Статус | Решение сотрудника |
|---|---|---|---|
| Обращение A-101 | CRM подтвердила запись не в ту карточку | Требует сверки | Исправить связь по правилам процесса |
| Обращение A-102 | Запись не запускалась | Ожидает ручной обработки | Подготовить карточку вручную |
| Обращение A-103 | Запрос отправлен, ответа CRM нет | Результат неизвестен | Найти операцию по идентификатору до повтора |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
После исправления команда проводит контролируемую проверку без внешней записи. Она проверяет, что нежелательное действие запрещено, новые обращения доступны сотруднику, а ручная обработка работает по принятому порядку. Затем назначенный владелец процесса решает, какие автоматические действия возвращать первыми.
Этот пример показывает ожидаемую последовательность проектирования. Он не подтверждает совместимость с конкретной CRM и не обещает сохранность событий без реализации и испытания выбранной архитектуры.
Ограничения и данные для обсуждения проекта
Описанный подход не гарантирует предотвращение всех ошибок, сохранение каждого события, отмену любой операции или мгновенную остановку активного выполнения. Реальный способ переключения зависит от платформы, версии, размещения, прав, архитектуры и подключённых систем.
Для обсуждения проекта подготовьте:
- схему входящих каналов;
- список инструментов и полномочий агента;
- перечень внешних систем;
- права используемых учётных записей;
- способы подтверждения результата операций;
- место хранения входящих задач;
- ответственных за остановку, ручную работу и возврат;
- действующий ручной процесс.
Switch On AI разрабатывает ИИ-агентов под конкретные рабочие операции: от требований и прототипа до проверки, внедрения и передачи кода в согласованном объёме. На первом обсуждении можно разобрать действия агента, точки запрета, входящий и ручной маршруты. Затем готовятся ТЗ и коммерческое предложение; ключевой сценарий можно показать на бесплатном прототипе. Прототип не равен полноценному внедрению, а подключения, состав работ, стоимость, сопровождение и эксплуатационные расходы согласуются отдельно.
Чтобы обсудить свой процесс, опишите задачу и участвующие системы.
Вопросы по этой задаче
Можно ли оставить агенту чтение данных, но запретить отправку сообщений и запись в CRM?
Это возможно как проектное требование, если архитектура разделяет инструменты, права и точки выполнения. Такой режим нужно реализовать и проверить для конкретных подключений; он не возникает автоматически во всех платформах.
Достаточно ли деактивировать workflow?
Нет. Само отключение не определяет судьбу уже начатых запросов, ожидающих запусков, входящих событий и действий, которые приняла внешняя система. Эти состояния проверяют отдельно.
Чем аварийный режим отличается от ручного подтверждения?
Ручное подтверждение задерживает выбранный вызов до выполнения. Аварийный режим вводят после обнаружения проблемы; он также охватывает входящие задачи, ручную работу, операции с неизвестным результатом и условия возврата автоматизации.
Как не потерять обращения во время остановки?
Приём и сохранение события нужно отделить от агентной обработки. Место хранения, идентификаторы, статусы и ручной маршрут проектируют и испытывают для каждого источника; без такой проверки абсолютную сохранность обещать нельзя.
Можно ли повторно запустить все накопившиеся задачи после исправления?
Нет. Сначала отделяют невыполненные операции от завершённых и операций с неизвестным результатом. Повтор допустим после сверки и проверки правила защиты от дублей.