MRM для GenAI: что не работает и что с этим делать

Есть такое место, в котором стыкуются самая зрелая дисциплина банковского риск-менеджмента и самая новая технология индустрии. Это место — Model Risk Management для GenAI. И оно — взрывоопасное. Потому что классический MRM, построенный на десятилетиях опыта работы с кредитными скорингами, антифрод-моделями и расчётами капитала, столкнувшись с большими языковыми моделями, не работает. Не «плохо работает». Не работает в принципе.

Я впервые остро почувствовал эту проблему на фасилитационной сессии в одном крупном международном банке в 2025 году. За столом, посвящённом теме Data & Model Risk, один из самых опытных MRM-специалистов банка говорил примерно следующее: «Наш фреймворк был построен для детерминированных моделей. Модель делает предсказание, мы его валидируем — прогоняем на отложенной выборке, сравниваем с фактом, смотрим на ошибки, строим confusion matrix. Всё понятно. А что мне делать с GenAI? Я не могу валидировать ответ GPT на запрос, потому что ответ каждый раз другой. Я не могу объяснить этот ответ, потому что модель не имеет внутренней логики в нашем понимании. У меня в руках всё разваливается».

Это честная формулировка проблемы. И это проблема, с которой сейчас сталкивается каждый крупный банк, пытающийся внедрить GenAI в регулируемые процессы. В этой заметке — что именно не работает в классическом MRM, когда его применяют к GenAI, и что делать вместо этого.

Почему классический MRM не работает

Классический MRM, описанный в документах типа SR 11-7 (Federal Reserve) и BCBS 239, построен на четырёх принципах.

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

Второй принцип — модель объяснима. У модели есть внутренняя структура, которую можно посмотреть: веса, коэффициенты, деревья решений, feature importance. Можно сказать, почему модель приняла такое решение.

Третий принцип — модель стабильна. Модель не меняет свои веса по собственной воле. Изменения происходят только при явном дообучении, которое тоже валидируется.

Четвёртый принцип — модель контролируема. Модель работает в контуре банка, её данные известны, её версия известна, её поведение воспроизводимо.

GenAI нарушает все четыре принципа.

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

Нарушение второе — не объяснима. У LLM есть миллиарды параметров, но они не поддаются интерпретации в терминах «вот этот вес отвечает за то-то». Современные инструменты объяснимости (attention maps, SHAP для LLM, circuit analysis) дают фрагментарные объяснения, но не целостные. Попросить LLM «объясни свой ответ» — это не объяснение, это новый генеративный ответ, который сам нуждается в валидации.

Нарушение третье — не стабильна. Модель за API-доступом может меняться без уведомления пользователя. OpenAI может сегодня отдавать один GPT-4, завтра — обновлённый, и это будут разные модели с разным поведением. Для on-premise моделей стабильность выше, но и они обновляются, дообучаются, адаптируются.

Нарушение четвёртое — вопрос контроля. На практике крупные банки не используют облачные модели для регулярной оценки рисков — это практически нереализуемо с точки зрения информационной безопасности. Облачные модели могут применяться для разработки пайплайнов и прототипирования, но не для продуктивной работы с клиентскими данными. Тем не менее теневое использование облачных API сотрудниками существует (см. заметку про теневой GenAI), и MRM должен учитывать этот риск. Для on-premise моделей контроль выше, но и они обновляются, дообучаются — версия модели может не совпадать с документированной.

Результат: когда MRM-специалист пытается применить классические процедуры к GenAI-системе, он упирается в стену. Все его инструменты перестают работать. И возникает желание либо полностью запретить GenAI в регулируемых процессах (что невозможно — см. заметку про теневой GenAI), либо притвориться, что всё работает (что опасно для банка).

Что работает вместо классического MRM

Правильный путь — не отказаться от MRM, а расширить его новыми элементами, которые отвечают специфике GenAI. Я их называю «четыре столба MRM для GenAI».

Первый столб — трассируемость. Вместо «валидации на отложенной выборке» — детальное логирование каждого запроса к модели. Не только вход (промпт) и выход (ответ), но и: версия модели, timestamp, контекст (какие документы были в RAG-памяти), пользователь, бизнес-процесс. Логи сохраняются навсегда и могут быть использованы для ретроспективной проверки. Это даёт ответ на вопрос «какие решения мы принимали с помощью GenAI в период с X до Y».

Второй столб — обратная пирамида принятия решений. Вместо «объясни решение модели» — структурированный отчёт, который позволяет проверить решение на любой глубине. В нашей практике мы пришли к формату, который называем «обратной пирамидой» или executive summary. Его структура напоминает отчёты крупных консалтинговых агентств, но адаптирована для AI-систем.

Отчёт строится по слоям:

