Автономные агенты

У страховщика среднего размера урегулирование убытка - это ручная цепочка из нескольких шагов. Сотрудники принимают заявление о страховом событии, проверяют комплект документов, оценивают ущерб, проверяют случай на признаки мошенничества, рассчитывают сумму и проводят выплату. На каждом шаге заявление передается между сотрудниками, данные вводятся повторно, а простые типовые случаи (ОСАГО, КАСКО, страхование от несчастных случаев, добровольное медицинское страхование) идут по той же длинной процедуре, что и сложные. В результате урегулирование растягивается, а в пик сезона растет нагрузка на контакт-центр и андеррайтеров (специалистов, которые оценивают риск и принимают решение по выплате).

Мы собираем мультиагентную систему из нескольких ИИ-агентов. Каждый агент отвечает за свой этап урегулирования, а отдельный агент-координатор связывает их в единый процесс. На одной инфраструктуре мы объединяем следующие компоненты:

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

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

У банка или страховщика среднего размера андеррайтинг - это ручная работа специалиста по каждой заявке. Специалист собирает данные о клиенте из внутренних систем и внешних источников, запускает скоринговую модель, разбирает факторы риска и готовит решение по полису или кредиту. Когда портфель растет, а штат андеррайтеров (специалистов, которые эту оценку ведут) не растет, заявки выстраиваются в очередь и время на каждую заявку становится узким местом. В результате компания либо упускает клиентов из-за долгого ответа, либо нанимает людей быстрее, чем может себе позволить. Отдельная сложность в том, что риск-комитет (внутренний комитет по рискам) и Банк России требуют объяснять, почему по заявке принято именно такое решение, а ручная подготовка такого обоснования отнимает время.

Мы собираем ИИ-агента, который помогает андеррайтеру. Агент снимает с человека рутину сбора и подготовки, но решение сам не принимает. На одной инфраструктуре работают следующие компоненты:

• Сбор данных по заявке. Агент собирает внутренние данные из автоматизированной банковской или страховой системы и историю клиента, а также внешние данные из СПАРК, Контур и кредитных бюро (сервисы проверки контрагентов и кредитной истории). Работает на базе языковой модели и выполнения действий в учетных системах.
• Запуск скоринга. Агент запускает скоринговую модель и собирает воедино факторы риска по заявке. Работает на базе классического машинного обучения.
• Подготовка предварительного решения. Агент формирует предварительное решение по полису или кредиту и пишет к нему обоснование с перечнем факторов, которые на это решение повлияли. Работает на базе языковой модели.
• Передача андеррайтеру. Агент передает человеку готовый пакет материалов с предварительным решением и обоснованием для утверждения. Работает на основе правил маршрутизации, без языковой модели.

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

У банка и страховщика поток подозрительных операций и заявлений с признаками мошенничества разбирают вручную аналитики и комплаенс-офицеры (сотрудники, которые отвечают за соблюдение требований регулятора по противодействию отмыванию денег). Каждый сигнал тревоги нужно проверить, то есть сверить с внутренними базами и отраслевыми источниками, оценить риск, собрать материалы и подготовить отчет. Когда клиентская база растет, растет и поток таких сигналов, аналитики тратят на разбор большую часть рабочего времени, а доля разобранных сигналов падает. Отдельная сложность в ложных срабатываниях, когда часть сигналов после проверки оказывается безобидной, но время на их разбор уже потрачено. В страховании добавляется рост дорожных происшествий с признаками инсценировки по ОСАГО и КАСКО. Банк России при этом предъявляет требования к качеству и срокам подачи отчетов о подозрительных операциях.

Мы собираем ИИ-агента, который снимает с аналитика рутину первичного разбора и подготовки, но сам не блокирует и не принимает решение. На одной инфраструктуре работают следующие компоненты:

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

Финальное решение, блокировка операции и подача отчета о подозрительной операции остаются за человеком. Это требование Банка России, по которому в платежных операциях и при блокировках человек обязателен, а агент не блокирует автономно. Подача отчетов и их оформление идут под контролем комплаенс-функции (115-ФЗ, противодействие отмыванию денег). Агент снимает рутину первичного разбора и подготовки, но не заменяет комплаенс-офицера. Внедряем в теневом режиме, без влияния на реальные блокировки, пока не убедимся, что оценки агента совпадают с решениями аналитиков.

В профессиональных услугах, банках и девелопменте много повторяющихся процедур, которые требуют большого объема работы с документами. Это проверка сделок (комплексная проверка контрагента, или due diligence), аудиторские процедуры, налоговые и юридические заключения, кредитные конвейеры, согласование договоров долевого участия. Специалист по каждому такому делу собирает документы из систем электронного документооборота и учетных систем, сверяет их с нормативными требованиями, проверяет факты по внешним источникам и готовит черновик заключения. Это занимает много времени квалифицированного человека, которого на рынке не хватает. Отдельная управленческая сложность - это ручной сбор статусов и рисков по портфелю проектов, из-за которого руководитель тратит время на ежедневные планерки и сведение отчетов вместо работы с самими рисками.

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

