Автор: Comb
Исследование реальных внедрений, продуктовых функций, preview-решений и reference-архитектур корпоративных AI-агентов.
Содержание статьи Как мы отбирали кейсы
1. Тендер из входящего письма превращается в проект заявки
2. Тендер разбирается до каждого требования и доказательства
3. Закупочная процедура идёт от потребности до заказа поставщику
4. Стратегический sourcing выполняет команда агентов
5. Письмо поставщика превращается в изменение заказа
6. Procure-to-pay собирается в один управляемый контур
7. Счёт поставщика проходит путь до готовности к оплате
8. Запрос клиента идёт от письма до оплаты
9. Заказ проверяется до выставления счёта
10. Дебиторская задолженность ведётся как долгоживущий кейс
11. Система сама обнаруживает, что автоматизация сломалась
12. Договор проходит путь от запроса до подписи — но это ещё не обязательно agentic AI
13. Юридический агент работает по playbook компании
14. Проблема проекта превращается в change order и billing event
15. Закрытие месяца собирается в единый пакет
16. Сверка идёт от расхождения к первопричине
17. KYC превращает пакет документов в доказуемое досье
18. Кредитное досье проверяется до и после выдачи
19. Financial crime alert проходит L1-проверку до аналитика
20. Страховой случай идёт от FNOL до решения
21. Prior authorization собирается до клинического решения
22. Отказ по медицинскому счёту превращается в исправление и appeal
23. Жалоба клиента проходит intake, research и resolution plan
24. Фото из магазина превращается в подготовленный кейс за секунды
25. IT-изменение получает план внедрения, тестирования и отката
26. Onboarding строится под конкретную роль и человека
27. Производственный заказ проверяется и выпускается
28. Склад сам находит дефицит и предлагает корректирующее действие
Дополнительные сложные процессы, которые уже появились в продуктовых каталогах
Что показал анализ источников
Где заканчивается workflow и начинается агент
Повторяющаяся архитектура AI-сотрудника
Почему один большой агент превращается в команду
Как измерять реальный эффект
Лестница внедрения
Какие процессы лучше выбирать для первого пилота
Что это означает для архитектуры AI-сотрудника
Итог
Сводная матрица кейсов
Когда бизнесу показывают возможности AI, примеры часто заканчиваются на довольно простых задачах:
найти документ;
пересказать встречу;
написать письмо;
подготовить коммерческое предложение;
сделать сводку;
ответить на вопрос сотрудника.
Это полезно. Но почти любую такую задачу хорошая модель может выполнить за один запрос. Для этого ей не обязательно понимать устройство компании, хранить состояние процесса или выполнять действия в корпоративных системах.
AI-сотрудник начинается в другом месте.
Не «напиши ответ на тендер», а:
Проверь, можем ли мы участвовать, разбери требования, найди подтверждения, собери полный комплект и доведи заявку до контрольной точки перед подачей.
Не «сделай КП», а:
Получи запрос клиента, сопоставь позиции, проверь цену и остатки, предложи аналоги, согласуй исключения и создай заказ.
Не «проверь договор», а:
Проведи его от запроса до согласования, подписи и контроля обязательств.
В этом исследовании собраны процессы, где AI делает больше, чем генерирует текст. Он получает событие или рабочую цель, собирает контекст, ведёт состояние дела, выбирает следующие шаги, вызывает инструменты и передаёт человеку только решения с высокой ценой ошибки.
Материал подготовлен по официальной документации, release notes, открытым репозиториям, reference-архитектурам и customer stories. Актуальность источников проверена 29 августа 2026 года.
Сложный AI-сотрудник ведёт не один документ, а несколько связанных процессов — от входящего события до контрольной точки и проверяемого результата.
МЕТОД Как мы отбирали кейсы
Слово agent в названии продукта само по себе ничего не доказывает. Иногда за ним действительно стоит система, которая планирует и действует. Иногда — обычный workflow с разговорным интерфейсом.
В исследование включались процессы, в которых присутствуют хотя бы четыре из шести признаков:
Событие или рабочая цель. Процесс запускается письмом, заявкой, изменением статуса, сроком или бизнес-задачей.
Несколько источников. Агент работает не с одним документом, а с почтой, ERP, CRM, политиками, историей и внешними системами.
Состояние дела. Работа продолжается дольше одной сессии и проходит несколько статусов.
Выбор следующего действия. Маршрут зависит от ситуации, а не полностью задан заранее.
Действия в системах. Агент создаёт или обновляет рабочие объекты, отправляет запросы, запускает согласование.
Исключения и контроль человека. Система понимает границы полномочий и умеет передать сложный случай.
Уровень доказательности источника
Класс Что это означает
A — именованное внедрение Есть конкретная компания, описан рабочий процесс и заявлены результаты. Цифры обычно опубликованы поставщиком решения, а не независимым аудитором.
B — продуктовая функция Возможность описана в официальной документации или release notes. Это подтверждает механику и доступность, но не экономический эффект.
C — preview или ранний релиз Направление уже видно, но данных о стабильности и внедрениях мало.
D — reference architecture / accelerator Есть код или архитектурный пример. Его нельзя считать готовой production-системой.
E — описание коммерческого поставщика Полезный рыночный сигнал, но возможности и результаты заявлены самим разработчиком.
Уровень автономности
Уровень Что делает система
1 Читает, ищет и пересказывает
2 Анализирует, рекомендует и готовит проект
3 Выполняет действия после подтверждения человека
4 Автономно ведёт типовые случаи в заданных границах, исключения передаёт человеку
5 Самостоятельно выполняет юридически, финансово или операционно значимый процесс без обычного подтверждения
Главный вывод заранее: большинство серьёзных корпоративных решений находится на уровне 3–4 , а не 5. Это не недостаток. Так выглядит нормальная система полномочий.
01 1. Тендер из входящего письма превращается в проект заявки
Источник Microsoft
Статус D — архивированный solution accelerator
Автономность 2–3 из 5
Microsoft Agent for RFP Response запускается по входящему письму с тендерной документацией.
Система:
определяет, какой продукт или услуга запрашивается;
читает RFP и вложения;
использует прошлые ответы как базу знаний;
формирует описание решения;
добавляет требования безопасности и соответствия правилам;
готовит верхнеуровневый план проекта;
рассчитывает оценку уверенности;
публикует черновик в Microsoft Teams.
Это уже не команда «напиши предложение». Есть событие, несколько источников, последовательность действий и рабочее пространство команды.
Но источник одновременно хорошо показывает границу доказательности. Microsoft прямо называет решение accelerator, а не production-продуктом. Репозиторий архивирован 20 марта 2026 года. Он полезен как открытый архитектурный пример, но не доказывает, что компания может поставить автономный тендерный отдел из коробки.
Где остаётся человек решение участвовать, цена, юридические заверения, финальная проверка и подача.
Что подтверждено архитектура автоматической обработки RFP и подготовки нескольких разделов предложения.
Что не подтверждено полноценное участие в торгах до юридически значимой подачи.
Источник: Microsoft Agent for RFP Response 1
02 2. Тендер разбирается до каждого требования и доказательства
Источники Responsive, Glean и специализированные RFP-платформы
Статус E — коммерческие продукты
Автономность 2–3 из 5
В специализированных системах единицей работы становится уже не весь документ, а отдельное требование.
Типовой процесс выглядит так:
загрузить PDF, DOCX или XLSX;
извлечь обязательные и желательные требования;
сохранить ссылку на страницу и исходный фрагмент;
назначить владельца ответа;
сопоставить требование с продуктом, политикой, сертификатом или прошлым ответом;
определить полное, частичное или отсутствующее соответствие;
сформировать compliance matrix;
подготовить проект ответа;
выделить пробелы для профильного эксперта;
экспортировать пакет в рабочий формат.
Responsive описывает автоматическое извлечение требований, fit analysis, compliance matrix и распределение ответственности. Glean показывает permission-aware процесс: разобрать RFP, найти знания, подготовить ответы и передать пробелы экспертам.
Такой процесс заметно сложнее обычного RAG. Система должна удерживать состояние сотен требований и не потерять ни одно обязательное условие.
Но последний шаг всё равно остаётся у proposal manager. Поставщики сами подчёркивают необходимость проверки.
Где остаётся человек bid/no-bid, коммерческая позиция, интерпретация спорных формулировок и финальная подача.
Что подтверждено рынок уже умеет автоматизировать compliance package и evidence-backed ответы.
Что не подтверждено массовая полностью автономная подача заявок на электронные торговые площадки.
Responsive Requirements Analysis 2
Glean: AI for RFP responses 3
03 3. Закупочная процедура идёт от потребности до заказа поставщику
Источник Oracle Fusion Procurement
Статус B — продуктовая функция
Автономность 4 из 5 в пределах заданной политики
Oracle Autonomous Sourcing Assistant автоматизирует массовые закупки с относительно низкой суммой и понятной политикой.
Процесс начинается с утверждённых строк потребности. Дальше система:
проверяет, подходит ли закупка под автономную политику;
создаёт negotiation;
формирует название и описание;
выбирает поставщиков по историческим данным;
отправляет процедуру на согласование, если оно включено;
публикует её после подтверждения;
ждёт ответы поставщиков;
применяет правила award;
выбирает лучший ответ по строкам или sole-source;
отправляет решение на согласование;
создаёт закупочные документы;
уведомляет владельца при ошибке.
Между созданием процедуры и заказом могут пройти дни. Агент должен дождаться ответов, проверить минимальное количество предложений и продолжить с сохранённого состояния.
Это один из самых сильных продуктовых примеров в исследовании: AI не просто анализирует закупку, а двигает её между транзакционными статусами в ERP.
Где остаётся человек публикация и выбор победителя могут проходить approval. Владелец разбирает нестандартные ошибки.
Что подтверждено productized-контур автономного sourcing с правилами, статусом и записью в систему.
Что не подтверждено широкая статистика внедрений и эффект на реальных категориях закупок.
Oracle Autonomous Sourcing Assistant 4
04 4. Стратегический sourcing выполняет команда агентов
Источник SAP Ariba / Joule
Статус B/C — продуктовый сценарий 2026 года
Автономность 3–4 из 5
SAP показывает не одного универсального закупщика, а несколько ролей:
Sourcing Event Agent создаёт процедуру на основе прошлых событий, договоров и данных поставщиков;
Bid Analysis Agent сравнивает предложения по цене, срокам, риску и другим параметрам;
Sourcing Negotiation Agent готовит переговорную стратегию и контрпредложения.
Получается цепочка:
потребность → процедура → поставщики → ставки → сравнение → переговорная позиция → контрпредложения → рекомендация по award.
Самая низкая цена не всегда означает лучший вариант. Поставщик может дать короткий срок, но худшие условия оплаты. Или хорошую цену при высоком риске срыва. Поэтому агент должен показать компромиссы, а не просто отсортировать таблицу.
Сильная сторона подхода — разделение одной роли на специализированных агентов. Слабая — пока мало публичных данных о длительной работе таких команд на реальных закупках.
Где остаётся человек стратегия, отношения с поставщиком, принятие компромисса и окончательный award.
SAP Sourcing Assistant 5
05 5. Письмо поставщика превращается в изменение заказа
Источник Farmlands Cooperative + Microsoft Dynamics 365
Статус A — именованное внедрение
Автономность 3–4 из 5
Farmlands Cooperative получает подтверждения заказов и изменения количества, цены, упаковки или даты поставки по электронной почте.
Раньше сотрудник открывал письмо, находил purchase order в Dynamics 365, определял затронутые строки и вручную переносил изменения.
Procurement Agent теперь:
читает письмо;
находит заказ и нужные строки;
расшифровывает смысл сообщения поставщика;
показывает изменение сотруднику;
предлагает принять или отклонить;
обновляет даты подтверждения;
готовит письма по задержанным и неподтверждённым заказам;
поддерживает автономную коммуникацию в разрешённых сценариях.
По данным Microsoft и Farmlands, агент помогает обрабатывать 50–60 писем по изменениям PO в день и готовить около 70 исходящих писем поставщикам. Компания оценивает экономию примерно в 20 часов команды в неделю. 70–80% релевантных писем система корректно интерпретирует без дополнительного обучения.
Это один из редких источников, где есть конкретный объём реальной работы.
При этом человек остаётся «firmly in the loop»: сотрудник видит предлагаемое изменение и подтверждает его.
Где остаётся человек нестандартная цена, серьёзное изменение условий и спорное сообщение поставщика.
Farmlands Cooperative customer story 6
06 6. Procure-to-pay собирается в один управляемый контур
Источник UiPath
Статус B/E — платформа и solution blueprint
Автономность 3–4 из 5
UiPath описывает procure-to-pay как единый процесс:
потребность → заявка → проверка политики → согласование → заказ → получение → счёт → сверка → исключение → подтверждение → ERP.
AI-агенты работают там, где нужен контекст:
помогают заполнить заявку;
проверяют её по политике;
находят отсутствующие поля;
классифицируют входящие счета;
извлекают данные из email, порталов, EDI и SFTP;
сопоставляют invoice, PO и goods receipt;
определяют тип расхождения;
готовят коммуникацию поставщику;
отправляют исключение нужному человеку с уже собранным контекстом.
Роботы и API выполняют детерминированные действия: создать запись, обновить поле, перенести данные, провести подтверждённую операцию.
Это важный архитектурный паттерн. Агент не заменяет workflow и RPA. Он добавляет принятие решений в тех местах, где входы неструктурированы и маршрут нельзя полностью задать заранее.
ERP остаётся системой учёта.
Где остаётся человек согласование выше лимита, изменение банковских реквизитов, неоднозначное расхождение и выпуск платежа.
UiPath Procure-to-Pay 7
07 7. Счёт поставщика проходит путь до готовности к оплате
Источник Oracle Payables Agent
Статус B — product release 26C
Автономность 3–4 из 5
Oracle Payables Agent покрывает invoice lifecycle до состояния payment readiness.
Система:
получает счета из разных каналов и форматов;
обрабатывает многостраничные и многоязычные документы;
извлекает реквизиты и строки;
сопоставляет данные с поставщиком и PO;
применяет значения по умолчанию;
проверяет compliance;
ищет аномалии;
запускает exception workflows;
поддерживает straight-through processing там, где все проверки пройдены.
Интересная часть продукта — перевод описанных естественным языком SOP в системные контроли. Это позволяет связать правила бизнеса и транзакционную систему.
Но это же риск. Неверно интерпретированная инструкция может превратиться в массовую ошибку. Такие правила должны проходить версионирование, тесты и approval перед публикацией.
Где остаётся человек спорный счёт, необычная аномалия, изменение платёжных данных, утверждение и платёж.
Oracle Payables Agent 26C 8
08 8. Запрос клиента идёт от письма до оплаты
Источник UiPath
Статус B/E — платформа и solution blueprint
Автономность 3–4 из 5
Order-to-cash показывает разницу между документом и работой особенно хорошо.
Подготовить коммерческое предложение — одна операция. Реальная задача выглядит так:
принять клиента → проверить данные → проверить кредитный риск → рассчитать предложение → создать заказ → исполнить → выставить счёт → получить и сопоставить оплату → отработать задолженность и спор.
UiPath распределяет работу между агентами, роботами и людьми.
Агенты:
классифицируют письма;
извлекают purchase orders;
анализируют условия;
помогают с кредитной проверкой;
готовят follow-up;
разбирают причины исключений.
Роботы и API обновляют CRM, ERP, billing и банковские системы.
Человек принимает дорогие решения.
Так появляется не «генератор КП», а система, которая ведёт заказ через несколько состояний.
Где остаётся человек нестандартная цена, кредитный риск, возврат, dispute и списание.
UiPath Order-to-Cash 9
09 9. Заказ проверяется до выставления счёта
Источник Danone + Microsoft
Статус A — именованное внедрение
Автономность 2–3 из 5
Danone ежедневно получает тысячи клиентских заказов через email, PDF и EDI. Разные форматы и ручной ввод приводили к ценовым расхождениям, спорам по счетам и задержкам оплаты.
Внедрённый агент:
анализирует заказ независимо от формата;
сверяет цены с ERP;
проверяет промо-инструменты;
обнаруживает возможное расхождение до выставления счёта;
рекомендует корректировку;
готовит письмо клиенту.
Это ещё не полностью автономный order-to-cash. Но AI встроен в точку, где ошибка обратима. Он предотвращает спор до возникновения, а не расследует его после неоплаты.
Компания сообщает об ускорении обработки и снижении billing disputes, но не публикует детальную статистику качества. Поэтому это сильный first-party пример, а не независимый benchmark.
Где остаётся человек изменение цены, спорное условие и окончательное подтверждение заказа.
Danone customer story 10
10 10. Дебиторская задолженность ведётся как долгоживущий кейс
Источник Oracle Collectors Workspace
Статус B/C — новая agentic application
Автономность 3 из 5
Collections плохо укладывается в один prompt. Работа продолжается неделями и зависит от истории:
какие счета просрочены;
есть ли спор;
каков риск клиента;
что он обещал;
когда был последний контакт;
выполнено ли promise-to-pay;
какое действие следует сделать дальше.
Oracle Collectors Workspace собирает ageing, открытые суммы, риск-сигналы и историю взаимодействий, затем:
приоритизирует аккаунты;
рекомендует next best action;
предлагает стратегию коммуникации;
координирует outreach и dispute resolution;
удерживает процесс активным во времени.
Главная ценность здесь не в письме должнику, а в памяти состояния и дисциплине следующего действия.
Публичные материалы в основном описывают продукт. Данных о внедрениях пока мало.
Где остаётся человек спор по долгу, реструктуризация, юридическая эскалация и списание.
Oracle Fusion Agentic Applications 11
11 11. Система сама обнаруживает, что автоматизация сломалась
Источник Tetra Pak + UiPath
Статус A — именованное внедрение
Автономность 3–4 из 5
Tetra Pak использует AI-агентов в финансах, supply chain, customer operations и поддержке автоматизаций.
По данным customer story:
точность обработки финансовых и налоговых документов приблизилась к 99% при сохранении человеческой проверки;
customer onboarding и supply-chain процессы сократились с дней до часов;
агенты суммируют запросы, маршрутизируют задачи и координируют работу между SAP, Salesforce и порталами;
healing agents обнаруживают изменение интерфейса или другой сбой, пытаются восстановить процесс и эскалируют, если это не удалось.
Последний сценарий особенно интересен. Обычная RPA ломается при изменении интерфейса и создаёт инцидент. Здесь отдельный агент следит за цифровым исполнителем и пытается восстановить его работу.
Это шаг к самоподдерживающейся операционной среде.
Как и другие customer stories, цифры опубликованы поставщиком. Методика расчёта 99% публично не раскрыта.
Где остаётся человек пограничные документы, нестандартный onboarding и неустранённые сбои.
Tetra Pak customer story 12
12 12. Договор проходит путь от запроса до подписи — но это ещё не обязательно agentic AI
Источник Microsoft Contract Processing Solution Accelerator
Статус D — архивированный accelerator
Автономность 2–3 из 5
Microsoft показывает процесс NDA:
проверить, существует ли уже договор;
собрать сведения;
создать документ из шаблона;
показать сотруднику;
отправить на электронную подпись;
сохранить подписанный файл в SharePoint;
записать статус и метаданные в Dataverse.
На уровне процесса это хороший пример. Договор проходит жизненный цикл, а не остаётся сгенерированным файлом.
Но глубокое чтение источника даёт важную поправку. В Transparency FAQ Microsoft прямо пишет, что sample не использует generative AI . Это в основном Copilot Studio, Power Platform, DocuSign и детерминированный workflow.
То есть слово Agent в названии ещё не доказывает наличие агентного рассуждения.
Этот кейс полезен как контрольный: иногда разговорная оболочка закрывает классическую автоматизацию. Если она решает задачу — это нормально. Но называть её автономным AI-сотрудником было бы преувеличением.
Где остаётся человек проверка договора и запуск подписи.
Microsoft Contract Processing Accelerator 13
Transparency FAQ 14
13 13. Юридический агент работает по playbook компании
Источник Google Gemini Enterprise for Legal
Статус C — preview, представлен 25 августа 2026 года
Автономность 2–3 из 5
Google выделил отдельный продукт для юридической функции.
Заявленные сценарии:
contract review;
redlining;
применение legal playbook;
legal research;
regulatory horizon scanning;
обработка DSAR;
сопоставление новых требований с внутренними политиками;
подготовка проекта изменений.
Ключевая идея правильная: базовой модели недостаточно. Юрист работает не по общим знаниям, а по позиции конкретной компании, допустимому риску, шаблонам и полномочиям.
Google также делает акцент на наследовании прав из подключённых систем и ссылках на доказательства.
Но продукт был представлен за четыре дня до даты этого исследования. Данных о стабильности, качестве redlining и реальных внедрениях ещё почти нет.
Это сильный индикатор направления рынка, но не доказательство готового автономного юридического отдела.
Где остаётся человек юридическая позиция, принятие риска, официальное обязательство и подпись.
Gemini Enterprise for Legal 15
14 14. Проблема проекта превращается в change order и billing event
Источник Oracle Fusion Project Management
Статус B — продуктовые функции 26C
Автономность 3 из 5
Oracle развивает несколько связанных project agents:
Project Change Order Initiation Assistant;
Project Contract and Customer PO Reconciliation Assistant;
Project Billing and Revenue Event Creation Assistant;
Project Contract Invoicing Assistant;
Project Contract Validation Assistant.
Из них складывается длинный сценарий:
возникла проблема проекта → определить влияние → инициировать change order → проверить договор и customer PO → обновить условия → создать billing/revenue event → подготовить счёт.
Например, billing assistant проверяет договор, строку, период, даты, сумму и существующие события. Сначала показывает preview и только после подтверждения создаёт запись.
Это процесс на стыке delivery, договора и финансов. Один пропущенный change order легко превращается в потерянную выручку.
Важно не переоценивать цельность решения: в документации это набор связанных assistants, а не обязательно один автономный агент, который сам проходит весь путь.
Где остаётся человек признание изменения, новая цена, изменение договора и создание billing event.
Oracle ERP AI feature catalog 16
15 15. Закрытие месяца собирается в единый пакет
Источник Anthropic Financial Services
Статус D — reference agent
Автономность 2–3 из 5
Month-End Closer получает компанию и период, после чего:
загружает trial balance;
строит accrual schedules;
готовит roll-forward;
анализирует отклонения к прошлому периоду и бюджету;
формирует пояснения;
подготавливает draft journal entries;
собирает close package;
передаёт его controller на sign-off.
Особенно полезны guardrails в исходнике:
документы поставщиков считаются недоверенными;
worker, который их читает, не получает доступ к инструментам записи;
агент не публикует проводки;
posting требует отдельного approval.
Это хороший инженерный пример разделения ролей. Компонент, читающий потенциально опасный документ, не должен одновременно иметь право изменить главную книгу.
Anthropic прямо называет весь репозиторий starting point. Это не production-бухгалтерия.
Где остаётся человек утверждение close package и posting.
Anthropic Financial Services 17
16 16. Сверка идёт от расхождения к первопричине
Источник Anthropic GL Reconciler
Статус D — reference agent
Автономность 2–3 из 5
GL Reconciler не ограничивается сравнением двух таблиц.
Он:
получает данные GL и subledger;
находит расхождения выше порога;
спускается до транзакций;
собирает доказательства;
классифицирует причину;
предлагает способ разрешения;
формирует exception report;
маршрутизирует результат на sign-off.
В reference-архитектуре также используется отдельная проверка результата. Это важный паттерн: исполнитель и контролёр не должны быть одной и той же логической ролью.
Как и Month-End Closer, это доказательство архитектурного подхода, а не внедрения в бухгалтерии крупной компании.
Где остаётся человек корректировка и проводка.
Anthropic GL Reconciler 18
17 17. KYC превращает пакет документов в доказуемое досье
Источники Anthropic и Google Cloud
Статус D — reference agents и blueprint
Автономность 2–3 из 5
Anthropic KYC Screener:
читает onboarding packet;
извлекает юридическое лицо, владельцев, адреса и идентификаторы;
строит inventory документов;
применяет KYC/AML-правила;
прикладывает доказательство к pass/fail;
проверяет sanctions, PEP и adverse media;
формирует gaps;
рекомендует риск;
собирает escalation packet.
Google показывает похожую multi-agent архитектуру:
root KYC agent;
document checker;
внешние проверки;
анализ PEP, санкций и adverse information;
проверка финансовых документов;
поиск дубля клиента в BigQuery;
сохранение case ID и состояния.
В обоих подходах итогом должен быть не красивый текст, а досье с происхождением каждого факта.
Риск-рейтинг остаётся рекомендацией. Окончательное решение принимает compliance officer.
Где остаётся человек onboarding и принятие риска.
Anthropic KYC Screener 19
Google KYC multi-agent workflow 20
18 18. Кредитное досье проверяется до и после выдачи
Источник UiPath Loan Origination
Статус B/C — purpose-built solution
Автономность 3 из 5
UiPath описывает два контура:
Loan Setup — анализ заявки и риска на ранней стадии;
QA/QC — проверка пакета до funding и после closing.
Система:
классифицирует документы;
извлекает данные;
проверяет атрибуты;
применяет правила кредитора;
сверяет документы между собой;
сравнивает их с LOS и внешними источниками;
выдаёт pass, fail или inconclusive;
формирует журнал каждого вывода;
передаёт исключения аналитику.
Кредитный специалист видит вывод агента рядом с исходным доказательством.
Это правильная граница: AI повышает полноту проверки, но не скрывает исходные данные и не принимает финальное кредитное решение.
Где остаётся человек lending decision и override правил.
UiPath Loan Origination 21
19 19. Financial crime alert проходит L1-проверку до аналитика
Источник UiPath / WorkFusion
Статус B/E — специализированные решения
Автономность 3–4 из 5 для очевидных false positives
Специализированные агенты работают с sanctions, PEP, payment и adverse-media alerts.
Они:
получают alert из screening-системы;
собирают сведения о сторонах;
сравнивают совпадения;
проверяют идентификаторы;
ищут adverse media;
формируют доказательства;
закрывают типовые false positives;
передают реальный или неоднозначный риск аналитику;
создают audit-ready narrative.
Поставщики заявляют высокий процент автоматического закрытия false positives и production-использование в банках. Эти данные стоит воспринимать осторожно: результат зависит от типа alerts, данных и допустимого риска.
Правильный KPI здесь — не доля закрытых сообщений, а false-negative rate и качество эскалации.
Где остаётся человек положительное совпадение, подозрительная активность и regulatory filing.
UiPath Financial Crime Compliance 22
20 20. Страховой случай идёт от FNOL до решения
Источник AWS
Статус D — reference architecture
Автономность 2–3 из 5
AWS показывает обработку автомобильного страхового случая.
Система может:
принять first notice of loss;
извлечь описание события;
проверить полис и exclusions;
изучить объяснение клиента;
проанализировать police report;
оценить фотографии повреждений;
проверить историю claims;
запустить fraud checks;
подготовить вывод и дальнейший маршрут.
Это мультимодальное дело: текст, изображения, структурированные данные, правила полиса и история клиента.
Но AWS показывает архитектуру, а не универсальную страховую систему. Реальная claims adjudication требует локальных правил, лицензированных оценок и контроля выплат.
Где остаётся человек спорная ответственность, мошенничество, крупная выплата и settlement.
AWS automated insurance claims 23
21 21. Prior authorization собирается до клинического решения
Источник UiPath
Статус B/E — purpose-built solution
Автономность 3 из 5
Prior authorization приходит через fax, портал, EDI/API или call center.
Агентный процесс:
принимает запрос;
извлекает сведения;
проверяет eligibility и benefits;
обнаруживает недостающие clinicals;
суммирует медицинские записи;
сопоставляет доказательства с payer policy;
маршрутизирует кейс по сложности;
передаёт RN или medical director;
готовит correspondence;
записывает результат обратно;
обновляет статус для провайдера.
AI не должен принимать медицинское решение. Но он может убрать большую часть административного поиска и сборки кейса.
Цитаты на исходные медицинские документы критичны. Без них специалист всё равно перечитает пакет целиком.
Где остаётся человек medical necessity и финальное клиническое решение.
UiPath Prior Authorization 24
22 22. Отказ по медицинскому счёту превращается в исправление и appeal
Источник UiPath
Статус B/E — purpose-built solution
Автономность 3–4 из 5
Denial management замыкает процесс в обратную связь.
Система:
до отправки claim проверяет eligibility, credentials и наличие prior authorization;
после отказа определяет reason code;
ищет root cause;
собирает недостающие данные;
готовит payer-specific appeal;
прикладывает clinical evidence;
отслеживает исправление до оплаты;
возвращает найденную причину в upstream-процессы регистрации и coding.
Агент не только чинит отдельный отказ, но и помогает предотвратить следующий.
Это уже операционный learning loop. Качество при этом зависит от актуальности payer rules и структуры EHR.
Где остаётся человек клинический аргумент, неоднозначная политика и дорогой appeal.
UiPath Denial Management 25
23 23. Жалоба клиента проходит intake, research и resolution plan
Источник ServiceNow Customer Service Management
Статус B — продуктовая документация
Автономность 3 из 5
ServiceNow использует команду агентов для complaint case:
принять обращение;
классифицировать;
определить priority и sentiment;
суммировать факты;
найти похожие кейсы;
проверить knowledge base и внешние системы;
создать связанные задачи;
подготовить resolution plan;
передать работу специализированному агенту;
эскалировать сложный случай.
Следующий шаг зависит от состояния и истории клиента. Жалоба может потребовать возврата, технического расследования, юридической проверки или обычного объяснения.
Это уже не чат-бот. Единицей работы становится кейс, который движется между состояниями.
Где остаётся человек компенсация, юридический риск и нестандартное решение.
ServiceNow complaint case handling 26
24 24. Фото из магазина превращается в подготовленный кейс за секунды
Источник ROSSMANN + ServiceNow
Статус A — именованное внедрение
Автономность 3–4 из 5
Сотрудник магазина может отправить фотографию, текст или голосовое описание проблемы.
Агенты:
распознают товар или объект;
классифицируют проблему;
запрашивают недостающие данные;
находят руководство;
подготавливают кейс;
выбирают маршрут;
в простых сценариях доводят запрос до решения;
в остальных передают человеку.
ServiceNow и ROSSMANN заявляют сокращение обработки с девяти минут до менее пяти секунд, 98% routing accuracy, шесть работающих агентов и 50% снижение трудозатрат. 89% входящих обращений автоматически категоризируются и приоритизируются по более чем 200 категориям.
У customer story есть важный нюанс. Верхний уровень говорит об автономном решении, но подробности показывают, что часть запросов всё ещё маршрутизируется человеку. Поэтому корректнее говорить об автономном intake, enrichment и routing, а не о полном закрытии любого обращения.
Где остаётся человек физический ремонт, нестандартная причина и действие вне цифровой системы.
ROSMANN customer story 27
25 25. IT-изменение получает план внедрения, тестирования и отката
Источник ServiceNow ITSM
Статус B — продуктовая документация
Автономность 3 из 5
Change Request Plans AI Agent получает change request и готовит:
implementation plan;
test plan;
backout plan;
justification;
risk analysis;
impact analysis.
Агент использует похожие закрытые изменения. Если подходящего примера нет, опирается на best practices. Он может переработать план по обратной связи и обновляет change record только после approval.
Другие агенты проверяют конфликты расписания, затронутые CI и сервисы.
Здесь хорошо видна гибридная архитектура:
AI собирает контекст и готовит план;
workflow удерживает статус;
CMDB задаёт мир объектов и связей;
approval защищает критическое действие;
ITSM хранит историю.
Где остаётся человек CAB approval и выполнение изменения в критичной системе.
ServiceNow change request plans 28
26 26. Onboarding строится под конкретную роль и человека
Источник ServiceNow HRSD
Статус B — продуктовая документация
Автономность 3 из 5
Команда агентов собирает:
сведения о сотруднике;
onboarding journey;
данные команды;
job description;
interview notes;
resume;
skills;
каталог обучения.
Затем система:
выделяет требования роли;
сопоставляет их с навыками сотрудника;
находит gaps;
подбирает обучение;
создаёт этапы плана;
добавляет курсы, задачи и 1:1;
назначает исполнителей;
рассчитывает сроки.
Менеджер разговорно редактирует план и публикует утверждённую версию в onboarding journey.
Это не самый автономный кейс, но хороший пример персонализированного долгоживущего процесса, где результат становится реальным набором задач.
Где остаётся человек ожидания роли, наставники и публикация плана.
ServiceNow onboarding ramp-up workflow 29
27 27. Производственный заказ проверяется и выпускается
Источник SAP S/4HANA Cloud
Статус B — официальная документация
Автономность 3 из 5
Production Planning and Operations Agent помогает выпускать до 20 производственных заказов одновременно.
Перед release он:
проверяет наличие компонентов;
ищет разрешённые альтернативы в BOM;
позволяет выбрать замену;
обновляет заказ;
проверяет загрузку work center;
обнаруживает перегрузку;
предлагает перенос;
показывает изменения;
после подтверждения выпускает заказы;
выдаёт итоговую сводку.
Это уже работа с физическими последствиями. Ошибка может остановить линию, создать дефицит или нарушить срок клиента.
Поэтому SAP сохраняет human-in-the-loop. Если требуется решение руководителя, процесс приостанавливается и показывает варианты.
Где остаётся человек замена компонента, перенос, приоритет и release.
SAP Production Planning and Operations Agent 30
28 28. Склад сам находит дефицит и предлагает корректирующее действие
Источник Oracle Fusion SCM
Статус B/C — новые agentic applications 26B–26C
Автономность 3–4 из 5
Warehouse Operations Workspace анализирует:
on-hand inventory;
спрос;
shortages и stockouts;
inbound и outbound;
медленно оборачиваемый запас;
партии с истекающим сроком;
резервы под приоритетные заказы.
Дальше система предлагает:
внутренний transfer;
новый purchase order;
перераспределение reservation;
другое действие для снятия риска.
Связанные command centers объединяют склад, транспорт и maintenance. Агенту приходится учитывать товар, партию, заказ, оборудование, техника и клиентское обязательство.
Большая часть функций новая. Публичных данных о длительной работе и экономике пока мало.
Где остаётся человек дорогое перемещение, списание, остановка производства и изменение обязательства клиенту.
Oracle Warehouse Operations Workspace 31
КАТ Дополнительные сложные процессы, которые уже появились в продуктовых каталогах
В официальной документации 2026 года есть ещё несколько классов:
Процесс Что делает AI Источник и зрелость
Supplier onboarding Проверяет регистрационные данные, анкеты, qualification и purchasing hold Oracle / SAP, B–C
Business Network documents Обрабатывает order confirmation, ASN, goods receipt, service entry и invoice между компаниями SAP, B–C
Sales order command center Ищет незавершённые заказы, объясняет причину и предлагает восстановление Oracle, B–C
Cost accounting close Проверяет готовность к закрытию периода, классифицирует исключения и ведёт их до устранения Oracle, B–C
Maintenance operations Приоритизирует work orders по состоянию оборудования, материалам, техникам и производственным обязательствам Oracle / SAP, B–C
Interview scheduling Сопоставляет календари, роли интервьюеров, ограничения и переносы ServiceNow, B
Job requisition Собирает требования, ищет похожие вакансии, определяет навыки и создаёт реальную заявку ServiceNow, B
Regulatory horizon scanning Находит изменения регулирования, сопоставляет с политиками и готовит задачи на обновление Google Legal, C
DSAR Ищет персональные данные в нескольких системах, собирает пакет и ведёт сроки Google Legal, C
Healthcare claims processing Проверяет комплектность, кодирование, политику и маршрут исключения AWS / UiPath, D–B
АНАЛИЗ Что показал анализ источников
1. Слово agent ничего не доказывает
Microsoft Contract Processing называется агентом, но его Transparency FAQ прямо говорит: generative AI не используется.
И наоборот, часть действительно сложных решений построена как гибрид из workflow, RPA, правил, моделей и человека. Они могут выглядеть менее эффектно, но реально двигают работу.
Оценивать нужно не название, а механику:
как запускается процесс;
где хранится состояние;
как выбирается следующий шаг;
какие действия доступны;
что происходит при исключении;
кто отвечает за результат.
2. Самые сильные доказательства пока редки
Особенно выделяются Farmlands, ROSSMANN и Tetra Pak: есть конкретные компании, рабочие объёмы и заявленные показатели.
Но даже эти материалы опубликованы поставщиками платформ. Независимых сравнений до и после, распределения ошибок, стоимости владения и false-positive rate почти нет.
У большинства остальных кейсов мы видим возможность продукта , а не доказанный экономический результат.
3. В тендерах автоматизирована подготовка, но не последний юридический шаг
Рассмотренные supplier-side решения уже умеют:
разбирать документацию;
извлекать требования;
строить compliance matrix;
сопоставлять продукты;
искать сертификаты;
готовить ответы;
вести статусы и сроки.
Но финальная подача обычно остаётся у человека.
Это вывод из рассмотренной выборки, а не утверждение, что полностью автоматической подачи нигде не существует.
Причина выглядит не технической. Последний шаг связан с электронной подписью, ценой, гарантией, полномочиями и ответственностью за неверные сведения.
Наиболее реалистичная архитектура сейчас:
AI ведёт тендер целиком, человек подтверждает bid/no-bid, цену, подпись и подачу.
4. Автономность заканчивается перед необратимым действием
Почти во всех зрелых источниках approval стоит перед одной из точек:
award поставщику;
электронная подпись;
платёж;
проводка в GL;
onboarding клиента;
кредитное решение;
клиническое решение;
крупная страховая выплата;
release производства;
критическое IT-изменение.
Это не временный костыль. Так выглядит нормальная система полномочий.
5. Корпоративные системы остаются системами учёта
ERP, CRM, ITSM, CLM и WMS не исчезают.
Они продолжают хранить:
факты;
статусы;
транзакции;
права;
историю;
юридически значимые записи.
AI-сотрудник двигает работу между этими системами, собирает контекст и обрабатывает исключения.
6. Проблема рынка — не только модель, а перестройка процесса
BCG в исследовании закупок 2026 года называет среди главных ограничений неоднородные входы, качество данных, интеграцию с legacy, параллельное ведение трансформации и governance.
McKinsey отмечает, что многие supply-chain пилоты быстро доказывают техническую возможность, но застревают, потому что компания не меняет сам способ работы.
То есть следующий прирост даёт не ещё одна модель. Он появляется, когда вокруг агента перестраивается end-to-end процесс.
BCG: Scaling Agentic AI in Procurement 32
McKinsey: Powering supply chain with agentic AI 33
FLOW Где заканчивается workflow и начинается агент
Обычный workflow заранее знает маршрут. Агентный процесс выбирает следующий шаг по данным, контексту и исключениям, а человек остаётся в контрольных точках. Обычный workflow знает маршрут заранее:
получить счёт → извлечь поля → сверить → отправить на согласование → провести.
Агент нужен там, где маршрут зависит от состояния:
PO отсутствует
→ определить, допустим ли non-PO invoice;
цена не совпадает
→ проверить допуск;
допуск превышен
→ найти договор;
в договоре есть индексирование
→ пересчитать;
подтверждения нет
→ запросить владельца закупки;
поставщик изменил реквизиты
→ остановить процесс и запустить fraud check.
Зрелая архитектура обычно гибридная:
deterministic workflow удерживает критическую последовательность;
case manager хранит состояние;
AI-агент читает неструктурированные данные и выбирает действие;
API или RPA выполняет точную операцию;
policy engine ограничивает допустимый диапазон;
человек подтверждает дорогие решения.
UiPath прямо разделяет предсказуемые BPMN-процессы и долгоживущие exception-heavy cases. Microsoft описывает автономного агента как систему, которая реагирует на событие, принимает решение и действует в заданных guardrails. ServiceNow добавляет supervised execution и kill switch для критических инструментов.
АРХ Повторяющаяся архитектура AI-сотрудника
Модель отвечает за рассуждение. Рабочего AI-сотрудника создаёт система вокруг модели: состояние, модель мира, навыки, инструменты и контроль. Во всех зрелых кейсах повторяется один и тот же контур.
1. Триггер
Процесс начинается не только с чата:
пришло письмо;
появилась заявка;
закончился тендер;
возник дефицит;
наступил срок;
изменился статус;
нарушен SLA.
2. Состояние дела
Агенту нужно помнить:
что уже сделано;
какие документы получены;
что ожидается;
какое решение принято;
какие исключения открыты;
кто отвечает;
когда следующий контрольный срок.
Памяти диалога недостаточно. Нужен внешний state store: case record, task tracker или другой объект процесса.
3. Модель мира
Агент должен понимать сущности и связи:
клиент;
договор;
заказ;
товар;
склад;
счёт;
поставщик;
сотрудник;
оборудование;
проект;
обязательство.
Без этого он каждый раз собирает мир заново из текстов.
4. Способ работы
Нужны исполняемые навыки:
как разобрать тендер;
как проверить счёт;
как провести KYC;
как подготовить change plan;
как выбрать аналог;
как расследовать расхождение.
Это не общая инструкция. Это стандарт работы со шагами, инструментами, проверками и критериями выхода.
5. Инструменты
Агент получает не «доступ к ERP», а конкретные операции:
прочитать заказ;
найти договор;
создать задачу;
запросить документ;
обновить дату;
сформировать файл;
отправить письмо;
вызвать другого агента.
6. Контрольный контур
Нужны:
role-based access;
минимальные права;
supervised execution;
approval;
лимиты;
circuit breaker;
kill switch;
audit trail;
evaluation;
replay;
версия навыка и политики.
РОЛИ Почему один большой агент превращается в команду
В сложном процессе опасно давать одному агенту всё сразу.
Надёжнее разделить роли:
reader читает недоверенный документ;
extractor превращает его в структуру;
analyst применяет правила;
planner выбирает маршрут;
worker вызывает разрешённый инструмент;
critic перепроверяет;
orchestrator удерживает цель и состояние;
human approver принимает дорогое решение.
Anthropic показывает особенно важный паттерн: worker, читающий потенциально опасный документ, не получает MCP и write tools.
Мультиагентность нужна не потому, что «команда агентов» звучит современно. Она нужна для разделения прав, ответственности и blast radius.
KPI Как измерять реальный эффект
Количество созданных документов и токенов почти ничего не говорит.
Скорость
cycle time;
время до первого действия;
время ожидания человека;
SLA misses;
возраст открытого исключения.
Автономность
touchless rate;
доля кейсов без ручного ввода;
доля автоматически выполненных обратимых действий;
human minutes per case.
Качество
first-pass completeness;
exception rate;
rework;
false-positive и false-negative rate;
escalation precision;
evidence coverage.
Контроль
audit completeness;
доля действий в пределах полномочий;
число остановок circuit breaker;
число override;
время расследования ошибки.
Экономический результат
стоимость кейса;
DSO;
invoice leakage;
win rate;
margin;
working capital;
stockout;
downtime;
cost-to-serve;
recovered revenue.
ПИЛОТ Лестница внедрения
Большинство зрелых корпоративных решений сегодня находится на уровнях 3–4: действие после подтверждения или автономное ведение типовых низкорисковых случаев. Полную автономность не нужно включать в первый день.
Этап 1. Наблюдение
Агент читает процесс и показывает, что произошло, чего не хватает и какое правило сработало. Ничего не записывает.
Этап 2. Черновик с доказательствами
Агент готовит документ, решение или письмо. Каждое существенное утверждение связано с источником.
Этап 3. Рекомендация действия
Агент предлагает конкретный следующий шаг и показывает последствия.
Этап 4. Выполнение после подтверждения
Пользователь нажимает одну кнопку, система выполняет несколько транзакционных шагов.
Это модель Farmlands и SAP production release.
Этап 5. Автономные типовые случаи
Низкорисковые кейсы проходят автоматически. Исключения уходят человеку.
Этап 6. Расширение полномочий после evaluation
Граница повышается только после накопления статистики на конкретном типе кейса, источниках и лимитах.
СТАРТ Какие процессы лучше выбирать для первого пилота
Хороший первый процесс имеет пять свойств:
высокий объём;
много ручных переходов между системами;
есть понятный объект и статус;
результат можно проверить;
ошибка обратима или ограничена.
Поэтому сильные стартовые кейсы:
обработка клиентской заявки;
PO confirmations;
invoice–PO–receipt matching;
тендерный compliance package;
сборка договорного пакета;
triage обращения;
контроль комплектности KYC;
подготовка change plan;
обнаружение складских исключений.
Плохой первый пилот:
редкая стратегическая задача;
нет владельца процесса;
данные противоречат друг другу;
успех невозможно измерить;
агент сразу получает подпись, деньги или полный доступ к ERP;
исключения нигде не регистрируются;
человек всё равно заново выполняет всю работу.
СЛОИ Что это означает для архитектуры AI-сотрудника
Сложный AI-сотрудник не собирается одним промптом.
Ему нужны несколько слоёв.
Agents.md — кто он
Роль, зона ответственности, полномочия, ограничения и маршрут к знаниям и инструментам.
Онтология — где он работает
Клиенты, договоры, товары, заказы, сотрудники, документы, системы и связи между ними.
Skills — как он выполняет работу
Шаги, проверки, правила, инструменты, исключения и критерии готового результата.
Память — что уже происходило
История дела, принятые решения, обратная связь, результаты и изменения правил.
Инструменты — что он может сделать
Не абстрактный доступ к CRM, а конкретные операции с минимальными правами.
Оркестрация — как работа движется во времени
Триггеры, состояние, ожидание, retry, timeout, SLA, approval и handoff между агентами и людьми.
Evaluation — почему ему можно доверять
Проверочные кейсы, журнал решений, сравнение с эталоном, контроль регрессий и наблюдение за production.
Модель отвечает за рассуждение.
AI-сотрудника создаёт система вокруг модели .
ИТОГ Итог
Исследование не показывает, что компании уже массово заменили отделы автономными агентами.
Оно показывает другое.
Корпоративный AI быстро уходит от отдельной генерации текста к исполнению реальной работы:
от ответа на RFP — к ведению тендерного пакета;
от заявки — к закупочной процедуре;
от распознавания счёта — к payment readiness;
от КП — к order-to-cash;
от черновика договора — к жизненному циклу соглашения;
от поиска расхождения — к расследованию причины;
от медицинской сводки — к готовому prior-authorization case;
от складского dashboard — к корректирующему действию.
Следующий этап корпоративного AI — не ещё один чат внутри CRM.
Единицей автоматизации становится дело .
Не «напиши КП», а:
Обработай запрос клиента и доведи до заказа.
Не «проанализируй тендер», а:
Проверь возможность участия, собери доказательства и подготовь комплект заявки.
Не «проверь договор», а:
Проведи его до следующей контрольной точки.
AI-сотрудник начинается там, где системе можно дать цель, состояние, правила, инструменты и ограниченные полномочия — и она двигает работу до проверяемого результата.
КЕЙСЫ Сводная матрица кейсов
№ Процесс Источник Зрелость Автономность Главная точка человека
1 RFP response Microsoft D 2–3 Финализация и подача
2 Tender compliance Responsive / Glean E 2–3 Bid/no-bid и заверения
3 Autonomous sourcing Oracle B 4 Publication / award
4 Strategic sourcing SAP B/C 3–4 Стратегия и award
5 PO confirmations Farmlands / Microsoft A 3–4 Нестандартное изменение
6 Procure-to-pay UiPath B/E 3–4 Исключение и платёж
7 Supplier invoice lifecycle Oracle B 3–4 Аномалия и approval
8 Order-to-cash UiPath B/E 3–4 Кредит, спор, списание
9 Order price validation Danone / Microsoft A 2–3 Изменение цены
10 Collections Oracle B/C 3 Спор и реструктуризация
11 Cross-system operations Tetra Pak / UiPath A 3–4 Edge cases
12 NDA lifecycle Microsoft D 2–3 Проверка и подпись
13 Legal playbook Google C 2–3 Юридическая позиция
14 Project change to billing Oracle B 3 Change order / billing
15 Month-end close Anthropic D 2–3 Posting
16 GL reconciliation Anthropic D 2–3 Корректировка
17 KYC dossier Anthropic / Google D 2–3 Risk decision
18 Loan origination QA/QC UiPath B/C 3 Lending decision
19 Financial crime alert review UiPath / WorkFusion B/E 3–4 Реальный риск
20 Insurance claims AWS D 2–3 Settlement
21 Prior authorization UiPath B/E 3 Clinical decision
22 Denial management UiPath B/E 3–4 Clinical/legal appeal
23 Complaint case ServiceNow B 3 Компенсация и риск
24 Store issue ROSSMANN / ServiceNow A 3–4 Физическое действие
25 IT change ServiceNow B 3 CAB / execution
26 Employee onboarding ServiceNow B 3 Публикация плана
27 Production order release SAP B 3 Замена / перенос / release
28 Warehouse exceptions Oracle B/C 3–4 Дорогое физическое действие
29 Supplier onboarding Oracle / SAP B/C 3 Qualification decision
30 Maintenance operations Oracle / SAP B/C 3 Опасная или дорогая работа
31 Regulatory horizon scanning Google C 2–3 Изменение политики
32 DSAR Google C 2–3 Юридическая выдача
ИСТ Основные источники
01 Источник: Microsoft Agent for RFP Response
02 Responsive Requirements Analysis
03 Glean: AI for RFP responses
04 Oracle Autonomous Sourcing Assistant
05 SAP Sourcing Assistant
06 Farmlands Cooperative customer story
07 UiPath Procure-to-Pay
08 Oracle Payables Agent 26C
09 UiPath Order-to-Cash
10 Danone customer story
11 Oracle Fusion Agentic Applications
12 Tetra Pak customer story
13 Microsoft Contract Processing Accelerator
14 Transparency FAQ
15 Gemini Enterprise for Legal
16 Oracle ERP AI feature catalog
17 Anthropic Financial Services
18 Anthropic GL Reconciler
19 Anthropic KYC Screener
20 Google KYC multi-agent workflow
21 UiPath Loan Origination
22 UiPath Financial Crime Compliance
23 AWS automated insurance claims
24 UiPath Prior Authorization
25 UiPath Denial Management
26 ServiceNow complaint case handling
27 ROSMANN customer story
28 ServiceNow change request plans
29 ServiceNow onboarding ramp-up workflow
30 SAP Production Planning and Operations Agent
31 Oracle Warehouse Operations Workspace
32 BCG: Scaling Agentic AI in Procurement
33 McKinsey: Powering supply chain with agentic AI
34 McKinsey: Agentic AI in procurement
35 Deloitte: Multi-Agentic AI for sourcing and procurement
Актуальность источников проверена 29 августа 2026 года. Статусы preview, release plans и доступность функций могут меняться. Перед использованием отдельных возможностей в архитектурном решении нужно повторно проверить документацию конкретной версии.
В материале
Как мы отбирали кейсы
1. Тендер из входящего письма превращается в проект заявки
2. Тендер разбирается до каждого требования и доказательства
3. Закупочная процедура идёт от потребности до заказа поставщику
4. Стратегический sourcing выполняет команда агентов
5. Письмо поставщика превращается в изменение заказа
6. Procure-to-pay собирается в один управляемый контур
7. Счёт поставщика проходит путь до готовности к оплате
8. Запрос клиента идёт от письма до оплаты
9. Заказ проверяется до выставления счёта
10. Дебиторская задолженность ведётся как долгоживущий кейс
11. Система сама обнаруживает, что автоматизация сломалась
12. Договор проходит путь от запроса до подписи — но это ещё не обязательно agentic AI
13. Юридический агент работает по playbook компании
14. Проблема проекта превращается в change order и billing event
15. Закрытие месяца собирается в единый пакет
16. Сверка идёт от расхождения к первопричине
17. KYC превращает пакет документов в доказуемое досье
18. Кредитное досье проверяется до и после выдачи
19. Financial crime alert проходит L1-проверку до аналитика
20. Страховой случай идёт от FNOL до решения
21. Prior authorization собирается до клинического решения
22. Отказ по медицинскому счёту превращается в исправление и appeal
23. Жалоба клиента проходит intake, research и resolution plan
24. Фото из магазина превращается в подготовленный кейс за секунды
25. IT-изменение получает план внедрения, тестирования и отката
26. Onboarding строится под конкретную роль и человека
27. Производственный заказ проверяется и выпускается
28. Склад сам находит дефицит и предлагает корректирующее действие
Дополнительные сложные процессы, которые уже появились в продуктовых каталогах
Что показал анализ источников
Где заканчивается workflow и начинается агент
Повторяющаяся архитектура AI-сотрудника
Почему один большой агент превращается в команду
Как измерять реальный эффект
Лестница внедрения
Какие процессы лучше выбирать для первого пилота
Что это означает для архитектуры AI-сотрудника
Итог
Сводная матрица кейсов
Следующая статья: Персональные ИИ-агенты: от чата к цифровому сотруднику