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

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

Разберём учебный сценарий. Он не описывает действующий процесс Wise Lab или результат клиентского проекта.

Зафиксируйте вход и результат

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

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

До сборки определите, какие запросы поддерживает первая версия. Например: посадочная страница, рекламный креатив, аналитический отчёт. Всё остальное получает статус «нужен разбор». Добавлять новые категории можно по мере появления реальных примеров.

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

Соберите последовательность действий

Рабочая схема может выглядеть так:

1. Принять запрос и присвоить ему постоянный идентификатор.
2. Проверить обязательные поля формы.
3. Передать модели текст задачи и список допустимых категорий.
4. Проверить структуру полученного ответа и значения полей.
5. Сохранить черновик со ссылкой на исходник.
6. Дать координатору принять, исправить или вернуть задачу на уточнение.
7. После принятия создать запись в рабочем трекере.

Выбор проекта лучше брать из поля формы. Допустимые категории проверяются по списку. Ограничение длины и корректность даты проверяются обычной программной логикой. Это оставляет модели понятный участок: извлечь смысл и обозначить пробелы.

Для инструкции модели подойдёт структура маркетингового брифа. Укажите, что неизвестное поле должно остаться пустым, а предположение нельзя записывать как подтверждённое условие.

Посмотрите, что произойдёт на живом языке

Возьмём условный запрос:

«Нужна посадочная под вебинар. Хотим запустить 10 октября 2026 года. Программы пока нет, форму регистрации ещё выбираем. Дизайн можно взять с прошлого мероприятия».

Из него можно подготовить такую карточку:

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

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

Оставьте человеку конкретное решение

Проверка «всё ли хорошо?» слишком расплывчата. Координатор должен увидеть исходный запрос, заполненные поля, пропуски и действие, которое выполнится после принятия карточки.

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

Если процесс собран через AI Agent в n8n, у отдельных подключённых инструментов можно включить подтверждение человеком. Выполнение такого инструмента приостанавливается до одобрения или отказа. Эта настройка относится к выбранным вызовам инструмента; её наличие не означает, что проверяются все действия процесса. Документация n8n о ручном подтверждении.

В нашем примере достаточно утверждения перед созданием рабочей задачи. Права на отправку клиентских сообщений или изменение рекламных кампаний этому процессу вообще не нужны.

Продумайте дубли и сбои

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

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

Разделяйте два случая. Временно недоступен сервис — допустим ограниченный повтор по заданному правилу. В запросе нет даты или программы — повторная генерация не создаст эти сведения. Такой запрос должен попасть на уточнение.

В n8n для сбоев выполнения предусмотрен отдельный процесс обработки ошибок с Error Trigger. Он может, например, уведомить ответственного о неудачном выполнении. Это техническая обработка сбоя; ошибочный смысл в корректно сформированном ответе потребуется обнаруживать вашими проверками. Документация n8n об ошибках.

Учитывайте содержимое входящих запросов

Текст обращения является данными для разбора. В нём могут оказаться посторонние инструкции: например, просьба пропустить проверку или отправить сведения на другой адрес. OWASP описывает такой риск при попадании инструкций во внешние материалы, которые читает модель. Описание prompt injection.

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

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

Проверьте первую версию на небольшой партии

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

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

Сохраните критерии из проверки ответов ИИ, назначьте владельца процесса и начните с ограниченного набора задач. Расширять сценарий стоит после того, как понятно, куда попадает каждый запрос и кто заметит сбой. Другие направления для следующего шага собраны в AI-разделе Wise Tools.