Insurance для ML-моделей (страхование)

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

Почему ML в страховании — это всегда спецкатегория ПДн?

Страховые компании обрабатывают данные, которые ст. 10 ФЗ-152 относит к специальным категориям: сведения о состоянии здоровья (ДМС, страхование жизни, несчастный случай), данные о финансовом поведении, в ряде случаев — биометрию (сканирование документов, голосовая идентификация при урегулировании убытков). Специальные категории требуют отдельного правового основания для обработки — как правило, явного письменного согласия субъекта по п. 4 ч. 2 ст. 10 ФЗ-152.

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

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

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

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

• Антифрод на данных о здоровье (ДМС), угрозы 2-го типа, более 100 000 субъектов — УЗ-2.
• Скоринг убыточности на общих данных (возраст, марка авто, регион), угрозы 3-го типа, менее 100 000 субъектов — УЗ-3.
• Биометрическая идентификация при СКУД или голосовом ботом, угрозы 1-го типа — УЗ-1 (максимальные требования).

Критическая ошибка — определять УЗ по «основной» системе учёта, а ML-сервисы относить к отдельной ИСПДн с заниженным уровнем. Если feature store содержит те же данные, что и основная ИСПДн, — он является частью той же системы и наследует её УЗ. Это подтверждает Приказ ФСТЭК № 21: набор мер формируется для всей ИСПДн, включая вспомогательные компоненты обработки.

Что считается обезличиванием для обучения ML-моделей?

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

На практике страховщики допускают две системные ошибки. Первая — псевдонимизация без удаления квазиидентификаторов: замена ФИО на ID при сохранении даты рождения, региона, марки авто и суммы страховки позволяет re-identification с высокой точностью. Вторая — обезличивание только «горячего» слоя, тогда как архивные снимки feature store содержат исходные данные.

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

Где проходит граница ответственности при использовании облачных ML-платформ?

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

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

Отдельная проблема — мультиарендные SaaS-платформы для ML (например, облачные feature store или AutoML). В мультиарендной архитектуре данные разных операторов физически изолированы, однако совместно используют инфраструктуру обучения. Если провайдер использует агрегированные данные для улучшения базовой модели — это несанкционированная цель обработки по ст. 5 ФЗ-152. Договор должен явно запрещать такое использование и предусматривать аудит провайдера.

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

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

Для ML-конвейеров критичны меры РСБ — логирование. Каждое обращение к персональным данным в feature store, каждая задача дообучения и каждый inference-запрос с передачей ПДн должны фиксироваться с атрибутами: идентификатор пользователя или сервиса, время, действие, результат. Журналы — доказательная база при расследовании инцидентов по Приказу РКН № 187. Отсутствие журналов лишает оператора возможности доказать отсутствие утечки и обосновать сроки уведомления РКН.

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

Типовые сценарии рисков для CTO страховой компании

Сценарий 1. Feature store с данными о здоровье без корректного УЗ. Страховщик развернул централизованный feature store для антифрод-модели. В него попали признаки из заявлений на страховое возмещение по ДМС, включая коды МКБ. Система отнесена к УЗ-3 по принципу «нет прямой идентификации». При проверке РКН выявлено: данные о здоровье требуют минимум УЗ-2, меры группы ИАФ и РСБ не реализованы. Результат — предписание, штраф по ч. 1 ст. 13.11 КоАП и требование привести систему в соответствие в течение 30 дней. Стратегия: провести DPIA до запуска системы, зафиксировать УЗ в приказе, реализовать базовый набор мер по Приказу ФСТЭК № 21.

Сценарий 2. Облачный AutoML у иностранного провайдера без договора поручения. CTO интегрировал AutoML-платформу европейского провайдера для скоринга. Договор заключён как SaaS-лицензия без условий поручения обработки. Данные реплицируются в датацентры ЕС. Нарушение двойное: отсутствие договора поручения по ст. 6 ч. 3 ФЗ-152 и нарушение локализации по ч. 5 ст. 18 ФЗ-152. Штраф за локализацию — 1–6 млн ₽ по ч. 8 ст. 13.11; при повторности — 6–18 млн ₽ по ч. 9. Стратегия: перевести первичную обработку в российскую инфраструктуру, переоформить договор с провайдером как поручение обработки с явным перечнем действий.

Сценарий 3. Утечка через ML-API без уведомления в 24 часа. Внешний ML-API для оценки рисков возвращал ответы с фрагментами обучающей выборки (т. н. training data extraction). Инцидент обнаружен SOC через 36 часов после первых признаков. К моменту обнаружения 24-часовой срок первичного уведомления РКН по ч. 3.1 ст. 21 ФЗ-152 истёк. Штраф за неуведомление — 1–3 млн ₽ по ч. 11 ст. 13.11. Если объём утечки превысил 10 000 субъектов — дополнительно ч. 13 ст. 13.11 (5–10 млн ₽). Стратегия: внедрить мониторинг аномалий на уровне API-шлюза, регламентировать процедуру фиксации инцидента с точным временем обнаружения.

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

Кейс 1. IT-компания, разрабатывающая ML-решения для страхового рынка (Центральный ФО, осень 2025), при подготовке к проверке РКН выявила, что feature store для обучения скоринговой модели классифицирован как УЗ-3, тогда как в обучающей выборке присутствовали признаки, косвенно характеризующие состояние здоровья. После аудита ИСПДн переведена на УЗ-2, реализован базовый набор мер Приказа ФСТЭК № 21, подписаны договоры поручения с двумя облачными подрядчиками. Плановая проверка завершилась без предписаний.

Кейс 2. Региональный страховщик (Сибирский ФО, начало 2026) получил уведомление от провайдера MLOps-платформы об инциденте с доступом к обучающим данным. CTO зафиксировал факт в течение двух часов после уведомления, направил первичное уведомление в РКН за 20 часов, через 68 часов — отчёт о расследовании по Приказу РКН № 187. Число затронутых субъектов составило менее 1 000. Дело по ст. 13.11 не возбуждалось — нарушения требований уведомления не установлено. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

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

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

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

1. Какой УЗ выбрать для SaaS с ML-функциональностью?

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

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

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

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

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

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

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

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

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

Итог

ML-инфраструктура страховщика — это всегда ИСПДн с повышенными требованиями: специальные категории ПДн, цепочки поручения через облачных провайдеров, риск утечки через inference-API. Ошибка в определении УЗ, отсутствие договора поручения или некорректное обезличивание превращают технологическое преимущество в правовой риск с ценником от 1 до 500 млн ₽.

DATUM сопровождает IT-команды страховых компаний в классификации ИСПДн, проведении DPIA, подготовке договоров поручения и построении документооборота по Приказу РКН № 187. Практика по 152-ФЗ охватывает как технические требования ФСТЭК, так и взаимодействие с РКН при проверках.

14 апреля 2029 года