Защита персональных данных субъекта: почему растут требования

Сравнение показывает резкий рост масштаба инцидентов, но само по себе не объясняет их причины: на статистику влияют и количество атак, и качество выявления утечек, и методика подсчёта.

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

С 30 мая 2025 года в России действуют новые правила административной ответственности за нарушения в сфере персональных данных. Для крупных операторов особенно важен переход к санкциям, связанным с оборотом компании. Формальное наличие политики конфиденциальности или пользовательского соглашения больше не выглядит достаточным доказательством того, что субъект защищён.

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

Эволюция ответственности: от формального соблюдения к оборотным штрафам

Федеральный закон № 420-ФЗ от 30 ноября 2024 года изменил экономику нарушений в сфере персональных данных. После вступления документа в силу 30 мая 2025 года ответственность по статье 13.11 КоАП РФ стала для бизнеса более чувствительной: в предусмотренных законом случаях размер санкции может зависеть не только от формального состава нарушения, но и от масштаба компании.

Раньше максимальные штрафы за многие нарушения воспринимались крупными организациями как ограниченный операционный риск. Их можно было заложить в бюджет, не меняя архитектуру хранения и обработки данных. Теперь такой подход становится гораздо менее рациональным. Чем больше оборот и чем шире массив персональных данных, тем выше потенциальная цена слабого контроля.

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

Чем больше оператор зависит от персональных данных, тем меньше ему помогает формальный комплаенс. Риск теперь считается не количеством папок с политиками, а устойчивостью реальных процессов.

Отдельное значение получили сроки реагирования. Оператор должен уведомить Роскомнадзор об инциденте в течение 24 часов с момента его обнаружения, а результаты внутреннего расследования представить в течение 72 часов. Эти сроки требуют не только юридической готовности, но и технической наблюдаемости: компания должна заметить подозрительную активность, определить её границы и быстро собрать минимально необходимую информацию.

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

• кто принимает решение об эскалации инцидента;
• какие журналы и телеметрия используются для проверки;
• кто связывается с подрядчиками и облачными провайдерами;
• как фиксируется время обнаружения;
• какие сведения можно передать регулятору на первом этапе;
• кто отвечает за последующее расследование и устранение причин.

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

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

Масштаб утечек и цена ошибки: статистика 2024–2025 годов

Сопоставление 300 миллионов записей в 2023 году и 710 миллионов в 2024-м выглядит как резкий скачок. Однако эти значения нельзя трактовать как точное число людей, чьи данные оказались скомпрометированы. Запись может дублироваться в разных системах, относиться к одному и тому же субъекту или представлять отдельное событие обработки. Корректнее говорить о количестве затронутых записей и масштабах массивов, попавших в инциденты.

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

Последствия зависят от состава данных. Утечка контактного номера создаёт один набор рисков, а сочетание паспортных сведений, СНИЛС, финансовой информации и истории обращений — другой. Данные могут использоваться для фишинговых рассылок, подмены звонков от банков и государственных сервисов, попыток оформить услуги от имени человека или давления через персонализированные сценарии.

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

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

Утечки — не единственный способ причинить вред. Не менее важен сценарий скрытого или чрезмерного профилирования. Система может не раскрывать данные наружу, но использовать их для оценки платёжеспособности, интересов, вероятности покупки или реакции на определённое предложение. Если субъект не понимает, какие выводы о нём делает алгоритм и на каких данных они основаны, формальный контроль над информацией оказывается ограниченным.

В качестве показательного международного примера в черновике упоминался штраф LinkedIn в размере 310 млн евро по GDPR за обработку, связанную с профилированием пользователей без надлежащего согласия. Такой кейс нельзя автоматически переносить на российское право, но он показывает общий тренд: регуляторное внимание смещается не только к факту кражи базы, но и к способам использования пользовательской информации.

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

Технологический вызов: ИИ-агенты и риски поведенческого профилирования

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

Затем этот контекст может попасть в историю диалога, журналы приложения, систему аналитики или инструменты контроля качества. Если сервис использует несколько моделей и внешних поставщиков, появляются дополнительные точки передачи и хранения. Оператору нужно понимать не только, какие данные собираются на входе, но и где они оказываются после обработки.

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

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

Принципы обработки данных в ИИ требуют как минимум нескольких вопросов:

1. Понятно ли субъекту, для какой цели используется его запрос и будет ли он передан внешней модели?

2. Отделены ли данные, необходимые для ответа, от информации, которая случайно появилась в диалоге?

3. Есть ли ограничения на сохранение чувствительных сведений в логах и системах мониторинга?

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

5. Ограничен ли доступ модели к внутренним системам конкретной задачей?

6. Проверяются ли ответы агента на раскрытие сведений о других клиентах?

Технология не отменяет распределения ответственности. Если ИИ-агент работает через облачный сервис или API подрядчика, оператору нужно контролировать условия обработки, маршруты передачи, права доступа и порядок реагирования на инцидент. Передача функции внешней платформе не означает автоматического исчезновения риска для субъекта.

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

Алгоритмы обезличивания и управление доступом как новая норма

Технологии защиты цифрового профиля строятся не вокруг одной кнопки, а вокруг разделения рисков. Оператору нужно уменьшать объём идентифицирующих данных там, где они не требуются, и одновременно жёстко контролировать доступ к тем сведениям, без которых услуга невозможна.

Алгоритмы обезличивания данных помогают отделить аналитическую задачу от личности субъекта. В простейшем варианте идентификатор заменяется техническим ключом, а прямые признаки удаляются или обобщаются. Для более сложных сценариев применяются подходы вроде k-анонимности, l-разнообразия и t-близости, а также методы дифференциальной приватности.

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

Для бизнеса особенно важен баланс между полезностью данных и степенью защиты:

• для отчётности часто достаточно агрегированных показателей;
• для тестирования продукта можно использовать синтетические или ограниченные выборки;
• для операционной услуги необходимы идентификаторы, но не обязательно полный профиль;
• для обучения модели стоит отделять данные, нужные для качества ответа, от сведений, которые лишь случайно попали в историю;
• для внешней аналитики разумно передавать минимальный набор признаков и исключать прямые идентификаторы.

Обезличивание не заменяет управление доступом. Если исходная база остаётся доступной слишком широкому кругу сотрудников или сервисов, риск сохраняется независимо от того, насколько аккуратно подготовлена аналитическая копия.

В классической ролевой модели RBAC права назначаются должности или группе. Это полезная основа, но её недостаточно для динамичных систем. Один и тот же сотрудник может иметь разные задачи, работать из разных сетей и получать доступ только к отдельным клиентским обращениям. Поэтому всё чаще применяются контекстные проверки: учитываются ресурс, цель запроса, устройство, время, уровень риска и история действий.

Подход Zero Trust также не является самостоятельным требованием закона или универсальным стандартом для каждого оператора. Это архитектурная концепция, которая помогает не полагаться на внутренний периметр как на доказательство доверия. Её элементы могут быть полезны там, где много удалённых сотрудников, облачных сервисов и интеграций по API.

Практический контур защиты обычно включает:

• разделение хранилищ с персональными данными и общих корпоративных систем;
• шифрование при передаче и хранении с понятным управлением ключами;
• многофакторную аутентификацию для администраторов и пользователей с расширенными правами;
• журналирование операций с возможностью проверить целостность логов;
• регулярный пересмотр разрешений и отзыв неиспользуемых доступов;
• контроль сервисных учётных записей, которые часто остаются вне внимания;
• ограничение выгрузок и копирования данных;
• проверку подрядчиков, подключённых к обработке через API или облако.

Эти меры не должны превращаться в формальный набор закупок. Шифрование без контроля ключей, MFA только для части администраторов или журналы, которые никто не анализирует, создают иллюзию защищённости. Качество системы определяется связкой: мера должна быть включена, настроена, проверяться и участвовать в реальном сценарии реагирования.

Инвестиции в безопасность: как минимизировать риски регуляторных санкций

Инвестиции в ИБ имеют смысл только тогда, когда их можно связать с конкретными рисками. Покупка лицензии сама по себе не доказывает, что оператор снизил вероятность утечки. Важнее показать, какие слабые места были выявлены, какие меры внедрены и как проверяется их результат.

Рабочая программа обычно начинается с инвентаризации. Компания должна составить карту систем, в которых есть персональные данные, определить владельцев процессов и зафиксировать маршруты обмена. На этом этапе часто обнаруживаются старые выгрузки, резервные копии, тестовые базы и доступы бывших сотрудников. Именно такие забытые фрагменты нередко становятся самым простым путём к компрометации.

Затем приоритеты можно распределить по нескольким направлениям:

1. Архитектура хранения. Удалить избыточные копии, отделить идентифицирующие сведения от аналитических массивов, сократить сроки хранения там, где цель обработки уже достигнута.

2. Доступы. Пересмотреть права сотрудников и сервисов, убрать общие учётные записи, включить многофакторную аутентификацию и контроль привилегированных действий.

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

4. Реагирование. Отработать сценарий обнаружения инцидента, определить ответственных и проверить, как компания укладывается в сроки уведомления.

5. Подрядчики. Зафиксировать в договорах порядок доступа, требования к защите, аудит, удаление данных после завершения работ и действия при инциденте.

6. Персонал. Регулярно обучать сотрудников распознаванию фишинга, социальной инженерии и ошибочных способов передачи файлов.

Киберстрахование может покрывать часть остаточного риска, но не заменяет технические и организационные меры. Страховщик, как правило, заинтересован в том, чтобы у компании уже были базовые средства контроля: MFA для администраторов, сегментация, резервное копирование, журналирование и понятный план реагирования. Полис без этих практик не делает систему безопаснее и не освобождает оператора от обязанностей перед субъектами и регулятором.

Отдельно стоит учитывать инсайдерский риск. Даже если точная доля утечек по вине сотрудников в России за отдельный период не установлена в открытой статистике, сама угроза очевидна: человек с легитимным доступом способен обойти часть внешних средств защиты. Особенно уязвимы процессы, где данные выгружаются вручную, передаются через почту или хранятся в общих папках.

Снизить такой риск помогают не тотальная слежка, а разделение полномочий, ограничение массовых выгрузок, контроль аномалий и своевременный отзыв доступа. Для подрядчиков нужен тот же принцип. Их следует рассматривать как часть контура обработки, а не как внешнюю зону, за которую оператор не отвечает.

Защита субъекта как инженерная задача

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

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

Безопасность субъекта в облачных сервисах особенно зависит от прозрачности границ. Нужно понимать, где размещаются данные, кто имеет административный доступ, как работает резервное копирование и что происходит при прекращении договора. В ИИ-сценариях к этому добавляются логи запросов, обучение моделей и возможность передачи контекста внешнему поставщику.

Профилирование и автономные агенты будут усложнять картину. Поэтому оператору недостаточно спрашивать, была ли база зашифрована. Не менее важны вопросы о том, зачем собираются данные, сколько они хранятся, кто видит результат обработки и может ли субъект понять, как сведения повлияли на решение системы.

Финансовые санкции — лишь один из последствий слабой защиты. Есть простой, но более долгий ущерб: потеря доверия, рост мошенничества против клиентов, блокировка процессов, срочная замена интеграций и восстановление инфраструктуры. Инженерный подход не устраняет все риски, но позволяет сделать их видимыми, управляемыми и проверяемыми.

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