Разработка AI-агента для автоматизации бизнес-процессов

Разработка AI-агента: почему прототип не доходит до работы

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

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

Качество ответов агента определяется тем, что он видит на входе. Без фильтрации по правам он либо отвечает «нет данных», либо показывает лишнее; без дедупликации справочника выбирает неактуальную запись; без сохранения контекста теряет нить на третьем уточнении. Без журнала вызовов решение невозможно разобрать постфактум: непонятно, из какой системы пришла запись и почему агент выбрал именно её. Ни одна из этих поломок не видна в демо — они проявляются только на живом потоке заявок.

Разбираем, где именно рвётся связка при разработке AI-агента и что меняется в архитектуре, чтобы пилот дошёл до эксплуатации, а не остался красивым прототипом.

Что меняется в процессах после внедрения агента

Эффект от агента проверяется не на демо, а в операционных показателях отдела. До запуска фиксируем базовые значения по пяти метрикам, после — сравниваем: расхождение и есть результат внедрения. Агент работает поверх моделей YandexGPT, поэтому разбор русскоязычных писем и заявок идёт без выгрузки данных за контур компании.

• Доля автоматизированных операций — типовые сценарии (сверка реквизитов, разбор входящего письма, подготовка выгрузки по регламенту) агент закрывает целиком, без оператора. На ограниченном контуре это обычно 60–75% объёма, остаток приходит человеку уже с собранным контекстом.
• Время обработки обращения — классификация и первичный ответ занимают секунды вместо часов ожидания в очереди; ночные и выходные заявки больше не копятся до утра.
• Ошибки ввода данных — агент переносит данные из документа в учётную систему напрямую, без ручной перепечатки, и уходит целый класс дефектов: опечатки в реквизитах и суммы, попавшие не в то поле.
• Пропускная способность отдела — растёт без расширения штата: тот же состав закрывает больше обращений в пиковые дни, а очередь разбирается внутри смены.
• Адаптация новых сотрудников — агент подсказывает следующий шаг по регламенту и подтягивает нужную карточку клиента, поэтому новичок выходит на норму за недели, а не за месяцы.
• Стоимость процесса — падает не за счёт сокращения людей, а за счёт того, что рутина перестаёт требовать ручных часов: расходы на хранение и сопровождение контура не растут вместе с объёмом.

Важная оговорка: метрики снимаем на одном и том же наборе обращений, иначе сравнение ничего не доказывает.

Варианты исполнения агента и их ограничения

Варианты реализации агента различаются не «умом» модели, а тем, к каким системам он подключён и кто отвечает за его поведение. Готовый конструктор агентов даёт быстрый старт, заказной контур — полный контроль над логикой и данными. Выбор сводится к числу интеграций и требуемой автономности.

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

Этапы инженерной работы: от аудита до передачи

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

1. Аудит процессов и данных. Проходим по каждому сценарию обработки, отмечаем источники, частоту обращений и типовые ветвления. На выходе — карта процесса с узкими местами, где ручная работа съедает больше всего времени.
2. Схема интеграции. Определяем, к каким системам агент обращается на чтение и на запись, как передаются данные, что происходит при недоступности внешнего сервиса. Схема интеграции согласуется до начала сборки — правки на этом шаге дешевле, чем переделка логики.
3. Настройка прав и доступов. Агент получает минимально необходимый набор прав, действия с изменением данных проходят через подтверждение, все обращения пишутся в журнал. Это позволяет разграничить, что агент делает сам, а что только предлагает.
4. Сборка сценариев. Собираем логику по шагам: разбор входящего запроса, выбор источника данных, формирование ответа, обработка отказов. Каждый сценарий заканчивается понятным результатом — карточкой, письмом или записью в системе.
5. Проверка на исторических данных. Прогоняем агента на накопленных обращениях и сравниваем ответы с тем, что делали сотрудники. Разбираем расхождения: часть закрываем доработкой сценария, часть — уточнением правил.
6. Опытная работа. Запускаем на ограниченном потоке параллельно с текущим процессом, сверяем результат и держим ручной контроль на спорных случаях. Так сбой в одном сценарии не затрагивает весь объём обращений.
7. Передача решения заказчику. Передаём настроенную систему, документацию по сценариям и журналам, обучаем команду вносить правки и разбирать инциденты. После этого сопровождение идёт силами заказчика или с нашей поддержкой.

