The EU AI Act is now part of the operating environment for any fashion business that develops, sources, or deploys AI tools in the European market. Yet the Act's definitions — the load-bearing terms on which risk classification, obligation mapping, and enforcement all rest — are routinely misread by the very teams responsible for compliance. The misreadings are not random: they cluster around concepts that sound familiar but carry precise statutory meanings that diverge from everyday usage. This digest identifies ten of those definitions, states what teams typically assume, and gives the correct reading with its practical implication.
This piece is written for compliance officers, product managers, and legal counsel working inside fashion technology teams. It does not substitute for legal advice; it is a working reference for the terms you will encounter most often.
Key takeaways
- The statutory definition of 'AI system' is narrower than 'software that uses machine learning': not every algorithmic tool your team ships qualifies.
- A fashion brand that configures and deploys a third-party AI tool is a 'deployer' with its own obligations — it is not simply a customer.
- A vendor that fine-tunes a foundation model on your data may become a 'provider' under the Act, shifting significant compliance obligations onto them — or onto you.
- 'General-purpose AI model' covers a specific class of large-scale models; most task-specific fashion AI tools do not meet the threshold.
- Risk classification is determined by use case and context, not by the sophistication of the underlying model.
Why do these misreadings matter?
The EU AI Act assigns obligations — documentation, transparency notices, conformity assessments, incident reporting — to specific roles and specific system types. If your team misidentifies which role it occupies, or misclassifies the system it is using, it maps obligations to the wrong party or applies the wrong compliance track. As Taylor Wessing's sector analysis of the Act's impact on fashion notes, most fashion AI applications fall into lower-risk categories — but that classification is only reliable if the underlying definitions are read correctly.
Deadlines under the Act have shifted. Morgan Lewis reported in June 2026 that revised timelines give organisations additional preparation time — but frame this explicitly as time to prepare, not as a reprieve. Teams that have not yet mapped their AI inventory against the correct definitions are behind, not safe.
The ten definitions, corrected
1. 'AI system'
Common misreading: Any software component that uses a model, a statistical method, or an API call to a language model is an 'AI system' under the Act.
Correct reading: Article 3(1) defines an AI system as a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that — for explicit or implicit objectives — infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence real or virtual environments. Rule-based systems, deterministic algorithms, and simple automation pipelines that do not infer from inputs in this sense are not AI systems under the Act.
Practical implication: A size-recommendation widget that applies a fixed lookup table is not an AI system. A widget that uses a trained model to infer fit probability from body measurements is. Audit your tool inventory against the statutory definition before classifying risk.
2. 'Provider'
Common misreading: The provider is the software vendor — the company whose name is on the product.
Correct reading: A 'provider' is any natural or legal person that develops an AI system or general-purpose AI model and places it on the market or puts it into service under their own name or trademark, whether for payment or free of charge. A fashion brand that commissions a bespoke AI tool, fine-tunes a foundation model, or substantially modifies a third-party system before deploying it may become a provider — even if it does not think of itself as a technology company.
Practical implication: If your team has built a custom demand-forecasting model or a product-description generator trained on your own catalogue, you are likely a provider. That carries obligations: technical documentation, conformity assessment for high-risk systems, a CE mark where required, and registration in the EU database.
3. 'Deployer'
Common misreading: The deployer is whoever presses the button — an end user with no formal compliance role.
Correct reading: A deployer is any natural or legal person that uses an AI system under their own authority in a professional context, except where the system is used for personal non-professional purposes. Deployers have their own obligations under the Act: they must use systems in accordance with the provider's instructions, implement human oversight measures, monitor for risks, and — for high-risk systems — carry out a fundamental rights impact assessment and inform workers where AI systems affect them.
Practical implication: A retailer such as Zalando that integrates a third-party AI recommendation engine into its platform is a deployer with statutory duties, not simply a licensee. The same applies to any fashion brand deploying an off-the-shelf AI tool for hiring, pricing, or customer profiling.
4. 'General-purpose AI model' (GPAI model)
Common misreading: Any large language model or image-generation model used in a fashion workflow is a GPAI model.
Correct reading: A GPAI model is an AI model trained on large amounts of data at scale, designed for general applicability, and capable of competently performing a wide range of distinct tasks. The Act further distinguishes GPAI models of 'systemic risk' — those trained using a total compute exceeding a defined threshold (currently set at 10^25 FLOPs). A task-specific model trained to classify garment attributes or generate size recommendations is not a GPAI model under this definition.
Practical implication: If your team is building on top of a GPAI model (via API or fine-tuning), the model provider carries GPAI-level obligations. Your obligations as a downstream provider or deployer are separate and depend on what you build on top of it and how you deploy it.
5. 'High-risk AI system'
Common misreading: High risk means the model is technically complex or handles large volumes of data.
Correct reading: High risk is determined by use case, not by technical sophistication. Annex III of the Act lists the categories: AI systems used in employment and worker management (including recruitment, task allocation, and performance monitoring), biometric identification, access to essential services, and several others. A simple model used for CV screening is high-risk; a sophisticated generative model used to draft product descriptions is not.
Practical implication: Fashion brands using AI for any stage of recruitment, scheduling, or performance evaluation — including tools embedded in HR platforms — are operating high-risk systems. The obligations are substantial: conformity assessment, logging, human oversight, and transparency to affected workers. As Taylor Wessing's analysis of the Act's fashion-sector impact notes, many fashion AI applications are lower risk, but employment use cases are a clear exception.
6. 'Substantial modification'
Common misreading: Retraining a model on your own data, or adding a fine-tuning layer, is a configuration choice — it does not change who the provider is.
Correct reading: A substantial modification is a change to an AI system after it has been placed on the market or put into service that affects the system's compliance with the Act's requirements, or changes its intended purpose. Where a deployer makes a substantial modification, they become the provider of the modified system and take on all provider obligations.
Practical implication: If your team fine-tunes a foundation model on proprietary catalogue data and deploys the result under your brand, you have likely made a substantial modification. You are now the provider of that system. Document the modification, assess the risk classification of the resulting system, and ensure your technical documentation reflects what you have built.
7. 'Intended purpose'
Common misreading: Intended purpose is whatever the AI tool is capable of doing.
Correct reading: Intended purpose is the use for which an AI system is designed by the provider, including the specific context and conditions of use, as specified in the instructions for use, promotional material, or technical documentation. Reasonably foreseeable misuse is a related but distinct concept. Risk classification follows intended purpose, not capability.
Practical implication: A virtual try-on tool intended for product visualisation is classified differently from the same underlying technology intended to infer body measurements for medical or insurance purposes. Document intended purpose precisely in your technical specifications. Scope creep in deployment — using a tool for a purpose beyond its stated intent — can shift your risk classification without any change to the model itself.
8. 'Transparency obligation'
Common misreading: Transparency means publishing a general AI policy on your website.
Correct reading: The Act's transparency obligations are specific and tiered. For AI systems that interact with natural persons (chatbots, virtual assistants), users must be informed they are interacting with an AI unless this is obvious. For emotion-recognition systems and biometric categorisation systems, disclosure is required. For AI-generated content intended to resemble real persons or events, labelling is required. A general policy statement does not satisfy these obligations.
Practical implication: A customer-service chatbot on a fashion e-commerce platform must identify itself as an AI at the start of the interaction. An AI-generated campaign image that depicts a realistic human face may require labelling. Review each customer-facing AI touchpoint against the specific transparency requirement that applies to it, not against a blanket disclosure.
9. 'Operator'
Common misreading: 'Operator' is a synonym for 'deployer' — the two terms are interchangeable.
Correct reading: The Act uses 'operator' as an umbrella term covering both providers and deployers. It is not a synonym for deployer. Where the Act addresses obligations to 'operators', it may be addressing both roles. Where it distinguishes between them, it uses 'provider' and 'deployer' specifically. Treating 'operator' as equivalent to 'deployer' causes teams to miss obligations that apply to providers.
Practical implication: When reading guidance documents, regulatory Q&As, or vendor contracts that use 'operator', check whether the source is using it in the Act's umbrella sense or in a narrower colloquial sense. Map every obligation back to the statutory text and to your specific role — provider, deployer, or both.
10. 'Putting into service'
Common misreading: Putting into service means launching a product to external customers.
Correct reading: Putting into service means the supply of an AI system for first use directly to the deployer or for own use on the EU market for its intended purpose. Internal deployment — using an AI tool within your own organisation, not for sale — counts as putting into service. A fashion brand that builds and internally deploys an AI tool for trend analysis or supplier evaluation has put that system into service, even if no external customer ever touches it.
Practical implication: Internal AI tools are not exempt from the Act by virtue of being internal. If the system falls into a regulated category, the obligations apply from the moment it is deployed for use within the organisation. Inventory your internal AI tools with the same rigour you apply to customer-facing products. Our coverage of the research gap between AI ambition and operational readiness in fashion — explored in our piece on fashion AI ambitions versus readiness — suggests that internal tooling is precisely where documentation and governance tend to be weakest.
Mapping your exposure
The ten misreadings above share a common root: teams apply intuitive, everyday meanings to terms that the Act defines with statutory precision. The corrective is straightforward in principle — read the definitions in the Act itself, not in vendor summaries or press coverage — but it requires dedicated time from legal and product teams working together.
For fashion businesses operating at scale, the provider/deployer distinction and the intended-purpose definition are the highest-priority items to resolve. A brand the size of H&M Group will occupy both roles simultaneously across different parts of its AI portfolio; the compliance mapping must be done system by system, not at the portfolio level.
The Act's definitions are not static: implementing acts and guidance from the AI Office will continue to refine them. Build a process for monitoring that guidance, not just a one-time audit.
FAQ
Is every recommendation algorithm a high-risk AI system under the EU AI Act? No. Risk classification depends on use case, not on the sophistication of the algorithm. A product recommendation engine on a retail site is not listed in Annex III. An AI system used to evaluate job applicants or allocate work tasks is high-risk regardless of its technical simplicity.
If we use a third-party AI tool via API, are we a provider or a deployer? Generally a deployer, unless you substantially modify the system or deploy it under your own name with a changed intended purpose. Fine-tuning on your own data and redeploying the result is likely a substantial modification that makes you a provider of the modified system.
Does the EU AI Act apply to AI tools used only internally, not sold to customers? Yes. Putting a system into service for own use within the EU counts as putting it into service under the Act. Internal tools in regulated categories carry the same obligations as customer-facing ones.
What does 'transparency' require for a fashion chatbot? At minimum, the system must identify itself as an AI to the user at the start of the interaction, unless it is obvious from context. A general AI policy page does not satisfy this requirement. The disclosure must be made at the point of interaction.
Where can I find the authoritative text of the definitions? Article 3 of Regulation (EU) 2024/1689 (the EU AI Act) contains the full definitions. Annex III lists the high-risk use cases. The European AI Office publishes guidance on interpretation; monitor its output alongside the statutory text.
Further reading
- Fashion meets the AI Act — Taylor Wessing sector analysis
- Changes to EU AI Act deadlines — Morgan Lewis