The EU AI Act distributes compliance obligations across every actor in the AI value chain — not just the company whose name appears on the product. For a fashion business, that chain typically spans data suppliers, foundation model providers, integration platforms, internal tooling teams, and downstream retail deployers. If you cannot name each node and its role, you cannot assign accountability correctly, and you cannot produce the technical documentation the Act requires.
Key takeaways
- The EU AI Act places distinct obligations on 'providers' (those who develop or place an AI system on the market) and 'deployers' (those who put it into use), and a single fashion pipeline often contains both roles simultaneously.
- Mapping must cover every AI component — including third-party APIs, embedded model calls, and AI features inside PLM or ERP platforms — not only bespoke models your team trained.
- A supply chain map is a living document: vendor acquisitions, model version changes, and new API integrations each create fresh accountability questions that require a documented review.
- The Act's obligations apply to systems placed on the EU market or affecting persons in the EU, regardless of where the vendor is headquartered.
- Governance leads should treat the mapping exercise as a prerequisite for both the conformity assessment and the Digital Product Passport data trail.
What you need before you start
Before beginning the mapping exercise, assemble the following:
- A current list of every software platform your product development, sourcing, and retail teams use — PLM, ERP, e-commerce, demand forecasting, customer service, visual search, and any internal tooling.
- Access to vendor contracts and data processing agreements, including sub-processor schedules.
- The name and version of every AI model or API your platforms call, where that information is available in documentation or settings panels.
- A copy of the EU AI Act's Annex III (high-risk system categories) and the GPAI provisions, so you can cross-reference risk classification as you build the map.
- At least one representative from legal, procurement, and each product engineering team in the room — accountability questions cross departmental lines.
The mapping session is not a one-off audit. Build it into your vendor onboarding checklist and your annual contract review cycle from the outset.
Step 1 — Enumerate every AI touchpoint in the product pipeline
Start at the beginning of the product lifecycle and walk forward: trend analysis, range planning, design, pattern development, sample approval, sourcing, quality control, logistics, e-commerce presentation, customer service, and post-sale analytics. At each stage, ask whether any software makes an automated prediction, classification, recommendation, or generation that a human then acts on.
Document each touchpoint in a spreadsheet with the following columns: pipeline stage, system name, vendor, AI capability used, model or API name (if known), data inputs, and outputs that flow downstream. Do not limit the exercise to systems your IT team procured centrally — shadow tools adopted by individual design or merchandising teams are just as subject to the Act.
Expected result: A raw inventory of AI touchpoints, likely between ten and forty rows for a mid-size fashion business, before any deduplication or risk classification.
Step 2 — Classify each component by EU AI Act role
For each row in your inventory, determine which role or roles your organisation holds under the Act:
- Provider — your organisation developed the system, fine-tuned a foundation model on proprietary data, or integrated components into a system it places on the market or puts into service under its own name.
- Deployer — your organisation uses a system developed by another party in a professional context.
- Distributor or importer — your organisation makes an AI system available on the EU market without substantial modification.
A fashion business running a demand-forecasting model fine-tuned on its own sales history is a provider for that system, even if the base model came from a third party. The same business using a cloud-hosted language model via an API — for example, through Azure OpenAI, Microsoft's enterprise-grade platform for hosted foundation models — is a deployer for that specific call, while Microsoft acts as provider of the underlying model.
Add a 'role' column to your inventory and a 'role rationale' column explaining in one sentence why you assigned that role. The rationale matters: it is the first thing an auditor or a notified body will ask for.
Expected result: Every row carries a role assignment with a written rationale. Rows where the role is genuinely ambiguous are flagged for legal review rather than left blank.
Where a vendor has been acquired or has changed its product substantially, update your records before assigning a role. Vendor status changes — including ownership transfers and product pivots — can shift where accountability sits in the chain.
Step 3 — Assign risk classification to each system
The Act distinguishes prohibited practices, high-risk systems (Annex III), systems subject to transparency obligations, and minimal-risk systems. Work through each inventory row against those categories.
For fashion, the systems most likely to attract high-risk classification are those that influence employment decisions (scheduling, performance scoring, recruitment screening) or that profile individuals in ways that affect their access to services. Demand forecasting, trend analysis, pattern generation, and visual merchandising tools generally fall into the minimal-risk or transparency-obligation tiers, though the analysis must be done case by case and documented.
Systems built on general-purpose AI models with systemic risk — a category the Act defines by training compute thresholds — carry additional obligations for the model provider, which flow downstream to deployers through contractual transparency requirements.
Add a 'risk tier' column and a 'classification rationale' column. Where a system sits near a boundary, record the arguments on both sides.
Expected result: A risk-classified inventory in which every high-risk row is flagged for conformity assessment and every GPAI-dependent row is flagged for provider transparency review.
Step 4 — Map the chain of responsibility for each high-risk or GPAI-dependent system
For every row classified as high-risk or as dependent on a GPAI model, draw the full chain from data origin to end output:
- Data supplier — who provided the training or inference data, under what licence, and with what data protection basis.
- Model provider — who trained or fine-tuned the model, and what technical documentation and conformity information they are contractually required to pass downstream.
- Integration layer — which platform or middleware connects the model to your workflow (for example, a PLM platform such as Centric PLM, the AI-powered product lifecycle management platform operated by Dassault Systèmes, which sits between upstream data and downstream product decisions in many fashion pipelines).
- Internal deployer — which team within your organisation configures and operates the system, and who is the named responsible person.
- Downstream deployer — if your organisation supplies AI-assisted outputs (size recommendations, generated product descriptions, automated quality scores) to retail partners or licensees, those partners are downstream deployers and your obligations include providing them with the information they need to meet their own duties.
Document this chain as a diagram or a structured table alongside the inventory. The chain is the evidence base for your technical documentation under Article 11 and your instructions for use under Article 13.
Expected result: A chain-of-responsibility record for each high-risk or GPAI-dependent system, naming each actor and the information-flow obligations between them.
Step 5 — Audit your contracts against the obligations the map reveals
Compare the chain-of-responsibility records against your existing vendor contracts. For each provider relationship, check whether the contract:
- Requires the vendor to supply technical documentation sufficient for your conformity assessment.
- Specifies the model version or system version you are licensed to use, and requires notification of material changes.
- Addresses data protection obligations, including the legal basis for any personal data processed during inference.
- Allocates liability for non-compliance and specifies the governing law.
Where gaps exist, open a contract remediation workstream. Vendors who cannot or will not provide the documentation the Act requires create a compliance gap that sits with your organisation as deployer.
The Act's deadline structure has shifted since initial publication. As of mid-2026, some application timelines have been extended, but legal counsel consistently advise treating the additional time as preparation time rather than a reprieve — changes to EU AI Act deadlines do not reduce the substantive obligations, only the date by which they must be met.
Expected result: A contract gap register with a remediation owner and target date for each gap.
Step 6 — Establish a review trigger and version control protocol
The map you have built reflects a point in time. Three categories of event require a documented review:
- Vendor change — an acquisition, a product pivot, or a sub-processor change at any node in the chain. Fashion technology vendors change hands with some frequency; a system you classified as minimal-risk under one owner may carry different obligations if the new owner repositions it or changes its training data.
- Model version change — a provider silently updating the underlying model can change the system's behaviour and, in some cases, its risk classification.
- New integration — any new API call, plugin, or AI feature enabled in an existing platform constitutes a new AI touchpoint and must be added to the inventory before it goes into production use.
Assign a named owner to the map, set a calendar review at least annually, and add the review trigger list to your vendor onboarding and change-management procedures.
Expected result: A governance protocol that keeps the map current without requiring a full re-audit each time a minor change occurs.
What success looks like
A completed supply chain map for EU AI Act accountability should give you:
- A single inventory document covering every AI touchpoint, with role, risk tier, and chain-of-responsibility records for each.
- A contract gap register with remediation actions underway.
- Named internal owners for each high-risk or GPAI-dependent system.
- A review protocol embedded in your change-management and vendor-onboarding processes.
- Sufficient technical documentation to support a conformity assessment for any high-risk system your organisation provides.
This foundation also supports adjacent obligations. The Digital Product Passport framework, which is advancing in parallel with the EU AI Act, will require traceability data about materials and processes across the supply chain — the discipline of mapping AI components is directly transferable to that exercise, as early adopters of digital product passports have found when building the data infrastructure for both simultaneously.
Troubleshooting common problems
The vendor cannot tell you which model version you are using. This is a contract and procurement issue, not a technical one. Escalate to your procurement lead and require version disclosure as a condition of contract renewal. In the interim, document the uncertainty and the steps taken to resolve it.
A system spans multiple risk tiers depending on how it is used. Classify by the highest-risk use case in your organisation. If the same system is used for both minimal-risk and high-risk purposes, document both use cases and apply the high-risk obligations to the system as a whole.
Your organisation is simultaneously a provider and a deployer for the same pipeline. This is common and the Act accommodates it. Document each role separately, with the obligations that attach to each, and ensure your internal governance distinguishes between the two.
A vendor acquired during the mapping exercise has not yet updated its documentation. Record the acquisition date, the previous and new owner, and the date on which you requested updated documentation. The gap is noted; the obligation to resolve it remains.
The fashion industry analysis you need is not covered by your legal team's expertise. The Taylor Wessing sector analysis of fashion and the AI Act provides a useful starting point for understanding how the Act's provisions map to fashion-specific AI use cases, including the treatment of systems that are low-risk in isolation but carry important compliance implications in context.
FAQ
What is the difference between a provider and a deployer under the EU AI Act?
A provider develops or places an AI system on the market under its own name. A deployer uses a system developed by another party in a professional context. A fashion business can be both simultaneously — provider for systems it builds or fine-tunes, deployer for third-party APIs and platforms it integrates.
Does the EU AI Act apply to AI tools used only internally, not sold to customers?
Yes. The Act covers systems put 'into service' in a professional context within the EU, not only systems placed on the market. Internal demand forecasting, HR screening, or quality-control tools are within scope if they meet the risk criteria.
How often should a fashion business update its AI supply chain map?
At minimum annually, and additionally whenever a vendor is acquired, a model version changes, or a new AI integration is enabled. Treat the map as a living governance document, not a one-time audit output.
What documentation must a deployer of a high-risk AI system maintain?
Deployers must maintain logs of system use where technically feasible, conduct a fundamental rights impact assessment for certain systems, ensure human oversight, and provide their provider with feedback on incidents. The specific obligations depend on the system category and the deployer's sector.
How does AI supply chain mapping connect to Digital Product Passport requirements?
Both frameworks require traceability across the value chain — the AI Act for model and data provenance, the DPP for material and process data. Building a disciplined mapping practice for AI components creates reusable infrastructure for DPP compliance, particularly for the data governance and supplier documentation elements.