• Агент сбора фактуры. Собирает и проверяет факты по делу из внешних и внутренних источников. Работает на базе языковой модели и выполнения действий в системах.
• Агент работы с документами. Извлекает и структурирует данные из системы электронного документооборота и учетной системы. Работает на базе компьютерного зрения и языковой модели.
• Агент нормативной проверки. Сверяет дело с нормативными требованиями и правилами. Работает на основе заданных проверочных правил и языковой модели.
• Агент доступа к базе знаний. Находит нужное в корпоративной базе знаний компании и подает это остальным агентам. Работает на базе языковой модели.
• Агент сборки черновика. Собирает из материалов черновик заключения. Работает на базе языковой модели.
• Агент-координатор. Распределяет работу между агентами и ведет журнал действий по каждому шагу. Работает на основе правил маршрутизации и языковой модели.

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

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

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

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

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

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

У многих систем нет программного интерфейса (API), то есть заранее подготовленного способа, которым одна программа напрямую обращается к другой. Так устроены старые учетные системы, банковские и складские программы, а также государственные веб-порталы (Росреестр, Федеральная таможенная служба, отраслевые и региональные порталы). К таким системам нельзя подключиться обычной интеграцией, поэтому сотрудник заходит в них вручную и сам открывает экран программы, ищет запись, вводит данные в форму, переключает вкладки, выгружает выписки и статусы, заполняет веб-формы на портале. Эта ручная работа повторяется ежедневно, отнимает время и приводит к ошибкам ввода. Классические программы-роботы (их называют RPA, это программы, которые повторяют заранее записанную последовательность действий по фиксированным координатам на экране) при смене верстки или интерфейса перестают работать и требуют постоянной доработки.

Мы собираем ИИ-агента, который действует как человек за рабочим местом там, где прямого подключения к системе нет. Если объяснить простыми словами, агент видит то же, что видел бы сотрудник на экране, понимает по смыслу, что перед ним, и выполняет нужные действия. Есть два режима работы:

• Работа через экран приложения. Агент видит экран устаревшей системы по изображению экрана, понимает, какие на нем элементы, и выполняет последовательность действий (вход в учетную систему, поиск записи, ввод данных в форму, переход по вкладкам, подтверждение операции). Работает на базе компьютерного зрения и языковой модели. В отличие от классических программ-роботов агент ориентируется по смыслу того, что на экране, а не по фиксированным координатам, поэтому устойчивее к изменениям интерфейса.
• Работа через веб-страницу портала. Агент работает в браузере, извлекает данные с веб- и государственных порталов (Росреестр, таможня и другие), отслеживает тендеры и электронные торговые площадки (площадки, где проходят торги и закупки), заполняет веб-формы, выгружает выписки и статусы. Работает на базе компьютерного зрения и языковой модели и ориентируется по смыслу страницы, поэтому смену верстки переносит легче, чем хрупкие программы, которые считывают данные прямо из кода страницы.

На ответственных операциях (перевод средств, изменение договора, подача документа в государственный орган) сотрудник обязательно подтверждает действие до того, как оно выполнено. Если агент не уверен или истекло время на операцию, он останавливается и передает задачу человеку, а не додумывает. Это вспомогательный механизм. Когда к системе можно подключиться обычной интеграцией, мы рекомендуем именно ее, потому что работа через экран дороже и медленнее прямого подключения. Агент через экран применяется тогда, когда обычная интеграция невозможна.

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

Мы собираем ИИ-агента, который закрывает верх воронки продаж, от поиска клиентов до передачи готового проверенного контакта менеджеру по продажам. На одной инфраструктуре мы объединяем следующие компоненты:

• Поиск клиентов. Агент ищет компании и контактных лиц по заданным признакам портрета клиента. Это отрасль, размер, а для логистики еще и внешнеторговые потоки по товарным группам, направлениям и объемам. Оценку соответствия компании портрету выполняет модель классического машинного обучения, а языковая модель извлекает и обобщает сведения из источников данных о компаниях.
• Первичный контакт по сценарию. Агент формирует первое сообщение под конкретную компанию и роль, а не одинаковую рассылку, и ведет разговор по заданному сценарию в переписке (почта, мессенджер) или голосом. Работает на базе языковой модели, а для голоса дополнительно на распознавании и синтезе речи.
• Квалификация интереса. Агент задает уточняющие вопросы, проверяет, подходит ли клиент по заданным признакам, отрабатывает базовые возражения и отсеивает неподходящих. Работает на базе языковой модели и заданной логики квалификации.
• Передача менеджеру. Агент заносит проверенный контакт в систему учета клиентов (CRM) вместе с историей разговора, а при готовности клиента предлагает встречу. Работает на базе языковой модели и подключения к системе учета клиентов.

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

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

