Consent to the processing of biometric personal data (EU/US/IL)

Operator (recipient of the consent): ⟦РЕШЕНИЕ: IL-юрлицо / название / реквизиты — владелец продукта⟧ Governing law: GDPR Art. 9(2)(a) (EU — explicit consent, special category) · US: BIPA-style state laws (e.g. Illinois BIPA 740 ILCS 14, Texas CUBI, Washington MHMDA — written informed consent, a public retention policy, a ban on selling biometrics) · IL Privacy Protection Law (consent plus requirements for databases and security). ⟦РЕШЕНИЕ: финальный перечень US-штатов приоритета и режим соответствия (Illinois — строже всех, private right of action) — юрист⟧

Core principle

An image of a person's face is biometric personal data (a special category under GDPR Art. 9; a "biometric identifier / information" under BIPA-style laws). Such data may be processed only on the basis of explicit, informed and revocable consent given before processing begins. Without consent the service is not provided. Consent is a separate act, not a clause inside general Terms (an "I accept everything" checkbox is insufficient under both GDPR and BIPA).

1. What we collect

• The image of the face from the photographs uploaded by the User (Source materials).
• Derived biometric data — the Likeness model (soul_id): a model built from facial features, trained by an external provider (see §4), which is required in order to generate the Result.
• The Service does not create a digital twin of the User and does not receive images of such a twin from the provider: the Service holds only the User's Source materials and the identifier of the Model.

2. Why (purposes of processing)

2.1. Training the User's Likeness model (soul_id) by an external provider — solely in order to provide the service to that User.

2.2. Generating artistic editorial / fashion images (the Result) on the User's order.

2.3. Revisions of the Result on the criterion of likeness to the User's Source materials (§0g).

2.4. Styling the look ("redressing"). The Result is prepared in two AI passes: (1) generating frames carrying the User's face from the Likeness model; (2) "redressing" — the generated frames (which carry the User's face) are passed, together with an image of the garment, to an AI provider in order to compose the final look. The second pass processes the same biometric data (the face in the generated frames) and is part of providing the service to that User. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: раскрытие двухпроходности (генерация + «переодевание») как отдельной операции обработки лица под GDPR ст. 13 / BIPA-transparency; достаточно ли покрытия целями 2.2⟧

Processing is strictly limited to these purposes. Any other purpose (for example publication, or training the provider's or the Service's GENERAL models) requires separate consent; by default we do not do this (see §3). Selling or transferring biometrics for consideration is prohibited and does not happen (a hard requirement of BIPA).

2a. The scale of processing — exactly how much

This is disclosed directly, because "two AI passes" (§2.4) does not tell the User how many times their face will be processed, and under GDPR Art. 13 / BIPA transparency it is the scale that matters, not only the fact.

In total, the User's face is processed in 60 generated images, of which they receive ten; 50 are not delivered and are deleted on the periods in §7 on the same footing as the delivered ones — they are not "drafts outside the policy", they are the same biometric derivatives. A human operator sees all 60 — selection is impossible without viewing them; the circle of people with access is limited by §5. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: достаточно ли раскрытия объёма таблицей, или требуется явная формулировка «сколько раз лицо передаётся суб-обработчику» в тексте самого акцепта⟧

3. Training models on the User's data

3.1. A personal Likeness model (soul_id) — YES, this is the essence of the service (§0g). The image of the User's face is transferred to an external provider, which trains a personal Likeness model on it for that specific User. The model is used only to generate the Result for that same User's orders. This is disclosed here and is the subject of this consent.

3.2. Training GENERAL (foundation) models — NO. Source materials and the Likeness model are not used to further train the Service's or the provider's general AI models, do not enrich anyone else's models, and are not transferred to third parties. The provider is obliged to process the data only on our instructions. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: (а) формулировка «персональная модель ≠ обучение общих моделей» под GDPR ст. 9 / BIPA; (б) запрет вторичного использования и передачи третьим лицам подлежит закреплению в DPA с провайдером и НЕ декларируется как факт до его подписания (задача DPA — backlog)⟧

