Чому детекція живої особи ламається на реальних потоках
У лабораторії перевірка живості виглядає надійно: рівне світло, штатив, чиста оптика.
У бойовому потоці через дешеву фронталку в метро чи біля вікна контраст падає, кадри йдуть із шумом і розсинхроном за стисненням — і детекція живої особи або пропускає підробку, або ріже реальних клієнтів.
Хибні відмови на реєстрації — найдорожча частина: людина один раз уткнулася в «повторіть», і частина вже не повертається.
Атаки підміни обличчя в бою теж рідко виглядають як у демо. Повторне використання запису — заздалегідь зняте відео диктора, піднесене до камери; грубіше — фото на екрані з блискучим склом.
Складніший перехоплення потоку: віртуальна камера або підміна відеоряду до аналізу, коли всі перевірки формально проходять, тільки замість людини — програмний двійник.
Перевірка живості за одним кадром цього не розрізняє: у неї немає ні глибини, ні динаміки. Звідси дві помилки одразу — високий поріг ловить сцени, але плодить відмови, низький відкриває обхід перевірки живості.
У довгій воронці страждає не безпека, а конверсія: потік іде в ручний розбір, а частина клієнтів — до тих, у кого реєстрація пройшла з першого разу.
Розбираємо, як це закривається: каскад перевірок, активні випробування й аналіз ін'єкцій на рівні захоплення потоку. Частина команд для швидкого старту бере готові рушії, наприклад iProov, — але сценарій згоди, деградації якості та відкату все одно проєктується під продукт.
Що дає перевірка живості: вимірювані ефекти на вході
Ефект перевірки живості вимірюється не точністю моделі на демонстраційній вибірці, а набором лічильників, які ми знімаємо з реального трафіку до впровадження й порівнюємо після. Так видно, що саме змінилося на вході в реєстрацію, а не «стало краще загалом».
Набір метрик однаковий для будь-якої воронки: частка відсічених атак, частка успішних проходжень, час перевірки, кількість повторних спроб і структура відмов.
- Частка відсічених атак — рахуємо окремо за класами підміни: статичний знімок, знімок з екрана, відеопотік з екрана, маска, синтетично згенероване обличчя. За презентаційними класами відсічення виходить на рівень, підтверджуваний незалежною сертифікацією iBeta, і не розмивається одним усередненим показником.
- Конверсія реєстрації — пасивна перевірка без завдань «поверніть голову» не зрізає воронку: живі користувачі проходять крок із першої спроби, а частка тих, хто дійшов до кінця, зростає за рахунок тих, хто раніше кидав сценарій на середині.
- Час проходження перевірки — вкладається в 1-3 секунди разом із захопленням кадру та ухваленням рішення; окремий застосунок і ручна модерація для цього не потрібні.
- Кількість повторних спроб — знижується, коли підказки щодо світла й положення обличчя в кадрі повертають людину в той самий сценарій, а не викидають на початок.
- Клас відмов — іде хибний пропуск підміни; хибна відмова живій людині стає керованою величиною через поріг чутливості та розбір спірних випадків за журналом рішень.
Кожен пункт — не звітна цифра, а ручка налаштування: змінюючи поріг, ми бачимо, як перебудовується баланс між відсіченням атак і часткою успішних проходжень.
Формати детекції живої особи: пасивна, активна, гібридна
Режим перевірки обирають не за точністю «у вакуумі», а за сценарієм входу: чим користувач знімає себе, скільки зусиль готовий вкласти й що дорожче обходиться — пропущена підміна чи втрачений клієнт.
Той самий алгоритм на масовому підключенні та на підтвердженні великої операції дає різний результат: там, де вища ціна пропуску, виправдана суворіша перевірка, там, де важливий потік, — непомітна для людини.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пасивна перевірка живості | Масовий вхід із мобільного: звичайне селфі, без інструкцій і зайвих кроків | Чутлива до світла та якості кадру; на слабких фронтальних камерах зростає частка хибних відмов, а причину відмови складно пояснити користувачеві |
| Активна перевірка живості | Повторна верифікація, зміна реквізитів, виведення коштів — сценарії з підвищеним ризиком | Помітно подовжує вхід, залежить від зрозумілості підказок; недоступна частині людей з обмеженнями руху, вища частка покинутих спроб |
| Гібридна схема перевірки | Змішаний потік: непомітна перевірка на вході з ескалацією в активну за рівнем ризику | Складніша в підтримці: потрібні калібрування порогів, аналітика відмов і дисципліна оновлення правил, довший вихід в експлуатацію |
Обмеження методу проявляються лише на живому трафіку, тому ми знімаємо метрики на пілотній вибірці — частка успішних спроб із першого разу, причини відмов, час проходження, — і за ними обираємо режим. Так рішення підлаштовується під ваш сценарій входу, а не під опис із презентації.
Етапи впровадження перевірки живості: від схеми до передачі
Впровадження перевірки живості починається не з коду, а з розбору вашого сценарію верифікації: де користувач, де оператор, що відбувається при відмові й який рівень ризику ви готові прийняти.
Далі порядок фіксований — спочатку описуємо дані в русі, потім калібруємо чутливість під ваш трафік, і тільки потім перевіряємо рішення на живих людях і спробах підміни.
Так виключається ситуація, коли детекція живої особи проходить лабораторні тести, але на бойовому потоці пропускає підробку або блокує реального клієнта.
-
Аудит сценарію верифікації. Розбираємо кроки користувача: реєстрація, вхід, повторна перевірка, ескалація на оператора. Фіксуємо, на якому кроці потрібна детекція і що вважається провалом — відмова чи запит додаткового підтвердження.
-
Схема потоків даних. Визначаємо, де знімається кадр, де обробляється, що йде в зовнішні сервіси, а що залишається у вашому контурі. На схемі видно точки зберігання та строки життя біометричних даних.
-
Налаштування порогів чутливості. Поріг — це компроміс між хибним пропуском підробки та хибною відмовою живій людині. Калібруємо на вашій статистиці: якість камер, освітлення, типові пристрої користувачів.
-
Перевірка на живих людях. Прогоняємо сценарій на співробітниках і реальному трафіку: різні умови знімання, вік, окуляри, головні убори, слабкий зв'язок.
-
Перевірка на спробах підміни. Окремий набір атак: фото з екрана, роздруківка, відеозапис, маска, підміна відеопотоку. Кожен клас рахуємо окремо, щоб бачити, де рішення тримає удар.
-
Передача рішення й навчання команди. Віддаємо конфігурації, схему, набір тестових сценаріїв, документацію щодо порогів і порядку перекалібрування. Ваші інженери змінюють чутливість і додають сценарії без нас.
Конфігурації, схеми й регламенти: що залишається замовникові
Застосунок перевірки живості не повинен залишатися чорною скринькою, доступною лише розробникові. Ми передаємо команді замовника повний набір артефактів — від профілів перевірок до порядку дій при підозрілій спробі проходу.
Цього достатньо, щоб налаштовувати чутливість під свій трафік, розбирати спірні випадки й розвивати рішення без нас.
- Профілі перевірок — активні сценарії, пороги впевненості та правила для різних точок входу: веб, мобільний застосунок, термінал на ресепшен. Змінюються налаштуванням, без перезбирання моделі.
- Схеми інтеграції — порядок викликів, формати відповідей, поведінка при недоступності сервісу, приклади запитів для кожного каналу.
- Регламент розбору інцидентів — як відрізнити хибну відмову від спроби підміни, які події зберігати, кому ескалювати й у які строки.
- Документація з верифікації — опис кожної перевірки, склад перевірного набору, частки хибних пропусків і хибних відмов на вашому потоці.
- Політика зберігання та журналювання — які кадри й події пишемо, що маскуємо, скільки зберігаємо й як видаляємо на запит суб'єкта.
- Інструкції з експлуатації — оновлення профілів, відкат на попередню версію моделі, список перевірок перед випуском змін.
- Передача знань — розбір архітектури з вашою командою, відповіді щодо спірних випадків, контакти за рівнями підтримки.
Після передачі рішення ви керуєте налаштуваннями й розбором випадків самі, а наша роль зводиться до консультацій щодо складних епізодів.
Кейс: як пішов клас атак із підміною обличчя на верифікації
Що було до
Верифікація трималася на порівнянні селфі з фото документа, а ознака «в кадрі жива людина» не перевірялася взагалі.
Обхід ішов трьома шляхами: фото з екрана, заздалегідь записане відео та віртуальна камера, що підміняє потік із пристрою, — кожна така спроба проходила як звичайна заявка.
Частка пропущених підмін трималася близько 9%, хибні відмови сягали 12%, а ручний розбір підозрілих заявок забирав в операторів майже половину зміни.
Що змінили
Перевірку живості вбудували прямо в момент знімання: пасивна оцінка кадру плюс коротка активна послідовність, яку неможливо відтворити записом.
Розбір спроб обходу винесли в окремий журнал — із типом підміни, причиною відмови та рішенням моделі, щоб кожну нову схему було видно й можна було закрити правилом, а не разовою забороною.
Налаштування вели на реальних заявках і окремо стежили, щоб відмови не отримували справжні клієнти при слабкому світлі, окулярах чи русі.
Що стало
Частка пропущених підмін упала з ~9% до 0.4%, хибні відмови — з 12% до 3%, успішних проходжень із першої спроби стало більше на чверть. Черга ручної перевірки скоротилася приблизно вчетверо: оператори дивляться лише на пограничні випадки.
Стійкість до нових схем підміни підтвердили незалежним тестом за методикою iBeta — це зовнішня перевірка, а не наша внутрішня оцінка.
Чим пасивна перевірка живості відрізняється від активної?
Пасивна перевірка не вимагає від людини нічого, крім погляду в камеру. Система сама набирає послідовність кадрів і оцінює ознаки живості: мікрорухи, зміну відображень, об'єм обличчя. Для користувача це звичайне селфі-знімання, для замовника — мінімум кроків у сценарії реєстрації.
Активна перевірка побудована як запит-відповідь: систему просять повернути голову, кліпнути за підказкою, наблизити чи віддалити обличчя.
Дія користувача під час перевірки стає частиною протоколу — запис екрана або підкладений знімок такого завдання не відтворять, бо воно генерується заново для кожної спроби.
Але з'являється залежність від поведінки: людина не зрозуміла підказку, відволіклася, поспішає на етапі оплати — і сценарій не закритий.
Частка хибних відмов у двох режимів різниться за джерелом. Пасивна дає менше відмов на потоці — провалити нічого, немає кроку, який можна виконати неправильно. Зате вона чутливіша до якості кадру: слабка камера, контрове світло, окуляри з бликом з'їдають частину ознак.
Активна стійкіша на слабких каналах, але отримує власну частку відмов від поведінки користувача, а не від якості знімання.
Вибір режиму перевірки — це не «що суворіше», а під який сценарій. Первинна реєстрація, повторний вхід в особистий кабінет і підтвердження операції з високим ризиком вимагають різного балансу між суворістю та конверсією.
Робоча схема — гібрид: пасивна перевірка на вході й активна як ескалація, коли впевненість моделі низька або запит виглядає нетипово.
Обмеження та технічні сумніви щодо перевірки живості
Слабке освітлення та фронтальна камера середнього сегмента дають більше відмов, ніж реальні підробки. Контрове світло й темне приміщення з'їдають деталі текстури, і пасивний сценарій починає відхиляти живих людей.
Пороги не бувають константою: при зміні потоку користувачів або моделей камер рішення потребує повторного калібрування. Окремо рахуємо частки хибних відхилень і пропусків — їхній баланс залежить від того, який клас помилок дорожчий у вашому процесі.
Що робити, якщо у клієнта слабке світло або стара камера?
Сценарій перебудовуємо під умови: просимо короткий рух, додаємо підсвічування та запасний маршрут знімків. Якщо якість кадру нижча за робочий діапазон, система повідомляє про неможливість перевірки, а не видає випадковий вердикт.
Чи зберігаєте ви зображення користувачів?
За замовчуванням ні: кадри живуть у пам'яті лише на час перевірки, далі залишається числовий дескриптор. Якщо за регламентом знімки потрібні для розбору спірних випадків, вмикаємо окреме сховище з обмеженим строком, шифруванням і розмежуванням доступу.
Як часто доведеться заново налаштовувати пороги?
Після запуску — один-два рази, далі за сигналом моніторингу: зростання відмов, масова зміна моделей камер, нове джерело трафіку. Калібрування йде за розміченою вибіркою з вашого боку, щоб пороги відображали реальну аудиторію, а не тестовий набір.
Обговоримо задачу: з чого починається проєкт
Проєкт із детекції живої особи починається не з вибору моделі, а з розбору сценарію верифікації клієнта.
Потрібно зрозуміти, де саме людина проходить перевірку — у мобільному застосунку, у веб-кабінеті чи на планшеті в оператора, — і які підробки для цього каналу реальні: фото з екрана, відеозапис, маска, підміна відеопотоку камери.
Від цього залежать і набір перевірок у ланцюжку, і пороги спрацювання, і те, як система поводиться при слабкому освітленні чи повільному каналі зв'язку.
