Персональные данные с 2024 года превратились в тихую систему координат: вроде не видно, но ошибся на пару градусов — и прилетел штраф или проверка. Особенно когда в одном бизнес-процессе перемешаны обычные, специальные и биометрические данные, а в политике обработки все зовут просто «информация о пользователе».
Время чтения: 12-14 минут
В начале 2026 я снова поймала себя на любимой сцене: отдел кадров уверенно говорит «мы не обрабатываем специальные данные, только анкеты», а в анкете аккуратный вопрос про здоровье и детей. Кофе к этому моменту обычно уже остыл, потому что мы лезем в 152-ФЗ и начинаем разбирать, что такое персональные данные «по-настоящему», а не «как кажется».
Я в PROMAREN живу в этой реальности каждый день: автоматизация, AI-агенты, n8n-сценарии, а где-то рядом — согласия, биометрия и 152-ФЗ, который никуда не делся. И чем активнее бизнес идет в цифру, тем критичнее понимать разницу между обычными, специальными и биометрическими данными, чтобы потом не объяснять регулятору, зачем вам в CRM поле «религия».
Что такое специальные данные и чем они отличаются от обычных?
3 из 5 компаний в РФ по опыту PROMAREN вообще не замечают, что уже собирают специальные данные, пока не приходят жалобы и проверки. Это критично, потому что режим их обработки гораздо жестче, чем для «обычных» полей анкеты.
Персональные данные — это любая информация, которая прямо или косвенно относится к конкретному человеку и позволяет его идентифицировать. Специальные персональные данные — подкатегория, куда закон складывает самые чувствительные вещи: здоровье, расу, национальность, религию, политические взгляды, интимную жизнь и сведения о судимости. Этот список закрытый, он сидит в ст. 10 152-ФЗ, и допридумывать туда ничего не нужно.
Как отличить специальные данные от обычных в живых процессах
Разница между обычными и специальными данными звучит просто, но в документах часто размазывается. Обычные — это все, что позволяет вас узнать: ФИО, дата рождения, паспорт, телефоны, идентификаторы в системах, данные о зарплате, история заказов, даже поведение на сайте, если его можно связать с конкретным человеком. Специальные начинают касаться убеждений, биологии и личной жизни — там, где раскрывается уязвимость или создается риск дискриминации.
Представь стандартный HR-сценарий: резюме в почте, анкета в Google-форме, карточка кандидата в Trello или в CRM. Пока вы спрашиваете ФИО, контакты, опыт — это обычные персональные данные. Как только появляется вопрос «семейное положение», «есть ли дети», «есть ли ограничения по здоровью» — вы вышли на уровень специальных, и простой фразы «галочка в политике обработки» уже не хватает. Здесь закон требует отдельного, явного, лучше письменного согласия, причем с нормальным описанием цели, а не «для кадрового учета».
Когда можно обрабатывать специальные данные и не улететь в штрафы
В начале 2026 картина такая: специальные данные можно обрабатывать либо с явным согласием, либо по узкому списку исключений. Это защита жизни и здоровья, исполнение закона (например, допуск к гостайне), алименты, соцобеспечение, работа с профсоюзами, случаи, когда человек сам сделал свои данные общедоступными. Стоп, вернусь назад: «общедоступность» — не про открытый аккаунт в соцсетях, а про сознательное размещение информации именно для неограниченного круга лиц.
По опыту проектов PROMAREN типичный перекос выглядит так: компания собирает в анкетах или медосмотрах лишнее «про запас», хранит всё в одном Excel на общем диске, а потом удивляется, когда Роскомнадзор интересуется, где цель и почему у половины сотрудников нет корректных согласий. Здесь работает простое правило: сначала фиксируем цель обработки, потом выбираем, какие специальные данные реально нужны, а все остальное смело вычеркиваем. Иначе специальные превращаются в специальную проблему.
Как защитить биометрические данные в 2024–2026 годах?
С биометрией сейчас жестче всех: после реформ 2023–2024 года любой «простой» счетчик рабочего времени по лицу вдруг попадает под режим ЕБС и аккредитаций. И да, «мы храним только фото, это не биометрия» уже не спасает.
Биометрические данные — это физиологические и биологические характеристики человека, которые позволяют однозначно идентифицировать его: голос, лицо по геометрии, радужка глаза, отпечатки пальцев, параметры походки. С 1 июня 2023 автоматизированная обработка таких данных в РФ по сути привязана к Единой биометрической системе (ЕБС), а локальные решения без аккредитации резко превратились в источник регуляторных приключений. По данным Минцифры и разъяснениям Роскомнадзора (источник), именно ЕБС стала базовым контуром для госуслуг и банковской идентификации.
Какие механизмы защиты биометрии сейчас реально работают
Если отбросить красивый маркетинг, по состоянию на начало 2026 у бизнеса по сути три пути. Первый — не трогать биометрию вообще и заменить ее на менее чувствительные способы идентификации: токены, одноразовые коды, классический доступ по пропускам. Второй — идти в ЕБС через банки, МФЦ или аккредитованных партнеров вроде АО «Центр биометрических технологий» и работать с векторами, которые возвращает система (вместо хранения «сырого» лица или голоса).
Третий путь сложнее: аккредитация своей биометрической системы, серьезные меры ИБ, отдельная политика, постоянные аудиты, и… и честное понимание, что это история уже уровня крупного банка или экосистемы, а не среднего бизнеса. Здесь помогает внутренняя архитектура: данные разделяются по контурам, биометрия не попадает в те же хранилища, где лежат договоры и CRM, а доступ к ней строится по принципу наименьших прав. В PROMAREN мы в таких проектах сразу рисуем карту потоков данных — иначе автоматизация через n8n легко делает «дырку» туда, куда никто не планировал.
Как обрабатывать биометрические данные, чтобы не нарушить закон
Юридическая часть выглядит скучно, но без нее все ИТ-меры обнуляются. Согласие на обработку биометрии теперь чаще всего живет в «Госуслугах» или оформляется через МФЦ, а не в виде бумажки на ресепшене. Постановление Правительства №408 2024 года ограничило виды биометрии, которые идут в ЕБС, так что самодеятельность «мы тут свой нейросетевой доступ на лицо прикрутили» стала слишком дорогой.
На практике схема получается такая: человек один раз сдает биометрию в ЕБС, вы как оператор получаете через легальный интерфейс вектор и дальше используете его только для аутентификации, без привязки к ФИО в своей базе. Тут работает простое правило: чем меньше вы храните исходных персональных данных и чем сильнее полагаетесь на обезличенные идентификаторы, тем ниже ваши риски. А поверх уже докручиваются шифрование, многофакторная аутентификация и нормальные журналы доступа — иначе красивая система превращается в дорогую имитацию безопасности.
Какие данные считаются биометрическими на практике?
Самая частая путаница в 2025–2026 — «это просто фото/запись голоса, а не биометрия». Закон и регулятор смотрят иначе: если вы используете характеристику тела, чтобы узнавать человека, — вы в зоне биометрии, даже если это всего одна камера на проходной.
По закону биометрические персональные данные — это сведения, которые характеризуют физиологические и биологические особенности человека и позволяют установить его личность. Классика жанра: отпечатки пальцев, дактилоскопические карты, геометрия лица, радужка глаза, тембр и спектр голоса. Фото само по себе еще не биометрия, но в момент, когда поверх фотографии накручивается алгоритм распознавания и начинается автоматическая идентификация, она очень быстро становится ей.
Где проходит граница между «обычным фото» и биометрией
Здесь я обычно прошу команды представить два сценария. В первом у вас корпоративный портал, сотрудники загружают фото в профиль, чтобы коллегам было проще узнать, кто есть кто. Вы не запускаете распознавание, не сравниваете лица, не используете это для доступа — это близко к обычным персональным данным. Во втором варианте та же камера стоит над турникетом, система строит шаблон лица и по нему решает, открывать дверь или нет. Все, вы в мире биометрии, со всеми вытекающими.
Сервисы уровня Yandex или Google давно живут в этой логике: голосовые ассистенты собирают голос, фото идет в модели, а в РФ все это должно стыковаться с ЕБС и локальными требованиями. Я вижу еще одну типичную иллюзию: «мы маленькие, к нам не придут». По данным обзоров Роскомнадзора и судебной практики за 2024 год (разборы регулятора), под проверки попадают как раз небольшие системы контроля доступа и учета рабочего времени, которые «слегка недооценили» биометрический статус своих данных.
Какие данные точно не относятся к биометрии
Стоп, это не значит, что теперь любые фотографии и любые поведенческие данные автоматически стали биометрическими. Если вы храните копию паспорта для договора — это обычные персональные данные. Если записываете вебинар и не используете запись лица или голоса для последующей автоматической идентификации — это больше про авторские права, чем про биометрию. И даже данные о здоровье (например, справка из медкомиссии) относятся к специальным, но не к биометрическим.
Это означает, что часть паники вокруг «любое фото = биометрия» излишняя, но расслабляться все равно нельзя. Важно честно ответить себе на вопрос: мы используем эту характеристику тела, чтобы однозначно узнать человека автоматически или нет. Если да — добро пожаловать в биометрический режим. Если нет — вы в других категориях, там свои требования, но уже без ЕБС и специфических ограничений, о которых я говорила выше.
Можно ли передавать персональные данные и как не перегнуть палку?
Передавать персональные данные можно, но не «как-нибудь», а по очень приземленной логике: цель — согласие — минимум данных — контроль получателя. В 2024–2025 регулятор перестал прощать формулировки вроде «передаем третьим лицам для улучшения сервиса».
Базовое правило из 152-ФЗ такое: передача возможна, если есть законное основание (договор, закон или согласие) и четко определена цель. Для обычных персональных данных достаточно нормально оформленного согласия с перечислением категорий и получателей. Для специальных и биометрических добавляются требования про письменную форму, отдельные пункты и иногда — про трансграничность, если данные уезжают на сервера за пределы РФ. Тут же всплывают любимые Yandex и Google: интеграции с внешними сервисами, push-аналитика, облака — всё это надо заранее описывать хотя бы в политике.
Как выстроить передачу данных, чтобы не превратить её в серую зону
На практике в проектах PROMAREN часто выясняется, что половина интеграций живет «самостоятельной жизнью»: маркетинг подключил внешний сервис для рассылок, ИТ настроил выгрузку в облако, а юристы про это узнают ближе к проверке. Здесь помогает очень приземленный список, который мы обычно собираем вместе с командой владельцев процессов.
Вот как выглядит рабочий каркас передачи персональных данных между системами и партнерами:
- Зафиксировать цели передачи: зачем вообще кому-то нужны эти данные и что без них не работает.
- Разбить данные по категориям: обычные, специальные, биометрические — у каждой свой набор ограничений.
- Проверить получателей: есть ли у них нужный режим безопасности и договор с нужными формулировками.
- Указать передачу в согласиях и политике: без общих фраз вроде «иным партнерам».
- Продумать журналы: кто, когда и какой массив выгрузил или получил через API.
После такого разбора становится видно, какие потоки можно легализовать, а какие проще отключить, чем тянуть за собой хвост рисков. На сайте PROMAREN я показываю схемы таких потоков и как они дальше превращаются в автоматизацию через n8n, когда уже понятно, какие данные куда можно тащить. И это напрямую подводит нас к вопросу: что будет, если в одном из этих потоков случится утечка.
Когда трансграничная передача становится отдельной головной болью
Трансграничность — это тот момент, когда ваши персональные данные выходят из юрисдикции РФ, а с ними уходят и привычные меры защиты. Сервера за рубежом, внешние аналитические платформы, рекламные кабинеты, которые собирают информацию о пользователях — всё это может попадать под режим трансграничной передачи. Здесь уже важно смотреть, есть ли в стране получателя «адекватная защита» по оценке регулятора или нужны дополнительные гарантии и уведомление Роскомнадзора.
Честно скажу, часть компаний к началу 2026 устала усложнять и просто переехала в отечественные облака, чтобы не спорить с юристами каждый раз, когда маркетинг хочет новый инструмент. Но даже в локальной инфраструктуре не исчезает базовое требование: минимизировать состав передаваемых персональных данных и не использовать «единый мастер-ключ» во всех системах. Поэтому в автоматизации через n8n или Make.com мы часто работаем не с ФИО и паспортами, а с внутренними идентификаторами — нигде так не экономится нервная система, как на осознанной архитектуре.
Чем опасны утечки персональных данных сейчас, а не «вообще»
Утечки персональных данных перестали быть «страшилкой на конференциях» и превратились в обычные новости Яндекса — как погода, только грустнее. В 2025–2026 внимание регуляторов сместилось от «просто факта утечки» к тому, какие именно категории данных ушли и что компания делала до этого момента.
Когда утекают только обычные персональные данные (ФИО, контакты, история заказов), это неприятно, но управляемо: спам, фишинговые звонки, мошенничество с кредитами. Специальные данные сразу добавляют в картину дискриминацию, репутационные потери, угрозы безопасности. Биометрия — отдельный уровень боли, потому что лицо, голос или отпечаток пальца нельзя «поменять», как пароль. По данным отраслевых отчетов уровня Gartner и крупных ИБ-вендоров (аналитика рынка), совокупный ущерб от утечек в 2024–2025 на порядок превышает прямые штрафы — основная часть в простое, потере клиентов и донастройке инфраструктуры.
Какие ошибки чаще всего приводят к утечкам чувствительных данных
В проектах PROMAREN я вижу одно и то же: проблема начинается не с ИБ-систем, а с архитектуры процессов. Специальные и биометрические данные легко оказываются в общем «котле»: медицинские справки в общем архиве кадровых документов, выгрузки из биометрической системы в той же папке, где лежат отчеты для бухгалтерии, доступ через один и тот же VPN для всех подряд. Сверху добавляется автоматизация «на коленке» — скрипт, который раз в час кидает Excel с полным составом персональных данных в Telegram-бота (я серьезно, так тоже делали).
Здесь работает небольшой, но рабочий набор мер, который мы часто собираем с командами:
- Разнести хранилища по категориям: обычные, специальные, биометрические не должны жить в одном общем файловом аду.
- Включить принцип «минимума прав»: доступ к биометрии и здоровью только тем, кому это действительно нужно.
- Пересмотреть автоматизацию: n8n, Make.com, собственные скрипты не должны таскать больше данных, чем требуется.
- Настроить уведомления об инцидентах: лучше лишний алерт, чем тихая утечка за полгода.
- Обучить людей: не пересылать «на всякий случай» в мессенджеры то, что потом придется отзванивать Роскомнадзору.
Когда такие вещи собрать в одну понятную схему, внезапно оказывается, что защита персональных данных — это не «еще один проект ИБ», а нормальная часть управления бизнесом. На страницах с кейсами автоматизации я показываю, как это стыкуется с AI-ботами, RPA и сценариями n8n. В какой-то момент понимаешь, что автоматизация без архитектуры обработки данных — это хаос с красивым интерфейсом, а не помощь бизнесу.
Что делать после утечки и почему готовиться нужно заранее
Формально алгоритм после утечки выглядит очевидно: зафиксировать инцидент, оценить масштаб, уведомить Роскомнадзор и пострадавших, закрыть дыру. Но в реальности без подготовки это превращается в пожар с параллельной импровизацией на тему «кто вообще знает, где у нас лежат персональные данные». Я один раз видела, как компания искренне считала, что хранит только обычные данные, а при разборе инцидента всплыли старые сканы медкарт в архивном облаке — их туда грузили «на время» три года назад.
Здесь работает не героизм, а рутина: карта систем, назначенные владельцы, регулярный аудит, тестовые учения по инцидентам (да-да, как пожарные тревоги) и нормальная коммуникация с людьми. Лучше один раз честно признать, что защита персональных данных — это скучная, но обязательная база, чем потом объяснять утечку в новостях. В PROMAREN мы называем это «методикой white-data»: данные не уходят за контур, который вы не контролируете, а всё, что автоматизируется, сначала проходит через фильтр категорий и прав.
Почему категории данных — это не про юристов, а про здравый смысл
Когда несколько лет подряд смотришь на персональные данные не только как аудитор, но и как человек, который строит автоматизацию, отношение меняется. Категории — обычные, специальные, биометрические — перестают быть «юридическим словарем» и становятся нормальным чек-листом для любого процесса: что мы собираем, зачем, как защищаем и кому отдаем. И если честно, половина проблем исчезает уже на этапе «мы просто перестали спрашивать лишнее в формах».
Для меня это все сводится к одной мысли: право на личную информацию — это не абстракция, а очень конкретная архитектурная задача. Чем прозрачнее процессы и честнее метрики, тем проще подключать нейросети, строить AI-агентов, запускать автоматизацию через n8n и не скакать каждый раз к юристам с криком «мы тут новый сервис прикрутили, можно?». И да, я тоже когда-то думала, что сначала надо сделать идеально, а потом документировать ха-ха сделала наоборот и живу спокойнее 🙂
Обо мне. Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead. С 2024 года помогаю в РФ строить автоматизацию на n8n, Make.com, Cursor, внедряю AI-агентов. Пишу в блоге и в канале PROMAREN.
Если хочется разложить ваши процессы по этим же «данным-слоям» и понять, что можно безопасно автоматизировать, загляни в подход PROMAREN. А если интересно посмотреть, как это работает на живых сценариях и ботовых воронках, заглядывай за разборами в тестовый доступ к демо-боту — там меньше теории и больше схем.
Что ещё важно знать про персональные данные
Нужно ли всегда получать согласие на обработку персональных данных
Не всегда нужно согласие, но по умолчанию лучше считать, что оно требуется. Закон допускает обработку без согласия, когда это связано с трудовыми отношениями, исполнением договора, обязанностями по закону или судебными процедурами. Но как только вы выходите за эти рамки, например, начинаете использовать данные для маркетинга, профайлинга или передачи партнерам, согласие становится обязательным. Если сомневаетесь, безопаснее оформить его, чем потом спорить с регулятором.
Можно ли считать пользовательские логи и куки персональными данными
Да, пользовательские логи, IP-адреса и куки часто считаются персональными данными, если позволяют идентифицировать человека. Когда лог или cookie связаны с аккаунтом, email или другим идентификатором, они попадают под 152-ФЗ. Даже агрегированная аналитика через системы вроде Yandex или Google может содержать персональные элементы. Поэтому нужно описывать работу с такими данными в политике конфиденциальности и учитывать их в общей архитектуре защиты.
Разрешено ли использовать биометрию только для внутреннего контроля доступа
Использовать биометрию для контроля доступа можно, но с 2023 года только в очень конкретном правовом режиме. Если система автоматизирована и строит шаблоны лица или отпечатка, вы попадаете под требования к биометрическим данным и ЕБС или аккредитацию. «Внутреннее использование» не освобождает от закона, оно лишь ограничивает круг субъектов. Поэтому для маленьких компаний зачастую дешевле и безопаснее выбрать небиометрические способы контроля доступа.
Что делать, если пользователь отозвал согласие на обработку его данных
При отзыве согласия нужно прекратить обработку тех данных и в тех целях, которые на нем держались. Это не значит автоматически удалить все сведения о человеке: часть можно продолжать хранить на основании закона, например, для бухгалтерии или отчетности. Но использовать данные для маркетинга, профайлинга или передачи партнерам уже нельзя. Хорошая практика — сразу в архитектуре процессов разделять данные по основаниям, чтобы отзыв не превращался в ручной квест с поиском.
Можно ли передавать обезличенные данные без ограничений
Обезличенные данные передавать проще, но не совсем «без ограничений». Если восстановить личность человека из массива невозможно, такие данные выходят из режима персональных и живут по другим правилам. Проблема в том, что реальное обезличивание сделать не так просто, особенно при склейке разных источников. Поэтому важно документировать метод обезличивания и не хранить рядом ключи, по которым можно обратно привязать информацию к конкретному пользователю.