243-ФЗ и банковский сектор: единственная отрасль, названная в законе прямо

Норма компактная, и её стоит прочитать целиком, потому что в пересказах она обычно превращается в «банкам запретят зарубежный ИИ».

Правительство вправе устанавливать случаи, когда допускается применение исключительно суверенных и (или) национальных больших фундаментальных моделей, а также перечень исключений из таких случаев. Это пункт 3 части 2 статьи 5. В том же пункте — оговорка: в банковской сфере и иных сферах финансового рынка такие случаи определяются по согласованию с Центральным банком. Аналогичное согласование предусмотрено в пункте 4, где речь о требованиях по предотвращению рисков применения моделей в отдельных отраслях.

Прямого запрета иностранных моделей в тексте нет. Есть полномочие, которым пока не воспользовались.

Существенно другое: банковская сфера — единственная отрасль, поименованная в законе. Ни КИИ, ни энергетика, ни транспорт, ни здравоохранение по именам не названы, они попадут в регулирование через общий механизм перечня. Финансовый сектор выделен отдельно, и для него это главная норма закона — не маркировка, о которой написали все, и не исключение из авторского права, которое адресовано разработчикам моделей со статусом. Полный постатейный разбор 243-ФЗ — в отдельном материале; здесь только то, что относится к финансовому сектору.

Практическое следствие оговорки про согласование с ЦБ важнее самой оговорки.

Отслеживать придётся два потока документов. Постановления Правительства зададут рамку — в каких случаях допустимы только модели со статусом. Акты и позиции Банка России определят, как это применяется к кредитным организациям, НФО, платёжным системам и участникам рынка ценных бумаг. Опыт последних лет по ГОСТ Р 57580 и требованиям к операционной надёжности показывает, что регулятор редко ограничивается ретрансляцией общей нормы: появляются свои сроки, свои формы отчётности, своя градация по значимости организации.

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

Есть и обратная сторона, которую стоит проговорить, потому что она работает в пользу банков. Согласование с Банком России — фильтр против резких движений: регулятор, отвечающий за устойчивость финансовой системы, плохо относится к сценариям, где половина рынка одновременно меняет технологический стек под давлением срока. Разумное ожидание — поэтапный режим, а не отсечка «с такого-то числа только суверенные модели». Это ожидание, а не факт, и на планирование оно влияет слабо: отсрочка по части 3 статьи 13 привязана к дате ввода вашей системы, а не к мягкости режима. Мягкий режим достаётся тем, кто успел.

Список пробелов для банка важнее списка требований: он определяет, что сейчас можно написать в позиции для правления.

Полный список пробелов — от отсутствия составов административных правонарушений до снятой категории «доверенная модель» — в постатейном разборе; для банковского меморандума хватает трёх строк выше.

Отдельно про ответственность, потому что в банке это блокирующий вопрос. Пока за решение отвечает должностное лицо, его утвердившее, руководитель кредитного подразделения или комплаенса оставляет риск себе, а компании передаёт экономию. 243-ФЗ этот барьер не снял и в ближайшее время не снимет, поэтому сценарии, где модель готовит и объясняет, а решение принимает человек, остаются единственными проходимыми в чувствительном контуре. Шесть таких сценариев мы разбирали в статье про ИИ в банках on-premise.

243-ФЗ не добавил банку ни одной новой обязанности по данным. Всё, что ограничивало генеративный ИИ в банковском контуре до июля 2026 года, ограничивает его и сейчас.

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

152-ФЗ работает независимо: подключение каждого нового внешнего сервиса означает переоценку состава операторов, оснований и места обработки. Мы разбирали этот механизм в материале про ИИ и персональные данные.

Требования Банка России к защите информации и операционной надёжности добавляют третий слой — со своей оценкой соответствия и внешним аудитом. Конкретные положения сверяются под тип организации; важен сам факт: генеративный контур попадает в область оценки наравне с остальными технологическими процессами.

Что 243-ФЗ действительно добавил — так это вторую ось в проектном решении. К вопросу «где обрабатываются данные» прибавился вопрос «чья это модель». Раньше происхождение весов было темой закупки и лицензионной экспертизы. Теперь оно может стать темой соответствия.

Дальше — сравнение трёх типовых архитектур генеративного ИИ в банке по единственному критерию: что произойдёт, если Правительство и ЦБ введут ограничение на выбор моделей. Оценки трудозатрат — наши, по проектам развёртывания в закрытом контуре; они меняются в разы в зависимости от числа интеграций и требований к аттестации среды.

В двух сценариях данные пересекают периметр банка, в третьем — нет

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

Сильный довод в пользу вендора — и его границы

Средний сценарий надо разобрать отдельно: против всей этой логики есть возражение, которое звучит на каждом втором обсуждении. Статус суверенной или национальной модели получат в первую очередь крупные российские вендоры — у них есть российское юридическое лицо, свои ЦОД и ресурс на подтверждение соответствия. Значит их модель по API закрывает выбор модели надёжнее, чем открытые веса в собственной стойке, и формально это самая соответствующая конфигурация из трёх.

