Обучение на финансовых данных

Финансовые данные — транзакционные истории, кредитные профили, остатки по счетам — представляют ценность именно потому, что связаны с конкретными людьми. Это делает их персональными данными по ФЗ-152 с момента сбора до уничтожения обучающей выборки. С 2025 года регуляторная нагрузка на оператора, использующего такие данные для ML, выросла сразу по трём направлениям: новая редакция ст. 13.11 КоАП (ФЗ-420 от 30.11.2024), уголовная ответственность по ст. 272.1 УК (ФЗ-421 от 30.11.2024) и обязанность применять методы обезличивания по приказу РКН. Ниже — анализ требований, которые CTO должен учесть до старта пайплайна обучения.

Какой правовой статус имеет обучающая выборка на финансовых данных?

Обучающая выборка — это набор данных, полученный в результате систематизации и накопления записей о субъектах. По ст. 3 ФЗ-152, обработка — это любое действие с ПДн, включая сбор, систематизацию, накопление, хранение, использование. Формирование датасета для модели подпадает под это определение полностью.

Финансовые данные физического лица — сумма транзакции, категория мерчанта, паттерн расходов, кредитный рейтинг — сами по себе могут не содержать ФИО. Однако в связке с идентификатором клиента (номером договора, номером телефона, cookie-идентификатором мобильного банка) они однозначно становятся персональными. Суды и РКН не принимают аргумент «мы убрали имя», если идентификатор позволяет восстановить личность.

Дополнительный правовой статус появляется, если в датасете присутствуют сведения о просрочках, банкротстве или кредитной истории: часть этих данных относится к специальным категориям по ст. 10 ФЗ-152, а именно к сведениям о «материальном положении» субъекта в расширительном толковании. Это влечёт необходимость отдельного согласия или иного основания по ч. 2 ст. 10 ФЗ-152.

Наиболее распространённое решение — отдельное согласие субъекта на обработку данных в аналитических и исследовательских целях (п. 1 ч. 1 ст. 6 ФЗ-152). Альтернатива — обезличивание выборки до начала обучения таким образом, чтобы данные перестали быть ПДн. Требования к методам обезличивания определены приказом РКН: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение.

Какой уровень защищённости (УЗ) выбрать для инфраструктуры ML-обучения?

Уровень защищённости информационной системы ПДн (ИСПДн) определяется по трём параметрам: категория данных, тип актуальных угроз и количество субъектов. Порядок определения — ПП РФ №1119 от 01.11.2012.

Для типичной финтех-компании с обучающей выборкой на клиентских транзакциях параметры выглядят так. Категория — иные ПДн (не специальные, не биометрические), если нет данных о состоянии здоровья или судимостях. Тип угроз — в большинстве случаев тип 3 (угрозы, не связанные с недокументированными возможностями системного ПО). Субъекты — если выборка превышает 100 000 записей, минимальный уровень защищённости повышается.

При параметрах «иные ПДн + угрозы типа 3 + более 100 000 субъектов» присваивается УЗ-3. Если субъектов менее 100 000 — УЗ-4. Если в датасете есть специальные категории (сведения о материальном положении, судимость) — УЗ может повыситься до УЗ-2.

Для СЗИ, применяемых в ML-инфраструктуре на УЗ-3, Приказ ФСТЭК №21 требует закрыть меры из 15 групп: идентификацию и аутентификацию (ИАФ), управление доступом (УПД), защиту носителей (ЗНИ), регистрацию событий (РСБ), антивирусную защиту (АВЗ), обнаружение вторжений (СОВ) и ряд других. Каждая группа содержит базовый набор мер, применимость которых уточняется при моделировании угроз.

Практический вывод для CTO: если ML-платформа находится в одной инфраструктуре с продакшн-системой обработки ПДн — уровень защищённости определяется по самой высокой категории данных в системе. Разделение контуров (data isolation) позволяет назначить ML-среде отдельную, потенциально более низкую категорию и снизить объём обязательных мер.

Как применять обезличивание для ML и чем это отличается от анонимизации?

Обезличивание по ФЗ-152 — это действия с ПДн, в результате которых становится невозможным без использования дополнительной информации определить принадлежность данных конкретному субъекту (ст. 3 ФЗ-152). Если обезличивание применено корректно и дополнительная информация уничтожена или недоступна — результирующий датасет перестаёт быть ПДн и выходит из-под большей части требований ФЗ-152.

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

Приказ РКН определяет пять методов обезличивания. Для финансовых датасетов наиболее применимы обобщение (замена точного значения диапазоном: вместо «37 500 ₽» — «от 30 000 до 50 000 ₽»), введение идентификаторов (суррогатный ключ при условии уничтожения таблицы соответствия) и декомпозиция (разбивка датасета на части, каждая из которых не содержит полного профиля субъекта). Перемешивание эффективно при работе с временными рядами транзакций: разрыв связи между транзакцией и клиентом при сохранении статистических свойств выборки.

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

