ИИ-агенты для бизнеса: что они делают и когда их внедрять

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

Базовый агентный контур включает три компонента:

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

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

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

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

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

Типовая схема выглядит так:

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

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

Обработка заявок и подготовка предложений

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

Цена, скидка, срок поставки и выбор спорного аналога подтверждаются менеджером.

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

• Регистрирует письмо и вложение.
• Получает текст документа через OCR.
• Извлекает позиции и количество.
• Находит организацию и прошлые обращения в CRM.
• Сопоставляет позиции с каталогом.
• Отмечает неоднозначные соответствия.
• Проверяет комплектность заявки.
• Создаёт черновик карточки.
• Передаёт менеджеру спорные поля и варианты дальнейшего действия.

В опубликованном кейсе AI-системы для B2B-поставщика заявки из почты, мессенджеров, Excel и PDF преобразуются в коммерческое предложение, а менеджер сохраняет проверку, переговоры и финальное решение.

Служба поддержки

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

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

Закупки и тендеры

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

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

Внутренний поиск и выполнение поручений

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

При этом система должна показывать источники, версии документов и дату их актуальности. Иначе сотрудник не сможет отличить подтверждённый факт от вывода модели.

Контроль продаж и коммуникаций

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

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

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

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

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

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

Не стоит начинать с агента, если:

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

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

Подробнее предварительный выбор процессов разобран в статье «Автоматизация бизнес-процессов: что стоит автоматизировать первым».

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

Источники и интеграции

Система получает данные из почты, CRM, ERP, телефонии, хранилища документов и внешних API. На этом уровне выполняются авторизация, проверка формата, обработка ошибок и повторные запросы.

Модель и оркестрация

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

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

Бизнес-правила

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

Инструменты

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

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

Контроль и журналирование

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

Автономность определяется не техническими возможностями модели, а последствиями ошибки.

Особенно важно сохранять ручное подтверждение для:

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

Управление рисками должно охватывать весь жизненный цикл системы: проектирование, тестирование, эксплуатацию, мониторинг и изменение условий применения. NIST AI RMF рассматривает оценку и управление рисками именно как непрерывный процесс, а не как разовую проверку перед запуском.

Ошибочный выбор инструмента

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

Галлюцинации

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

Избыточные права

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

Недостоверные и устаревшие источники

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

Зацикливание и рост расходов

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

Атаки через входящие данные

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

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

Пилот должен проверять изменение бизнес-процесса, а не способность модели провести эффектную демонстрацию.

1. Выбрать ограниченный участок

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

2. Описать текущий процесс

Фиксируются:

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

3. Собрать реальные примеры

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

4. Разделить технологии

Для каждого шага определяется отдельный механизм:

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

5. Установить права и ограничения

До разработки нужно определить:

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

6. Начать с безопасного режима

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

7. Зафиксировать критерии приёмки

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

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

Стоимость определяется не словом «агент», а границами рабочего контура. На оценку влияют:

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

Пилот, промышленное внедрение и регулярную эксплуатацию нужно оценивать отдельно.

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