- 1Фото или аудиозапись не следует автоматически квалифицировать как биометрические данные. Нужно установить признаки, цель и фактическое использование информации.
- 2Статья 11 152-ФЗ предусматривает письменное согласие и законные исключения. Для идентификации и аутентификации отдельно оценивается допустимая схема по 572-ФЗ.
- 3Изменение фотографии на числовой шаблон не снимает вопросы защиты. Важны возможность связать результат с человеком и функция этого результата в системе.
Правовые выводы приведены по состоянию на 2 октября 2026 года. Примеры описывают условные ситуации; рекомендации по организации работы отделены от обязательных требований.
Почему важна цель, а не формат файла
Часть 1 статьи 11 152-ФЗ связывает специальный режим со сведениями о физиологических и биологических особенностях, позволяющими установить личность, которые оператор использует для установления личности человека.
Поэтому одинаковое изображение может участвовать в разных процессах. В профиле оно служит аватаром. При входе в приложение система сравнивает признаки лица с эталоном пользователя. Во втором случае нужно оценивать распознавание личности, а не только хранение фотографии.
С голосом работает тот же подход. Запись разговора для контроля качества и голосовой шаблон для подтверждения клиента нельзя объединять в одну юридическую оценку. Обозначение «аудио» скрывает различие между записью содержания и распознаванием человека.
Отсутствие специального режима биометрии еще не означает, что информацию можно обрабатывать свободно. Фото, запись и связанные с ними сведения могут оставаться персональными данными и требовать проверки по общим правилам.
Какие функции нужно проверить в продукте
Составьте перечень сценариев с лицом, голосом и их производными признаками. В него стоит включить вход по лицу, поиск человека в базе изображений, сравнение селфи с документом, голосовое подтверждение и контроль доступа на объект.
Отдельно изучите функции, которые внешне похожи на распознавание личности: обнаружение лица в кадре, оценка качества изображения, проверка живости. Сами названия ничего не решают. Нужно выяснить, сравниваются ли признаки с данными конкретного человека и как результат используется дальше.
Например, проверка живости может быть только техническим этапом перед сравнением селфи с эталоном. В таком процессе оценивать нужно весь путь, а не отдельный модуль, который поставщик описывает как «не хранящий биометрию».
Попросите разработчика показать входные данные, создаваемый шаблон, источник эталона и итоговое действие. По этой схеме легче определить, где возникает установление или подтверждение личности.
Согласие: что нельзя заменить обычной галочкой
По общему правилу статьи 11 152-ФЗ требуется согласие в письменной форме; исключения перечислены в части 2. Общая галочка под политикой конфиденциальности сама по себе не подтверждает выполнение этого требования. Электронную форму нужно проверить на соответствие установленным правилам.
Пользователь должен понимать, для какой цели обрабатываются его признаки, кто получает сведения и что происходит с ними после проверки. Описание «улучшение сервиса» плохо объясняет вход по лицу или сопоставление с документом.
Часть 3 той же статьи ограничивает обязательность предоставления биометрии и отказ в обслуживании при отказе ее предоставить или согласовать обработку; нужно учитывать предусмотренные законом условия и исключения.
Для обычного продукта заранее продумайте альтернативный путь, если биометрическая функция добровольна: иной способ входа или подтверждения, понятный пользователю и работоспособный. Не оставляйте вопрос отказа на момент обращения в поддержку.
Почему одного согласия недостаточно для 572-ФЗ
Для идентификации и аутентификации важен также 572-ФЗ. Он устанавливает специальную систему правил, включая ограничения обработки вне Единой биометрической системы. В частности, статья 15 содержит запреты и исключения, а статья 16 регулирует аутентификацию через информационные системы организаций.
Из этого следует практический вывод: нельзя обосновать собственную базу лиц только согласием пользователей. Сначала нужно определить допустимую правовую схему, участие ЕБС, требования к организации и применимые исключения. После этого можно проектировать хранение и обмен данными.
Не следует и объявлять, что любая работа с фотографией обязательно требует ЕБС. Статья 1 572-ФЗ определяет сферу действия и исключения, в том числе для предусмотренной ею проверки с участием уполномоченного должностного лица. Исключение из этого закона не отменяет самостоятельную проверку по 152-ФЗ.
Назначение системы нужно описать точно: поиск неизвестного человека, подтверждение заявленной личности и проверка документа — разные задачи. До подключения распознавания попросите юриста сопоставить конкретный процесс с допустимой схемой; выбирать основание после разработки гораздо труднее.
Что происходит с числовым шаблоном
Модель может преобразовать лицо или голос в набор чисел для сравнения. Исходная фотография удаляется, но шаблон продолжает помогать узнавать пользователя. Поэтому утверждение «мы храним только числа» не завершает правовую оценку.
Установите, с какой учетной записью связан шаблон, можно ли использовать его для повторного сравнения и кто имеет к нему доступ. Если результат остается частью механизма распознавания человека, его роль нужно учитывать при определении правового режима.
Для технической команды полезно разделить исходный файл, производный шаблон и журнал проверки. Для каждого определить необходимый срок хранения, доступ и удаление. Сохранять всё бессрочно удобнее для разработки, но для правовой оценки цель и необходимость такого хранения придется обосновать.
Проверьте, не попадают ли изображения и шаблоны в общие журналы, систему аналитики и резервные копии. Настройка удаления в основном сервисе не гарантирует, что сведения исчезают из всех связанных компонентов.
Что выяснить у поставщика распознавания
Уточните, принимает ли поставщик исходный файл или только производные сведения, сохраняет ли их, кто может просматривать результаты и используются ли они для обучения. Если доступ имеют привлеченные организации, выясните их роль и условия обработки.
Попросите описание результата API. Ответ «совпадение найдено» может непосредственно открывать доступ к операции; оценка похожести может лишь помогать сотруднику. Этот результат нужно связать с назначением всей системы и выбранной правовой схемой.
В договоре согласуйте цели обработки, необходимые меры защиты, уведомления о существенных изменениях и инцидентах, сроки хранения и порядок удаления. Содержание поручения обработки и роли сторон проверяются отдельно. Подписанный договор с поставщиком не делает допустимым процесс, который противоречит ограничениям закона.
Как проверить функцию до запуска
Начните с одного сценария и соберите короткое описание: цель, входные сведения, способ сравнения, результат и дальнейшее действие. Отдельно отметьте данные, которые получает внешний сервис и которые остаются у компании.
На этой основе определите режим по статье 11 152-ФЗ и допустимую схему по 572-ФЗ. Затем сопоставьте вывод с интерфейсом, формой согласия, альтернативным способом обслуживания, договором и настройками хранения. Если выводы расходятся с архитектурой, исправлять нужно и документы, и продукт.
Повторите проверку при изменении назначения функции. Приложение, которое вчера только показывало фотографию, после обновления может начать подтверждать личность. Для команды это новая возможность; для компании — основание пересмотреть правовой режим обработки.