- 1Отдельного закона о валидации любого AI-скоринга в России нет. Но там, где результат модели становится частью регулируемого решения, регулятор уже спрашивает, можно ли ей доверять.
- 2Защищает компанию не AI Policy, а связка из реестра моделей, независимой проверки перед релизом, контроля изменений и журнала решений.
- 3Внешний LLM не снимает ответственность. Условия об изменениях модели, данных и журналах должны быть в договоре с поставщиком.
С 1 января 2026 года на российском микрофинансовом рынке произошло изменение, которое стоит читать шире, чем очередную поправку к расчёту ПДН. Банк России прямо зафиксировал: МФО больше не могут использовать невалидируемые регулятором внутренние методики оценки дохода заёмщика по займам до 50 тыс. рублей и автозаймам. В 2025 году модельный подход применялся уже в 71% соответствующих выдач. После изменения правил большинство компаний вернулось к более формализованным источникам оценки дохода.1
Это не означает, что с 2026 года в России появился универсальный закон «каждый AI-скоринг должен пройти валидацию Банка России». Такого правила нет. Но для IT-компаний и финтеха здесь важен другой вывод: модель перестаёт быть только технологией в тот момент, когда её output становится частью регулируемого бизнес-решения. Именно в этой точке возникает Model Governance.
Что именно произошло на рынке МФО
Банк России в обзоре рынка за I квартал 2026 года связал снижение выдач, среди прочего, с ужесточением порядка оценки долговой нагрузки. Регулятор отдельно отметил исключение модельного подхода без его валидации Банком России и указал, что это способствовало использованию более корректных сведений о доходах клиентов. Доля заёмщиков с высокими доходами, которые ранее принимались в расчёт преимущественно со слов клиента, снизилась почти втрое.2
Для самой МФО это конкретное отраслевое регулирование. Для остальных компаний это хороший пример того, как будет выглядеть правовой риск вокруг алгоритмов.
Представим SaaS, который рассчитывает лимит клиенту. Модель разработана data science-командой, затем несколько раз дообучалась, часть признаков изменилась, а внешний поставщик обновил API. С точки зрения продукта всё работает. Но если через полгода потребуется объяснить, почему конкретному клиенту был установлен именно такой лимит, у компании возникает другой набор вопросов: какая версия модели приняла решение, на каких данных, какие метрики действовали, кто разрешил релиз и можно ли воспроизвести результат.
Это уже не MLOps в чистом виде. Это доказательная инфраструктура бизнеса.
Действующее право, soft law и наша практическая модель
Важно не смешивать уровни регулирования.
Действующее отраслевое регулирование. В отдельных сегментах финансового рынка модели уже встроены в пруденциальные и потребительские требования. Пример МФО показывает, что регулятор может ограничить использование внутренней модели, если не обеспечен требуемый механизм её проверки. Банк России также последовательно развивает риск-ориентированный подход к ИИ на финансовом рынке.3
Рекомендации и регуляторная политика. В материалах Банка России по ИИ обсуждаются аудит, мониторинг, управление жизненным циклом и рисками ИИ‑систем. Это не надо выдавать за универсальную обязанность каждой российской компании. Но для финансовых организаций это ориентир того, какие вопросы регулятор считает существенными.4
Практическая модель AI Governance. Инвентаризация моделей, независимый validation gate, drift monitoring, change control и audit trail составляют предлагаемую нами архитектуру управления риском. Её конкретный объём зависит от продукта и отрасли.
Почему обычного тестирования недостаточно
У разработчика естественный вопрос: чем validation gate отличается от обычного QA. QA отвечает, работает ли система в соответствии с техническими требованиями. Валидация модели отвечает на более неприятный вопрос: можно ли доверять модели именно в том бизнес-процессе, куда её поставили.
Accuracy 94% сама по себе почти ничего не говорит юристу или риск-менеджеру. Нужно знать цену ошибки. Для антифрода false positive может заблокировать нормального клиента. Для скоринга false negative увеличивает кредитный риск. Для LLM в службе поддержки hallucination может превратить справочный ответ в недостоверный оффер. Поэтому метрики должны быть связаны с последствиями.
Как должен выглядеть Model Governance Gate
Рабочая схема начинается не с длинной AI Policy, а с реестра. Компания должна знать, какие модели реально работают в production и какие решения они затрагивают. Для каждой существенной модели фиксируются владелец, назначение, версия, источники данных, критичность решения, baseline-метрики и допустимые пороги. Перед production-релизом проводится отдельная проверка, и желательно, чтобы её выполнял не тот человек, который оптимизировал модель под KPI.
- 01Реестр моделей
- 02Класс риска
- 03Валидация
- 04Допуск к релизу
- 05Мониторинг
- 06Контроль изменений
- 07Журнал решений
Следующий слой составляет change control. Новая версия модели, новый датасет, новый системный prompt, смена внешнего LLM-провайдера или добавление инструмента AI-agent могут изменить риск-профиль системы. Значит, не каждое изменение должно уходить в production автоматически.
И наконец, audit trail. Для значимых решений нужна возможность восстановить как минимум входные данные или их идентификатор, версию модели, результат, применённые policy rules и факт ручного подтверждения, если оно требовалось.
Внешний LLM тоже является модельным риском
У SaaS-компаний есть соблазн считать, что модель не наша, значит и governance не наш. С юридической точки зрения это слабая позиция. Если внешний API встроен в продукт компании, именно компания определяет сценарий использования и отношения со своим клиентом.
Поэтому в договоре с AI-поставщиком важны не только uptime и цена токенов. Нужны условия об изменениях модели, обработке данных, журналировании, сроках уведомления о существенных изменениях, инцидентах, возможности выгрузить необходимые логи и последствиях деградации сервиса.
Технически полезно отделять provider API от бизнес-процесса собственным AI Gateway или policy layer. Тогда смена модели не меняет автоматически правила принятия критичного решения.
Что проверить компании сейчас
Не нужно валидировать одинаково корпоративный генератор поздравлений и модель, определяющую кредитный лимит. Риск-ориентированный подход начинается с классификации.
После классификации задайте простой вопрос: если через шесть месяцев придётся доказать, почему система сделала именно это, что мы сможем показать? Если ответ звучит как «посмотрим в логах, если они сохранились», governance ещё нет.
Практический вывод
Российское регулирование ИИ развивается не как один универсальный AI Act, а фрагментарно: через персональные данные, финансовое регулирование, информационную безопасность, потребительские требования и отраслевые правила. Поэтому ждать единого федерального перечня обязательных процедур рискованно.
Кейс МФО показывает более практичную траекторию: сначала модель становится значимой частью регулируемого решения, затем регулятор начинает спрашивать, насколько этой модели можно доверять и как подтверждается качество её применения. Для бизнеса разумная подготовка состоит не в бюрократической папке «про ИИ», а в связке из реестра, классификации, проверки, допуска, мониторинга, контроля изменений и журнала решений.
