When a fashion enterprise wraps a foundation model inside its own internal platform and rolls it out to thousands of employees, it does not simply inherit the compliance posture of its upstream vendor. Under the EU AI Act, the organisation that deploys the system to end users carries a distinct and non-delegable set of obligations—regardless of who trained the underlying model. For legal, compliance, and engineering leads at large fashion groups, understanding exactly where that boundary falls is the first step toward a defensible governance programme.
Key takeaways
- The EU AI Act distinguishes between providers (who place a system on the market) and deployers (who use it in a professional context); large fashion enterprises running internal AI platforms are typically deployers, but can be reclassified as providers under specific conditions.
- A fashion group that brands, substantially modifies, or changes the intended purpose of a third-party AI system assumes full provider obligations under Article 25 of Regulation (EU) 2024/1689.
- Internal generative AI platforms built on models such as Azure OpenAI are not automatically exempt from the Act simply because they are not sold externally.
- Risk classification drives the compliance burden: most internal creative and productivity tools fall into the limited-risk or minimal-risk categories, but HR, performance monitoring, and recruitment applications may cross into high-risk territory.
- Governance controls—human oversight, logging, incident response, and employee information obligations—apply to deployers from the moment they put a system into regular operational use.
What does the EU AI Act actually say about deployers?
The EU AI Act (Regulation (EU) 2024/1689, in force from August 2024) creates a tiered compliance architecture built around the concept of a value chain. At one end sits the provider—the entity that develops or places an AI system on the market. At the other sits the deployer—the entity that uses an AI system under its own authority in a professional context.
For most fashion enterprises running internal tooling, the default classification is deployer. You did not train the foundation model; you did not place it on the market. You licensed access to it—through a service such as Azure OpenAI—and you built an application layer on top.
But the Act does not leave that classification static. Article 25 of Regulation (EU) 2024/1689 specifies the conditions under which a distributor, importer, deployer, or other third party is reclassified as a provider and becomes subject to the full provider obligation set. Those conditions include:
- Branding: putting your name or trademark on a high-risk AI system already placed on the market.
- Substantial modification: making a material change to a high-risk system that alters its performance, intended purpose, or risk profile.
- Change of intended purpose: deploying a general-purpose or limited-purpose system for a high-risk use case that the original provider did not intend or document.
The practical implication is direct: if your internal platform takes a general-purpose language model, adds a layer that makes automated decisions about employee performance or recruitment, and deploys it under your group's brand, you have likely crossed the threshold into provider territory for that specific application—even if the underlying model is unchanged.
How does this apply to a fashion group running an internal generative AI platform?
The Otto Group model as a reference point
Otto Group is one of the clearest public examples of a large fashion and retail conglomerate that has built and scaled an internal generative AI platform. The group launched ogGPT, a secure internal chatbot built on OpenAI's technology via Microsoft's Azure OpenAI Service, and made it available to employees across the organisation. The stated rationale was to enable professional use of an AI assistant with access to internal company information while maintaining privacy compliance.
By the group's own account, the e-commerce platform OTTO alone operates more than 70 AI products across its value streams, and AI is described as a relevant component of all business processes. That scale of internal deployment is precisely the scenario the EU AI Act's deployer obligations are designed to reach.
Otto Group has also published a Responsible AI Guide, developed by its Tech Strategy department together with data and AI experts from across the organisation, intended to serve as a group-wide compass for the responsible use of AI. That kind of internal policy instrument is not merely a reputational asset—it maps directly onto the governance documentation that deployers are expected to maintain under the Act.
Risk classification for internal fashion AI tools
Before assigning governance controls, you need to classify each internal tool by risk tier. The Act establishes four levels:
- Unacceptable risk (prohibited): systems that manipulate individuals subliminally, exploit vulnerabilities, or enable real-time biometric surveillance in public spaces. No internal fashion AI tool should fall here; if it does, it cannot be deployed.
- High risk: systems used in employment, workforce management, and access to self-employment—including tools that sort, filter, or evaluate job applicants, monitor employee performance, or make or materially influence decisions about promotion or termination. Fashion enterprises using AI for HR screening or performance scoring must treat those applications as high-risk.
- Limited risk: systems that interact with humans (chatbots, virtual assistants) or generate synthetic content. Internal chatbots like ogGPT, AI image generation tools using DALL-E, and AI-assisted copywriting platforms typically fall here. The primary obligation is transparency: users must know they are interacting with an AI.
- Minimal risk: the majority of AI applications—recommendation engines, search ranking, trend analysis—carry no specific Act obligations beyond general good practice.
For most internal creative and productivity tooling in fashion—AI-generated campaign imagery, AI-assisted product descriptions, internal knowledge retrieval—the classification will be limited risk. The governance burden is real but manageable. The danger zone is any application that touches employment decisions.
What governance controls must deployers implement?
For limited-risk systems (the typical internal creative tool)
Transparency to users. Employees using an internal AI chatbot or image generation tool must be informed that the system is AI-powered. This does not require elaborate disclosure; a persistent UI label or an onboarding notice is sufficient, but it must be present and unambiguous.
Acceptable use policy. Document the intended purposes of each tool. If your internal platform is deployed for product description drafting, that scope should be stated. Scope creep—using the same tool for HR correspondence or disciplinary documentation—can shift the risk classification without a corresponding governance review.
Data handling documentation. Generative AI tools that process employee data or customer data must comply with GDPR in parallel with the AI Act. For tools built on Azure OpenAI, the contractual data processing terms from Microsoft define what data leaves your environment and under what conditions. Your compliance team should have reviewed and documented those terms before deployment.
Incident logging. Maintain a log of material failures, unexpected outputs, and user-reported issues. This is not a statutory requirement for limited-risk systems under the current text, but it is standard practice for any system that could produce outputs with reputational or legal consequences, and it will be expected in any regulatory inquiry.
For high-risk systems (HR, performance, recruitment)
If any internal tool crosses into high-risk territory, the obligations are substantially heavier:
- Human oversight: the system must be designed so that a human can intervene, override, or halt its operation. Automated decisions about employees cannot be final without human review.
- Technical documentation: a conformity assessment file covering the system's design, training data (if applicable), performance metrics, and risk mitigation measures.
- Registration: high-risk AI systems must be registered in the EU database before deployment.
- Fundamental rights impact assessment: deployers of high-risk systems in employment contexts must conduct and document an assessment of the system's impact on fundamental rights.
- Employee information: workers subject to AI-assisted monitoring or evaluation must be informed in advance.
The Taylor Wessing analysis of the AI Act's application to fashion notes that while many fashion AI applications are low risk, the sector's use of AI in HR and customer-facing personalisation creates pockets of higher regulatory exposure that practitioners should not overlook.
What is still unresolved?
Several questions remain genuinely open at the level of regulatory guidance:
General-purpose AI model obligations and their interaction with deployer duties. The Act introduces a separate regime for general-purpose AI models (GPAIs) with systemic risk. How the obligations on GPAI providers—such as OpenAI under its agreement with Microsoft for Azure OpenAI—interact with the downstream deployer's own obligations is still being worked out in implementing guidance. Fashion enterprises should not assume that a GPAI provider's compliance automatically satisfies their own.
The boundary between substantial modification and configuration. Prompt engineering, fine-tuning on proprietary data, and retrieval-augmented generation all sit in a grey zone. Regulators have not yet published clear criteria for when configuration becomes modification sufficient to trigger Article 25 reclassification.
Deadline sequencing. The Act's obligations are phased in over time, and the sequencing of those phases has itself been subject to adjustment. Legal counsel should be tracking the current implementation timeline actively rather than relying on earlier summaries.
Sector-specific guidance for fashion. No fashion-specific guidance has been issued by the AI Office. The sector's particular characteristics—large volumes of AI-generated imagery, AI-assisted trend forecasting, AI-driven personalisation—are not addressed in the general guidance documents published to date.
What should your governance programme look like in practice?
A workable internal AI governance programme for a fashion enterprise running tools like ogGPT or equivalent platforms should include the following components:
- AI system inventory: a register of every internal AI tool, its vendor, its risk classification, its intended use, and its data flows. Update it whenever a new tool is deployed or an existing tool's use case changes.
- Classification review process: a lightweight cross-functional review (legal, engineering, HR, data protection) triggered whenever a new use case is proposed for an existing tool.
- Acceptable use policies per tool: short, specific documents that define what the tool is for, what it is not for, and what employees must do when the tool produces an unexpected or harmful output.
- Transparency implementation: UI-level disclosure for all employee-facing AI tools, documented and version-controlled.
- Data processing agreements: verified and filed for every third-party AI service, including cloud-hosted foundation model APIs.
- Incident response procedure: a named owner, a reporting chain, and a log. For high-risk systems, this feeds into the mandatory serious incident reporting obligation.
- Responsible AI policy: a board-level or executive-level document that sets principles and accountability. Otto Group's published Responsible AI Guide is a public example of what this looks like at group scale.
- Training: employees who use AI tools in professional contexts have a right to be informed; employees who govern those tools need to understand the Act's obligations. These are different programmes.
FAQ
Is an internal AI tool that is never sold to customers covered by the EU AI Act? Yes. The Act applies to AI systems used in a professional context within the EU, regardless of whether they are commercial products. An internal chatbot deployed to employees is within scope as soon as it is put into regular operational use by a deployer.
If we use Azure OpenAI, does Microsoft's compliance cover our obligations? No. Microsoft, as the provider of the Azure OpenAI service, carries its own obligations under the Act. Your organisation, as the deployer, carries a separate and non-delegable set of obligations. The two compliance postures are complementary, not substitutable.
When does configuring a model become a substantial modification that triggers provider obligations? This is not yet definitively settled in regulatory guidance. The Act's text points to changes that alter a system's intended purpose or materially affect its performance or risk profile. Fine-tuning on proprietary data or deploying a general-purpose model for a high-risk use case are the clearest triggers; prompt configuration alone is less likely to qualify, but the boundary is not bright.
What is the risk classification for an AI image generation tool used for internal campaign concepting? Most internal creative tools of this kind fall into the limited-risk category. The primary obligation is transparency—users must know the output is AI-generated. If the outputs are used in external communications, additional considerations around synthetic content labelling may apply.
Do we need to register our internal AI tools with any EU authority? Only high-risk AI systems require registration in the EU database before deployment. Limited-risk and minimal-risk systems do not carry a registration obligation, though maintaining an internal inventory is good practice and will be expected in any regulatory review.