A demand forecasting model in fashion retail processes personal data — purchase histories, browsing behaviour, loyalty programme records — to predict what customers will buy and when. That combination of profiling, automated processing, and large-scale consumer data means a Data Protection Impact Assessment (DPIA) is not optional: it is a legal requirement under GDPR Article 35 before the system goes live. This guide walks you through each step, from initial scoping to the decision on whether to consult your supervisory authority.
Key takeaways
- Demand forecasting models that profile consumer behaviour at scale meet at least two of the Article 29 Working Party's high-risk criteria, making a DPIA mandatory before deployment.
- The DPIA must document the necessity and proportionality of every processing operation, not just the security controls around it.
- Residual risks that cannot be reduced to an acceptable level require prior consultation with the competent supervisory authority before processing begins.
- The EU AI Act adds a parallel conformity layer for AI systems; your DPIA and your AI Act documentation should be designed to share evidence rather than duplicate effort.
- Operational tools that embed demand forecasting — such as Style Arcade's buying and planning workspace — should be assessed as processors, with their data processing agreements reviewed as part of Step 2.
What you need before you start
- A named Data Protection Officer (DPO) or external data protection counsel with GDPR Article 37–39 authority.
- A data inventory or record of processing activities (RoPA) entry that covers the forecasting system, even if incomplete at this stage.
- Access to the model's technical architecture documentation: data inputs, training pipeline, inference pipeline, output schema, and any third-party sub-processors.
- The supervisory authority's published DPIA list for your jurisdiction. The CNIL guidance on DPIA methodology and the Irish Data Protection Commission's DPIA obligations page are useful starting references regardless of where your establishment is registered.
- The Article 29 Working Party Guidelines on DPIA (WP248rev.01), endorsed by the EDPB, which remain the authoritative interpretive framework.
- A structured DPIA template — most supervisory authorities publish one; the Italian Garante's list of processing types subject to mandatory DPIA is a useful cross-reference if you operate in Italy.
- Sign-off from senior management that the DPIA process has authority to delay or block deployment.
Step 1 — Determine whether a DPIA is mandatory
Check the processing against the nine criteria identified by the WP29 and adopted by EU supervisory authorities. A demand forecasting system almost always meets at least two:
- Evaluation or scoring / profiling: the model assigns predicted purchase propensity scores to individual customers based on behavioural data.
- Large-scale processing: fashion retailers typically process millions of transaction records.
- Innovative use of technology: machine learning applied to consumer behaviour is still considered novel in the regulatory sense.
If two or more criteria are met, a DPIA is required. Document which criteria apply and why — this record becomes the justification section of your DPIA.
Note: Your supervisory authority may maintain a mandatory list that names specific processing types. Check that list first; if your system appears on it, the threshold analysis above is confirmatory rather than determinative.
Expected result: A written determination, signed by the DPO, confirming that a DPIA is required and identifying the applicable criteria.
Step 2 — Describe the processing systematically
GDPR Article 35(7)(a) requires a systematic description of the envisaged processing operations and their purposes. For a demand forecasting system, this section of the DPIA should cover:
Data flows — map each of the following:
- Input data categories: transaction history (item, SKU, price, date, channel), customer identifiers, loyalty tier, returns data, browsing/click-stream data if used, geographic or store-level aggregates.
- Whether data is pseudonymised before entering the training pipeline, and at what stage.
- Third-party data sources: if you enrich with external trend signals (for example, via a merchandising analytics platform), document the legal basis and the data processing agreement.
- Model outputs: are predictions linked back to individual customer records, or aggregated to SKU/category level? This distinction materially affects the risk profile.
- Retention periods for training data, model weights, and inference logs.
- Sub-processors: cloud infrastructure providers, any unified data and AI platform (for example, Databricks if used for the lakehouse and model training pipeline), and any SaaS merchandising tools.
Purposes and legal bases:
State the purpose precisely — "predict demand at SKU level to optimise purchasing volumes" is more defensible than "improve business operations". Map each data category to a legal basis under Article 6. For most fashion retail demand forecasting, the candidate bases are legitimate interests (Article 6(1)(f)) or contract performance (Article 6(1)(b)); consent is rarely the right basis for operational analytics.
Expected result: A completed processing description table that a supervisory authority could read without needing to ask follow-up questions.
Step 3 — Assess necessity and proportionality
This step is frequently underweighted. The DPIA must demonstrate that each data category processed is necessary for the stated purpose and that the processing is proportionate to the benefit sought.
Work through the following questions for each data category:
- Could the forecasting objective be achieved with aggregated or anonymised data instead of individual-level records?
- Is the retention period limited to what is necessary for model retraining cycles?
- If individual-level outputs are produced, is there a documented business justification for not aggregating them?
- Are data minimisation controls implemented in the pipeline — for example, dropping direct identifiers before features are computed?
Document the answer to each question. Where the answer is "no, individual-level data is necessary", record the reasoning. Necessity and proportionality findings feed directly into the risk assessment in Step 4 and into the mitigation measures in Step 5.
Warning: A model that ingests full transaction histories but only needs category-level purchase frequency for its features has a proportionality problem. Identify and close these gaps before the DPIA is finalised, not after.
Expected result: A necessity and proportionality matrix, one row per data category, with a documented finding for each.
Step 4 — Identify and assess risks to data subjects
For each processing operation described in Step 2, identify the risks to the rights and freedoms of the individuals whose data is processed. In a demand forecasting context, the most material risks typically include:
- Discriminatory inference: if the model learns to associate demographic proxies (postcode, purchase category, price sensitivity) with predicted behaviour, it may produce outputs that disadvantage certain groups — even if protected characteristics were never explicitly processed.
- Function creep: demand forecasting infrastructure built on individual-level data is technically capable of being repurposed for individual customer scoring or targeted pricing. Document controls that prevent this.
- Data breach: training datasets containing years of transaction history are high-value targets. Assess the likelihood and severity of unauthorised access.
- Lack of transparency: customers whose purchase patterns inform model training may have no awareness of this use. Assess whether your privacy notice adequately describes it.
- Inaccuracy and automated decision-making: if model outputs feed automated purchasing or markdown decisions without human review, assess whether Article 22 GDPR applies.
For each risk, assign a likelihood (low / medium / high) and a severity (low / medium / high) before mitigation. Use a standard 3×3 or 5×5 matrix and document your reasoning.
Fashion AI governance is attracting increasing regulatory and journalistic scrutiny — a point noted in industry commentary — which makes a thorough risk register more important than it might have seemed two or three years ago.
Expected result: A risk register with pre-mitigation likelihood and severity scores for each identified risk.
Step 5 — Define mitigation measures
For each risk in your register, specify the technical and organisational measures you will implement, and re-score likelihood and severity after mitigation to produce residual risk scores.
Technical measures to consider:
- Pseudonymisation or tokenisation of customer identifiers before features enter the training pipeline.
- Differential privacy techniques if the model is trained on sensitive behavioural data.
- Role-based access controls on training datasets and model outputs, with audit logging.
- Data retention automation: scheduled deletion of training records beyond the defined retention window.
- Model output aggregation: where individual-level predictions are not operationally required, aggregate to SKU or store level before outputs leave the model serving layer.
- Automated monitoring for distributional shift that could indicate the model is producing biased outputs.
Organisational measures to consider:
- A documented acceptable-use policy for model outputs, specifying which teams may access individual-level predictions and for what purposes.
- A human review requirement for any automated decision that has a material effect on an individual (for example, a personalised markdown offer).
- Processor agreements with all sub-processors that include the Article 28 GDPR mandatory clauses.
- Staff training for anyone with access to the training data or model outputs.
- A defined process for responding to data subject access requests that touch model training data.
Organisations such as Otto Group, which operates AI-commerce capabilities across its retail brands at scale, face exactly this challenge of governing model outputs across multiple business units — the organisational controls are as important as the technical ones.
Expected result: An updated risk register with post-mitigation residual risk scores and a named owner for each measure.
Step 6 — Document the DPIA and obtain internal sign-off
The DPIA document must contain, at minimum:
- The systematic description of processing (Step 2 output).
- The necessity and proportionality assessment (Step 3 output).
- The risk assessment (Step 4 output).
- The mitigation measures and residual risk scores (Step 5 output).
- The DPO's opinion, recorded in writing.
- The controller's decision on whether residual risks are acceptable.
The DPO's opinion is not a veto, but it must be sought and documented. If the DPO recommends against proceeding and the controller overrides that recommendation, the override must be recorded with reasons.
Internal sign-off should come from the business owner of the forecasting system, the DPO, and — where residual risks touch IT security — the CISO or equivalent.
Expected result: A complete, version-controlled DPIA document with dated signatures from all required parties.
Step 7 — Decide whether prior consultation is required
If residual risks remain high after all mitigation measures have been applied, GDPR Article 36 requires you to consult the competent supervisory authority before processing begins. The supervisory authority then has up to eight weeks (extendable by a further six weeks in complex cases) to respond.
Do not treat this as a last resort to be avoided. Supervisory authorities in several EU member states have published guidance and sector-specific opinions that can inform your mitigation design; engaging early reduces the risk of a post-deployment enforcement action.
If residual risks are medium or low across the board, prior consultation is not required — but retain the DPIA and make it available to the supervisory authority on request.
Note: The EU AI Act introduces a parallel conformity assessment obligation for certain AI systems. Demand forecasting systems in fashion retail are generally classified as limited-risk under the Act's current framework, but the regulatory picture continues to evolve. Review the Taylor Wessing analysis of the AI Act's application to fashion alongside your DPIA to identify where documentation can be shared across both frameworks.
Expected result: A documented decision — with reasoning — on whether Article 36 prior consultation is required, and if so, a submitted consultation package.
Step 8 — Review and maintain the DPIA
A DPIA is not a one-time exercise. You must review it whenever there is a material change to the processing — a new data source, a change in model architecture, a new use of model outputs, or a change in the applicable legal framework.
Set a calendar review at least annually, and build a change-management trigger into your model deployment pipeline so that any significant update to the forecasting system automatically flags a DPIA review.
Expected result: A scheduled review cadence documented in your governance framework, with a named owner responsible for triggering reviews.
Troubleshooting: common problems
"We aggregate all outputs to SKU level — does a DPIA still apply?" If the training data contains individual-level records, the DPIA applies to the training pipeline regardless of how outputs are aggregated. Assess the training phase separately from the inference phase.
"Our legal basis is legitimate interests — do we still need a DPIA?" Yes. Legal basis and DPIA obligation are independent questions. A legitimate interests basis requires a Legitimate Interests Assessment (LIA); the DPIA addresses risk to data subjects regardless of basis.
"The model vendor says their platform is GDPR-compliant — can we rely on that?" No. Compliance certifications or contractual assurances from a processor do not substitute for your own DPIA as controller. They are evidence to cite in Step 5 as a mitigation measure, not a replacement for the assessment.
"We retrain the model monthly on new data — does each retraining cycle require a new DPIA?" Not automatically. If the retraining uses the same data categories, the same pipeline, and produces the same type of outputs, the original DPIA covers it. A new DPIA (or a formal review of the existing one) is required if the retraining introduces new data categories or materially changes the model's behaviour.
"The DPO is not available until after the planned launch date." Delay the launch. Processing that requires a DPIA and proceeds without one exposes the controller to administrative fines under GDPR Article 83(4). The DPO's opinion is a procedural requirement, not an optional review.
What success looks like
A completed DPIA for a fashion AI demand forecasting system should be a document that:
- A supervisory authority inspector can read and understand without additional explanation.
- Demonstrates that privacy was considered in the design of the system, not retrofitted after deployment.
- Contains no unresolved high residual risks — either they have been mitigated to medium or low, or prior consultation has been completed.
- Is version-controlled, with a clear audit trail of who approved what and when.
- Is integrated into your broader AI governance framework so that it does not become an isolated compliance artefact.
FAQ
Does every demand forecasting model in fashion require a DPIA? If the model processes personal data and meets two or more of the WP29 high-risk criteria — profiling, large-scale processing, or innovative technology — yes. A model trained only on anonymised aggregate sales data with no individual-level records may fall below the threshold, but that determination must itself be documented.
How long does a DPIA typically take to complete? For a moderately complex demand forecasting system, expect four to eight weeks from scoping to sign-off, assuming the technical documentation is available and stakeholders are responsive. Prior consultation with a supervisory authority adds up to fourteen weeks on top of that.
Can the DPIA and the EU AI Act conformity documentation be combined? Partially. The risk assessment and technical measures sections overlap substantially. Maintain them as separate documents with cross-references, since the legal frameworks have different scope, different reviewers, and different update triggers.
Who is responsible for the DPIA — the DPO or the engineering team? The controller is legally responsible. In practice, the DPO leads the process and provides the formal opinion, but the engineering and product teams must supply the technical description and the evidence for mitigation measures. Neither can complete it without the other.
What happens if we discover a high residual risk after the system is already live? Stop the processing, or implement emergency mitigations that reduce the risk to an acceptable level, and initiate prior consultation with the supervisory authority. Document the timeline and the actions taken. Voluntary disclosure of a compliance gap is treated more favourably than a gap discovered during an inspection.
Further reading
- WP248rev.01 — Guidelines on DPIA (Article 29 Working Party / EDPB)
- CNIL — Ce qu'il faut savoir sur l'AIPD
- Data Protection Commission Ireland — DPIA obligations
- Garante — Elenco dei trattamenti soggetti a DPIA
- Taylor Wessing — Fashion meets the AI Act