Кто несёт ответственность при мультиарендной SaaS и поручении обработки?

Финтех-компания, которая обучает модель на данных своих клиентов через стороннюю ML-платформу (SaaS), создаёт отношения поручения обработки ПДн по п. 3 ст. 6 ФЗ-152. В этой схеме финтех — оператор, платформа — лицо, осуществляющее обработку по поручению. Ответственность перед субъектами и РКН — у оператора.

Мультиарендная SaaS-платформа создаёт дополнительный риск: данные нескольких клиентов (тенантов) обрабатываются в одной инфраструктуре. Если платформа недостаточно изолирует контексты тенантов — возникает риск несанкционированного доступа к данным соседнего тенанта, что квалифицируется как утечка. Оператор (финтех) несёт ответственность, даже если инцидент произошёл на стороне платформы.

Обязательный элемент — договор поручения обработки с перечнем действий, которые вправе совершать платформа, и запретом на обработку данных в собственных целях. Если обучающая выборка уходит в облако на серверах за рубежом — это трансграничная передача ПДн по ст. 12 ФЗ-152 с обязанностью уведомить РКН до начала передачи в страну без адекватной защиты.

Каковы сценарии регуляторного риска для CTO при обучении моделей?

Три сценария наиболее характерны для финтех-команд, запускающих ML в продакшн.

Сценарий 1. Обучающая выборка сформирована из транзакционной базы без отдельного правового основания. Ситуация: команда использует продакшн-дамп для обучения модели скоринга. Правовое основание — исполнение договора с клиентом (п. 5 ч. 1 ст. 6 ФЗ-152) — покрывает транзакционную обработку, но не охватывает использование данных для обучения сторонней ML-системы. Доказательства нарушения: журналы выгрузки датасета, договор с ML-платформой без поручения обработки. Вероятный исход: протокол по ч. 1 ст. 13.11 КоАП — штраф 150 000–300 000 ₽ за юрлицо; при повторности — ч. 1.1 ст. 13.11, штраф 300 000–500 000 ₽. Стратегия: оформить поручение обработки, закрыть правовое основание согласием или корректным обезличиванием до следующего цикла обучения.

Сценарий 2. Утечка обучающей выборки через уязвимость ML-платформы. Ситуация: SaaS-платформа подверглась атаке, данные тенанта (финтех) оказались в открытом доступе. Число субъектов — 15 000. Оператор-финтех обнаружил инцидент через 30 часов. Доказательства: логи платформы, уведомление платформы оператору. Вероятный исход: нарушение 24-часового срока уведомления РКН по ч. 3.1 ст. 21 ФЗ-152 → штраф по ч. 11 ст. 13.11 КоАП в диапазоне 1–3 млн ₽ + штраф по ч. 13 ст. 13.11 за утечку 10 000–100 000 субъектов (5–10 млн ₽). Стратегия: настроить автоматический мониторинг инцидентов на стороне платформы, добавить в договор поручения SLA на уведомление оператора в течение 4 часов с момента обнаружения.

Сценарий 3. Данные обучающей выборки хранятся в зарубежном облаке без уведомления РКН. Ситуация: команда использует AWS US или GCP EU для хранения датасета и весов модели. Локализация по ч. 5 ст. 18 ФЗ-152 требует, чтобы первичная запись, накопление и хранение ПДн граждан РФ осуществлялась в базах на территории РФ. Уведомление о трансграничной передаче в РКН не подавалось. Доказательства: договор с облачным провайдером, адрес датацентра. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП за нарушение локализации — 1–6 млн ₽; при повторности — ч. 9, 6–18 млн ₽. Стратегия: мигрировать датасет в российское облако (Яндекс Облако, VK Cloud, Selectel), направить уведомление о трансграничной передаче по ст. 12 ФЗ-152 до возобновления работы с зарубежным регионом.

Как это применяется на практике

Кейс 1. Финтех-компания (Центральный ФО, начало 2026) обучала модель кредитного скоринга на транзакционном датасете из 200 000 клиентских записей. ML-платформа находилась в зарубежном облаке. RKN провёл внеплановую проверку по жалобе субъекта, обнаружил отсутствие уведомления о трансграничной передаче и нарушение локализации. Технический директор получил требование об устранении в 30-дневный срок. Параллельно был составлен протокол по ч. 8 ст. 13.11 КоАП. Компания перенесла датасет в российский датацентр, направила уведомление РКН и в арбитражном суде добилась снижения штрафа до минимального порога диапазона с учётом оперативного устранения нарушения.

