Bias в моделях и дискриминация

Алгоритмическая дискриминация перестала быть абстракцией. Российский регулятор в 2023–2025 годах зафиксировал десятки случаев, когда модели принимали решения по признакам, которые закон запрещает использовать без отдельного согласия. Для CTO это означает двойной риск: технический (модель «закрепляет» исторические неравенства) и правовой (обработка спецкатегорий ПДн без оснований). Разбираем, где проходит граница, как её не пересечь и что делать, если модель уже обучена на подозрительных данных.

Почему bias в ML — это вопрос ФЗ-152, а не только этики?

Классический технический подход рассматривает bias как статистическую проблему: модель «подтягивается» к паттернам обучающей выборки и воспроизводит их на инференсе. Правовой подход добавляет к этому другой вопрос: какие признаки попали в выборку и на каком основании они обрабатывались.

По ст. 10 ФЗ-152 обработка специальных категорий ПДн — сведений о расовой и национальной принадлежности, политических взглядах, состоянии здоровья, интимной жизни, судимости — допустима только при наличии явного основания из закрытого перечня п. 2 той же статьи. Если модель обучалась на исторических данных кредитного скоринга, медицинских страховок или отборочных HR-воронок — велика вероятность, что спецкатегории присутствуют неявно: в признаке «район проживания», «название работодателя», «диагноз в анамнезе».

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

Как технический выбор признаков создаёт правовые риски?

В практике аудитов DATUM повторяется одна конфигурация: команда data science убрала «чувствительные» поля из датасета, но оставила признаки, коррелирующие с ними. Модель воспроизводит дискриминацию по полу, возрасту или этнической принадлежности через косвенные переменные. С точки зрения ФЗ-152 это всё равно обработка: именно для квалификации признака как ПДн достаточно, что информация прямо или косвенно относится к определённому физическому лицу (ст. 3 ФЗ-152).

Приказ ФСТЭК №21 в группе мер ОПС (ограничение программной среды) требует контролировать состав обрабатываемых данных на каждом этапе жизненного цикла ИСПДн. Для ML-систем это означает документированный feature registry с пометкой правового основания для каждого признака. Отсутствие такого реестра — типовое замечание при плановых проверках РКН, фиксируемое в актах как нарушение ст. 18.1 ФЗ-152 (не обеспечена возможность демонстрации соответствия).

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

Что требует закон от оператора, использующего автоматизированные решения?

ФЗ-152 содержит прямую норму об автоматизированных решениях в ст. 16: решения, порождающие правовые последствия для субъекта или существенно затрагивающие его интересы, не могут приниматься исключительно на основе автоматизированной обработки без возможности оспаривания. Норма распространяется на кредитный скоринг, автоматический отказ в найме, динамическое ценообразование по профилю клиента.

Обязанности оператора в этом случае: уведомить субъекта о факте автоматизированного решения, обеспечить право на возражение и пересмотр с участием человека. Отсутствие такого механизма — основание для предписания РКН и штрафа по ч. 5 ст. 13.11 КоАП (50–90 тыс. ₽ за невыполнение требования субъекта), а при повторности — по ч. 5.1 (300–500 тыс. ₽).

Для обезличивания данных, передаваемых в ML-пайплайн, с 2025 года действует регуляторный фреймворк по ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024). Приказ РКН определяет пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение. Для ML наиболее практичны обобщение (агрегация) и введение псевдонимов — они сохраняют статистические свойства выборки, необходимые для обучения.

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

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

Правовые последствия существенны. Соперирование означает солидарную ответственность по ст. 13.11 КоАП. Если утечка произошла из общей обучающей выборки, штраф может быть предъявлен как вендору, так и заказчику. Практика ВС РФ подтверждает: оператор отвечает за утечку через подрядчика, если договор поручения не ограничивал состав передаваемых данных.

Для SaaS-компаний, работающих с несколькими арендаторами, технически необходима изоляция обучающих выборок по арендатору (tenant isolation) и явный запрет в договоре на использование данных одного арендатора для обучения моделей других. Это снижает риск переквалификации роли вендора с обработчика на оператора.

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

Кейс 1. IT-компания (Сибирский ФО, осень 2024) разрабатывала HR-платформу с автоматизированным ранжированием кандидатов. Аудит DATUM выявил, что модель использовала признак «учебное заведение» как прокси для социально-экономического статуса, который коррелировал с этнической принадлежностью кандидатов. Данные обрабатывались без правового основания по ст. 10 ФЗ-152. После аудита вендор исключил признак, провёл повторное обучение на обобщённых данных и получил документально подтверждённый feature registry. РКН при плановой проверке не выявил нарушений.

Кейс 2 (из реестра DATUM). Финтех-компания (Уральский ФО, начало 2025) использовала SaaS-платформу зарубежного вендора для скоринга. Договор поручения обработки не ограничивал использование данных для дообучения модели вендора. При утечке части обучающей выборки РКН квалифицировал компанию как соператора. Итог: штраф в сотни тысяч рублей по ч. 1 ст. 13.11 КоАП и предписание о расторжении договора в части, противоречащей ч. 5 ст. 18 ФЗ-152 (локализация). Пересмотр договора и добавление ограничительных условий позволили сохранить сервис.

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

• DPIA (оценка воздействия) — оценка рисков ML-модели, определение УЗ, ролей оператора и обработчика.
• Аудит соответствия 152-ФЗ — проверка feature registry, договоров поручения, мер по Приказу ФСТЭК №21.
• Комплект ОРД под ключ — политика обработки, согласия, регламент автоматизированных решений по ст. 16 ФЗ-152.

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

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

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

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

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

3. Что такое обезличивание для ML и чем оно отличается от анонимизации?

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

4. Кто является оператором в мультиарендной SaaS — вендор или заказчик?

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

5. Какие СЗИ обязательны для ML-системы по Приказу ФСТЭК №21?

Конкретный набор зависит от определённого УЗ. Для УЗ-3 и УЗ-4 обязательны меры по группам ИАФ (идентификация и аутентификация), УПД (управление доступом), РСБ (регистрация событий — логирование), АВЗ (антивирусная защита), ЗИС (защита информационной системы). Для УЗ-1 и УЗ-2 добавляются сертифицированные ФСТЭК средства криптографической защиты и требования к СОВ (системе обнаружения вторжений). Применение несертифицированных СЗИ при УЗ-1/2 — нарушение ст. 19 ФЗ-152 и основание для предписания.

Итог

Bias в ML-моделях — это не только техническая проблема воспроизведения исторических неравенств. Это правовой риск обработки спецкатегорий ПДн по ст. 10 ФЗ-152 без надлежащего основания, неверного определения УЗ по ПП РФ №1119 и смешения ролей оператора и обработчика в SaaS-архитектурах. С 30.05.2025 цена ошибки при повторной утечке — оборотный штраф по ч. 15 ст. 13.11 КоАП от 20 млн ₽, а с 11.12.2024 — потенциальная уголовная ответственность по ст. 272.1 УК РФ.

DATUM сопровождает IT-компании в определении УЗ для ML-систем, проведении DPIA, разграничении ролей в SaaS-договорах и выстраивании feature registry с правовым обоснованием каждого признака обучающей выборки.