Документация, схемы и регламенты сопровождения

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

• Документация на агента — схема потоков данных: какие системы отдают данные, где агент берёт базу знаний, куда пишет результат, какие внешние вызовы могут не ответить и как обрабатывается отказ.
• Описание сценариев и промптов — по каждому типу обращения: что запускает агента, какие шаги он проходит, где заканчиваются его полномочия и по какому условию диалог уходит на оператора.
• Матрица доступа — перечень учётных записей и прав агента в каждой системе, явные запреты, владелец доступа и порядок его отзыва при смене сотрудника.
• Набор тестовых сценариев — размеченные обращения с эталонными ответами: прогон перед каждым обновлением показывает, что новая версия не сломала ранее работавшие ветки.
• Инструкция для поддержки — что делать при типовых сбоях: молчание внешней системы, пустой или нерелевантный ответ, неверная маршрутизация, ручной перевод диалога на человека.
• Регламент сопровождения — периодичность проверок качества, порядок правки промпта, правила отката на предыдущую версию, ответственные и срок реакции на обращение.
• Журнал изменений — версия, суть правки, причина и на каких тестах она проверялась.

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

Кейс: как агент разгрузил обработку входящих заявок

Где процесс упирался

Служба обработки обращений работала на пределе: в пиковые дни в очереди висело до 400 неразобранных заявок, а первый ответ клиент получал через 6–9 часов. Больше половины запросов были типовыми — статус заявки, продление доступа, комплект закрывающих документов. Оператор вручную собирал данные из трёх систем, переносил их в ответ и всё равно возвращал на доработку каждое пятое обращение: в тексте не хватало контекста, и клиент писал повторно.

Что именно сделали

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

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

Метрики после трёх месяцев

Доля автоматических закрытий заявок вышла на 43% от всего входящего потока. Время первого ответа сократилось с 6–9 часов до 4 минут в рабочие часы и до 15 минут ночью. Доля возвратов на доработку упала с 21% до 6% — в основном за счёт того, что оператор получает обращение уже с собранным контекстом. Нагрузка на смену снизилась примерно на треть, и те же люди стали разбирать спорные случаи вместо копирования данных между окнами.

Что делать, если прототип агента уже собран на платформе

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

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

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

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

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

Частые технические сомнения перед стартом проекта

Сомнения на входе почти всегда одни и те же — снимаем их архитектурой, а не обещаниями.

Какие права получает агент?

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

Как проверить качество ответов?

До запуска собираем эталонные сценарии с ожидаемым результатом и прогоняем их при каждой правке инструкций или смене модели. Ответ без опоры на документ агент не отдаёт — при нехватке контекста диалог уходит оператору.

Не привяжемся ли к одному поставщику модели?

Логика сценария отделена от слоя вызова: модели подключаются сменными модулями с единым интерфейсом. Замена поставщика — правка конфигурации и повторный прогон эталонного набора, а инструкции и база знаний остаются вашими.

Кто отвечает за результат после передачи?

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

Что подготовить, чтобы мы вернулись с оценкой и планом

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

• Границы процесса: с какого события он начинается, каким результатом завершается и кто в нём участвует.
• Системы-источники данных и способ доступа к ним — программный интерфейс, выгрузка файлом, база, доступ только на чтение.
• Примеры реальных входных данных: 10–20 обезличенных обращений или документов с ожидаемым результатом — по ним определяется метрика качества.
• Что агент делает сам, а что подтверждает человек: где обязателен оператор, где допустимо автоматическое действие.
• Ограничения: персональные данные, требования к хранению и журналированию, контур развёртывания — своя инфраструктура или облако.
• Объём: сколько обращений в сутки, пиковая нагрузка, число сценариев и типов документов.
• Критерий приёмки: доля корректных ответов, время обработки, доля задач, снятых с оператора.

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