Deploying an AI virtual try-on system that processes shoppers' uploaded photographs is almost certainly a high-risk processing activity under GDPR Article 35. That means a Data Protection Impact Assessment is not optional — it is a legal prerequisite before you go live. This guide takes you through every mandatory element of that assessment, with risk-scoring criteria and mitigation measures calibrated to the specific characteristics of body-image AI.
Key takeaways
- Processing user-uploaded body photographs for virtual try-on constitutes systematic large-scale processing of data that can reveal sensitive attributes, triggering mandatory DPIA under GDPR Article 35(3)(b).
- The EU AI Act classifies virtual try-on systems as limited-risk AI, requiring transparency obligations on top of your GDPR obligations — both frameworks must be addressed in the same assessment cycle.
- Effective risk mitigation centres on three controls: purpose limitation enforced at the inference layer, on-device or ephemeral server-side processing, and granular, freely withdrawable consent.
- A DPIA is a living document; it must be reviewed whenever the model, the data flows, or the vendor change.
- Involving your DPO from scoping — not just at sign-off — materially reduces the chance of late-stage redesign.
What you need before you start
- A completed Record of Processing Activities (RoPA) entry for the virtual try-on feature, or at minimum a draft data-flow diagram showing every system that touches the user photograph.
- The data processing agreement (DPA) and sub-processor list from your virtual try-on vendor.
- The vendor's published documentation on model architecture, data retention, and inference infrastructure (on-device versus server-side).
- Your organisation's existing DPIA template (Article 29 Working Party / EDPB guidelines prescribe the minimum structure; use that as your base).
- Access to your supervisory authority's list of processing operations that require a mandatory DPIA — most EU DPAs have published one.
- Legal counsel familiar with both GDPR and the EU AI Act if the deployment spans multiple member states.
Step 1 — Determine whether a DPIA is mandatory
Before investing in a full assessment, confirm that the threshold is met. Virtual try-on systems typically satisfy at least two of the EDPB's nine criteria that indicate high risk: systematic processing of biometric or body-image data, and large-scale processing of data concerning physical characteristics. If your system also uses the output to profile users (for example, to infer size, age range, or body type for recommendation), a third criterion — profiling with significant effects — may apply as well.
Check your supervisory authority's mandatory-DPIA list. Several EU DPAs have explicitly listed processing of photographs for AI-based body analysis. If your processing appears on that list, the DPIA is mandatory regardless of scale. Document your threshold determination and retain it as part of the DPIA file.
Note: The EU AI Act adds a parallel obligation. As Taylor Wessing's analysis of fashion and the AI Act sets out, virtual try-on systems fall into the limited-risk category, which requires providers to ensure users are informed they are interacting with an AI system. That transparency obligation must be reflected in your DPIA's description of the processing and in your consent or notice layer.
Expected result: A one-page threshold memo, signed by the DPO, confirming that a DPIA is required and identifying the applicable supervisory authority.
Step 2 — Define the scope and describe the processing
Article 35(7)(a) requires a systematic description of the processing. For virtual try-on, this section must cover:
- What data is collected: The user's uploaded photograph (or camera feed), device identifiers, session tokens, and any derived outputs (for example, a generated composite image, a size estimate, or a body-measurement vector).
- Who provides it: The end user, acting on an explicit, affirmative action (upload or camera grant).
- How it is processed: Whether inference runs on-device, in a vendor-operated cloud, or in a hybrid model. Identify every sub-processor and the jurisdiction of each server.
- How long it is retained: Distinguish between the raw photograph, intermediate embeddings, and the output image. Each may have a different retention period and a different legal basis.
- Who receives it: The vendor's inference infrastructure, your own recommendation engine if the output feeds into it, and any analytics pipeline.
For deployments using a vendor such as Aiuta — which offers a hybrid virtual try-on platform covering both user-uploaded images and AI-generated virtual models — you must map whether the user photograph is transmitted to the vendor's servers, processed ephemerally, or handled entirely on the client device. That distinction is material to your risk score in Step 4.
Expected result: A data-flow diagram and a narrative description of the processing, covering all six elements above, attached to the DPIA file.
Step 3 — Assess necessity and proportionality
Article 35(7)(b) requires you to assess the necessity and proportionality of the processing in relation to the purposes. Ask three questions:
- Is processing the photograph strictly necessary to deliver the feature? Yes, for a photorealistic try-on. But derived data — body-measurement vectors, inferred size, age-range estimates — may not all be necessary. Apply data minimisation: if the inference model produces a body-measurement embedding as an intermediate step, confirm it is not persisted unless there is a separate, documented purpose.
- Is the legal basis appropriate? For a consumer-facing feature, consent under Article 6(1)(a) is the most defensible basis. If the photograph could reveal health-related information (visible disability, pregnancy), Article 9(2)(a) explicit consent is required for that special-category dimension. Document the legal basis for each data element separately.
- Are retention periods proportionate? A photograph needed only for a single session should not be retained beyond that session. If you retain it to improve the model, that is a new purpose requiring a separate legal basis and a separate DPIA entry.
Expected result: A necessity-and-proportionality table, one row per data element, recording the purpose, legal basis, retention period, and whether minimisation has been applied.
Step 4 — Identify and score the risks
This is the analytical core of the DPIA. For each risk, score likelihood (1–3) and severity (1–3); risks scoring 6 or above require mandatory mitigation before go-live.
| Risk | Likelihood | Severity | Score |
|---|---|---|---|
| Unauthorised access to raw photographs (data breach) | 2 | 3 | 6 |
| Vendor retains photographs beyond agreed period | 2 | 3 | 6 |
| Model infers sensitive attributes (health, pregnancy) not disclosed to user | 2 | 3 | 6 |
| Photograph used to train vendor's general model without consent | 2 | 3 | 6 |
| User cannot effectively withdraw consent or delete data | 2 | 2 | 4 |
| Cross-border transfer to non-adequate third country | 1 | 3 | 3 |
| Re-identification of anonymised body embeddings | 1 | 3 | 3 |
Adjust these scores to your specific deployment. A server-side inference model with indefinite photograph retention will score higher on the first two rows than an on-device model with ephemeral processing.
Warning: Body photographs are not formally classified as biometric data under GDPR Article 9 unless they are processed specifically to uniquely identify a natural person. However, if your model generates a body-measurement vector that could be used for re-identification, that vector may constitute biometric data. Obtain a legal opinion on this point before finalising your risk scores.
Expected result: A completed risk register, with each risk scored and flagged as requiring mitigation or accepted as residual.
Step 5 — Define and implement mitigation measures
For each risk scoring 4 or above, document a specific technical or organisational measure:
- Unauthorised access / data breach: Encrypt photographs at rest and in transit (AES-256 / TLS 1.3 minimum). Implement access controls so that only the inference service account can read raw photographs. Require the vendor to demonstrate SOC 2 Type II or ISO 27001 certification.
- Vendor retention beyond agreed period: Include a contractual deletion obligation with a specific timeframe (for example, 24 hours post-inference for raw photographs). Require the vendor to provide deletion logs on request. Audit annually.
- Inference of sensitive attributes: Contractually prohibit the vendor from running secondary inference tasks (age estimation, health inference) on user photographs. Request model cards or technical documentation confirming the model's output space.
- Training on user photographs without consent: Ensure the DPA explicitly prohibits use of customer data for vendor model training unless the user has given separate, granular consent. Verify this is enforced at the infrastructure level, not just contractually.
- Ineffective withdrawal / deletion: Build a self-service deletion flow accessible from the user's account. Test it end-to-end before launch. Confirm deletion propagates to all sub-processors within 30 days.
Expected result: A mitigation register, one row per risk, recording the measure, the responsible team, the implementation deadline, and the evidence of completion.
Step 6 — Consult stakeholders and, if necessary, the supervisory authority
GDPR Article 35(9) requires you to seek the views of data subjects or their representatives where appropriate. For a consumer product, this typically means user research or usability testing that specifically probes privacy expectations around photograph upload — not a formal consultation, but documented evidence that you considered user perspectives.
If, after applying all mitigation measures, one or more risks remain at a score of 6 or above, Article 36 requires prior consultation with your supervisory authority before processing begins. Prepare a consultation package: the completed DPIA, the residual risk register, the technical architecture diagram, and a plain-language summary of the processing. Supervisory authorities typically respond within eight weeks; build this into your launch timeline.
Expected result: A stakeholder-consultation note and, if required, a prior-consultation submission to the supervisory authority.
Step 7 — Record, approve, and schedule review
The completed DPIA must be signed off by the DPO and, where applicable, by the controller's senior management. Retain the full document — including all working papers, vendor documentation, and the risk register — for the duration of the processing activity and for three years after it ends.
Schedule a review trigger for each of the following events:
- The virtual try-on model is retrained or replaced.
- The vendor changes its infrastructure or sub-processors.
- A data breach occurs involving user photographs.
- A supervisory authority publishes new guidance on body-image AI processing.
- The EU AI Act's delegated acts or implementing regulations introduce new obligations for limited-risk AI systems.
Expected result: A signed DPIA document stored in your records-management system, with a review schedule and named owners for each trigger.
Troubleshooting common issues
The vendor will not share model documentation. This is a red flag. Your DPA should require the vendor to provide sufficient information to complete a DPIA. If they refuse, escalate to legal counsel and consider whether the deployment can proceed. A controller cannot outsource its GDPR obligations.
You are unsure whether the photograph constitutes biometric data. Do not resolve this in the DPIA itself. Obtain a written legal opinion, attach it to the DPIA file, and apply the more conservative interpretation (Article 9 treatment) until the opinion is received.
The vendor is based outside the EU and has no EU representative. Map the transfer carefully. If the vendor's servers are in a non-adequate third country, you need a transfer mechanism (Standard Contractual Clauses, Binding Corporate Rules, or an adequacy decision) and a transfer impact assessment. The transfer impact assessment can be appended to the DPIA.
Your consent flow is challenged by the UX team as too disruptive. Consent for body-photograph processing must be freely given, specific, informed, and unambiguous. A pre-ticked box or a bundled consent buried in terms of service does not meet that standard. Work with the UX team to design a clear, single-purpose consent screen; the short-term friction is preferable to enforcement action.
The DPA with the vendor predates the virtual try-on feature. Update it. A DPA that does not describe the specific processing activity — including the nature of the data, the purposes, and the deletion obligations — does not satisfy Article 28.
What success looks like
A completed DPIA for a virtual try-on deployment should produce:
- A signed threshold determination confirming the DPIA obligation.
- A data-flow diagram and processing description covering all data elements and sub-processors.
- A necessity-and-proportionality table with documented legal bases.
- A risk register with scores and mitigation measures, all risks reduced below 6 or escalated to the supervisory authority.
- An updated DPA with the vendor, including deletion obligations and a prohibition on secondary inference.
- A self-service deletion flow, tested and documented.
- A review schedule with named owners.
If you reach sign-off with all of those outputs in place, you have met the minimum GDPR standard and created the documentation foundation for any future regulatory inquiry.
FAQ
Is a DPIA always required for virtual try-on, or only above a certain user volume? The DPIA obligation is triggered by the nature of the processing — systematic processing of body-image data — not by volume alone. Even a small-scale deployment that processes photographs to infer physical characteristics is likely to meet the threshold. Check your supervisory authority's mandatory-DPIA list.
Can we rely on legitimate interests instead of consent as the legal basis? Legitimate interests can theoretically apply, but processing body photographs for a non-essential feature will rarely pass the balancing test when weighed against users' reasonable privacy expectations. Consent is the more defensible basis and is strongly recommended by most EU DPAs for this type of processing.
Does the EU AI Act change anything in the DPIA process? The AI Act adds transparency obligations — users must be told they are interacting with an AI system — but it does not replace the DPIA. You need to satisfy both frameworks. Document the AI Act compliance measures (transparency notice, conformity assessment if applicable) within the DPIA so the two are aligned.
How long does a DPIA take to complete? A well-resourced team with vendor cooperation can complete a DPIA in four to six weeks. Prior consultation with a supervisory authority, if required, adds up to eight weeks. Plan accordingly before committing to a launch date.
What happens if we go live without completing the DPIA? Processing without a mandatory DPIA is a standalone GDPR infringement, separate from any underlying data protection failure. Supervisory authorities can issue corrective orders and administrative fines. Complete the DPIA before any user photographs are processed in production.