Биометрия и ИИ: что требует 152-ФЗ и как обрабатывать по закону

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

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

Почему биометрия требует отдельного разговора

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

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

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

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

Третья: граница между «просто фото» и биометрией, используемой для идентификации, перестала быть размытой. Законодательство всё чётче разграничивает фотографию в личном деле и шаблон лица, на основании которого система принимает решение о доступе. Это разные категории, разные правовые основания, разный режим обработки.

Что это означает для оператора

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

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

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

Для GDPR, европейского регуляторного аналога, биометрия тоже относится к специальной категории (статья 9) с аналогичной логикой: явное согласие, ограниченные основания обработки, строгие требования к безопасности. Компании, работающие одновременно с российскими и европейскими субъектами, оказываются между двумя режимами, которые в части биометрии предъявляют схожие, но не идентичные требования.

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

Как устроена изоляция на практике

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

Мы разворачиваем изолированный контур под требования регулятора: сегментация и изоляция сети, разграничение доступа по ролям (RBAC, то есть управление доступом на основе ролей), нулевое доверие по умолчанию между компонентами. Узлы могут располагаться в РФ, в одном из наших центров обработки данных в нескольких странах или на площадке самого заказчика: это зависит от требований к локализации и операционной модели.

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

Защита критической информационной инфраструктуры, если заказчик относится к этой категории, обеспечивается в соответствии с требованиями 187-ФЗ (закона о безопасности критической информационной инфраструктуры), включая уведомление ГосСОПКА (государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак) и взаимодействие с НКЦКИ (Национальным координационным центром по компьютерным инцидентам). Если требования КИИ не применимы, контур строится под профиль заказчика без этих обязательных процедур.

Пример: финтех с биометрической верификацией

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

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

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

Похожая схема работает в HR-секторе: системы биометрической идентификации при проходе на объект на собственных биометрических шаблонах, где требования к изоляции и локализации аналогичны.

Честный разговор о границах ответственности

Важно назвать вещи своими именами, чтобы не было недопонимания.

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

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

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

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

Итог

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

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

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