AI Model Governance в России: почему модель уже нельзя выпускать в прод без валидации

С 1 января 2026 года на российском микрофинансовом рынке произошло изменение, которое стоит читать шире, чем очередную поправку к расчёту ПДН. Банк России прямо зафиксировал: МФО больше не могут использовать невалидируемые регулятором внутренние методики оценки дохода заёмщика по займам до 50 тыс. рублей и автозаймам. В 2025 году модельный подход применялся уже в 71% соответствующих выдач. После изменения правил большинство компаний вернулось к более формализованным источникам оценки дохода.¹

Это не означает, что с 2026 года в России появился универсальный закон «каждый AI-скоринг должен пройти валидацию Банка России». Такого правила нет. Но для IT-компаний и финтеха здесь важен другой вывод: модель перестаёт быть только технологией в тот момент, когда её output становится частью регулируемого бизнес-решения. Именно в этой точке возникает Model Governance.

1. Что именно произошло на рынке МФО

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

Для самой МФО это конкретное отраслевое регулирование. Для остальных компаний хороший пример того, как будет выглядеть правовой риск вокруг алгоритмов.

Представим SaaS, который рассчитывает лимит клиенту. Модель разработана data science-командой, затем несколько раз дообучалась, часть признаков изменилась, а внешний поставщик обновил API. С точки зрения продукта всё работает. Но если через полгода потребуется объяснить, почему конкретному клиенту был установлен именно такой лимит, у компании возникает другой набор вопросов: какая версия модели приняла решение, на каких данных, какие метрики действовали, кто разрешил релиз и можно ли воспроизвести результат.

Это уже не MLOps в чистом виде. Это доказательная инфраструктура бизнеса.

2. Действующее право, soft law и наша практическая модель

Важно не смешивать уровни регулирования.

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

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

Практическая модель AI Governance. Инвентаризация моделей, независимый validation gate, drift monitoring, change control и audit trail — это уже предлагаемая нами архитектура управления риском. Её конкретный объём зависит от продукта и отрасли.

3. Почему обычного тестирования недостаточно

У разработчика естественный вопрос: чем validation gate отличается от обычного QA. QA отвечает, работает ли система в соответствии с техническими требованиями. Валидация модели отвечает на более неприятный вопрос: можно ли доверять модели именно в том бизнес-процессе, куда её поставили.

Например, accuracy 94% сама по себе почти ничего не говорит юристу или риск-менеджеру. Нужно знать цену ошибки. Для антифрода false positive может заблокировать нормального клиента. Для скоринга false negative увеличивает кредитный риск. Для LLM в службе поддержки hallucination может превратить справочный ответ в недостоверный оффер. Поэтому метрики должны быть связаны с последствиями.

4. Как должен выглядеть Model Governance Gate

Рабочая схема начинается не с длинной AI Policy, а с реестра. Компания должна знать, какие модели реально работают в production и какие решения они затрагивают.

Для каждой существенной модели фиксируются владелец, назначение, версия, источники данных, критичность решения, baseline-метрики и допустимые пороги. Перед production-релизом проводится отдельная проверка. Желательно, чтобы её выполнял не тот же человек, который оптимизировал модель под KPI.

Следующий слой — change control. Новая версия модели, новый датасет, новый системный prompt, смена внешнего LLM-провайдера или добавление инструмента AI-agent могут изменить риск-профиль системы. Значит, не каждое изменение должно уходить в production автоматически.

5. Внешний LLM тоже является модельным риском

У SaaS-компаний есть соблазн считать, что модель не наша, значит и governance не наш. С юридической точки зрения это слабая позиция. Если внешний API встроен в продукт компании, именно компания определяет сценарий использования и отношения со своим клиентом.

Поэтому в договоре с AI-поставщиком важны не только uptime и цена токенов. Нужны условия об изменениях модели, обработке данных, журналировании, сроках уведомления о существенных изменениях, инцидентах, возможности выгрузить необходимые логи и последствиях деградации сервиса.

Технически полезно отделять provider API от бизнес-процесса собственным AI Gateway или policy layer. Тогда смена модели не меняет автоматически правила принятия критичного решения.

6. Что проверить компании сейчас

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

Красная зона

Модели, которые влияют на деньги, доступ к услуге, права физлица, безопасность, антифрод, скоринг, существенные договорные условия или действия AI-agent через API

Жёлтая зона

Модели, создающие проекты решений, которые проверяет человек

Зелёная зона

Вспомогательные сценарии без самостоятельного внешнего эффекта

После классификации задайте простой вопрос: если через шесть месяцев придётся доказать, почему система сделала именно это, что мы сможем показать. Если ответ звучит как «посмотрим в логах, если они сохранились», governance ещё нет.

7. Практический вывод

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

Кейс МФО показывает более практичную траекторию: сначала модель становится значимой частью регулируемого решения, затем регулятор начинает спрашивать, насколько этой модели можно доверять и как подтверждается качество её применения.

Для бизнеса разумная подготовка — не бюрократическая папка «про ИИ», а связка model inventory → risk tier → validation → approval → monitoring → change control → audit trail.