--- md_version: 2 title: "ИИ-агент в бизнес-процессе: что ему делегировать" description: "Как выбрать безопасный участок процесса для ИИ-агента, задать уровни автономности и измерить результат пилота." canonical: "https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/" markdown: "https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/index.md" published: "2026-08-21" author: "TESS Technology" organization: "ООО ТЕСС ТЕХНОЛОДЖИ" language: "ru-RU" category: "Технологии и AI" direction: "technology-ai" tags: ["ИИ-агенты","Бизнес-процессы","Автоматизация","Метрики"] image: "https://tesstech.ru/upload/articles/september-2026/0109_1.webp" related_service: title: "Системная ИИ-трансформация" url: "https://tesstech.ru/services/ai-transformation/" related_articles: - title: "ИИ-агент в CRM: как ограничить доступ до инцидента" url: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/" markdown: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md" - title: "AI-трансформация аналитического отдела: модель пилота" url: "https://tesstech.ru/blog/ai-transformatsiya-analiticheskogo-otdela-kejsy-i-vyvody/" markdown: "https://tesstech.ru/blog/ai-transformatsiya-analiticheskogo-otdela-kejsy-i-vyvody/index.md" - title: "Почему корпоративный ИИ не знает ваш бизнес" url: "https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/" markdown: "https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/index.md" sources: - "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/" - "https://genai.owasp.org/llmrisk/llm062025-excessive-agency/" --- # ИИ-агент в бизнес-процессе: что ему делегировать Пока ИИ только готовит черновик, его ошибку обычно успевает заметить человек. Но как только система получает доступ к почте, CRM или сервисным заявкам, цена ошибки меняется. Агент уже может исправить карточку не того клиента, запустить согласование или разослать сообщение раньше времени. Поэтому агентный проект начинается не с выбора модели. Сначала нужно ответить на четыре приземленных вопроса: какое событие запускает работу, что системе разрешено решать, какое действие она может выполнить и кто принимает результат. Без этих границ компания внедряет не помощника, а плохо описанного участника процесса. ## Не автоматизируйте должность целиком Формулировка «сделать агента менеджера по продажам» почти бесполезна. Внутри одной должности смешаны поиск, переговоры, оценка риска, обещания клиенту, оформление данных и внутренние согласования. У этих действий разная цена ошибки и разная потребность в контексте. Рабочая единица проектирования — ограниченный фрагмент процесса. Например: после входящего письма определить клиента и тему обращения, найти связанную сделку, подготовить проект ответа и предложить следующую задачу ответственному. Отправка письма и изменение суммы сделки остаются у человека. Такой контур можно описать, протестировать и остановить. Для первого внедрения подходят операции, в которых: - входные события и ожидаемый результат можно перечислить; - используются доступные и достаточно качественные данные; - действие обратимо либо требует подтверждения; - объем повторений достаточен, чтобы измерить эффект; - владелец процесса готов разбирать исключения. Плохо подходят процессы, где решение строится на негласной договоренности, цена единичной ошибки высока, а правильность невозможно проверить даже после выполнения. Там сначала нужно упорядочить сам процесс. ## Способность агента — это не задача бизнеса Демонстрация обычно показывает, что система умеет читать текст, рассуждать и обращаться к инструментам. Бизнесу нужно другое доказательство: конкретный экземпляр процесса завершился быстрее, дешевле или качественнее при приемлемом риске. Поэтому пилот описывают через результат. Не «агент анализирует обращения», а «для стандартного обращения определяет категорию, подбирает актуальную инструкцию, формирует проект ответа и создает задачу; сотрудник подтверждает или исправляет результат». Здесь видны границы, объект контроля и роль человека. Полезно разложить работу на четыре слоя. - Контекст. Какие данные нужны: карточка клиента, история переписки, каталог продукта, правила обслуживания, текущие ограничения. - Решение. Что именно выбирает система: категорию, маршрут, приоритет, следующий шаг. - Действие. Какие инструменты разрешены: поиск, создание черновика, запись служебного комментария, постановка задачи. - Контроль. Что проверяется автоматически и где требуется подтверждение человека. Если один слой нельзя описать, агент будет компенсировать пробел догадкой. В эффектной демонстрации это может выглядеть разумно. В рабочем процессе это источник нестабильности. ## Пять уровней автономности Автономность лучше наращивать ступенчато. Ниже — рабочая шкала для пилота, а не общепринятый отраслевой стандарт. На нулевом уровне система только ищет и объясняет. На первом готовит предложение, но ничего не записывает. На втором создает черновик в рабочей системе. На третьем выполняет низкорисковые действия в пределах лимита и сообщает о них. На четвертом ведет целый стандартный сценарий, передавая человеку только исключения. Каждая ступень должна иметь собственные условия перехода. Например, доля корректных классификаций, доля принятых без правки черновиков, количество неверно выбранных записей, время проверки и число остановленных действий. Решение о расширении прав принимается по накопленным данным, а не по впечатлению от нескольких удачных запусков. ## Что измерять вместо числа запросов Количество обращений к модели и число сгенерированных текстов нужны для эксплуатации, но не доказывают бизнес-результат. Метрики пилота должны быть связаны с процессом. Первая группа — время: длительность полного цикла, время активной работы сотрудника, ожидание между этапами. Вторая — качество: доля принятых результатов, число исправлений, возвраты и повторная работа. Третья — поток: сколько случаев процесс завершает за период и где после автоматизации появляется новая очередь. Четвертая — риск: ошибочные действия, нарушения лимитов, утечки контекста, доля случаев, переданных человеку. Пятая — экономика: стоимость обработки одного случая с учетом интеграции, контроля, эксплуатации и доработок. Важно замерить исходный процесс до пилота. Если нет базовой длительности, структуры ошибок и трудоемкости проверки, команда сможет показать активность, но не эффект. Условный сценарий: отдел обрабатывает типовые запросы клиентов. До внедрения сотрудник тратит в среднем двенадцать минут на поиск данных и подготовку ответа. Агент сокращает подготовку до трех минут, но проверка занимает еще четыре. Экономия составляет не девять, а пять минут. Если высвобожденное время не увеличивает объем обработки, не сокращает сверхурочную работу и не заменяет другую стоимость, это резерв мощности, а не уже полученная прибыль. ## Минимальная архитектура управляемости Надежный контур отделяет модель от производственных систем. Агент не должен самостоятельно решать, какими правами он обладает. Между его предложением и действием нужен слой политик: проверка роли, объекта, лимита, допустимого инструмента и необходимости подтверждения. Для каждого запуска сохраняют исходное событие, использованный контекст, предложенное решение, вызванный инструмент, результат проверки и итоговое действие. Такой журнал нужен не ради формальной отчетности. Без него невозможно понять, почему система ошиблась и что именно улучшать: данные, инструкцию, модель, интеграцию или правило процесса. Отдельно задают безопасную остановку. Владелец процесса должен иметь возможность отключить действие, отозвать ключи, перевести агента в режим черновика и обработать незавершенные случаи. Если остановка требует участия разработчика и нескольких часов диагностики, автономность выдана раньше, чем создано управление. ## Как провести первый пилот Первый этап занимает не весь процесс, а один повторяемый маршрут. Команда собирает фактическую выборку, включая редкие и неудобные случаи. Затем описывает эталон результата и признаки, при которых работа передается человеку. После этого запускает агента в теневом режиме: система предлагает действия, но процесс живет по старой схеме. Так сравнивают решения без производственного риска. Следующий шаг — режим черновика в рабочей системе. Только после устойчивого результата агенту разрешают одну обратимую операцию с малым лимитом. Расширение происходит отдельно по каждому инструменту. На контрольной встрече следует обсуждать не «насколько умным выглядит агент», а четыре таблицы: результаты по классам случаев, ошибки и их причины, фактическую экономику, список исключений. Это превращает пилот из технологического показа в управленческий эксперимент. ## С чего начинать ИИ-агент приносит пользу, когда получает не расплывчатую должность, а измеримый участок процесса. Контекст, полномочия, проверка и журналирование здесь так же важны, как качество ответа модели. Первый разумный режим — предложение или черновик. Право на действие появляется позже, после проверки на реальных случаях. Продолжение темы: [как ограничить доступ ИИ-агента к CRM](https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/) и [как устроить пилот AI-трансформации аналитического отдела](https://tesstech.ru/blog/ai-transformatsiya-analiticheskogo-otdela-kejsy-i-vyvody/). ## Проверенные источники - [NIST AI RMF Core: постановка задачи, измерение и управление риском](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) - [OWASP: риск избыточной автономности и полномочий LLM-систем](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) ## Услуга по теме [Системная ИИ-трансформация](https://tesstech.ru/services/ai-transformation/) — Находим процессы, где ИИ дает измеримый результат, и сопровождаем пилот до внедрения. ## Материалы по теме - [ИИ-агент в CRM: как ограничить доступ до инцидента](https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md) - [AI-трансформация аналитического отдела: модель пилота](https://tesstech.ru/blog/ai-transformatsiya-analiticheskogo-otdela-kejsy-i-vyvody/index.md) - [Почему корпоративный ИИ не знает ваш бизнес](https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/index.md)