The EU AI Act assigns concrete obligations to both providers and deployers of AI systems. As a fashion brand deploying a vendor's tool, you are a deployer under the Act — and deployer status carries its own duties around human oversight, incident reporting, and data governance. The eight questions below give your procurement and legal teams a structured script for vendor conversations, with the reasoning behind each so you can evaluate answers rather than simply collect them.
Key takeaways
- The EU AI Act distinguishes between providers and deployers; fashion brands that deploy vendor tools carry independent compliance obligations.
- High-risk classification triggers documentation, logging, and conformity assessment requirements that vendors must be able to evidence before you sign.
- Transparency obligations under Article 50 apply from August 2026, with a limited grace period — vendors should already have implementation plans in place.
- Data governance questions are not optional: how a vendor trains its models on your pattern and product data determines your exposure under both the AI Act and GDPR.
- A vendor that cannot answer these questions clearly is itself a compliance signal.
Why does this checklist matter for fashion brands specifically?
Fashion AI tools span a wide range of functions — demand forecasting, visual search, automated tech-pack generation, size recommendation, trend analysis. The risk classification of each function under the AI Act differs, and the compliance posture of a vendor serving a large retailer is not the same as one serving an independent studio. Procurement teams that treat AI vendor selection the same way they treat SaaS procurement generally will miss obligations that sit specifically with the deployer.
Research and advisory firms such as Gartner consistently note that enterprise technology buyers underestimate the compliance transfer risk in AI contracts — the assumption that the vendor carries all regulatory exposure is not supported by the Act's text.
The eight questions
1. What risk tier does the EU AI Act assign to your system, and how did you reach that determination?
The Act establishes four risk tiers: a set of prohibited practices, high-risk systems subject to strict compliance requirements, systems with transparency obligations, and minimal-risk systems. The classification is not self-evident for fashion tools. A recommendation engine that influences employment decisions (for example, workforce scheduling) sits in a different tier from a pattern-generation tool. Ask the vendor to show you the written risk assessment, not just state a conclusion.
What a strong answer looks like: A documented risk assessment that names the specific Annex III categories considered, explains why the system does or does not fall within them, and identifies who signed off on the determination.
What to watch for: A vendor who says 'we are minimal risk' without documentation, or who conflates the risk tier of the underlying foundation model with the risk tier of their application layer.
2. If your system is high-risk, what conformity assessment has been completed?
High-risk AI systems must undergo conformity assessment before being placed on the market. For most high-risk categories, this is a self-assessment against the harmonised standards, documented in a technical file. For some categories, a notified body is involved. Ask for the conformity assessment report or, at minimum, the technical file index.
What a strong answer looks like: A reference to the specific harmonised standard applied, the date of assessment, and the person or body responsible. If the system is not yet assessed, a credible timeline with interim controls.
What to watch for: Vendors who describe roadmap intentions as current compliance. Additional preparation time granted by revised deadlines is not a reprieve from the underlying obligation — as legal commentary on the Act's employer and HR technology provisions has noted, the message is that this is preparation time, not a waiver.
3. What technical documentation and logs do you maintain, and can we access them as the deployer?
The Act requires providers of high-risk systems to maintain technical documentation and automatic logging capabilities. As a deployer, you have a right to access the logs relevant to your deployment, and you may need them to demonstrate your own compliance or to respond to a supervisory authority. Clarify contractually who holds the logs, for how long, and under what conditions you can retrieve them.
What a strong answer looks like: A data processing agreement or AI-specific annex that specifies log retention periods, access procedures, and the format in which logs are provided on request.
What to watch for: Vendors who treat logs as their own proprietary data with no deployer access, or who cannot specify retention periods.
4. How does your system support human oversight, and what controls do we retain as the deployer?
Deployers are responsible for ensuring human oversight once a system is in operation. This is not a passive obligation: you need to be able to intervene, override, or suspend the system. Ask the vendor what override mechanisms exist, how quickly a human operator can interrupt an automated output, and whether the system flags low-confidence outputs for review.
What a strong answer looks like: Documented override workflows, configurable confidence thresholds, and audit trails that record when a human intervened and what action was taken.
What to watch for: Systems where automation is the only path and human review is a post-hoc check on outputs already acted upon.
5. What is your incident reporting process, and what are our obligations as the deployer?
Deployers must report serious incidents and malfunctions to the relevant national authority. The Act defines 'serious incident' in specific terms. Ask the vendor how they define an incident, what their internal escalation timeline is, how they notify you, and what information they will provide to support your own reporting obligation.
What a strong answer looks like: A written incident response procedure with defined severity levels, notification timelines (hours, not weeks), and a named point of contact for deployer escalation.
What to watch for: Vendors who conflate general SLA breach procedures with AI Act incident reporting, or who have not yet mapped their incident categories to the Act's definitions.
6. How do you handle transparency obligations toward end users of AI-generated outputs?
Article 50 of the Act imposes transparency obligations when individuals interact with AI systems or receive AI-generated content. Deployers must disclose certain AI-generated outputs and ensure that individuals know they are interacting with an AI system where this is not obvious. For fashion brands, this may affect AI-generated product descriptions, AI-driven customer service interactions, or AI-generated visual content. The Article 50 FAQ published by the European Commission clarifies that machine-readable marks and clear labelling are the expected implementation path, and that these obligations apply from August 2026.
What a strong answer looks like: A vendor who has mapped their outputs to Article 50 categories, implemented or is implementing machine-readable content provenance marks, and can advise you on the labelling you need to add at the deployer layer.
What to watch for: Vendors who treat transparency as a marketing question rather than a legal one, or who have not read Article 50 in the context of their specific outputs.
7. How is our data — including pattern files, product data, and customer data — used to train or improve your models?
This is the question most procurement teams ask too narrowly. The issue is not only GDPR compliance (though that matters). It is whether your proprietary design data — DXF pattern archives, tech packs, BOM structures — is used to train a shared model that also serves your competitors. Under the AI Act, data governance for high-risk systems must meet quality and traceability standards. Under GDPR, any personal data in your datasets requires a lawful basis for processing.
Ask the vendor explicitly: does your pattern or product data leave your environment, is it used to improve a general model, and is there tenant isolation between your data and other customers' data?
Vendors answer this question differently. FashionINSTA, for example, trains each brand's model exclusively on that brand's own DXF pattern archive in a private, tenant-isolated environment, with no cross-client learning and no use of customer patterns to improve a shared general model. PTC FlexPLM, a PLM platform used by apparel and retail companies to manage design files and tech packs, approaches data governance through its broader enterprise security and data residency controls. The point is not which architecture is correct in the abstract — it is that you should understand exactly which model applies to your deployment before you sign.
What a strong answer looks like: A written data processing agreement that specifies whether your data is used for model training, under what conditions, with what opt-out or isolation mechanisms, and how long it is retained.
What to watch for: Vague references to 'industry-standard data practices' without specifics, or contracts that grant the vendor broad rights to use customer data for product improvement without distinguishing personal data from proprietary design data.
8. What is your roadmap for maintaining compliance as the Act's requirements evolve?
The Act's obligations are phased, and the technical standards that underpin conformity assessment are still maturing. A vendor who is compliant today may not be compliant when the next set of obligations comes into force. Ask about their regulatory monitoring process, their relationship with notified bodies or legal counsel specialising in AI regulation, and how they communicate compliance changes to deployers.
What a strong answer looks like: A named regulatory affairs function or external counsel, a process for monitoring European standardisation activity, and a contractual commitment to notify you of material compliance changes within a defined period.
What to watch for: Vendors who treat compliance as a one-time certification rather than an ongoing programme, or who cannot name the standards bodies whose output they are tracking.
How to use these questions in practice
Send the questions in writing before the vendor meeting so that answers are documented. Request supporting materials — technical files, data processing agreements, incident response procedures — rather than accepting verbal assurances. Where a vendor cannot provide documentation, ask for a timeline and make delivery of that documentation a condition of contract signature.
If you use a PLM platform such as PTC FlexPLM to manage your design and supplier data, map the AI Act obligations that arise at the PLM layer separately from those that arise at the AI tool layer. The two are not the same, and your compliance programme needs to address both.
Gartner's research and advisory work on enterprise AI governance consistently emphasises that deployer organisations need internal ownership of AI risk — a single team or individual who is accountable for the AI Act obligations that sit with the brand, not delegated entirely to vendors.
FAQ
Is a fashion brand a provider or a deployer under the EU AI Act?
Most fashion brands that use a vendor's AI tool are deployers, not providers. Providers are the entities that develop and place the AI system on the market. Deployers use that system in a professional context. Both roles carry obligations, but they differ: deployers are primarily responsible for human oversight, incident reporting, and ensuring the system is used as intended.
Which fashion AI use cases are most likely to be classified as high-risk?
Use cases that influence employment decisions — such as workforce scheduling or performance evaluation tools — are more likely to fall into high-risk categories under Annex III. Demand forecasting, pattern generation, and trend analysis tools are generally assessed at lower risk tiers, though the specific implementation determines classification. Always request the vendor's written risk assessment.
What does Article 50 require fashion brands to do in practice?
Article 50 requires deployers to disclose when AI-generated content is used in contexts such as customer-facing communications or product descriptions on matters of public interest, and to ensure individuals know they are interacting with an AI system where this is not obvious. Machine-readable content marks and clear labelling are the expected implementation path.
Can we rely on the vendor to handle all EU AI Act compliance on our behalf?
No. The Act assigns independent obligations to deployers that cannot be fully contracted away to the provider. Human oversight, incident reporting to national authorities, and data governance at the deployment layer are deployer responsibilities. Vendor contracts can allocate information-sharing and support obligations, but they cannot transfer the deployer's legal status.
What happens if a vendor cannot answer these questions?
A vendor who cannot produce documentation for risk classification, conformity assessment, or data governance is itself a compliance signal. Deploying a non-compliant system exposes the brand to supervisory action. Treat the inability to answer as a material risk factor in your vendor selection, not as a gap to be resolved post-contract.
Further reading
- AI Act — Shaping Europe's digital future
- Transparency obligations under Article 50 of the AI Act — FAQs
- Changes to EU AI Act deadlines — Morgan Lewis