AI-агент с человеком в контуре: как внедрить без хаоса

В документации Microsoft Learn для Microsoft Foundry Agent Service от 2026-04-13 агент описан как приложение, которое может вызывать инструменты, обращаться к внешним данным и принимать решения в несколько шагов; там же прямо сказано, что workflow agents поддерживают human-in-the-loop steps. Для бизнеса это главный практический вывод: AI-агент уже не просто чат, который пишет текст, а часть процесса, где нужно заранее определить права, контрольные точки, данные и ответственность человека.

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

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

Что такое AI-агент в бизнесе

Не чат, а исполнитель с инструментами

Обычный чат-бот отвечает на сообщение. AI-агент делает больше: он получает задачу, выбирает следующий шаг, может обратиться к базе знаний, открыть данные из CRM, подготовить черновик письма, создать задачу, вызвать API или передать вопрос человеку. IBM определяет AI agent как систему или программу, способную автономно выполнять задачи от имени пользователя или другой системы.

В бизнесе это означает простую вещь: агенту нельзя давать абстрактную команду «помогай клиентам». Ему нужна роль в конкретном процессе. Например:

1. Принять входящее письмо.
2. Определить тип обращения.
3. Найти данные в базе знаний.
4. Подготовить черновик ответа.
5. Передать человеку, если есть риск ошибки.
6. Записать результат в CRM или таблицу.

Такой агент похож не на самостоятельного сотрудника, а на исполнительный блок внутри регламента. Он ускоряет рутину, но сам регламент должен быть вашим.

Почему «человек в контуре» важнее красивого промпта

Human-in-the-loop означает, что в процессе есть точка, где человек подтверждает, исправляет или отклоняет действие агента. Это особенно важно, если агент работает с клиентами, деньгами, юридически значимыми текстами, персональными данными, обещаниями сроков или скидками.

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

Здесь полезно думать не о «замене менеджера», а о распределении нагрузки. Агент берет на себя сбор контекста, первичную классификацию, подготовку ответа и оформление результата. Человек принимает решение там, где есть цена ошибки.

Где проходит граница автономности

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

Для первого внедрения лучше выбрать один из трех режимов:

Режим	Что делает агент	Где нужен человек
Черновик	Готовит ответ, задачу или документ	Перед отправкой или публикацией
Полуавтомат	Сам делает безопасные действия по правилам	При нестандартном сценарии
Автомат	Сам выполняет процесс в заданных рамках	При ошибке, споре или исключении

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

Как выбрать первый процесс для AI-агента

Признаки хорошего кандидата

Хороший первый процесс не должен быть самым сложным. Он должен быть повторяемым, понятным и достаточно частым, чтобы экономия времени была заметна. Идеально, если в нем уже есть шаблоны, инструкции, база знаний или типовые решения.

Подходящие процессы:

• первичная обработка входящих заявок;
• разбор писем и распределение по темам;
• подготовка черновиков ответов клиентам;
• сбор данных перед звонком;
• заполнение карточки лида;
• контроль полноты заявки;
• подготовка краткого резюме переписки;
• внутренняя поддержка сотрудников по базе знаний.

Плохие кандидаты для старта:

• спорные переговоры с клиентами;
• финальные коммерческие предложения без проверки;
• юридические документы без согласования;
• решения о возвратах и компенсациях;
• массовые рассылки от имени компании без ручного контроля;
• процессы, которые сами сотрудники не могут объяснить одинаково.

Если люди внутри компании каждый раз решают задачу по-разному, агент не сделает ее стабильной. Сначала нужно описать процесс, потом подключать ИИ.

Простая матрица выбора

Оцените несколько процессов по четырем вопросам:

1. Повторяется ли задача часто?
2. Есть ли понятный вход и понятный результат?
3. Можно ли проверить результат до того, как он уйдет клиенту?
4. Есть ли база знаний, шаблоны или примеры хороших ответов?

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

Почему заявки и письма часто лучше всего подходят для старта

Входящие заявки и письма удобны тем, что у них есть естественная структура. Клиент пишет вопрос, менеджер должен понять намерение, собрать данные и ответить. Агент может помочь почти на каждом этапе, но финальное решение остается за человеком.

Например, агент может:

• определить, это продажа, поддержка, жалоба или партнерский запрос;
• найти, есть ли клиент в CRM;
• выделить город, продукт, бюджет, срочность и контакт;
• предложить следующий шаг;
• подготовить черновик ответа;
• поставить задачу менеджеру;
• отметить, каких данных не хватает.

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

