Метод 5: обобщение/агрегация

Технический директор, выстраивающий обработку данных для ML или BI, сталкивается с одним и тем же вопросом: когда агрегированная выборка перестаёт быть персональными данными по смыслу ст. 3 ФЗ-152? Ответ определяет, нужны ли согласия, уведомление РКН и технические меры по Приказу ФСТЭК №21. Ниже — разбор пятого метода обезличивания с позиции архитектора системы и compliance-офицера.

Что такое метод обобщения и агрегации и чем он отличается от других четырёх?

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

Обобщение заменяет точное значение диапазоном или категорией: возраст «34 года» становится «30–39 лет», адрес «ул. Ленина, 5, кв. 12» становится «Центральный район». Агрегация вычисляет производную статистику по группе: среднее, медиану, счёт, сумму — и публикует только её. Индивидуальная запись при этом не доступна даже косвенно.

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

Когда агрегации достаточно для снятия режима ПДн в аналитике и ML?

Для CTO критичен именно этот вопрос: не «как применить метод», а «когда применённый метод достаточен». РКН при оценке обезличенности данных смотрит на два параметра: размер агрегирующей группы и риск повторной идентификации через перекрёстное сопоставление с внешними источниками.

Практическое правило для ML: агрегирующая группа должна содержать не менее k субъектов, где k выбирается из соображений k-анонимности. Минимально допустимое значение в большинстве международных практик — k=5, однако для чувствительных категорий (ст. 10 ФЗ-152: здоровье, вероисповедание, биометрия) рекомендуемый порог — k=20 и выше. Российский регулятор не фиксирует конкретное число, но требует документального подтверждения того, что идентификация субъекта невозможна.

Второй параметр — внешние источники. Если публикуемая агрегация по небольшой когорте (например, «средний возраст 5 сотрудников отдела ИБ в компании N») сопоставима с LinkedIn-профилями — деобезличивание технически осуществимо. Это означает, что агрегат по малой группе с уникальными признаками не соответствует критерию ст. 3 ФЗ-152 независимо от применённого метода.

Для аналитических витрин и BI-дашбордов правило проще: если конечный пользователь не видит строк с индивидуальными значениями и не может через drill-down добраться до записи с менее чем k субъектами — обезличивание считается выполненным на уровне представления.

Как применять агрегацию в SaaS с мультиарендной архитектурой?

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

Если провайдер формирует кросс-тенантную аналитику (сравнительные бенчмарки, отраслевые отчёты) на основе данных нескольких арендаторов — он de facto создаёт новый набор данных. Правовое основание для такой обработки требует либо явного согласия каждого оператора-арендатора, либо применения обезличивания, достаточного для снятия режима ПДн до формирования кросс-тенантного набора.

Агрегация здесь работает следующим образом: на уровне тенанта формируются агрегаты (средние, медианы, счёт) без экспорта строк. Кросс-тенантный набор собирается из агрегатов, не из индивидуальных записей. Дополнительно применяется дифференциальная приватность для защиты от атак на члены малых групп.

Какие требования предъявляет Приказ ФСТЭК №21 к системам, применяющим агрегацию?

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

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

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

Для систем, квалифицированных как объекты критической информационной инфраструктуры по ФЗ-187, применяются дополнительные требования ФСТЭК независимо от наличия ПДн. Если SaaS-платформа обслуживает клиентов из категорий КИИ (банки, здравоохранение, транспорт), стоит проверить, не передаётся ли на платформу информация, связанная с объектами КИИ.

Типовые ситуации: как применяется метод агрегации на практике

Ситуация 1. ML-модель кредитного скоринга. Финтех-компания (Центральный ФО, лето 2025) обучала модель на записях о транзакциях и демографических данных 2,4 млн пользователей. Обезличивание применялось только на этапе выгрузки в обучающую выборку через агрегацию по когортам. Регулятор при проверке установил: агрегация применялась к группам по 3 субъекта, что позволяло деобезличивание по внешним признакам. Документация метода отсутствовала. Результат — протокол по ч. 1 ст. 13.11 КоАП. Стратегия: применять агрегацию с k-порогом не ниже 10 для общих категорий, документировать в регламенте обезличивания, проводить DPIA до запуска обучения.

Ситуация 2. BI-дашборд для b2b-клиентов SaaS. Провайдер аналитической платформы (Северо-Западный ФО, осень 2025) предоставлял клиентам отраслевые бенчмарки на основе данных 200+ арендаторов. Кросс-тенантная агрегация формировалась без договора поручения с арендаторами и без явного основания для объединения данных разных операторов. Роскомнадзор квалифицировал это как обработку без правового основания по ч. 1 ст. 13.11. Стратегия: заключить договор поручения с каждым арендатором, явно указав допустимость участия данных в кросс-тенантных агрегатах, либо применять агрегацию на уровне тенанта до объединения.

Ситуация 3. Публичный API со статистикой. EdTech-платформа (Сибирский ФО, весна 2026) раскрывала через открытый API агрегированные данные об успеваемости — средний балл по курсам с разбивкой по регионам и возрастным когортам. В ряде когорт размер группы составлял 1–2 пользователя. Это позволяло точно установить личность по косвенным признакам. РКН зафиксировал нарушение как неправомерное распространение по ст. 10.1 ФЗ-152. Стратегия: при публикации агрегатов через API применять порог подавления — не выводить строки, где k < установленного минимума, а заменять символом подавления.

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

• DPIA (оценка воздействия) — оценка рисков обезличивания, k-анонимности и публикации агрегатов
• Аудит соответствия 152-ФЗ — проверка архитектуры ИСПДн, метода обезличивания и уровня защищённости
• Комплект ОРД под ключ — регламент обезличивания, договор поручения, журнал операций

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

1. Какой УЗ выбрать для SaaS?

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

2. Можно ли использовать иностранные облака?

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

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

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

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

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

5. Какие СЗИ обязательны?

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

Итог

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

DATUM сопровождает CTO и команды разработки при выборе и документировании метода обезличивания, проводит DPIA для ML-конвейеров и аналитических хранилищ, формирует регламенты обезличивания в составе ОРД и оценивает соответствие архитектуры уровню защищённости по ПП РФ №1119 и Приказу ФСТЭК №21.