Содержание статьи +
- TL;DR
- Почему Это Важно
- Что На Самом Деле Значат «Детекция Лиц» И «Распознавание Лиц» – И Почему Различие Несёт Юридический Вес
- Продакшен-Стек Моделей – Детекция, Выравнивание, Эмбеддинг, Liveness
- Калибровка Выбора – Сравнительная Таблица
- EU AI Act, Простым Языком, Для Инженеров По Лицам
- Слой GDPR Под AI Act
- Эталонная Соответствующая Архитектура
- Где Тут Фора Софт
- Три Ошибки, Которые Продолжают Топить Деплои Лиц
- Численный Пример – Когда Распознавание Окупается
- Ключевые Выводы
- Что Читать Дальше
TL;DR
Детекция лиц – поиск прямоугольников, внутри которых находится лицо в видеокадре – это commodity-технология, которую можно отгрузить в любом браузере, на любом телефоне, на любой встраиваемой плате с помощью open-source-моделей весом меньше мегабайта, работающих быстрее пяти миллисекунд на кадр. Распознавание лиц – взять обнаруженное лицо и сопоставить его с известной личностью – это регулируемая технология в Европейском союзе с 2 августа 2026 года, когда EU AI Act становится полностью применимым к высокорисковым биометрическим системам, и организация, которая разворачивает её без законного основания одновременно по AI Act и по GDPR, рискует штрафами до 35 миллионов евро или 7 процентов мирового оборота за худшие категории нарушений. Самое важное инженерное решение в любой видео-фиче, связанной с лицами, в 2026 году – нужно ли вам на самом деле распознавание или достаточно одной детекции, потому что переход через эту границу превращает низкорисковую продуктовую фичу в задокументированную, зарегистрированную, прошедшую оценку основных прав высокорисковую ИИ-систему. Эта статья проводит вас через технический пайплайн, выбор моделей, защиту от спуфинга, обязательства EU AI Act и GDPR, которые накладываются поверх каждого деплоя, и архитектурный паттерн, который мы используем в Фора Софт, чтобы держать фичи с лицами в соответствии с требованиями, не убивая их полезность.
Почему Это Важно
Если ваш продукт направляет вебкамеру на человека – инструмент видеоконференций, приложение для телемедицинских консультаций, система онлайн-прокторинга экзаменов, чек-ин на живом мероприятии, ИИ-камера видеонаблюдения, дашборд ритейл-аналитики, приложение для знакомств, фитнес-приложение, онбординг в банке – вас рано или поздно попросят добавить фичу с лицами. Иногда запрос невинный: размыть фон только когда в кадре есть лицо; автоматически кадрировать говорящего; посчитать, сколько людей в комнате. Иногда запрос несёт огромный юридический вес: определить, кто в кадре; пометить повторного посетителя; проверить, что человек на онбординге – тот же, что на ID-документе; узнать студента, вошедшего на экзамен. Эти две категории раньше делили один и тот же код. С тех пор как запреты AI Act вступили в силу 2 февраля 2025 года, а высокорисковые обязательства приходят 2 августа 2026 года, они живут в разных мирах. Компании, которые их перепутали – собирая лица из открытого веба, разворачивая идентификацию в реальном времени в публичных местах, вшивая распознавание эмоций в найм или образование – уже заплатили восьмизначные штрафы. Компании, которые провели границу чисто – детекция во фронтенде, распознавание за задокументированным, огороженным и зарегистрированным бэкендом, с записью всего на бумаге – не заплатили. Эта статья показывает, где проходит граница и как провести её в коде.
Что На Самом Деле Значат «Детекция Лиц» И «Распознавание Лиц» – И Почему Различие Несёт Юридический Вес
Люди употребляют детекцию лиц и распознавание лиц так, будто это два варианта одного и того же. Это не так. Это две разные задачи с двумя разными выходами, двумя разными профилями вычислений и – в Европейском союзе с 2026 года – двумя разными регуляторными режимами.
Детекция лиц – это задача найти все лица в изображении и сообщить их ограничивающие рамки. Модель получает RGB-кадр и выдаёт список прямоугольников, по одному на лицо. Некоторые детекторы также сообщают пять ключевых точек лица – левый глаз, правый глаз, нос, левый угол рта, правый угол рта – и оценку уверенности на каждое лицо, но ни на одном этапе процесса детектор не знает, кому принадлежат эти лица. Детекция работает с каждым лицом одинаково, как счётчик людей на входе стадиона работает одинаково с каждым человеком: он считает, но не запоминает. Детекция – это то, что приводит в действие автокадрирование тамбнейла в Zoom или Google Meet, автофокус по лицу на камере телефона, триггер, который подсказывает вашему конференц-приложению, когда включить размытие фона, «улыбочный затвор» в мыльнице.
Распознавание лиц – это задача взять обнаруженное лицо и ответить на один из двух дальнейших вопросов. Первая форма – верификация лиц (также называемая сопоставлением 1:1) – это вопрос «то же ли это лицо, что у нас сохранено для этого пользователя?». Вы видите это каждый раз, когда разблокируете телефон лицом, или когда онбординг в банке проверяет, что только что сделанное селфи совпадает с фото на ID-документе. Вторая форма – идентификация лиц (также называемая сопоставлением 1:N) – это вопрос «кто этот человек из этих N людей в нашей базе?». Вы видите это, когда камера наблюдения помечает вернувшегося магазинного вора, когда турникет стадиона узнаёт владельца абонемента, когда поиск пропавшего человека прогоняет захваченное лицо по списку наблюдения. Обе формы работают, пропуская обнаруженное лицо через модель распознавания, которая выдаёт вектор фиксированной длины – обычно 256, 384 или 512 чисел с плавающей точкой – называемый эмбеддингом лица. Два эмбеддинга затем сравниваются по косинусному сходству или евклидову расстоянию, и настраиваемый порог решает, пришли ли они от одного человека.
Две задачи делят вход – кадр вебкамеры, неподвижное фото, поток CCTV – и первую стадию: лицо нужно найти, прежде чем его можно сопоставить. После этого они расходятся. У детекции нет памяти; распознавание целиком построено вокруг памяти, потому что весь смысл эмбеддинга в том, что вы сохранили его более раннюю копию.
Именно это архитектурное различие – тот шов, по которому режут EU AI Act и GDPR. Общий регламент по защите данных (GDPR) относит данные о лице к особой категории персональных данных по Статье 9 только когда они обрабатываются «с целью однозначной идентификации физического лица» – ровно та задача, которую выполняет распознавание лиц. Анонимная детекция лиц, используемая для подсчёта посетителей, для запуска автокадрирования, для размытия фона, не подпадает под это определение и остаётся под более лёгким режимом обычных персональных данных по Статье 6. AI Act проводит ту же границу, в том же месте, другим языком: детекция – это фича, распознавание – это система биометрической идентификации. Статья 5 AI Act прямо запрещает некоторые применения биометрической идентификации; Приложение III (Annex III) относит остальные к высокому риску и накладывает задокументированный, зарегистрированный, прошедший оценку основных прав режим соответствия на каждый деплой.
Остальную часть статьи мы проведём, предполагая, что вы поняли это различие. Почти каждое инженерное решение в видео-продукте с распознаванием лиц вытекает из него.
Продакшен-Стек Моделей – Детекция, Выравнивание, Эмбеддинг, Liveness
У современного продакшен-пайплайна лица четыре стадии, а не две. Каждая стадия использует свою модель со своими компромиссами по размеру, задержке и точности. Выбор на каждой стадии определяет и стоимость, и комплаенс-позицию.
Стадия 1 – Детекция
Детектор – это всегда включённая стадия. Он работает на каждом кадре или хотя бы на каждом N-м кадре входного потока. Его задача – найти лица и дать каждой следующей стадии хорошо обрезанное, хорошо повёрнутое, хорошо масштабированное изображение лица. В 2026 году в продакшене доминируют два семейства моделей.
Первое семейство – SCRFD от проекта InsightFace. SCRFD – это одностадийный anchor-free детектор лиц, принятый на ICLR 2022. Опубликованное семейство моделей простирается от SCRFD-0.5GF, крошечной модели на 0,5 гигафлопа для мобильного и edge-инференса, до SCRFD-34GF, модели на 34 гигафлопа для критичной к точности пакетной обработки. На сложном (hard) подмножестве WIDER Face – стандартном академическом бенчмарке, который содержит мелкие, перекрытые, в профиль и размытые лица – SCRFD-34GF достигает около 96 процентов средней точности (AP) и превосходит предыдущий лучший детектор TinaFace на 4,78 процента, работая при этом более чем в 3 раза быстрее на GPU. SCRFD-2.5GF, середина семейства, – практическая рабочая лошадка: он весит 2,5 мегабайта после экспорта в ONNX и квантизации, работает за ~7 миллисекунд на кадр на одном ядре CPU и поддерживает вывод пяти ключевых точек, который нужен последующему выравниванию.
Второе семейство – YOLOv5-Face, YOLOv8-Face, YOLOv10-Face и YOLOv11-Face – продакшен-линейка YOLO, адаптированная к задаче детекции лиц добавлением пяти голов регрессии ключевых точек к стандартной голове YOLO. Face-варианты YOLO чуть менее точны, чем SCRFD на WIDER Face hard, но чуть быстрее, и они наследуют богатую оснастку ONNX и TensorRT, которая идёт с экосистемой YOLO. Для команд, уже использующих продакшен-линейку YOLO для общей детекции объектов, YOLO-face – путь наименьшего сопротивления.
Под этими двумя стоит MediaPipe Face Detector, та самая модель, что приводит в действие тамбнейл лица в Google Meet. MediaPipe Face Detector – это single-shot multibox-детектор, настроенный под мобильный и веб-кейс. Его карточка модели заявляет около 1 миллисекунды на кадр на GPU Pixel 6, и он поставляется нативно в пакете @mediapipe/tasks-vision, который мы рекомендовали в уроке по размытию фона. MediaPipe Face Detector – правильный выбор, когда фича с лицом работает в браузере, анонимна и не используется как шаг к распознаванию.
Для большинства серверных или surveillance-кейсов SCRFD-2.5GF – выбор по умолчанию в 2026 году, потому что он стоит в золотой середине по размеру, скорости, точности ключевых точек и экосистеме (он поставляется с эмбеддинг-моделями InsightFace в том же репозитории, с согласованными конвенциями выравнивания).
Стадия 2 – Выравнивание
Эмбеддинги лиц чувствительны к масштабу, повороту и центрированию. Лицо, наклонённое на двенадцать градусов вправо, даёт другой эмбеддинг, чем то же лицо, держащееся прямо, и косинусное сходство между ними может упасть достаточно, чтобы перебросить решение о верификации через порог. Выравнивание это исправляет. Выравниватель берёт пять ключевых точек, выданных детектором, и применяет преобразование подобия (2D-аффинное, допускающее поворот, равномерный масштаб и сдвиг, но не скос), так что центры двух глаз попадают в фиксированные пиксельные координаты в каноническом кропе – обычно 112×112 пикселей для семейства InsightFace ArcFace.
Выравнивание дёшево. Преобразование – это шесть умножений на выходной пиксель плюс билинейная интерполяция. На современном CPU это стоит меньше миллисекунды на лицо. Причина, по которой мы продолжаем это подчёркивать, в том, что пропуск выравнивания – самая частая причина плохой точности распознавания лиц в продакшене. Команды отгружают детектор, отгружают эмбеддер, видят уровень ложных отказов в 5–10 процентов, винят эмбеддер и после недель отладки обнаруживают, что рамка детектора была невыровнена. Хелпер InsightFace face_align.norm_crop() делает правильную вещь в семи строках Python; используйте его.
Стадия 3 – Эмбеддинг
Модель эмбеддинга берёт выровненный кроп лица 112×112 и выдаёт вектор фиксированной длины – обычно 512 чисел с плавающей точкой – который представляет личность. В продакшене доминируют два семейства.
Первое – семейство ArcFace, из того же проекта InsightFace, что и SCRFD. ArcFace был представлен на CVPR 2019 и остаётся архитектурной базой для продакшен-распознавания лиц в 2026 году. Опубликованный зоопарк моделей включает ArcFace-MobileFaceNet (2 мегабайта, для мобильных), ArcFace-R50 (вариант на 50-слойном ResNet, ~95 мегабайт, используется в большинстве серверных деплоев) и ArcFace-R100 (вариант на 100 слоёв, ~250 мегабайт, используется, когда точность – главное ограничение). На бенчмарке IJB-C – стандартном академическом бенчмарке идентификации, со 130 000 изображений 3 500 личностей – ArcFace-R100 достигает около 96 процентов уровня истинного принятия (TAR) при уровне ложного принятия (FAR) 10⁻⁵, что является порогом, который NIST Face Recognition Technology Evaluation использует для своего высшего уровня точности.
Второе – AdaFace, улучшение 2022 года, которое адаптирует отступ (margin) в функции потерь в зависимости от сложности каждого обучающего примера. AdaFace примерно эквивалентен ArcFace на чистых бенчмарках вроде LFW и немного лучше на сложных бенчмарках вроде IJB-C и TinyFace, но топология модели и число параметров те же, что у ArcFace, так что стоимость деплоя идентична. Для нового деплоя «с нуля» в 2026 году AdaFace – разумный выбор по умолчанию; для проекта, который уже использует ArcFace, выигрыш от перехода мал.
Какое бы семейство вы ни выбрали, модель эмбеддинга – это точка пайплайна, в которой начинается режим Статьи 9 GDPR. Ограничивающая рамка – не биометрические данные; 512-мерный эмбеддинг, который идентифицирует человека, – биометрические. Всё, что ниже эмбеддера по потоку – хранение, передача, сравнение, удержание – теперь оперирует персональными данными особой категории, и дизайн защиты данных обязан это уважать.
Стадия 4 – Liveness / анти-спуфинг
Система распознавания, которая не проверяет, принадлежит ли лицо на экране реальному живому человеку перед камерой, может быть обманута поднесением распечатанной фотографии или воспроизведением deepfake-видео. Защита от этого – проверка живости (liveness detection) или анти-спуфинг лиц. В 2026 году продакшен-паттерн совмещает пассивную модель – сеть, которая классифицирует один кадр как реальный или поддельный – с опциональным активным челленджем – подсказкой, просящей пользователя моргнуть, повернуть голову или выполнить определённый жест.
Пассивная модель обучена на датасете вроде CelebA-Spoof, который содержит 625 537 изображений 10 177 субъектов с поддельными изображениями, снятыми в 8 сценах более чем 10 сенсорами. Типичная пассивная liveness-модель – это небольшой классификатор MobileNetV3 или EfficientNet-B0, который берёт тот же выровненный кроп 112×112, что потребляет эмбеддер, и выдаёт вероятность «реальный-или-подделка». Лучшие опубликованные пассивные модели на 6-м Face Anti-Spoofing Challenge достигают усреднённого уровня ошибки классификации (ACER) около 2,1 процента.
Для сценариев высокой гарантии – онбординг в банке, государственный KYC, прокторинг экзаменов – одной пассивной liveness недостаточно. Промышленный стандарт – сертификация iBeta Presentation Attack Detection Level 1 или Level 2, независимый сторонний тест против распечатанных фото, экранных повторов, 3D-печатных масок и силиконовых масок. Сертификацию iBeta рекламируют платёжные процессоры и платформы верификации личности (Onfido, Jumio, Veriff, Persona), когда продают свои liveness-продукты. Если вы строите такую систему сами, планируйте лицензировать сертифицированный вендорский SDK; воспроизведение защиты уровня iBeta своими силами занимает 12–24 месяца сфокусированной работы и непрерывную программу состязательного тестирования.
Калибровка Выбора – Сравнительная Таблица
| Компонент пайплайна | Модель | Размер | Задержка (одно лицо, CPU) | Когда выбирать |
|---|---|---|---|---|
| Детектор | MediaPipe Face Detector | 0,2 MB | ~3 мс | В браузере, анонимная детекция, без распознавания дальше |
| Детектор | SCRFD-0.5GF | 1,1 MB | ~3 мс | Мобильный или edge, нужно распознавание дальше |
| Детектор | SCRFD-2.5GF | 2,5 MB | ~7 мс | Серверный или surveillance по умолчанию |
| Детектор | YOLOv8-Face | 5–6 MB | ~5 мс | Команды, уже на стеке YOLO |
| Выравниватель | InsightFace norm_crop | н/д | <1 мс | Всегда |
| Эмбеддер | ArcFace-MobileFaceNet | 2 MB | ~5 мс | Мобильное распознавание |
| Эмбеддер | ArcFace-R50 | 95 MB | ~15 мс | Серверный по умолчанию |
| Эмбеддер | ArcFace-R100 / AdaFace-R100 | 250 MB | ~35 мс | Критично к точности (банк, KYC, высокие ставки ID) |
| Liveness | Кастомный MobileNetV3 + CelebA-Spoof | 5 MB | ~6 мс | Конференции, e-learning |
| Liveness | iBeta-сертифицированный вендорский SDK | н/д | варьируется | Банк, KYC, платежи, гос. ID |
Задержки – ориентировочные цифры для одного лица на современном ядре x86 CPU с ONNX Runtime; цифры на GPU примерно в 4–6 раз быстрее для более тяжёлых моделей. Числа, приведённые по каждой модели, совпадают с цифрами, опубликованными в карточках моделей, оригинальных статьях и публичных бенчмарках InsightFace. Относитесь к ним как к оценкам для планирования, а не как к замене измерению на вашем целевом железе.
EU AI Act, Простым Языком, Для Инженеров По Лицам
EU AI Act – это горизонтальный регламент Европейского союза об искусственном интеллекте. Полный текст – Регламент (ЕС) 2024/1689 – вступил в силу 1 августа 2024 года. Обязательства вводятся поэтапно в течение трёх лет. Фазы, которые имеют значение для любой фичи с лицами, таковы:
- 2 февраля 2025. Вступили в силу запреты Статьи 5. После этой даты в ЕС незаконно выводить на рынок или использовать любую ИИ-систему, попадающую в восемь запрещённых категорий. Четыре из этих восьми категорий напрямую касаются технологий с лицами.
- 2 августа 2025. Вступили в силу обязательства провайдеров моделей ИИ общего назначения (вышестоящий слой базовых моделей). Это в основном актуально для организаций, которые обучают или распространяют крупные vision-language-модели.
- 2 августа 2026. Вступают в силу обязательства по высокорисковым ИИ-системам в рамках Annex III. Это дедлайн, который имеет значение почти для каждого деплоя распознавания лиц в ЕС. С этой даты любая организация, которая выводит на рынок или вводит в эксплуатацию систему распознавания лиц в ЕС, обязана соответствовать полному высокорисковому режиму: управление рисками, управление качеством, техническая документация, пострыночный мониторинг, оценка соответствия, регистрация в базе данных ЕС, прозрачность для деплоеров и человеческий надзор.
Закон применяется национальными органами в каждом государстве-члене ЕС при координации Европейского офиса по ИИ (European AI Office). Штрафы за категории запрещённых практик достигают 35 миллионов евро или 7 процентов мирового годового оборота, в зависимости от того, что больше. Штрафы за несоблюдение высокорисковых обязательств достигают 15 миллионов евро или 3 процентов мирового оборота. Оба потолка превышают максимальный штраф GDPR (20 миллионов евро или 4 процента мирового оборота).
Четыре запрещённых применения лиц
Статья 5(1) AI Act прямо запрещает эти связанные с лицами применения в ЕС. Нет ни пути сертификации, ни механизма opt-in, ни отраслевой «тихой гавани». Строить или продавать такую систему незаконно.
- Нецелевой сбор изображений лиц для построения или расширения баз распознавания лиц. Статья 5(1)(e) прямо называет паттерн Clearview: краулинг веба или сбор записей CCTV для наполнения поисковика по лицам. Именно за это французский орган по защите данных оштрафовал Clearview ИИ на 20 миллионов евро.
- Распознавание эмоций на рабочих местах и в образовательных учреждениях. Статья 5(1)(f) запрещает системы, которые выводят эмоции физических лиц на рабочем месте или в образовании, с узкими исключениями для медицинских целей и безопасности. «Анализатор настроения кандидата» в видео-пайплайне найма или «оценщик вовлечённости студента» в онлайн-классе незаконен в ЕС.
- Биометрическая категоризация по чувствительным признакам. Статья 5(1)(g) запрещает системы, которые категоризируют физических лиц по биометрическим данным, чтобы вывести расу, политические взгляды, членство в профсоюзе, религиозные или философские убеждения, сексуальную ориентацию или половую жизнь. «Детектор расы» или «классификатор религии», построенный поверх модели лица, незаконен.
- Биометрическая идентификация в реальном времени в публично доступных пространствах для целей правоохранительных органов. Статья 5(1)(h) запрещает распознавание лиц в реальном времени в публичных местах, с тремя узкими исключениями, зарезервированными только для правоохранительного использования и под судебной санкцией: целевой поиск жертв похищения, торговли людьми или сексуальной эксплуатации; предотвращение неминуемой угрозы жизни или теракта; и розыск подозреваемых в тяжких преступлениях, наказуемых лишением свободы не менее четырёх лет. Исключения требуют оценки воздействия на основные права по Статье 27 и регистрации в базе ЕС по Статье 49. Коммерческий продукт, который ставит идентификацию лиц в реальном времени в торговом центре, на стадионе или на вокзале, проданный частным операторам, не подпадает ни под какое исключение и незаконен.
Высокорисковый режим для всего остального
Распознавание лиц, которое не запрещено, по умолчанию высокорисковое. Annex III, пункт 1 AI Act относит к высокому риску любую ИИ-систему, предназначенную для использования как «система удалённой биометрической идентификации» (с узким исключением для биометрической верификации – случая 1:1 «разблокируй свой телефон»), для биометрической категоризации по чувствительным признакам (когда не запрещена прямо) или для распознавания эмоций (когда не запрещено прямо).
Высокорисковая классификация запускает девять конкретных обязательств. Мы кратко изложим каждое, затем опишем инженерную работу, которую оно подразумевает.
1. Система управления рисками (Статья 9). Непрерывный, задокументированный процесс, который идентифицирует, анализирует и снижает риски на протяжении жизненного цикла системы. В инженерных терминах это означает письменный реестр рисков, владельца на каждый риск, доказательства снижения на каждый риск и ежеквартальный повторный пересмотр. Стройте его на той основе ISMS или управления качеством, что у вас уже есть; не изобретайте заново.
2. Управление данными (Статья 10). Обучающие, валидационные и тестовые датасеты должны быть релевантными, репрезентативными, свободными от ошибок и полными. Для систем с лицами это напрямую отображается в демографическую справедливость. Система должна быть протестирована на паритет точности по возрасту, полу и тону кожи – трек верификации 1:1 NIST FRVT и трек идентификации 1:N FRVT публикуют ровно эту оценку, и высокорисковый деплоер должен ссылаться на NIST FRVT или проводить эквивалент своими силами.
3. Техническая документация (Статья 11, Annex IV). Подробное досье, охватывающее назначение системы, архитектуру, датасеты, метрики производительности, управление рисками, план мониторинга и инструкции по использованию. Это документ, который нотифицированный орган или национальный регулятор потребует во время аудита соответствия. Планируйте от 30 до 80 страниц в зависимости от сложности системы.
4. Ведение записей (Статья 12). Автоматическое логирование событий, релевантных для идентификации рисков. Для системы распознавания лиц это означает защищённый от подделки журнал каждого решения об идентификации (совпадение / нет), каждого изменения порога, каждой развёрнутой версии модели и каждой модификации базы данных.
5. Прозрачность для деплоеров (Статья 13). Система должна сопровождаться инструкциями по использованию, которые раскрывают точность, ограничения, границы предполагаемого использования и требования к человеческому надзору.
6. Человеческий надзор (Статья 14). Система должна быть спроектирована так, чтобы человек мог вмешаться, интерпретировать выходы и отменять решения. Для идентификации лиц это означает проверку человеком в контуре любого значимого совпадения до того, как будет предпринято действие (никакого полностью автоматического ареста, отказа во входе или расторжения договора на основании одного совпадения лица).
7. Точность, устойчивость, кибербезопасность (Статья 15). Количественные заявления о точности, устойчивость к состязательным входам и стандартная гигиена кибербезопасности.
8. Оценка соответствия (Статьи 43, 44). Формальная оценка соответствия до вывода на рынок. Для систем с лицами это обычно внутренняя оценка соответствия по Annex VI, поддержанная нотифицированным органом только тогда, когда гармонизированные стандарты ещё недоступны.
9. Регистрация в базе данных ЕС (Статья 49). Провайдер обязан зарегистрировать систему в публичной базе данных ЕС до вывода на рынок. Деплоеры (организации, которые вводят систему в использование и могут отличаться от провайдера) также обязаны зарегистрировать своё использование, если они являются публичными органами.
Две другие статьи проходят поперёк этих обязательств и важны для систем с лицами:
- Статья 27 – оценка воздействия на основные права. Публичные органы и частные операторы высокорисковых биометрических систем обязаны провести FRIA до первого использования. FRIA документирует категории затронутых физических лиц, конкретные риски вреда, меры человеческого надзора и механизмы управления. Банк, разворачивающий онбординг с верификацией лица, обязан составить её до запуска в ЕС.
- Статья 50 – обязательства по прозрачности для определённых ИИ-систем. Даже когда система не классифицирована как высокорисковая, деплоеры биометрической категоризации или распознавания эмоций (где не запрещено) обязаны информировать затронутых физических лиц, что они взаимодействуют с такой системой. Деплоеры любой системы, которая генерирует или манипулирует синтетическим контентом (deepfakes), обязаны раскрывать, что контент сгенерирован искусственно.
Слой GDPR Под AI Act
AI Act стоит поверх GDPR; он его не заменяет. Система распознавания лиц, которая соответствует AI Act, всё равно обязана удовлетворять GDPR. Система детекции лиц, которая не запускает AI Act, всё равно обязана удовлетворять GDPR, если детекция происходит в ЕС или обрабатывает данные резидентов ЕС.
Отношение GDPR к данным о лице имеет две стороны.
Первая сторона – законное основание по Статье 6. Каждой операции обработки нужно законное основание. Для потребительской фичи с лицом самые частые основания – явное согласие (Статья 6(1)(a)), исполнение договора (Статья 6(1)(b)) и законные интересы (Статья 6(1)(f)). Анонимная детекция лиц – для автокадрирования, подсчёта посетителей, запуска размытия фона – обычно может опираться на законные интересы после теста на баланс, который документирует необходимость обработки и минимальность удерживаемых данных.
Вторая сторона – условие особой категории по Статье 9, которое вступает в силу в тот момент, когда система обрабатывает биометрические данные с целью однозначной идентификации человека. Статья 9 исходит из запрета по умолчанию: обработка биометрических данных для идентификации запрещена, если не применяется одно из десяти исключений. Для деплоев частного сектора единственное реалистичное исключение – Статья 9(2)(a), явное согласие. Явное согласие – более высокая планка, чем обычное согласие по Статье 7: это должен быть ясный утвердительный акт, в письменной форме или записанным заявлением, называющий конкретную операцию обработки и её цели, и отзываемый в любой момент без ущерба.
Два известных правоприменительных действия показывают цену ошибки в любой из сторон. Испанская сеть супермаркетов Mercadona была оштрафована на 2,52 миллиона евро в 2021 году органом AEPD за развёртывание распознавания лиц в магазинах против магазинных воров; AEPD не нашёл ни действительного законного основания, ни пропорциональности. Французский CNIL оштрафовал Clearview ИИ на 20 миллионов евро в 2022 году за сбор биометрических данных из более чем 20 миллиардов онлайн-фотографий без согласия, и запрет AI Act 2025 года позже подтвердил, что эта практика теперь запрещена прямо.
Есть ещё пять положений GDPR, которые жёстко кусают системы с лицами и которые инженеры склонны недооценивать:
- Минимизация данных (Статья 5(1)(c)). Храните наименьшее представление, которое решает задачу. Для верификации вам не нужно удерживать фото – нужен только эмбеддинг. Для идентификации может не понадобиться и то, и другое. Выбрасывайте пиксели, как только получили вектор.
- Ограничение хранения (Статья 5(1)(e)). Удержание должно быть привязано к цели. Эмбеддинг лица, хранимый «на случай, если понадобится позже», – это нарушение. Задайте политику удержания на каждый кейс; мы обычно ставим по умолчанию 24 часа для эфемерной идентификации (например, пропуск посетителя), 90 дней для эмбеддингов расследования мошенничества и срок жизни аккаунта для эмбеддингов верификации, привязанных к личности пользователя.
- Право на доступ (Статья 15) и право на удаление (Статья 17). Пользователь должен иметь возможность запросить копию своего эмбеддинга и потребовать его удаления. Модель данных обязана поддерживать перечисление и удаление эмбеддингов по каждому пользователю, в том числе в любом векторном индексе.
- Оценка воздействия на защиту данных (Статья 35). Обязательна для «систематической и обширной оценки персональных аспектов» и для «обработки в крупном масштабе особых категорий». Система распознавания лиц в продакшене почти всегда запускает оба – DPIA по сути является предусловием.
- Статья 22 – автоматизированное принятие решений. Выход распознавания лиц, который порождает «решение, основанное исключительно на автоматизированной обработке... которое порождает юридические последствия в отношении него или аналогичным образом существенно его затрагивает», даёт субъекту данных право на вмешательство человека. Это стыкуется со Статьёй 14 AI Act – человеческий надзор требуется дважды, по разу каждым регламентом.
Два регламента сцепляются чисто. Там, где AI Act требует логировать решения и проводить FRIA, GDPR требует логировать доступ и проводить DPIA. Делайте оба одним набором артефактов, где возможно; не притворяйтесь, что одно обязательство отменяет другое.
Эталонная Соответствующая Архитектура
Фича с лицом, построенная для ЕС в 2026 году, выглядит иначе, чем построенная для США в 2020-м. Архитектурный паттерн ниже – тот, что мы используем в проектах Фора Софт. Он принципиальный; это не единственный валидный паттерн, но он устраняет целые классы комплаенс-провалов по построению.
У паттерна четыре направляющих принципа.
Детектируй на клиенте, распознавай на сервере. Детектор работает в браузере или на устройстве с MediaPipe Face Detector или SCRFD-0.5GF в ONNX Runtime Web. Сырой кадр никогда не покидает устройство для фич только-детекции (размытие фона, автокадрирование, определение присутствия). Для фич, которым нужно распознавание, клиент отправляет на сервер только выровненный кроп лица 112×112 – и только после того, как пользователь дал явное согласие на эту конкретную операцию. Пиксели и рамки не текут в путь распознавания, пока пользователь не согласился.
Две зоны хранения с односторонним шлюзом. Операционные эмбеддинги (для живых звонков, эфемерной идентификации) лежат в горячем векторном хранилище с TTL 24 часа. Постоянные эмбеддинги (для верификации, для расследования мошенничества) лежат в отдельном холодном хранилище с явными метаданными удержания на каждую строку и контролем доступа по цели. Код, читающий из холодного хранилища, огорожен за сервисом, который логирует каждый доступ для аудит-трейла Статьи 12 AI Act.
Никакого удержания изображений по умолчанию. Пайплайн производит эмбеддинг и отбрасывает исходные пиксели в том же запросе. Удержание сырых изображений лиц требует явного флага по цели, явной записи согласия, периода удержания и задания на удаление. Мы не видели в 2026 году продакшен-кейса, который оправдывал бы постоянное удержание сырых пикселей вне форензики расследования мошенничества, и даже там мы используем короткоживущие зашифрованные блобы.
Человек в контуре на каждом значимом совпадении. Ни одно бизнес-решение – предоставление доступа, пометка мошенничества, отказ в услуге – не работает на одном совпадении лица. Человек-проверяющий видит кандидатное совпадение, исходный кадр, сопоставленный шаблон и структурированную оценку уверенности, прежде чем будет предпринято любое действие. Это требуется Статьёй 14 AI Act и согласуется со Статьёй 22 GDPR.
В коде эти четыре принципа превращаются в горстку архитектурных узлов: клиентский пакет детекции, API подачи кропа лица, принимающий токен согласия, stateless-сервис эмбеддинга, который выдаёт вектор и не хранит пиксели, горячий векторный индекс с заданием TTL, холодное векторное хранилище за сервисом логирования доступа и UI проверки, который выводит совпадения для подтверждения человеком. Ничего из этого не экзотично; всё это нудно дорабатывать задним числом. Стройте это с первого дня.
Где Тут Фора Софт
Мы строим фичи с распознаванием лиц в конференциях, телемедицине, видеонаблюдении, e-learning и приложениях для знакомств с 2018 года. Паттерн в этой статье дистиллирован из тех проектов. Самый частый запрос, который мы слышим в 2026 году, – от продуктовых команд, которые начали с анонимной детекции в 2022-м, добавили фичу «запомни этого пользователя» в 2023-м и теперь должны примирить эту тихо отгруженную фичу распознавания с дедлайном AI Act в августе 2026-го. Исправление редко техническое и почти всегда организационное: письменный DPIA, письменная FRIA, письменная политика удержания, письменный протокол человеческого надзора, зарегистрированная запись в базе данных ЕС и откровенный разговор с командой по работе с клиентами о том, что раскрывать конечным пользователям. Мы помогаем с архитектурой и инженерией; юридический текст мы передаём специалисту по защите данных клиента для доработки, а не пишем с нуля.
Три Ошибки, Которые Продолжают Топить Деплои Лиц
Одни и те же три провала появляются в комплаенс-аудитах снова и снова. Распознайте их в своей собственной дорожной карте раньше, чем это сделает аудитор.
Первая ошибка – использование одного и того же кода для детекции и распознавания. Команды пишут FaceService, который детектирует, выравнивает, эмбеддит и сопоставляет в одном вызове, а затем выставляют его на каждую продуктовую поверхность. Результат: фича автокадрирования, которой никогда не нужно было распознавание, в итоге проходит через код, который касается хранилища эмбеддингов, журнала согласий и аудит-трейла. Каждый аудит стоит в десять раз дороже, чем должен. Разделяйте пути кода с первого дня. Детекция – один сервис; распознавание – другой; ничто не пересекает границу без явного токена согласия.
Вторая ошибка – использование хостингового вендора без чтения приложения об обработке данных (DPA). Многие API для лиц – включая некоторые популярные – обучают свои модели на изображениях, присланных клиентами, по умолчанию, если клиент явно не откажется в письменной форме. Даже если ваш договор соответствует требованиям, эталонная архитектура вендора может не соответствовать. Проверьте поток данных вендора, потребуйте DPA, запрещающее вторичное использование, и проверьте собственную позицию вендора по AI Act и GDPR до интеграции.
Третья ошибка – отгрузка распознавания без liveness под этикеткой «безопасно». Верификация без анти-спуфинга обходится распечатанным фото. Маркетинг фичи разблокировки или онбординга по лицу без задокументированной защиты liveness – это проблема раскрытия риска мошенничества раньше, чем проблема комплаенса; как только первый deepfake-обход попадёт в новости, она становится и тем, и другим. Если кейс – что-либо иное, чем эфемерная идентификация в контролируемой среде, отгружайте liveness с первого дня и закладывайте бюджет на путь сертификации iBeta.
Численный Пример – Когда Распознавание Окупается
Короткий пример, чтобы заземлить выбор моделей в стоимости. Предположим, вы оперируете корпоративной платформой видеоконференций на 10 000 сотрудников. Вы хотите добавить вход по верификации лица: сопоставление 1:1 между кадром вебкамеры пользователя и фото из досье, используемое как второй фактор после пароля.
Стоимость вычислений на один вход: одна детекция (SCRFD-0.5GF, ~3 мс), одно выравнивание (~0,5 мс), одно извлечение эмбеддинга (ArcFace-MobileFaceNet, ~5 мс), одно косинусное сходство (пренебрежимо мало). Итого на вход: ~9 миллисекунд CPU.
Стоимость хранения на один вход: 1 эмбеддинг × 512 чисел × 4 байта = 2 048 байт = 2 KB на пользователя. На 10 000 пользователей: 20 мегабайт. Векторное хранилище помещается в RAM на самом маленьком облачном инстансе.
Сетевая стоимость на один вход: выровненный кроп 112×112 в градациях серого – 12,5 KB; ответ-эмбеддинг – 2 KB. Round-trip уверенно меньше 50 KB.
При 10 000 входов в день предельная стоимость вычислений – 0,025 CPU-часа в день, или примерно $0,03 в месяц по стандартным облачным ценам. Фича верификации окупается в первый же раз, когда блокирует атаку перебором учётных данных (credential stuffing).
Теперь рассмотрим ту же архитектуру, превращённую в идентификацию 1:N – система должна узнать, кто из 10 000 сотрудников только что вошёл в переговорную. На один инференс: одна детекция плюс один эмбеддинг плюс 10 000 косинусных сравнений. Косинус на 512-мерном векторе – это 1 024 умножения-сложения; 10 000 сравнений – это примерно 10 миллионов MAC, которые современный CPU отрабатывает за 5–10 миллисекунд векторизованным кодом. Итого на инференс: ~20 миллисекунд. Хранение и сеть не меняются.
Стоимость вычислений едва отличается. Стоимость комплаенса отличается дико. Случай верификации 1:1 исключён из Annex III, требует явного согласия по Статье 9 GDPR, но не является высокорисковой ИИ-системой по AI Act. Случай идентификации 1:N является высокорисковой ИИ-системой по Annex III и запускает полный режим из девяти обязательств выше. Те же 20 миллисекунд CPU перемещают проект из двухнедельного спринта в шестимесячную комплаенс-программу. Выбирайте соответственно.
Ключевые Выводы
- Детекция лиц не регулируется AI Act и живёт под Статьёй 6 GDPR; распознавание лиц высокорисковое и живёт под Статьёй 9 GDPR.
- Два регуляторных режима встречаются на шаге эмбеддинга – всё, что производит 512-мерный вектор личности, запускает часы особой категории.
- AI Act прямо запрещает четыре конкретных применения лиц в ЕС с февраля 2025 года; строить или продавать их незаконно независимо от согласия.
- Дедлайн августа 2026 года приносит полный высокорисковый режим – документация, регистрация, FRIA, человеческий надзор – почти для каждого другого деплоя распознавания лиц.
- Продакшен-выборы по умолчанию в 2026 году – SCRFD-2.5GF для детекции, выравнивание InsightFace, ArcFace-R50 или AdaFace для эмбеддинга, CelebA-Spoof для пассивной liveness и iBeta для сценариев высокой гарантии.
- Самая дешёвая комплаенс-позиция архитектурна: разделить детекцию и распознавание, огородить шлюз согласием, удерживать эмбеддинги, а не пиксели, и ставить человека на каждое значимое совпадение.
Что Читать Дальше
- SAM 2 для видео – модуль памяти, распространение, ротоскопинг – примитив сегментации, который лежит в основе маскирования области лица, когда вам нужна маска, а не рамка.
- MediaPipe Selfie Segmentation V2 с WebGPU – production-размытие фона – браузерный пайплайн сегментации, который естественно сочетается с анонимной детекцией лиц для автокадрирования и присутствия.
- Форма ИИ внутри видео-продукта – карта архитектуры – архитектурный праймер, объясняющий, куда фичи с лицами цепляются в типичном видео-пайплайне.