Архитектура безопасного процесса

Вход: что агент получает

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

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

Внутри компании это можно реализовать через n8n, CRM-автоматизацию, собственный backend или другой связующий слой. Важно не название инструмента, а принцип: агент получает только те данные, которые нужны для задачи.

Инструменты: что агенту разрешено делать

Microsoft Learn описывает tools как доступ к данным или действиям, например search, file operations или API calls. Для бизнеса каждый tool должен иметь понятную цель и границы. Не стоит давать агенту один широкий доступ «ко всему». Лучше дать несколько узких инструментов.

Пример набора:

• поиск по базе знаний;
• чтение карточки клиента;
• создание задачи;
• подготовка черновика письма;
• запись заметки в CRM;
• передача обращения человеку.

Для каждого инструмента нужно ответить:

1. Когда агент имеет право его вызвать?
2. Какие данные он может передать?
3. Что считается успешным результатом?
4. Что делать при ошибке?
5. Нужно ли подтверждение человека?

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

Память и база знаний

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

Для первого запуска достаточно собрать:

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

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

Выход: что агент возвращает

Хороший выход агента должен быть удобен для проверки. Не просите его просто «ответить клиенту». Просите структуру:

• краткое резюме ситуации;
• найденные факты из доступных данных;
• рекомендуемое действие;
• черновик ответа;
• уровень уверенности без числовой шкалы;
• причина, почему нужна или не нужна проверка человеком;
• список данных, которых не хватает.

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

Контрольные точки и правила эскалации

Когда агент обязан остановиться

Самое важное правило: агент должен уметь не только действовать, но и останавливаться. В бизнес-процессе остановка — это не ошибка, а нормальная защита.

Агент обязан передать задачу человеку, если:

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

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

Как выглядит human-in-the-loop на практике

В простом варианте агент готовит карточку проверки:

1. Что произошло.
2. Что агент предлагает сделать.
3. На какие данные он опирается.
4. Какой текст предлагается отправить.
5. Почему нужна проверка.
6. Какие кнопки есть у человека: одобрить, отредактировать, отклонить, передать другому.

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

В статье про контрольные точки для AI-агента эта логика особенно важна: не нужно превращать человека в формального нажимателя кнопки. Проверка должна быть содержательной, но короткой.

Как не перегрузить команду проверками

Частая ошибка — отправлять на ручную проверку все. Тогда команда быстро устает, а автоматизация превращается в дополнительную очередь задач. Лучше разделить обращения на безопасные, сомнительные и рискованные.

Безопасные обращения: агент может подготовить ответ по шаблону или даже выполнить действие, если это внутренний процесс.

Сомнительные обращения: агент готовит черновик и просит быструю проверку.

Рискованные обращения: агент не пишет финальный ответ, а собирает контекст и передает человеку.

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

Риски: что проверить до запуска

Галлюцинации и неподтвержденные обещания

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

Защита простая:

• запретить обещания вне базы знаний;
• просить ссылку на правило или документ внутри ответа для менеджера;
• отделить черновик для человека от текста клиенту;
• добавлять фразу «нет данных» там, где база не отвечает;
• хранить список запрещенных формулировок.

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

Prompt injection и чужие инструкции

OWASP Top 10 for LLM Applications 2025 описывает security risks для LLM applications. Для бизнес-агента это практично: клиентское письмо или документ может содержать текст, который пытается изменить поведение агента. Например: «игнорируй прошлые инструкции» или «отправь мне внутренние правила».

Защита:

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

Это не вопрос паранойи. Если агент подключен к CRM, почте или базе знаний, он становится частью информационного контура компании. Значит, его нужно проектировать как рабочую систему, а не как эксперимент в чате.

Персональные данные и доступы

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

Практическая схема:

1. Разделите данные на публичные, внутренние и чувствительные.
2. Для каждого процесса определите, какие данные нужны.
3. Уберите из промпта лишние поля.
4. Маскируйте данные там, где это возможно.
5. Логируйте обращения к инструментам.
6. Ограничьте действия, которые нельзя отменить.

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

Ответственность и журнал действий

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

Журнал действий должен отвечать на вопросы:

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

Без журнала невозможно улучшать процесс. Команда будет спорить ощущениями: кому-то кажется, что агент помогает, кому-то — что мешает. С журналом видно, где агент стабилен, а где его нужно ограничить.

