Running an AI pilot without a governance framework is how fashion groups end up locked into underperforming vendors, exposed to regulatory risk, or unable to recover their own training data. This checklist gives procurement, legal, and technology decision-makers at mid-to-large fashion organisations a structured sequence to follow before a pilot contract is signed — covering vendor due diligence, data-processing agreements, success-metric definition, and exit clauses.
Key takeaways
- Establish oversight mechanisms and a documented governance plan before any AI pilot begins, not after.
- Data-processing agreements must specify data residency, sub-processor lists, and deletion timelines under GDPR before data is transferred to a vendor.
- Success metrics must be defined in the contract, not left to post-pilot negotiation.
- Exit clauses and data-portability rights are as important as the core commercial terms.
- EU model contractual clauses for AI procurement are now available in an updated form and should be used as a baseline for high-risk and non-high-risk deployments alike.
What do you need before starting this checklist?
Gather the following before working through the steps:
- A written statement of the pilot's business objective (e.g., AI-assisted tech pack generation, demand forecasting, size recommendation)
- A preliminary risk classification under the EU AI Act (high-risk vs. non-high-risk)
- A data inventory listing every dataset the vendor will access, process, or train on
- Nominated leads for procurement, legal/privacy, and technology
- Your organisation's standard vendor onboarding documentation
- Access to your PLM system's data export formats (relevant if the pilot touches product data held in platforms such as PTC FlexPLM or Centric PLM)
Step 1: Define the pilot scope and risk classification
Action: Write a one-page scope document and assign an EU AI Act risk tier.
Before any vendor conversation, your team must agree on exactly what the AI system will do, which data it will touch, and which human decisions it will inform or automate. Vague scope is the single most common cause of pilot failure: vendors optimise for what is measured, and if nothing is measured precisely, nothing improves.
Map the intended use case against the EU AI Act's risk categories. A system that influences hiring, creditworthiness, or access to essential services is high-risk; a system that generates pattern suggestions or drafts product descriptions is generally not. The classification determines which contractual clauses apply and how much oversight infrastructure you must build.
Note: The UK Government's AI procurement guidelines recommend establishing appropriate oversight mechanisms to allow scrutiny of AI systems throughout their lifecycle, and applying different considerations depending on the risk profile of the project. Even for low-risk pilots, document your rationale.
Expected result: A signed-off scope document with a risk tier, a named business owner, and a list of datasets in scope.
Step 2: Run structured vendor due diligence
Action: Issue a standardised questionnaire to every shortlisted vendor before any demo or commercial negotiation.
Vendor selection in fashion AI is frequently driven by demos rather than by documented capability. A structured questionnaire corrects this. Cover the following areas:
Technical architecture
- Where are models trained and hosted (region, cloud provider, shared vs. tenant-isolated infrastructure)?
- Does the vendor use your data to train shared models, or is training strictly per-tenant?
- What is the data retention period after contract termination?
- What output formats does the system produce, and are they interoperable with your existing PLM and CAD environment?
Security and compliance
- ISO 27001 or SOC 2 Type II certification — current, not lapsed?
- Sub-processor list: who else processes your data, and in which jurisdictions?
- Penetration testing cadence and most recent report date?
AI-specific governance
- Does the vendor maintain a model card or system card describing training data provenance, known limitations, and bias testing?
- How are model updates communicated, and do updates require your re-approval before deployment in your environment?
- What human-in-the-loop controls exist for outputs that inform business decisions?
Commercial sustainability
- What is the vendor's current customer base and renewal rate?
- Is the product roadmap publicly documented?
- What happens to your data and integrations if the vendor is acquired or ceases operations?
For PLM-integrated pilots, verify that the AI layer can read and write in the data formats your PLM uses natively. PTC FlexPLM and Centric PLM — now part of Dassault Systèmes — both expose APIs and standard export formats, but the specifics differ; confirm compatibility at this stage, not during integration.
Warning: Vendors that decline to answer sub-processor or data-residency questions before contract signature are a governance risk. Treat non-disclosure as a red flag, not a negotiating tactic.
Expected result: A completed due-diligence matrix for each vendor, with gaps flagged for legal review.
Step 3: Draft and negotiate the data-processing agreement
Action: Use the EU model contractual clauses as a baseline and customise for your data inventory.
The European Commission's community of practice on AI procurement released an updated set of EU AI model contractual clauses in early 2025, covering both high-risk and non-high-risk AI systems and translated into all EU languages. Use these as your starting template rather than accepting a vendor's standard terms.
Your data-processing agreement (DPA) must address:
- Lawful basis and purpose limitation: Under GDPR, data processed for AI training must have a documented lawful basis. If you are transferring product images, customer size data, or supplier records, each category needs its own basis.
- Data residency: Specify the permitted processing regions. For EU-based fashion groups, data leaving the EEA requires either an adequacy decision or standard contractual clauses.
- Sub-processors: The vendor must provide a complete list and notify you of any changes before they take effect, not after.
- Deletion and return: Define the timeline and format for data deletion or return at contract end. Insist on written confirmation of deletion.
- Audit rights: You must be able to verify compliance, either by direct audit or by a third-party audit report.
- Incident notification: Specify the notification window for security incidents (72 hours is the GDPR standard for controllers; align vendor obligations accordingly).
For AI-specific terms, the updated EU clauses include provisions on model transparency, human oversight, and documentation obligations that align with the EU AI Act's requirements for providers and deployers.
Note: Get commercial and legal advice early. As the UK Government AI Knowledge Hub notes, AI procurement is not exempt from procurement law, and data protection must be built into the process from the start, not retrofitted.
Expected result: A signed DPA that covers all datasets in scope, with sub-processor list attached and deletion obligations specified.
Step 4: Define success metrics and measurement protocol
Action: Write quantified success criteria into the pilot contract, with a defined measurement methodology.
A pilot without pre-agreed success criteria is a sales exercise, not an evaluation. Fashion AI pilots frequently fail to produce actionable conclusions because the metrics were left implicit. Make them explicit and contractual.
For each use case, define:
- Primary metric: The single number that determines whether the pilot succeeded (e.g., reduction in tech pack revision cycles, forecast accuracy at SKU level, pattern iteration time).
- Baseline: The current performance level against which improvement is measured. Establish this before the pilot begins, using your own historical data.
- Measurement methodology: Who measures, using which data, over which time window. Agree this with the vendor in writing.
- Secondary metrics: Operational indicators that provide context (user adoption rate, system uptime, integration error rate).
- Threshold for continuation: The minimum performance level required to proceed to a broader rollout. Below this threshold, the pilot ends without obligation.
Brands we speak to report that the most useful pilots run for a defined period — typically eight to sixteen weeks — with a mid-point review built in. A mid-point review lets you identify integration or data-quality problems early enough to correct them within the pilot window.
Warning: Avoid metrics that the vendor controls unilaterally. If the vendor defines what counts as a successful output, you have no independent basis for evaluation. Use your own operational data as the ground truth.
Expected result: A signed measurement protocol, with baseline figures recorded and a threshold for continuation agreed.
Step 5: Build in oversight mechanisms and a governance plan
Action: Appoint a pilot governance board and document the oversight process before go-live.
Oversight is not a post-pilot activity. You need a named governance structure in place from day one. At minimum:
- Pilot owner: A senior business stakeholder accountable for outcomes.
- Technical lead: Responsible for integration, data quality, and incident response.
- Privacy/legal lead: Monitors DPA compliance and handles any data incidents.
- Vendor contact: A named escalation point on the vendor side with authority to act.
Document the cadence for governance reviews (weekly during integration, fortnightly during live operation is a reasonable default). Record decisions and escalations. This documentation serves two purposes: it keeps the pilot on track, and it provides evidence of appropriate oversight if the system is later scrutinised under the EU AI Act or by a data protection authority.
For AI systems that inform business decisions — demand forecasting that affects buying volumes, for example — document the human review step explicitly. Who reviews the AI output before it is acted on? What is the escalation path if the output is anomalous?
Expected result: A governance plan document, signed by all leads, with review cadence and escalation paths defined.
Step 6: Negotiate exit clauses and data-portability rights
Action: Ensure the contract contains explicit exit rights, data-portability provisions, and a transition period.
Vendor lock-in is a structural risk in AI procurement. Once your product data, supplier records, or training datasets are inside a vendor's platform, extracting them can be technically and commercially difficult if exit rights are not pre-negotiated.
Your contract must include:
- Termination for convenience: The right to exit the contract with reasonable notice (typically 30–90 days) without cause, not only for breach.
- Data portability: The right to receive all your data — including any fine-tuned model weights trained on your data, if applicable — in a standard, machine-readable format within a defined period after termination.
- Transition assistance: An obligation on the vendor to provide reasonable support during migration to an alternative system, at no additional cost beyond standard rates.
- No post-termination use: An explicit prohibition on the vendor using your data after the contract ends, including for training shared models.
- Escrow or continuity provision: For mission-critical integrations, consider source-code escrow or a continuity plan in the event the vendor ceases operations.
Research and advisory organisations such as Gartner have consistently highlighted vendor lock-in as a top risk in enterprise AI adoption. Negotiate exit terms with the same rigour as commercial terms.
Expected result: A contract that includes termination for convenience, data-portability obligations with timelines, and transition assistance provisions.
Troubleshooting common issues
The vendor refuses to provide a sub-processor list. This is a GDPR compliance requirement for data processors, not a commercial preference. If a vendor cannot or will not provide a complete sub-processor list before contract signature, they cannot be your data processor. Escalate to legal and consider whether the vendor is suitable.
Baseline data is unavailable or inconsistent. If your organisation does not have clean historical data for the metric you want to improve, the pilot cannot produce a meaningful result. Spend two to four weeks cleaning and documenting baseline data before the pilot begins. This is not wasted time; it is a prerequisite.
The vendor's API does not align with your PLM's export format. This is a common integration failure point, particularly when AI tools need to read or write data held in PLM systems. Resolve format compatibility in a technical proof-of-concept before the formal pilot begins. Do not assume compatibility based on vendor marketing.
Legal review is taking longer than the pilot timeline. AI contracts are more complex than standard SaaS agreements. Build at least four to six weeks of legal review time into your project plan. Starting the DPA negotiation in parallel with the due-diligence phase, rather than sequentially, reduces elapsed time significantly.
The governance board is not meeting. If governance reviews are being skipped, the pilot is at risk. Make attendance mandatory for the pilot owner and technical lead. If a review must be skipped, require a written update instead. Undocumented pilots are ungovernable pilots.
What success looks like
At the end of a well-governed pilot, you should be able to answer the following questions with documented evidence:
- Did the AI system meet the pre-agreed success threshold on the primary metric?
- Were all data-processing obligations met, with no incidents or near-misses?
- Does the vendor's system integrate cleanly with your existing PLM and data environment?
- Is the vendor commercially and technically capable of supporting a broader rollout?
- What is the total cost of ownership at scale, including integration, training, and ongoing governance?
If you can answer all five with evidence, you have a defensible basis for a rollout decision. If you cannot, the pilot has produced useful information about what to fix before proceeding — which is also a valid outcome.
The McKinsey State of Fashion report identifies AI adoption as one of the defining strategic priorities for fashion organisations in the current period. Governance is what separates organisations that capture value from AI from those that absorb cost and risk without return.
FAQ
What is the EU AI Act risk classification for fashion AI tools? Most fashion AI tools — pattern generation, demand forecasting, product description drafting — fall outside the high-risk categories defined in the EU AI Act. High-risk applies to systems used in employment decisions, credit, or essential services. Confirm your classification with legal counsel before contracting.
Do we need a separate DPA for each AI vendor in a pilot? Yes. Each vendor that processes personal data on your behalf must have its own data-processing agreement. A single master services agreement does not substitute for a DPA if personal data is involved.
How long should a fashion AI pilot run? Eight to sixteen weeks is a practical range for most use cases. Shorter pilots rarely produce statistically meaningful results; longer pilots without a mid-point review accumulate risk without correction opportunities.
Can we use the EU model contractual clauses for non-EU vendors? Yes. The EU model AI contractual clauses are designed to be used in any procurement where the deployer is subject to EU law, regardless of where the vendor is headquartered. They are available in all EU languages and cover both high-risk and non-high-risk deployments.
What happens to our data if the AI vendor is acquired? Without an explicit contractual provision, an acquirer inherits the vendor's data-processing obligations but may change the sub-processor list, data residency, or product direction. Negotiate a change-of-control clause that gives you the right to terminate and retrieve your data if the vendor is acquired.