RPA против ИИ: выбор технологии для автоматизации банков

В той же выборке 82% применяют ИИ для выявления мошенничества, 80% — для AML/CFT, 80% — для оценки кредитоспособности, около 75% — для профилирования и кластеризации клиентов и транзакций. Это срез ответов банков, участвовавших в опросе EBA, а показатель по всему сектору на сегодня не установлен.

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

Фундаментальные различия: от жестких алгоритмов к интерпретации данных

RPA — программный робот, исполняющий заранее описанную последовательность действий. Digital.gov определяет технологию как решение с низким или нулевым объёмом программирования: оператор записывает клики и ввод данных, робот их воспроизводит. Архитектура детерминирована. Если интерфейс меняется, робот ломается. Если правило не покрывает кейс, робот останавливается или эскалирует задачу оператору.

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

RPA детерминирован, ИИ вероятностен. Это разные кривые отказа и разные требования к аудиту.

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

Строки таблицы — не абстракция. У каждой ячейки конкретные последствия для SLA, бюджета и периметра аудита.

Сценарии применения RPA: автоматизация структурированных операций

RPA закрывает бэк-офисные операции с фиксированным входом и выходом:

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

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

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

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

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

Интеллектуальные системы в действии: антифрод и кредитный скоринг

Сценарии ИИ лежат там, где правила заранее не описаны или меняются быстрее, чем их успевают формализовать:

• классификация транзакций: мошенничество или легитимная операция;
• кредитный скоринг на поведенческих и транзакционных данных;
• AML/CFT — выявление подозрительных паттернов в графах транзакций;
• кластеризация клиентов для сегментации и таргетинга;
• прогноз оттока и LTV;
• обработка неструктурированных документов и обращений.

По отчёту EBA за декабрь 2022 года, 82% банков-респондентов применяют или разрабатывают ИИ для выявления мошенничества, 80% — для AML/CFT, 80% — для оценки кредитоспособности. Это доли ответов участников RAQ, а не универсальный показатель по глобальному банковскому сектору и не оценка на текущий квартал.

Логика концентрации именно в этих трёх направлениях проста. Антифрод, AML и кредитный скоринг исторически работали на правилах, которые постоянно отставали от схем мошенников и поведения заёмщиков. В каждом из них накоплены большие массивы размеченных данных — исторических транзакций с известным исходом, кредитных дел с дисконтом по факту платёжного поведения. Эти данные и есть топливо для модели. Там, где данных мало или метка размыта, отдача ИИ быстро падает.

Архитектурный риск ИИ — дрейф модели. Со временем распределение входных данных смещается, метрики качества деградируют. Без мониторинга и регулярного переобучения модель выдаёт ошибочные решения без видимого сигнала. В отличие от RPA, ошибка ИИ часто невоспроизводима: один и тот же вход может давать разный выход в зависимости от версии модели, состояния пайплайна и состава обучающих данных. Диагностика такой ошибки требует отдельного контура наблюдения, иначе сбой остаётся незамеченным до жалобы клиента или предписания регулятора.

Правовые барьеры и прозрачность решений в эпоху ИИ

Регуляторы ужесточают требования к объяснимости автоматизированных решений. В США CFPB 26 мая 2022 года выпустил циркуляр 2022-03: при отказе в кредите или ином неблагоприятном решении кредитор обязан сообщить конкретные и точные основные причины, даже если решение принято сложным алгоритмом, ИИ или моделью машинного обучения. Положения касаются Regulation B и не переносятся автоматически на другие юрисдикции.

Для американских банков это прямое следствие из Equal Credit Opportunity Act и Reg B: «основные причины» должны быть понятны клиенту, конкретны и достаточны для проверки. Если модель выдаёт решение, банк обязан уметь перевести его на язык причин, доступный заёмщику. Это требование к архитектуре объяснения, а не только к интерфейсу уведомления.

В ЕС Европейское банковское управление отдельно рассматривало применение машинного обучения во внутренних рейтинговых моделях IRB и его пересечение с GDPR и Законом ЕС об ИИ. Ведомство отмечало правовую неопределённость и необходимость дополнительных уточнений для снижения регуляторного риска. GDPR и Закон ЕС об ИИ задают разные, частично пересекающиеся слои требований: один — к обработке персональных данных и автоматическим решениям, второй — к самим системам ИИ как продуктам с разным уровнем риска. Банку, работающему на нескольких рынках, приходится собирать комплаенс-картину из нескольких режимов одновременно.

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

Риск-менеджмент при внедрении цифровых инструментов

Базельский комитет в сообщении от 16 мая 2024 года перечислил ИИ, машинное обучение, API и облачные вычисления среди технологий, меняющих банковскую цепочку создания стоимости. Одновременно комитет указал: цифровизация создаёт новые уязвимости и усиливает существующие риски. Это концентрация поставщиков облачных услуг, зависимость от внешних API, непрозрачность моделей, кибератаки на пайплайны данных, ошибки в обучающих выборках. Все эти факторы входят в периметр операционного риска и требуют отдельного контура контроля.

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

Практический риск-менеджмент по каждой технологии различается.

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

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

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

Выбор технологии под задачу

RPA и ИИ решают разные задачи. Это разные слои автоматизации с разной кривой отказа. Универсального сравнения стоимости, скорости и точности в открытых источниках нет, метрики зависят от банка, процесса и качества данных.

Ориентир по задачам:

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

Гибридная связка — практический сценарий, к которому банки приходят после раздельного внедрения RPA и ИИ. RPA закрывает перенос данных между системами без API и подготовку витрин, ИИ принимает решение на конкретном узле — скоринговый балл, антифрод-вердикт, классификацию обращения, а человек остаётся в контуре контроля исключений и обратной связи. Такой контур позволяет банку получить скорость и масштабируемость автоматизации, сохранив аудируемость и управляемость процессов.

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

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