Оба вопроса закрываются только в одной конфигурации из четырёх

Спорить с этим по существу нечем. Ограничивает возражение себя само: вопрос выбора модели — не единственный. Банковская тайна и локализация производных данных решаются не статусом модели, а тем, где выполняется инференс и где остаются журналы запросов. Модель со статусом по внешнему API закрывает статью 5 закона об ИИ и не закрывает статью 26 закона о банках.

Второе ограничение — зависимость. Состав моделей, версии, тарифы, сроки поддержки и сам факт получения статуса определяет вендор. Для сценария, встроенного в кредитный процесс или контакт-центр, смена версии модели на стороне поставщика означает внеплановое регрессионное тестирование.

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

Здесь стоит быть честным, потому что рынок легко скатывается в лозунг «разверни у себя — и ты соответствуешь».

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

Устойчивость on-premise в другом. Замена базовой модели в готовом контуре — работа внутри существующей архитектуры: переиндексация корпуса, перенастройка сценариев, регрессионное тестирование, повторная приёмка. Дорого, но предсказуемо. У заказчика из промышленности мы меняли базовую модель на пилоте за три недели без потери качества; на промышленной установке та же операция стоит кратно дороже — там уже проиндексирован полный корпус и подписаны акты. Но это по-прежнему замена компонента, а не новый инфраструктурный проект.

Разница между «заменить модель» и «построить контур» — примерно порядок величины. Именно её банк и выбирает сейчас, пока перечня нет.

Норма, ради которой банку стоит читать закон, — часть 3 статьи 13.

Требование применять исключительно суверенные или национальные модели до 1 сентября 2032 года не распространяется на информационные системы, в которых такие модели созданы и (или) эксплуатируются на день вступления этой нормы в силу — то есть на 1 марта 2027 года — при условии обработки и хранения данных на территории Российской Федерации.

Два условия на отсечке и две ветки, которые из них следуют

В проектном плане это выглядит так. Система работает и данные лежат в России — банк получает пять с половиной лет вне режима ограничений, даже если финансовый сектор попадёт в перечень одним из первых. Не успели — общий режим применяется сразу, как только перечень выйдет. До отсечки чуть больше шести месяцев, и это тот редкий случай, когда регуляторный аргумент играет на инвестиционном комитете в пользу проекта; финансовая часть разговора при этом не меняется — структуру затрат на on-premise LLM мы разбирали отдельно.

Что именно проверяется

Оба условия — про инфраструктуру, и оба подтверждаются документами.

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

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

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

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

Дальше добавляется банковская специфика. Закупка GPU-серверов идёт через инвестиционный комитет со своими окнами планирования. Каждый генеративный сценарий связан с СЭД, CRM, ITSM, IAM, SIEM и DLP — переезд означает пересборку интеграций и повторное согласование с владельцами систем. Тестирование на реальных данных требует отдельного контура и процедуры обезличивания. Плюс два контура, работающих параллельно весь переходный период, — отдельная строка в бюджете эксплуатации.

Две задержки из банковских пилотов в план почти никогда не попадают. Чтобы RAG читал содержимое закрытых папок СЭД, нужно менять схему доступа — отдельное согласование с ИБ, месяц, если спохватились на развёртывании. И разграничение прав через вложенные группы Active Directory, где сервисная учётная запись получает либо слишком много, либо слишком мало. Обе лечатся на этапе архитектуры и обе всплывают на приёмке.

Перенос сценариев можно вести параллельно, аттестацию — нет

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

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

Что имеет смысл сделать до появления перечня, а не после.

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

Оценка стоимости миграции по каждому сценарию. Не «сколько стоит on-premise вообще», а сколько стоит перевести конкретно этот сценарий, с его интеграциями и требованиями к аттестации. Без этой цифры разговор на инвестиционном комитете сводится к обмену мнениями.

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

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

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

Банковская сфера — единственная отрасль, поименованная в 243-ФЗ. Не повод для тревоги и не основание для срочной миграции, но финансовый сектор с большой вероятностью окажется в перечне раньше остальных.

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

Источников требований два — Правительство и Банк России. Согласование с ЦБ прописано и для случаев обязательного применения моделей со статусом, и для отраслевых требований по рискам; мониторинга только правительственных актов недостаточно.

Дата, вокруг которой строится план, — 1 марта 2027 года. Системы, эксплуатируемые на эту дату с локализованными данными, выходят из-под требования до сентября 2032-го. Девятнадцать месяцев — реальный срок для одного контура и напряжённый для портфеля.

Статус модели и локализация данных — два разных вопроса. Модель вендора со статусом по внешнему API решает первый и не решает второй; открытая модель в своём контуре — наоборот. Сходятся они в одной конфигурации: модель российского вендора, развёрнутая внутри периметра.

Ближайший шаг — реестр генеративных сценариев с датами ввода в эксплуатацию. Неделя работы, после которой видно, какие сценарии успевают в окно, а по каким решение нужно принимать в этом квартале.