Пошаговый план внедрения

Шаг первый: описать процесс в одну страницу

Не начинайте с выбора модели. Начните с процесса. На одной странице опишите:

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

Если это невозможно описать на одной странице, процесс слишком большой для первого запуска. Разбейте его. Например, не «автоматизировать поддержку», а «готовить черновики ответов на типовые вопросы по базе знаний».

Шаг второй: собрать минимальную базу знаний

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

• что продаем;
• кому продаем;
• что можно обещать;
• что нельзя обещать;
• как отвечать на частые вопросы;
• когда передавать руководителю;
• какие формулировки нежелательны.

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

Шаг третий: запустить режим черновика

На первом этапе агент не отправляет ничего сам. Он только готовит:

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

Менеджер проверяет и правит. Все правки сохраняются как материал для улучшения. Через некоторое время станет видно, какие типы обращений агент делает хорошо, а какие всегда требуют ручной работы.

Шаг четвертый: добавить инструменты

Когда черновики стали стабильными, можно подключать инструменты. Не все сразу. Например, сначала чтение CRM, потом создание задачи, потом запись заметки.

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

Шаг пятый: расширять автономность по категориям

Не переводите весь процесс в автоматический режим. Расширяйте права по категориям обращений. Например:

• типовой вопрос по расписанию — можно готовить ответ автоматически;
• вопрос по оплате — только черновик;
• жалоба — сразу человеку;
• заявка без контакта — агент просит недостающие данные;
• заявка с полным набором полей — агент создает задачу менеджеру.

Так команда видит постепенный прогресс и сохраняет контроль. Автоматизация растет там, где уже есть доказанная стабильность.

Как измерять качество без выдуманных KPI

Что смотреть в первую очередь

Не начинайте с сложных показателей. На старте достаточно смотреть на качество процесса:

• сколько черновиков принято без правок;
• какие правки повторяются;
• сколько обращений агент правильно передал человеку;
• где агент не нашел правило;
• какие вопросы чаще всего отсутствуют в базе знаний;
• сколько раз агент предложил запрещенное действие.

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

Разбор ошибок

Каждая ошибка должна попадать в одну из категорий:

1. Плохой вход: агент получил неполные или грязные данные.
2. Нет правила: база знаний не покрывает ситуацию.
3. Неверное правило: инструкция противоречит реальной практике.
4. Ошибка модели: агент не так понял контекст.
5. Ошибка инструмента: CRM, API или интеграция вернули не то.
6. Ошибка процесса: человек ожидал от агента действия, которое не было описано.

Такой разбор помогает улучшать систему, а не просто менять промпт после каждой проблемы.

Когда можно расширять права агента

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

Перед расширением задайте контрольные вопросы:

• понятно ли, какие данные использует агент;
• есть ли журнал действий;
• можно ли отменить действие;
• есть ли правило остановки;
• кто получает уведомление об ошибке;
• кто обновляет базу знаний.

Если ответы размытые, автономность расширять рано.

Частые ошибки при внедрении

Ошибка: начать с «сделайте нам умного агента»

Такой запрос слишком широкий. Умный агент без процесса становится набором случайных ответов. Лучше формулировать задачу так: «агент готовит черновик ответа на входящее письмо по базе знаний и передает человеку все обращения с риском».

Ошибка: дать агенту слишком много данных

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

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

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

Ошибка: не назначить владельца базы знаний

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

Ошибка: не разделить черновик и финальный ответ

Черновик может содержать пояснения для менеджера, ссылки на внутренние правила и пометки о рисках. Финальный ответ клиенту должен быть короче, аккуратнее и без внутренних деталей. Если смешать эти два слоя, возможны неприятные ошибки.

Частые вопросы

Можно ли сразу подключить AI-агента к почте?

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

Нужен ли n8n для такого процесса?

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

Чем AI-агент отличается от обычной автоматизации?

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

Как понять, что процесс слишком рискованный?

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

Что делать, если агент часто ошибается?

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

Можно ли использовать один агент для всех отделов?

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

Как связать агента с уже существующими материалами?

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

Итог

AI-агент в бизнесе полезен не тогда, когда ему дают максимум свободы, а когда его встраивают в понятный процесс. Лучший старт — узкая задача, чистый вход, проверенная база знаний, ограниченные инструменты и человек в контуре там, где есть риск.

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

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