Обучение на резюме (HR-tech)

Рынок HR-tech в России рос последние три года на волне автоматизации подбора. Платформы, агрегирующие резюме, скоринговые движки, рекомендательные системы — всё это работает на персональных данных кандидатов. С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024: штрафные диапазоны выросли кратно, появился оборотный состав при повторной утечке по ч. 15. В этой статье — как CTO HR-tech-компании выстроить правомерную обработку резюме для ML-обучения, какой уровень защищённости назначить ИСПДн и что сделать до того, как РКН пришёл с проверкой.

Почему резюме — это персональные данные и что из этого следует?

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

HR-tech-платформа, которая принимает резюме и обрабатывает их для скоринга или подбора, является оператором ПДн по ст. 3 ФЗ-152. Если платформа обрабатывает данные по заданию корпоративного клиента (работодателя), это поручение обработки по п. 3 ч. 1 ст. 6 ФЗ-152: нужен письменный договор с чётко ограниченным перечнем действий.

Ключевая проблема HR-tech: платформа получает резюме из нескольких источников — напрямую от кандидатов, через API работных сайтов, из ATS-систем работодателей. Правовые основания и согласия у каждого источника свои. Объединение этих потоков в единую базу для обучения модели — самостоятельное целеполагание, на которое исходное согласие кандидата, данное при размещении резюме на джоб-сайте, не распространяется.

Как определить уровень защищённости ИСПДн для HR-tech-платформы?

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

Для большинства HR-tech-платформ исходные данные такие: категория — общие ПДн (имя, контакты, опыт работы), кроме случаев, когда обрабатываются медицинские справки или сведения о судимостях. Тип угроз — угрозы второго типа (НДВ в системном ПО отсутствуют, но угрозы актуальны). Число субъектов — обычно более 100 000 (агрегаторы резюме) или менее 100 000 (корпоративные ATS).

• УЗ-3 — общие ПДн, угрозы 2-го или 3-го типа, более 100 000 субъектов. Типично для крупного агрегатора резюме или зрелой HR-tech-платформы с широкой клиентской базой.
• УЗ-4 — общие ПДн, угрозы 3-го типа, менее 100 000 субъектов. Типично для корпоративного ATS среднего работодателя.
• УЗ-2 — если среди обрабатываемых данных есть спецкатегории (сведения о состоянии здоровья для медосмотров, судимость) либо биометрия в целях идентификации, при угрозах 2-го типа и более 100 000 субъектов.

Повышение до УЗ-2 означает обязательное применение сертифицированных средств защиты информации класса не ниже КС2. Для SaaS-платформы на стандартном облаке без сертифицированных СЗИ это существенное изменение архитектуры.

Что такое обезличивание для ML и как его применять к резюме?

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

С 2025 года порядок обезличивания регулируется подзаконным актом РКН. Установлены пять методов: введение идентификаторов (замена ФИО на псевдоним), изменение состава или семантики (удаление прямых идентификаторов), декомпозиция (разбивка записи на несвязанные части), перемешивание (перестановка значений атрибутов), обобщение или агрегация (замена точных значений диапазонами). Для резюме наиболее применимы первый и второй методы в сочетании.

Практический минимум для правомерного обучения ML на резюме:

• Удалить или заменить псевдонимом: ФИО, email, телефон, ссылки на соцсети, адрес.
• Обобщить: год рождения заменить возрастным диапазоном (25–30 лет), конкретные работодатели — отраслью и размером компании.
• Удалить фото полностью — распознавание лица по фото в обучающей выборке создаёт риск обработки биометрических ПДн без согласия.
• Зафиксировать метод обезличивания в приказе и технической документации — Роскомнадзор вправе запросить подтверждение при проверке.
• Хранить сопоставительную таблицу (ФИО → псевдоним) отдельно от обучающего датасета с доступом по принципу минимальных привилегий.

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

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

Мультиарендность (multi-tenancy) создаёт юридически неоднородную картину. Работодатель, загружающий резюме кандидатов в HR-tech-платформу, является оператором ПДн этих кандидатов. Платформа при этом действует как лицо, осуществляющее обработку по его поручению (ст. 6 ФЗ-152).

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

Разграничение ответственности в договоре с клиентом (работодателем) должно включать:

• Перечень действий, которые платформа вправе совершать с ПДн кандидатов клиента.
• Запрет или явное разрешение использовать данные для обучения собственных моделей платформы.
• Обязанность клиента обеспечить наличие согласия кандидата на передачу данных платформе.
• Порядок уничтожения ПДн при расторжении договора — со сроком и подтверждением.

Без такого разграничения, если в HR-tech-платформу через API приходят резюме от 50 работодателей и она обучает на них собственную модель, каждый работодатель — потенциальный нарушитель (передал данные без надлежащего основания), а платформа — оператор без правового основания обработки.

Какие технические меры защиты обязательны по Приказу ФСТЭК №21?

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

Критичные для HR-tech-платформы группы мер:

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

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

Как это применяется на практике: два кейса