Мы собираем ИИ-агента, который в одном диалоге не только отвечает, но и сам выполняет действие в системах компании. Внутри языковая модель понимает запрос клиента и обращается к учетным системам компании, где не только читает данные, но и записывает их. На одной инфраструктуре мы объединяем следующие компоненты:

• Диалоговый слой. Понимает обращение клиента в чате, мессенджере или по телефону, ведет диалог, уточняет детали. Тему и намерение обращения на входящем потоке определяет быстрый классификатор (классическое машинное обучение), диалог ведет языковая модель, голос обрабатывает распознавание речи.
• Выполнение действий в системах. Агент обращается к системе управления клиентами, системе управления заказами, складской или банковской системе и совершает операцию, например узнает статус заказа, оформляет возврат, меняет адрес или регистрирует претензию. Работает через программный интерфейс (API) с ограниченными правами, то есть агент может делать только то, что ему явно разрешено.
• Контур подтверждения человеком. По каждому действию задан порог, до какой суммы и до какого уровня риска агент действует сам, а что требует подтверждения клиента или оператора. В банке выписку агент готовит сам, а перевод проводит только после явного подтверждения клиента. Работает на основе заданных порогов и правил, без языковой модели.
• Журнал действий. Каждый шаг агента записывается, чтобы можно было разобрать любую операцию и подтвердить ее соответствие требованиям. Работает на основе системы протоколирования.

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

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

Мы собираем ИИ-агента (программу, которая сама выполняет цепочку действий по подбору персонала). Он берет на себя рутину верхней части воронки найма и оставляет решения рекрутеру. На одной инфраструктуре мы объединяем следующие компоненты:

• Поиск кандидатов по смыслу. Агент находит подходящих людей в базах и на площадках поиска работы и сопоставляет их с вакансией по смыслу требований, а не по совпадению отдельных слов. Работает на базе языковой модели и семантического поиска. Семантический поиск - это подбор по смыслу текста, при котором модель переводит смысл резюме и вакансии в числа (смысловые представления) и сравнивает уже их. Поэтому в выборку попадает и подходящий человек, который описал свой опыт другими словами.
• Отбор резюме. Агент ранжирует отклики по соответствию вакансии, отсеивает неподходящие и формирует короткий список с объяснением, почему именно этот кандидат подходит. Сопоставление и ранжирование выполняет специализированная модель классического машинного обучения на тех же смысловых представлениях текста, а объяснение выбора готовит языковая модель.
• Первичный контакт. Агент связывается с кандидатами, отвечает на типовые вопросы, собирает уточнения и проводит первичную квалификацию (проверяет базовое соответствие кандидата вакансии). Работает на базе языковой модели.
• Назначение интервью. Агент согласовывает время и сводит календари кандидата и рекрутера. Работает на основе правил планирования.
• Обновление системы подбора. Агент фиксирует статусы и контекст по каждому кандидату в системе управления подбором персонала, чтобы у рекрутера была полная картина. Работает через программный интерфейс (API) к этой системе.

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

У финансового директора закрытие периода - это долгая ручная работа. Данные лежат в нескольких системах, среди них хранилище данных, система управления ресурсами предприятия и биллинг (система выставления счетов). Финансовая команда вручную выгружает эти данные, сверяет их между собой, ищет расхождения и собирает управленческую отчетность в нужных разрезах. На анализ и сценарные расчеты времени почти не остается, а когда руководство просит модель «что будет, если выручка вырастет, а затраты изменятся», построение такой модели снова занимает дни. Чтобы получить ответ на простой вопрос к данным, финансовому директору приходится ставить задачу аналитику и ждать. В результате команда тратит силы на сбор и сверку, а не на выводы.

Мы собираем ИИ-агента с управляемым доступом к финансовым системам компании. На одной инфраструктуре мы объединяем следующие компоненты:

• Сбор и сверка данных. Агент подключается к хранилищу данных, системе управления ресурсами предприятия и биллингу, собирает данные и сверяет их между собой, находя расхождения. Работает через программный интерфейс (API) к этим системам.
• Черновик закрытия периода. Агент сводит данные, проводит сверки и готовит черновик закрытия периода, который финансовая команда проверяет. Работает на базе языковой модели и заданных правил учета.
• Сценарные модели. Агент строит расчеты «что будет, если» по выручке, затратам и экономике на единицу продукта. Числа считает расчетный движок по заданным правилам, а языковая модель формулирует выводы и отвечает на вопросы по модели. Числовые значения из языковой модели не берутся.
• Запросы к данным на естественном языке. Финансовый директор задает вопрос обычными словами, а агент сам формулирует запрос к базе данных и возвращает ответ. Работает на базе языковой модели, которая переводит вопрос в запрос к базе данных.
• Журнал запросов и действий. Каждый запрос агента к данным и каждый его шаг записываются, чтобы результат можно было проверить. Работает на основе автоматического ведения журнала.

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