A revision relative to the earlier draft: this section previously said "training on faces — NO by default". Under §0g (product owner's decision of 2026-07-10), training a personal Likeness model on the User's face *is* the mechanism of the service; the prohibition concerns GENERAL models and secondary use.

4. Who processes the data (transfers to third parties)

4.0. The external provider that trains the Likeness model (Higgsfield) is a sub-processor of BIOMETRICS: it is the party to which the facial image is transferred in order to train the Likeness model (soul_id) and to generate images. The provider processes the data on our instructions, and is obliged not to use it for its own purposes, not to pass it to third parties, and to delete it on our request with confirmation. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: гарантии закрепляются в DPA и не декларируются как факт до его подписания⟧

4.1. Generation is carried out with the involvement of third-party AI providers (e.g. NanoBanana Pro/2, GPT Image, Seedream and others — see Phase 0, User Journey step 5) and cloud storage infrastructure (S3-compatible Cloudflare R2 storage, with the bucket in an EU jurisdiction; delivery is only through signed links, and no public CDN is used for personal photos). 4.1a. "Redressing" (the second pass, §2.4) is performed by the provider NanoBanana via Higgsfield: the generated frames carrying the User's face are transferred to it a second time (together with an image of the garment) in order to compose the final look. This introduces no new recipient entities (Higgsfield and NanoBanana are already listed above as a sub-processor / AI provider), but it adds a second instance of transferring the facial image to those same providers. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: раскрыть второй проход передачи лица; отразить в DPA/SCC наравне с первым⟧

4.2. ⟦РЕШЕНИЕ: перечень процессоров/суб-обработчиков и их юрисдикции; условия передачи им биометрии (ИИ-провайдеры — преимущественно US) — DPA/SCC, критично для трансграничной передачи — юрист⟧

⚠️ The transfer of a facial image to external AI providers is a material fact that must be disclosed in the consent. The User agrees to such a transfer knowingly.

5. How long we keep it

Personal data — the Likeness model (soul_id at the external provider), the Source photographs (with us, including the reduced copy used for analysis) and the profile (height, clothing size, build, gender) ⟦исправлено 2026-10-08, сверка канона B-TXT-01; юрист смотрит после⟧ are kept for 30 days after the User's last action with them (uploading photos, editing the profile, paying for a shoot, a message in the order chat; on the Service's side — delivering an order or a request to the User). While the User has an order on which the next step is the Service's (paid, in production, in review, a revision), the period does not run. On expiry — deletion at the provider with confirmation of deletion (a log entry plus the request forwarded to the provider) and deletion at our end; the account and the list of orders are retained. Order data — the finished Results and the order correspondence are kept for 30 days after the last action on the order (delivery; the Service's request for photos; cancellation; for an unpaid draft — the last message). While the order is paid and in production, in review or in revision (including an open revision request), the period does not run. Then deletion from storage with CDN cache invalidation and a log of the deletion; the order itself and the payment are retained. Reminders — 7 days and 3 days before, and on the day of deletion (bot / email, and in the account). The User can extend storage by 30 days by an explicit action (a click = opt-in; the period is added to the deletion date; there is no limit on the number of extensions) or delete the data right away. On replacement of the Likeness model with a new one, the previous model is unlinked and deleted once a recovery window of about 5 days has passed. ⚠️ Changed on 2026-10-06 (owner's decision, S56): previously — four separate periods with different starting points (training · delivery · upload) and a single reminder 3–5 days before. The wording was brought into line with the fact by us and IS AWAITING THE LAWYER'S REVIEW.

5.4. Details — the Data Retention and Deletion Policy. A published retention schedule is a BIPA requirement (a published retention / destruction policy).

5.5. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: два срока от последнего действия и пауза срока на время работы над заказом; доказательство удаления у суб-обработчика⟧

6. Cross-border transfers

6.1. The operator is an IL legal entity; Israel holds an EU adequacy decision — transfers EU → IL are permitted without additional mechanisms ⟦подтвердить актуальность решения — юрист⟧.

6.2. Transfers to AI providers and services in the US are made on the basis of ⟦РЕШЕНИЕ: EU-US Data Privacy Framework (если провайдер сертифицирован) / SCC — по каждому суб-обработчику — юрист⟧.

7. The User's rights

7.1. Withdraw consent at any time — processing stops and the biometrics (photos + the Likeness model soul_id) are deleted early through the same cascade: storage + the deletion request forwarded to the provider + a log entry. If the withdrawal takes the form of account deletion, erasure starts immediately after confirmation, with no cancellation window , and is irreversible (see the Privacy Policy §6a). Lawful exceptions (which the deletion takes into account): de-identified payment records are retained on tax grounds, and a PII-free snapshot of the fact of consent is retained in the deletion record as evidence that the processing of biometrics was lawful (BIPA/GDPR accountability) — see the Privacy Policy §6b–§6c.

7.2. Obtain access to your data, request deletion or correction (GDPR Arts. 15–17; IL PPL).

7.3. The way to withdraw depends on the identity channel: ◧ bot — a command in the bot (identity = the Telegram account); ◨ website — a button in the personal account (sign-in via Google OAuth). ⟦РЕШЕНИЕ: финальные формулировки/UX отзыва — владелец продукта⟧

Withdrawing consent makes it impossible to continue providing the service.

8. The User's warranties

8.1. The User is 18+ and gives consent in respect of their own image.

8.2. The User does not upload other people's faces without the consent of the person depicted and does not upload images of minors.

9. The form in which consent is obtained (implementation)

9.1. Consent is recorded by an explicit affirmative action (not a pre-ticked box) before photos are uploaded: a separate screen / step in the Telegram bot and on the website, with the full text and a confirmation. For the US (BIPA-style laws) the form must satisfy the "written release" requirement ⟦эквивалентность электронного подтверждения письменной форме — юрист⟧.

9.2. The fact of consent is logged: the version of the text, the date and time, the identity identifier for the channel (◧ tg_user_id — the Telegram account; ◨ the verified email from Google OAuth), and the method of confirmation. ⟦РЕШЕНИЕ: финальный состав полей — согласовать с privacy-policy и схемой consents (S1) — владелец продукта + юрист⟧

_The database schema (S1) already contains a consents table — the consent-capture endpoint is implemented in S3–S4 (bot flow W1/W2). What is fixed here are the requirements for the content of the consent._

Open decisions (summary)

• The operator (IL legal entity, registration details); the list of priority US states and the BIPA compliance regime.
• Training AI models on user data (NO by default; otherwise — separate consent + a governance signal).
• The list of sub-processors (AI providers) and transfer mechanisms (DPF/SCC); whether the EU→IL adequacy decision is still current.
• The starting point for the 30-day count; the final UX for withdrawing consent; the set of logged fields.
• "Redressing" (REDRESS, Spec 004, §2.4/§4.1a): whether disclosing the two passes here is enough or a separate consent clause is needed; reflecting the second face-transfer pass (NanoBanana via Higgsfield) in the DPA/SCC.