How to Write a Compliant AI System Card for a Fashion Recommendation Engine
· Last updated:
A fashion product recommendation engine almost certainly qualifies as a limited-risk AI system under the EU AI Act, which means your compliance obligation centres on transparency: users must know they are interacting with an AI, and your organisation must be able to produce structured technical documentation on demand. This guide walks you through producing that documentation—a system card—from first principles, using a personalised product recommendation engine as the worked example throughout.
Key takeaways
- Fashion recommendation engines typically fall into the limited-risk tier under the EU AI Act, triggering transparency obligations rather than the full conformity-assessment process required for high-risk systems.
- A system card is the practical instrument for meeting those obligations: it records intended purpose, data provenance, performance metrics, known limitations, and human-oversight mechanisms in one auditable document.
- Regulators and legal analysts note that revised EU AI Act timelines give organisations additional preparation time, but treat that as runway for thorough documentation, not a reason to delay.
- Retailers such as Zalando already operate AI-driven personalisation at scale across tens of millions of customers, making documented governance a commercial as well as a legal expectation.
- Gartner research consistently identifies AI transparency and explainability as top enterprise risk priorities; a well-structured system card directly addresses both.
What do you need before you start?
Before drafting a single section of your system card, gather the following:
- A written statement of intended use — what the engine recommends (products, outfits, size variants), to whom (logged-in customers, anonymous visitors, both), and on which surfaces (website, app, email).
- Data inventory — a list of every training and inference-time data source, including purchase history, browsing behaviour, product catalogue attributes, and any third-party signals. Note the legal basis for each under GDPR.
- Model lineage records — framework, architecture family, training date range, fine-tuning runs, and the team or vendor responsible for each.
- Evaluation results — offline metrics (precision@k, recall, NDCG) and any online A/B test outcomes, with the population and time window they cover.
- Incident and monitoring logs — at least one review cycle of production monitoring data showing how the system behaves on edge cases (new users, out-of-season catalogue, size scarcity).
- A designated system owner — a named individual or role accountable for the card's accuracy and for triggering updates when the model changes.
Note: If you are using a third-party recommendation model or a vendor API, you are still the deployer under the Act and remain responsible for the documentation. Request the vendor's own technical documentation and incorporate it by reference, noting any gaps.
Step 1 — Classify your system's risk tier
Open the EU AI Act's risk taxonomy and locate your system. A fashion recommendation engine that surfaces products to consumers does not make decisions with significant legal or similarly significant effects on individuals; it does not operate in a sector listed as high-risk (such as employment, credit, or law enforcement). Legal analysis of the Act's application to fashion confirms that most consumer-facing recommendation and personalisation tools sit in the limited-risk category, which triggers transparency obligations under Article 22 (disclosure that the user is interacting with an AI) rather than the conformity-assessment process that high-risk systems must complete.
Expected result: A one-paragraph risk classification statement, signed off by your legal or compliance team, that you will paste into Section 1 of the system card. It should name the relevant article(s), state the tier, and record the date of the assessment.
Warning: If your engine feeds into automated pricing, employment-related decisions (e.g., which warehouse staff to deploy based on predicted demand), or credit-adjacent buy-now-pay-later eligibility, re-evaluate: those use cases may push the system into a higher tier and require a separate conformity assessment.
Step 2 — Draft the system card header and scope section
A system card is a structured document, not a narrative essay. Open with a header block that captures the administrative facts an auditor will check first:
System name: e.g., Product Recommendation Engine v3.2
System owner: Name, role, team
Deployment context: Consumer-facing e-commerce, EU markets
Risk classification: Limited-risk (EU AI Act)
Document version: 1.0
Last reviewed: [Date]
Next scheduled review:Date, recommend ≤12 months
Follow the header with a Scope section of no more than 200 words covering: what the system outputs (ranked product lists, "you may also like" carousels, personalised search re-ranking), what it does not do (it does not set prices, does not approve or decline transactions, does not process biometric data), and which user populations it affects.
Expected result: A header block and scope section that any member of your legal, engineering, or product team can read in under two minutes and understand exactly what is and is not covered.
Step 3 — Document intended purpose and use constraints
Article 13 of the EU AI Act requires that limited-risk systems provide sufficient information for users and operators to understand the system's capabilities and limitations. Translate this into a plain-language Intended Purpose section:
- State the primary task: ranking products from your catalogue by predicted relevance to an individual user at a given moment.
- State the intended operators: your internal merchandising and personalisation teams, and any third-party integrators accessing your recommendation API.
- State explicit out-of-scope uses: the system must not be used to infer sensitive attributes (health, religion, political opinion) from browsing behaviour, and must not be the sole basis for any decision that materially affects a user's legal position.
Add a Known limitations subsection. Be specific: the model performs less reliably for users with fewer than five recorded interactions (cold-start problem); it may over-index on recency during promotional periods; catalogue coverage for extended sizes has historically been lower than for standard sizes, which can affect recommendation diversity.
Expected result: A section that doubles as the disclosure text your product team can adapt for user-facing transparency notices, satisfying the Act's requirement that users know an AI is involved in the experience they receive.
Step 4 — Record data provenance and GDPR alignment
This section is where compliance teams most often find gaps. For each data source feeding the engine, document:
- Source name and type (e.g., first-party clickstream, purchase history, product catalogue metadata, third-party trend signals)
- Legal basis under GDPR (consent, legitimate interest, contract performance)
- Retention period as applied to training data
- Anonymisation or pseudonymisation measures applied before training
- Data subjects' jurisdiction — note that EU AI Act obligations stack on top of GDPR, not instead of it
If your engine uses collaborative filtering, document whether user-to-user similarity is computed on pseudonymised identifiers or on raw user IDs. If it uses content-based features derived from product images, note whether any computer-vision model was used to extract those features and whether that model itself requires documentation.
Tip: Attach or link your Data Protection Impact Assessment (DPIA) here if one exists. Auditors will expect to see the two documents cross-reference each other.
Expected result: A data provenance table that your Data Protection Officer can sign off on independently of the engineering team, and that survives a Subject Access Request without exposing model internals.
Step 5 — Capture model architecture and training methodology
You do not need to publish your model weights or expose proprietary architecture details publicly. The system card is an internal governance document (and a document you share with regulators on request); it is not a marketing brochure. Record:
- Architecture family (e.g., two-tower neural retrieval, matrix factorisation, transformer-based sequential model)
- Training data time window and approximate size (number of interactions, number of distinct users, number of catalogue items)
- Fine-tuning or re-ranking layers and their update cadence
- Hyperparameter selection methodology (grid search, Bayesian optimisation, manual)
- Third-party components — if you use a foundation model or an embedding service, name the provider and the version
Include a brief Model card lineage subsection listing every major version deployed to production in the past 12 months, with the date of deployment and the primary change in each version.
Expected result: An engineering-authored section that a non-engineer compliance reviewer can read to confirm that the organisation knows what it has deployed and can reproduce or audit the training process.
Step 6 — Record performance metrics and evaluation methodology
State your offline evaluation metrics, the dataset they were computed on, and the result. Then state your online evaluation methodology and any production metrics you track continuously. Be honest about what the metrics do and do not capture:
| Metric | Value | Dataset | Limitation |
|---|---|---|---|
| Precision@10 | — | Held-out test set, last training run | Does not capture catalogue diversity |
| Recall@50 | — | Held-out test set, last training run | Cold-start users excluded |
| Click-through rate (online) | — | A/B test, last deployment | Measures engagement, not satisfaction |
| Conversion rate lift (online) | — | A/B test, last deployment | Confounded by promotional calendar |
(Fill in your actual figures; leave the column blank in the template rather than inventing numbers.)
Add a Fairness and bias evaluation subsection. At minimum, report whether recommendation quality was evaluated separately for user segments defined by gender presentation, size range, and geographic market. If it was not, state that and record it as a known gap with a target date for remediation.
Expected result: A metrics section that gives an auditor confidence the system was evaluated before deployment, and that gives your product team a baseline for regression testing when the model is updated.
Step 7 — Define human oversight and incident response
The EU AI Act's transparency requirements are not satisfied by documentation alone; you must also demonstrate that a human can intervene when the system behaves unexpectedly. Document:
- Monitoring cadence: how often production outputs are sampled and reviewed (automated alerting thresholds, weekly human review, monthly deep-dive)
- Override mechanisms: how a merchandiser or compliance officer can suppress a recommendation, exclude a product category, or disable personalisation for a user segment
- Incident classification: what constitutes a reportable incident (e.g., systematic recommendation of out-of-stock items, evidence of discriminatory output patterns, a data breach affecting training data)
- Escalation path: named roles responsible at each stage, from first alert to regulatory notification if required
Warning: "Human in the loop" is not sufficient if the human has no practical ability to act on what they observe. Document the actual controls, not the aspiration.
Expected result: An oversight section that your engineering on-call team, your compliance officer, and your DPO have each reviewed and agreed reflects operational reality.
Step 8 — Version, sign off, and schedule reviews
A system card that is not maintained is worse than no system card: it creates a false record. Build the following into your engineering and compliance calendar:
- Trigger-based review: any significant model update, any change in data sources, any expansion to a new market or user population, or any incident classified above a defined severity threshold must trigger a card review within 30 days.
- Calendar-based review: at minimum annually, regardless of whether a trigger event occurred.
- Sign-off matrix: record who approved each version of the card (system owner, legal/compliance, DPO, engineering lead).
- Version history table: append a row to a version history table at the bottom of the document each time the card is updated.
Expected result: A living document with a clear audit trail, not a PDF filed and forgotten.
Troubleshooting common problems
"We use a vendor's recommendation API and don't have access to the model internals." Request the vendor's own system card or model card as a contractual deliverable. Document what you have received, note explicitly what you could not verify, and record the contractual obligation on the vendor to notify you of material model changes. You remain the deployer; the gap is a risk you must manage, not ignore.
"Our data science team updates the model frequently and the card goes out of date immediately." Treat the system card as code: store it in version control alongside the model artefacts, and add a card-update step to your model deployment pipeline. A card that is updated at deployment time is always current.
"Legal wants one document; engineering wants a technical spec; product wants a user-facing summary." Write one canonical system card and derive the other artefacts from it. The legal section (risk classification, GDPR basis, oversight mechanisms) and the technical section (architecture, metrics) can live in separate appendices of the same document. The user-facing transparency notice is a 100-word extract, not a separate research project.
"We're not sure whether our engine qualifies as limited-risk or something else." The Taylor Wessing analysis of how the EU AI Act applies to fashion is a useful starting point for mapping your specific use case to the Act's risk categories. Engage your legal team with a written description of every downstream decision the engine's output influences, not just the output itself.
"We heard the deadlines have shifted and we have more time." Revised timelines do create additional runway, but Morgan Lewis's analysis of changes to EU AI Act deadlines is explicit: this is additional preparation time, not a reprieve. Use it to produce documentation that is thorough rather than rushed.
What success looks like
A completed, compliant system card for your fashion recommendation engine will:
- Be readable by a non-technical regulator in under 30 minutes
- Contain no claims that cannot be verified against a linked internal artefact (training run log, DPIA, A/B test report)
- Be current: the version date matches the last model deployment
- Have named sign-offs from engineering, legal, and data protection
- Be stored somewhere your compliance team can retrieve it within 24 hours of a regulatory request
It will not be a marketing document. It will contain honest statements about limitations, gaps in evaluation, and open remediation items. That honesty is not a liability; it is evidence of a functioning governance process.
FAQ
Is a system card the same as a model card? The terms overlap but are not identical. A model card focuses on the ML model itself—architecture, training data, evaluation metrics. A system card covers the deployed system in context: the model plus the data pipeline, the user interface, the oversight mechanisms, and the legal classification. For EU AI Act purposes, you need the system-level view.
Does a limited-risk fashion recommendation engine need to register in the EU AI Act database? The public database requirement applies to high-risk AI systems. Limited-risk systems do not require registration, but you must be able to produce technical documentation on request from a national supervisory authority.
How often must we update the system card? The Act does not specify a fixed interval. Best practice is to update on any material change to the model, data sources, or deployment context, and to conduct a full review at least annually. Record both trigger-based and calendar-based reviews in a version history.
What happens if our recommendation engine is later reclassified as high-risk? You would need to conduct a conformity assessment, register the system, and implement the full set of high-risk obligations including logging, human oversight, and accuracy requirements. A well-maintained system card makes that transition significantly faster because the technical documentation is already structured.
Can we use the same system card for multiple recommendation engines? Only if the engines share the same architecture, data sources, intended purpose, and deployment context in every material respect. In practice, a size-recommendation engine and a product-discovery engine are different systems and need separate cards, even if they share infrastructure.
Further reading
- Fashion meets the AI Act — low-risk systems with important implications — Taylor Wessing
- Changes to EU AI Act Deadlines — Morgan Lewis
- Digital Product Passport: The next step for textiles and fashion — Recover™