Кейс 1. HR-tech-стартап в Сибирском ФО (осень 2025) разработал скоринговую модель ранжирования кандидатов, обученную на 180 000 резюме из собственной базы. Технический директор компании был уверен, что согласие на размещение резюме покрывает последующее обезличивание и ML-обучение. При подготовке к проверке РКН юристы выявили: ИСПДн соответствует УЗ-3 (более 100 000 субъектов, общие ПДн, угрозы 2-го типа), однако меры по группам РСБ и ЗНИ не реализованы. Обучающий датасет хранился без шифрования, без разделения ролей доступа. В результате аудита компания внедрила шифрование хранилищ, настроила логирование по группе РСБ и разработала внутренний регламент обезличивания — до начала проверки. Протокол по ст. 19 ФЗ-152 составлен не был.

Кейс 2. Мультиарендная HR-платформа (Центральный ФО, начало 2026) агрегировала данные кандидатов от 35 работодателей-клиентов для обучения единой модели рекомендаций. Договоры с клиентами не содержали разрешения на такое использование. После жалобы одного из работодателей РКН возбудил дело по ч. 1 ст. 13.11 КоАП — обработка ПДн в целях, несовместимых с заявленными. Штраф составил несколько сотен тысяч рублей. Платформа параллельно переработала договорную базу с клиентами и внедрила разделение датасетов по тенантам. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

Можно ли использовать иностранные облака для хранения резюме?

По ч. 5 ст. 18 ФЗ-152 запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан Российской Федерации должны осуществляться в базах данных, расположенных на территории России. Это требование локализации действует с 01.09.2015 и распространяется на все операции первичной обработки ПДн граждан РФ.

На практике это означает: основная база резюме российских кандидатов должна находиться на серверах в России. Использование AWS, Google Cloud, Azure или иных иностранных облаков для хранения оригинальных ПДн — нарушение ч. 5 ст. 18. Штраф по ч. 8 ст. 13.11 КоАП — от 1 000 000 до 6 000 000 ₽. При повторном нарушении — от 6 000 000 до 18 000 000 ₽ по ч. 9 ст. 13.11.

Для обезличенных данных запрет локализации не применяется: обезличенные данные по смыслу ст. 13.1 ФЗ-152 не являются персональными данными после надлежащего обезличивания. Обучение ML-модели на обезличенном датасете в иностранном облаке — технически допустимо, если обезличивание выполнено по установленным методам до передачи за рубеж и сопоставительная таблица хранится в России.

Матрица сценариев для CTO HR-tech-платформы

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

Сценарий 2. Облачная инфраструктура платформы — в иностранном ЦОД.
Ситуация: SaaS развёрнут на AWS EU-West, туда же реплицируется база резюме для отказоустойчивости.
Доказательства: конфигурация репликации; WHOIS-данные IP-адресов серверов; договор с AWS без указания российских регионов.
Вероятный исход: нарушение ч. 5 ст. 18 ФЗ-152; штраф по ч. 8 ст. 13.11 КоАП 1–6 млн ₽. При наличии предписания и продолжении — повторный состав 6–18 млн ₽.
Стратегия: перенос базы ПДн в российский ЦОД (Яндекс.Облако, SberCloud, VK Cloud); иностранное облако использовать только для обезличенных обучающих датасетов.

Сценарий 3. Уровень защищённости занижен, меры ФСТЭК не реализованы.
Ситуация: ИСПДн классифицирована как УЗ-4, фактически соответствует УЗ-3 по числу субъектов. Часть мер по Приказу ФСТЭК №21 не реализована — нет логирования (РСБ), нет шифрования хранилищ (ЗНИ).
Доказательства: инвентаризация технических мер; отсутствие сертифицированных СЗИ; акт классификации с ошибочными вводными.
Вероятный исход: предписание РКН об устранении нарушений ст. 19 ФЗ-152; штраф за неисполнение предписания по ч. 5 ст. 13.11 КоАП 50 000–90 000 ₽; при повторном — 300 000–500 000 ₽.
Стратегия: переклассификация ИСПДн, разработка актуальной модели угроз, внедрение недостающих мер, фиксация в документации.

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

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

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

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

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

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

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

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

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

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

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

5. Какие средства защиты информации обязательны для HR-tech ИСПДн по Приказу ФСТЭК №21?

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

Итог

Обучение ML-моделей на резюме — правомерная практика при соблюдении трёх условий: надлежащее правовое основание (согласие с указанием ML-обучения или корректное обезличивание), правильно определённый УЗ с реализованными мерами по Приказу ФСТЭК №21, договорное разграничение ролей оператора и обработчика в мультиарендной архитектуре. Нарушение любого из этих условий создаёт состав по ст. 13.11 КоАП в редакции ФЗ-420 — с санкциями от 150 000 ₽ до 6 000 000 ₽ за локализацию.

DATUM сопровождает HR-tech-компании на всём цикле: от классификации ИСПДн и разработки регламентов обезличивания до подготовки договоров поручения обработки и прохождения проверок РКН. Практика по 152-ФЗ с 2014 года.