Согласие на обработку биометрических персональных данных (EU/US/IL)
Оператор (получатель согласия): ⟦РЕШЕНИЕ: IL-юрлицо / название / реквизиты — владелец продукта⟧ Применимое право: GDPR ст. 9(2)(a) (EU — explicit consent, особая категория) · US: BIPA-подобные законы штатов (напр. Illinois BIPA 740 ILCS 14, Texas CUBI, Washington MHMDA — письменное информированное согласие, публичная retention-политика, запрет продажи биометрии) · IL Privacy Protection Law (согласие + требования к базам данных/безопасности). ⟦РЕШЕНИЕ: финальный перечень US-штатов приоритета и режим соответствия (Illinois — строже всех, private right of action) — юрист⟧
Ключевой принцип
Изображение лица человека — биометрические персональные данные (особая/специальная категория по GDPR ст. 9; «biometric identifier/information» по BIPA-подобным законам). Их обработка допускается только на основании явного, информированного и отзывного согласия, данного до начала обработки. Без согласия услуга не оказывается. Согласие — отдельный акт, а не пункт в общем ToS (галочка «принимаю всё» недостаточна ни по GDPR, ни по BIPA).
1. Что мы собираем
- Изображение лица из загруженных Пользователем фотографий (Исходные материалы).
- Производные биометрические данные — Модель личности (soul_id): модель на основе черт лица, которую обучает внешний провайдер (см. §4), необходимая для генерации Результата.
- Сервис не создаёт цифрового двойника Пользователя и не получает от провайдера изображений такого двойника: у Сервиса остаются только Исходные материалы Пользователя и идентификатор Модели.
2. Зачем (цели обработки)
2.1. Обучение Модели личности (soul_id) Пользователя внешним провайдером — исключительно для оказания услуги данному Пользователю.
2.2. Генерация художественных editorial/fashion-изображений (Результата) по заказу Пользователя.
2.3. Правки Результата по критерию сходства с Исходными материалами Пользователя (§0g).
2.4. Оформление образа («переодевание»). Результат готовится в два ИИ-прохода: (1) генерация кадров с лицом Пользователя по Модели личности; (2) «переодевание» — сгенерированные кадры (несут лицо Пользователя) вместе с изображением предмета одежды передаются ИИ-провайдеру для оформления итогового образа. Второй проход обрабатывает те же биометрические данные (лицо в сгенерированных кадрах) и является частью оказания услуги данному Пользователю. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: раскрытие двухпроходности (генерация + «переодевание») как отдельной операции обработки лица под GDPR ст. 13 / BIPA-transparency; достаточно ли покрытия целями 2.2⟧
Обработка строго в этих целях. Для иных целей (напр. публикация, обучение ОБЩИХ моделей провайдера или Сервиса) — требуется отдельное согласие; по умолчанию мы этого не делаем (см. §3). Продажа/передача биометрии за вознаграждение запрещена и не производится (жёсткое требование BIPA).
2а. Объём обработки — сколько именно
Раскрывается прямо, потому что «два ИИ-прохода» (§2.4) не говорят Пользователю сколько раз его лицо будет обработано, а под GDPR ст. 13 / BIPA-transparency значим именно объём, а не только факт.
| Этап | Что происходит с лицом Пользователя | Сколько |
|---|---|---|
| Приём | Пользователь загружает фотографии со своим лицом | 10–30 снимков |
| Обучение Модели личности | пак снимков уходит внешнему провайдеру (§4) | один раз на Пользователя |
| Проход 1 — генерация | провайдер создаёт кадры, несущие лицо Пользователя | 45 изображений (15 сюжетов × 3 дубля) |
| Отбор оператором | человек отбирает лучший дубль каждого сюжета | 45 → 15 |
| Проход 2 — «переодевание» | 15 отобранных кадров с лицом уходят ИИ-провайдеру повторно (§2.4) | 15 изображений |
| Финальная приёмка | человек отбирает итоговую серию | 15 → 10 |
| Выдача | Пользователь получает | 10 изображений |
Итого лицо Пользователя обрабатывается в 60 сгенерированных изображениях, из которых он получает десять; 50 не выдаются и удаляются по срокам §7 наравне с выданными — они не «черновики вне политики», а те же биометрические производные. Оператор-человек видит все 60 — отбор невозможен без просмотра; круг лиц ограничен §5. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: достаточно ли раскрытия объёма таблицей, или требуется явная формулировка «сколько раз лицо передаётся суб-обработчику» в тексте самого акцепта⟧
3. Обучение моделей на данных пользователя
3.1. Персональная Модель личности (soul_id) — ДА, это суть услуги (§0g). Изображение лица Пользователя передаётся внешнему провайдеру, который обучает на нём персональную Модель личности именно этого Пользователя. Модель используется только для генерации Результата по заказам этого же Пользователя. Это раскрывается здесь и является предметом настоящего согласия.
3.2. Обучение ОБЩИХ (foundation) моделей — НЕТ. Исходные материалы и Модель личности не используются для дообучения общих ИИ-моделей Сервиса или провайдера, не обогащают чужие модели и не передаются третьим лицам. Провайдер обязан обрабатывать данные только по нашему поручению. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: (а) формулировка «персональная модель ≠ обучение общих моделей» под GDPR ст. 9 / BIPA; (б) запрет вторичного использования и передачи третьим лицам подлежит закреплению в DPA с провайдером и НЕ декларируется как факт до его подписания (задача DPA — backlog)⟧
Пересмотр относительно прежнего черновика: раньше здесь стояло «обучение на лицах — по умолчанию НЕТ». По §0g (реш. владельца продукта 2026-07-10) обучение персональной Модели личности на лице Пользователя — и есть механизм услуги; запрет касается ОБЩИХ моделей и вторичного использования.
4. Кто обрабатывает (передача третьим лицам)
4.0. Внешний провайдер обучения Модели личности (Higgsfield) — суб-обработчик БИОМЕТРИИ: именно ему передаётся изображение лица для обучения Модели личности (soul_id) и генерации. Провайдер обрабатывает данные по нашему поручению, обязан не использовать их для собственных целей, не передавать третьим лицам и удалять по нашему запросу с подтверждением. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: гарантии закрепляются в DPA и не декларируются как факт до его подписания⟧
4.1. Генерация выполняется с привлечением сторонних ИИ-провайдеров (напр. NanoBanana Pro/2, GPT Image, Seedream и др. — см. Phase 0, User Journey шаг 5) и облачной инфраструктуры хранения (S3-совместимое хранилище Cloudflare R2, бакет в EU-юрисдикции; выдача — только по подписанным ссылкам, публичный CDN для персональных фото не используется). 4.1a. «Переодевание» (второй проход, §2.4) выполняется провайдером NanoBanana через Higgsfield: сгенерированные кадры, несущие лицо Пользователя, передаются ему повторно (вместе с изображением предмета одежды) для оформления итогового образа. Новых сущностей-получателей это не вводит (Higgsfield и NanoBanana уже перечислены как суб-обработчик/ИИ-провайдер выше), но добавляет второй факт передачи изображения лица тем же провайдерам. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: раскрыть второй проход передачи лица; отразить в DPA/SCC наравне с первым⟧
4.2. ⟦РЕШЕНИЕ: перечень процессоров/суб-обработчиков и их юрисдикции; условия передачи им биометрии (ИИ-провайдеры — преимущественно US) — DPA/SCC, критично для трансграничной передачи — юрист⟧
⚠️ Передача изображения лица внешним ИИ-провайдерам — существенный факт, который должен быть раскрыт в согласии. Пользователь соглашается на такую передачу осознанно.
5. Сколько храним
Личные данные — Модель личности (soul_id у внешнего провайдера), Исходные фотографии (у нас, включая уменьшенную копию для разбора) и анкета (рост, размер одежды, тип фигуры, пол) ⟦исправлено 2026-10-08, сверка канона B-TXT-01; юрист смотрит после⟧ хранятся 30 дней после последнего действия Пользователя с ними (загрузка фото, правка анкеты, оплата съёмки, сообщение в переписке; со стороны Сервиса — выдача заказа или просьба Пользователю). Пока у Пользователя есть заказ, по которому следующий шаг за Сервисом (оплачен, в работе, на проверке, правка), срок не идёт. По истечении — удаление у провайдера с подтверждением удаления (лог + проброс запроса провайдеру) и удаление у нас; учётная запись и список заказов сохраняются. Данные заказа — готовые Результаты и переписка по заказу хранятся 30 дней после последнего действия по заказу (выдача; просьба Сервиса прислать фото; отмена; для неоплаченного черновика — последнее сообщение). Пока заказ оплачен и в работе, на проверке или в правке (в т.ч. по открытой просьбе о правке), срок не идёт. Затем удаление из хранилища с инвалидацией CDN-кэша и логом факта удаления; сам заказ и оплата сохраняются. Напоминания — за 7 дней, за 3 дня и в день удаления (бот / email, а также в личном кабинете). Пользователь может продлить хранение на 30 дней явным действием (клик = опт-ин, срок прибавляется к дате удаления, число продлений не ограничено) или удалить данные сразу. При замене Модели личности новой — прежняя отвязывается и удаляется по истечении окна восстановления ~5 дней. ⚠️ Изменено 2026-10-06 (решение владельца, S56): прежде — четыре отдельных срока с разными точками отсчёта (обучение · выдача · загрузка) и одно напоминание за 3–5 дней. Формулировка приведена к факту нами и ЖДЁТ ПРОВЕРКИ ЮРИСТОМ.
5.4. Детали — Политика хранения и удаления. Публичность retention-графика — требование BIPA (публикуемая политика хранения/уничтожения).
5.5. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: два срока от последнего действия и пауза срока на время работы над заказом; доказательство удаления у суб-обработчика⟧
6. Трансграничная передача
6.1. Оператор — IL-юрлицо; Израиль имеет решение об адекватности ЕС (adequacy decision) — передача EU → IL допустима без доп. механизмов ⟦подтвердить актуальность решения — юрист⟧.
6.2. Передача к ИИ-провайдерам и сервисам в US — на основании ⟦РЕШЕНИЕ: EU-US Data Privacy Framework (если провайдер сертифицирован) / SCC — по каждому суб-обработчику — юрист⟧.
7. Права Пользователя
7.1. Отозвать согласие в любой момент — обработка прекращается, биометрия (фото + Модель личности soul_id) удаляется досрочно тем же каскадом: хранилище + проброс удаления провайдеру + лог. Если отзыв оформлен как удаление аккаунта, стирание начинается сразу после подтверждения, без окна отмены , и необратимо (см. Политику конфиденциальности §6a). Законные исключения (с учётом которых происходит удаление): обезличенные платёжные записи сохраняются по налоговому основанию, а PII-free снимок факта согласия сохраняется в записи об удалении как доказательство правомерности обработки биометрии (BIPA/GDPR accountability) — см. Политику конфиденциальности §6b–§6c.
7.2. Получить доступ к своим данным, потребовать удаления/исправления (GDPR ст. 15–17; IL PPL).
7.3. Способ отзыва — по каналу личности: ◧ бот — команда в боте (личность = Telegram-аккаунт); ◨ сайт — кнопка в ЛК (вход Google OAuth). ⟦РЕШЕНИЕ: финальные формулировки/UX отзыва — владелец продукта⟧
Отзыв согласия делает невозможным дальнейшее оказание услуги.
8. Гарантии Пользователя
8.1. Пользователю 18+; он даёт согласие в отношении собственного изображения.
8.2. Пользователь не загружает чужие лица без согласия изображённого и не загружает изображения несовершеннолетних.
9. Форма получения согласия (реализация)
9.1. Согласие фиксируется явным активным действием (не преднастроенная галочка) до загрузки фото: отдельный экран/шаг в Telegram-боте и на сайте с полным текстом и подтверждением. Для US (BIPA-подобные) — форма должна соответствовать «written release» ⟦эквивалентность электронного подтверждения письменной форме — юрист⟧.
9.2. Факт согласия логируется: версия текста, дата/время, идентификатор личности по каналу (◧ tg_user_id — Telegram-аккаунт; ◨ verified email из Google OAuth), способ подтверждения. ⟦РЕШЕНИЕ: финальный состав полей — согласовать с privacy-policy и схемой consents (S1) — владелец продукта + юрист⟧
_В схеме БД (S1) уже есть таблица consents — consent-capture endpoint реализуется в S3–S4 (бот-флоу W1/W2). Здесь фиксируем требования к содержанию согласия._Открытые решения (сводка)
- Оператор (IL-юрлицо, реквизиты); перечень приоритетных US-штатов и режим BIPA-соответствия.
- Обучение ИИ-моделей на данных пользователя (по умолчанию НЕТ; иначе — отдельное согласие + governance-сигнал).
- Список суб-обработчиков (ИИ-провайдеры) и механизмы передачи (DPF/SCC); актуальность EU→IL adequacy.
- Точка старта отсчёта 30 дней; финальный UX отзыва согласия; состав логируемых полей.
- «Переодевание» (REDRESS, Spec 004, §2.4/§4.1a): достаточно ли раскрытия двухпроходности здесь, или нужен отдельный consent-пункт; отражение второго прохода передачи лица (NanoBanana через Higgsfield) в DPA/SCC.