1. Проект решения — рекомендация наверху. Если у пользователя нет времени, он может посмотреть только на это и быстро принять решение.
2. Факты, допущения, интерпретации — на что опиралась модель. Важно помечать каждый элемент: это факт из документа, это допущение модели, или это интерпретация?
3. Точные цитаты из документов — не пересказ LLM, а прямые выдержки. На этом слое идёт проверка, что модель не галлюцинировала и не придумала цитаты из документов, которых нет.
4. Расчёты и вычисления — если решение основано на цифрах, показать промежуточные шаги.
5. Подсветка фрагментов документов — выделение цветом конкретных мест в исходных документах, которые использовались для заключения. Это позволяет пользователю совершать меньше движений для быстрой оценки качества рассуждений.
6. Ссылка на источник — номер страницы, название документа, фрагмент таблицы или выгрузки данных.
7. Доступ к исходным документам и данным — возможность самостоятельно открыть оригинал и проверить.

Ключевая идея: если пользователь доверяет системе — он останавливается на первом слое. Если не доверяет — погружается глубже. Каждый следующий слой уменьшает неопределённость и приближает к первоисточнику. Это не «объяснение модели» в классическом MRM-смысле, но это прозрачность, достаточная для принятия решения и для внутреннего аудита.

Третий столб — continuous monitoring. Вместо «разовой валидации перед выходом в прод» — постоянный мониторинг поведения модели в продакшне. Drift-детекция: не меняется ли распределение ответов со временем. Quality-metrics: не падает ли субъективное качество по оценкам пользователей. Cost-metrics: не растёт ли стоимость обработки одного запроса. Это даёт быстрое обнаружение проблем до того, как они превратятся в инцидент.

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

Практически: что это означает для банка

Если классический MRM в банке уже работает (а в крупных банках он работает), то внедрение GenAI не требует «выкинуть всё и сделать заново». Оно требует добавить четыре новых слоя поверх существующего.

Слой первый — логирование. Любая система GenAI в банке должна иметь логирование на уровне каждого запроса. Это техническая задача, и её надо выполнять на этапе архитектурного проектирования, а не добавлять потом. Если вы пытаетесь добавить логирование в уже запущенную систему, вы потратите месяцы.

Слой второй — семантическое связывание с источниками. Каждый ответ модели, который используется в регулируемом процессе, должен сопровождаться ссылками на источники. Для RAG-систем это встроенное свойство архитектуры. Для чистых LLM без RAG — это сложнее, и я в таких случаях рекомендую не использовать чистые LLM в регулируемых процессах, а строить их как RAG с контролируемой базой знаний.

Слой третий — мониторинг в проде. Отдельная наблюдаемость для AI-систем, не совмещённая с обычным APM. Метрики поведения модели: distribution shifts, response quality, cost per query, latency, error rate. Алертинг на аномалии.

Слой четвёртый — политика использования. Чёткие правила: какие процессы можно автоматизировать через GenAI, какие нельзя; какие данные можно отдавать в модель, какие нельзя; кто отвечает за результаты. Это управленческий документ, не технический.

Что я рекомендую делать

Если вы MRM-специалист или руководитель риск-функции банка, и вы столкнулись с задачей адаптировать MRM под GenAI, вот что я рекомендую.

Первое — не пытаться переизобретать всё. У вас есть работающий классический MRM. Он продолжает работать для классических моделей. Не нужно его выкидывать. Нужно добавить новый блок для GenAI, как отдельный раздел корпоративной политики.

Второе — начать с логирования. Это техническая задача, и она — основа всего остального. Без логирования невозможны ни трассируемость, ни continuous monitoring. Первое, что нужно потребовать от любого GenAI-пилота в банке, — как вы будете логировать каждый запрос.

Третье — согласовать политику с ИБ и юристами. Политика работы с GenAI в банке — это документ, который должен быть согласован с четырьмя сторонами: бизнесом (кому это нужно), IT (как это будет работать технически), информационной безопасностью (какие риски), юристами (соответствие нормативным требованиям). Без согласования у политики нет веса.

Четвёртое — обучать команду. В моих корпоративных программах и фасилитациях есть отдельный блок по адаптации MRM под GenAI. Это не презентация, это разбор практических ситуаций и совместная выработка решений.

Где об этом подробнее

Эта заметка — введение. Полная методика адаптации MRM под GenAI — большая тема, которой я посвящаю отдельную главу в моей третьей книге «Автономный Бизнес», выходящей в декабре 2026 года в крупнейшем издательстве РФ. В книге — детальный разбор всех четырёх столбов, практические шаблоны политик, примеры из практики.

До выхода книги — формат обсуждения через корпоративные программы и Диагностику автономности. Если у вас конкретная задача адаптации MRM для GenAI в вашем банке — приходите обсудить.

Записаться на обсуждение →