Кейс 2. IT-компания — оператор SaaS для МФО (Сибирский ФО, осень 2025) предоставляла мультиарендную платформу скоринга. При аудите выяснилось, что договоры с клиентами-операторами не содержали поручения обработки ПДн по п. 3 ст. 6 ФЗ-152. Аудит выявил также отсутствие разграничения контуров тенантов на уровне базы данных. DATUM подготовил типовой договор поручения, помог провести DPIA и описать модель угроз для присвоения УЗ-3, что позволило компании подтвердить соответствие перед корпоративными клиентами при следующем тендере.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка пайплайна обучения по 38 пунктам, отчёт с приоритетами устранения.
• DPIA (оценка воздействия) — идентификация рисков ML-инфраструктуры, модель угроз, обоснование УЗ.
• Комплект ОРД под ключ — договор поручения обработки, политика, согласия, приказы для ML-команды.

Частые вопросы

1. Какой УЗ выбрать для SaaS, обучающей модели на финансовых данных?

Уровень защищённости определяется по ПП РФ №1119: категория данных (иные ПДн или специальные), тип актуальных угроз (1, 2 или 3) и число субъектов. Для большинства финтех-SaaS с иными ПДн, угрозами типа 3 и выборкой более 100 000 субъектов — УЗ-3. Если выборка менее 100 000 — УЗ-4. Наличие данных о материальном положении, судимости или состоянии здоровья может повысить УЗ до 2. Конкретный набор мер по присвоенному УЗ — Приказ ФСТЭК №21. Рекомендуется проводить определение УЗ до проектирования инфраструктуры.

2. Можно ли использовать иностранные облака для хранения обучающей выборки?

Первичная запись, накопление и хранение ПДн граждан РФ должны осуществляться в базах данных на территории России по ч. 5 ст. 18 ФЗ-152 (требование локализации, действует с 01.09.2015). Хранение обучающей выборки, содержащей ПДн, в зарубежном облаке без российского зеркала нарушает это требование. Штраф — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП, при повторности — 6–18 млн ₽ по ч. 9. Передача весов модели или обезличенного датасета в зарубежное облако отдельных норм локализации не нарушает, если данные действительно обезличены по методам приказа РКН.

3. Что такое обезличивание для ML и какие методы признаёт регулятор?

Обезличивание по ФЗ-152 — это приведение данных к виду, при котором невозможно без дополнительной информации установить принадлежность конкретному субъекту. Регулятор признаёт пять методов (приказ РКН): введение идентификаторов (при уничтожении таблицы соответствия), изменение состава и семантики, декомпозиция, перемешивание, обобщение. Псевдонимизация (суррогатный ключ при наличии таблицы соответствия) обезличиванием не является. Технические методы — дифференциальная приватность, федеративное обучение — нормативного признания в российском праве не имеют, хотя могут использоваться как дополнительный технический контроль.

4. Кто является оператором ПДн в мультиарендной SaaS?

В мультиарендной SaaS оператором остаётся компания-клиент платформы: она определяет цели и состав обработки данных своих пользователей. SaaS-платформа выступает лицом, осуществляющим обработку по поручению оператора (п. 3 ст. 6 ФЗ-152). Обязательное условие — договор поручения с исчерпывающим перечнем разрешённых действий и запретом использования данных в целях платформы. При отсутствии такого договора обе стороны могут быть признаны операторами с самостоятельной ответственностью перед РКН.

5. Какие СЗИ обязательны для ML-инфраструктуры с ПДн?

Обязательный состав мер определяется Приказом ФСТЭК №21 исходя из присвоенного УЗ. Для УЗ-3 базовый набор включает: идентификацию и аутентификацию пользователей ML-среды (ИАФ), управление правами доступа к датасету и моделям (УПД), регистрацию и анализ событий безопасности (РСБ), антивирусную защиту рабочих нод (АВЗ), обнаружение вторжений (СОВ), защиту носителей данных (ЗНИ). Применяемые СЗИ должны иметь сертификаты ФСТЭК России для соответствующего класса защиты. Конкретный перечень СЗИ формируется по результатам моделирования угроз.

Итог

Обучение на финансовых данных — это полноценная обработка ПДн с момента формирования датасета до уничтожения весов модели, если в выборке присутствуют идентификаторы физических лиц. Правовое основание, уровень защищённости, методы обезличивания и договор поручения — четыре обязательных элемента, которые CTO должен закрыть до первого цикла обучения. Штрафы по новой редакции ст. 13.11 КоАП делают цену игнорирования этих требований несопоставимой со стоимостью предварительного аудита.

DATUM сопровождает IT-команды на всём цикле: от определения УЗ и выбора методов обезличивания до DPIA и договора поручения с ML-платформой. Опыт включает финтех, SaaS для МФО и банковские ML-проекты.