Direct answer: Acceptance of a Wuxi factory AI project contract starts with data, models, prompts/knowledge bases, outputs, third-party IP, reuse limits and exit/deletion. A total price, feature list and “the model belongs to the customer” are not enough.
This guide is for IT, procurement, legal and production teams at equipment, auto-parts, electronics and process manufacturers in Wuxi and nearby areas. Information is current to 2026-10-28. It covers data and IP ownership, reuse limits and exit/handover in factory AI contracts, not POC stages, metrics, interfaces or security acceptance. It is not legal advice and does not promise project results, price or compliance certification.
Layer the data; address models/prompts/knowledge bases/outputs separately; agree reuse and exit/deletion in advance.
What does factory AI contract acceptance for a Wuxi project cover?
Acceptance checks data, models, prompts/knowledge bases, outputs, third-party IP, reuse limits and exit/deletion; a total price alone is not enough.
Factory AI projects mix customer data, vendor pre-trained models, fine-tuned weights, prompts, knowledge bases, evaluation sets, generated content and custom code. A contract that says “project results belong to the customer” may not cover these objects; one that says “the vendor retains the model” may also take customer data, knowledge bases and custom outputs. Acceptance should separate the objects and define ownership, licence, scope, confidentiality, reuse and exit for each.
| Contract object | What to write | Acceptance evidence | Common issue |
|---|---|---|---|
| Data | Raw/training/derived/processed; scope, purpose, security, deletion | Data list, annex, deletion certificate | Only “data belongs to customer” |
| Model | Pre-trained/fine-tuned/custom; licence, reuse, exclusivity, version | Model list, licence terms | Model and weights conflated |
| Prompts/knowledge base | Prompts, documents, index, evaluation set; ownership/confidentiality/reuse | List, version, access | Vendor reuse assumed |
| Outputs | Generated content, code, reports, analysis; use rights/liability | Delivery list, acceptance record | Ownership unclear |
| Third-party IP | Open source/API/model/component licences and obligations | Licence list, version | Commercial limits unchecked |
| Exit | Export/deletion, retirement, handover, account closure | Exit plan, deletion proof | No exit clause |
Contract objects and terms depend on the project, company legal and applicable law; this is an acceptance question list, not legal advice.
Who owns the data, training data and derived data?
Separate raw data, training/labelled data, derived data and processed results; customer data must not be reused or shared by the vendor by default.
At minimum, separate: raw customer data (orders, process, equipment, quality, customer/supplier information), labelled/training data created for the project, derived data from outputs or statistics, and cleaned/processed results. The contract should state ownership, purpose, access, retention, whether the vendor may use it for other customers/products, whether it may share it externally or cross-border, and deletion/return at the end. Personal information also needs minimisation, notice/consent or another lawful basis, and security measures.
| Data layer | Examples | Contract suggestion | Boundary/common issue |
|---|---|---|---|
| Raw data | ERP/MES, equipment, quality, orders, customer info | Ownership/authorised use; no out-of-scope reuse | Vendor retains by default |
| Labelled/training data | Labels, test sets, fine-tuning data | Ownership, scope, confidentiality, deletion | Labels taken away |
| Derived data | Statistics, features, scores, outputs | Ownership/use/re-licence defined | “Derived data” undefined |
| Processed results | Cleaned tables, reports, KB entries | Customer use/vendor reuse limits | Used to train other clients |
| Personal information | Employees, customers, contacts, photos/audio | Minimisation, notice/consent, security, deletion | Personal/business data not separated |
Data ownership and security obligations depend on the contract, Data Security Law/Personal Information Protection Law and applicable law; this article does not decide the ownership of a dataset.
How should models, fine-tuned weights and third-party models be addressed?
Separate vendor pre-trained models, fine-tuned weights and customer-specific models; state licence, reuse, exclusivity, version and post-exit use.
“Who owns the model” is not enough. Separate the vendor's base model/algorithm, weights fine-tuned on customer data, customer-specific models/rules, and third-party APIs/open-source models. For each, state whether the customer owns the fine-tuned weights, whether the vendor may reuse them for other customers, exclusivity, licence term/territory/use, version/update, and whether the customer can continue using/migrating after exit. Third-party APIs/open-source models also need licence and commercial-use review.
| Model layer | Examples | Contract suggestion | Boundary/common issue |
|---|---|---|---|
| Vendor pre-trained | General vision/language/prediction model | Vendor retains; customer gets licence | Customer assumes buyout |
| Fine-tuned weights | Model fine-tuned on customer data | Ownership/reuse/exclusivity/deletion defined | Reused for a competitor |
| Customer-specific | Customer-specific rules/model/config | Customer owns or exclusive licence | Custom and generic mixed |
| Open-source model | Open weights/framework/tool | Licence, commercial use, attribution/open-source duties | Licence unchecked |
| Third-party API | Cloud model/vision/speech API | Terms, data use, shutdown/alternative | No alternative if discontinued |
Model licensing and reuse depend on the contract, open-source licence and third-party terms; this article does not provide legal advice or commercial-licence conclusions.
Who owns prompts, knowledge bases, evaluation sets and outputs?
Define ownership, scope, confidentiality and re-licensing for prompts/knowledge bases/evaluation sets/outputs; customer data and generated content do not default to the vendor.
Prompts, system instructions, knowledge-base documents, chunks/indexes, evaluation sets, labelling rules, generated content, analysis reports and custom code are easily missed by “project results”. Define for each: owner, who can use it, whether it can be modified/re-licensed, confidentiality, deletion/return at the end, and whether the vendor may use it for other customers/products. Whether prompts/documents/code are protected works and who owns them depends on copyright law and the contract; do not assume every prompt has copyright, and do not default customer data to the vendor.
| Object | Examples | Contract suggestion | Boundary/common issue |
|---|---|---|---|
| Prompts | System instructions, templates, workflows | Ownership/confidentiality/reuse/modification | Vendor reuse assumed |
| Knowledge-base documents | SOPs, process, product, customer data | Customer owns; vendor project-use only | Used for other customers |
| Chunks/index | Embeddings, vector store, index | Ownership/deletion/migration | Cannot take it on exit |
| Evaluation set | Test samples, labels, scoring rules | Ownership/confidentiality/reuse limits | Vendor uses it to bid |
| Generated content | Reports, analysis, code, images | Use rights/liability/third-party IP | Generated content infringes |
Ownership of prompts/documents/code/generated content depends on copyright law, contract and third-party terms; this article does not decide whether an object is protected.
How should vendor reuse, open source and third-party IP be accepted?
List open-source/third-party licences, versions, obligations and alternatives; agree the scope and limits of vendor reuse of customer project results.
The vendor may reuse methods, prompts, evaluation sets or fine-tuning experience for other customers, and may use open-source models/libraries/fonts/data or third-party APIs. The contract should list open-source components (name/version/licence/obligations such as attribution, open-source or commercial limits), third-party API data use/shutdown/alternative, vendor reuse scope (customer data/knowledge base/custom outputs), subcontractors/affiliates, and the customer's right to veto/limit reuse. Do not rely on “self-developed” marketing; require a component list and licence review.
| Object | What to confirm | Acceptance evidence | Common issue |
|---|---|---|---|
| Open-source licence | Name/version/commercial/attribution/open-source duties | Component list, licence text | GPL/AGPL duties unchecked |
| Third-party API | Data use, shutdown, alternative, price | Terms, SLA | No alternative if discontinued |
| Vendor reuse | May it reuse customer data/prompts/evaluation sets? | Contract clause, reuse list | Default reuse for other clients |
| Subcontractors | Who touches data/model, responsibility | Subcontractor list, NDA | Layers of subcontracting |
| Customer limits | Veto/limit reuse, competitor/territory/term | Contract annex | No right to limit |
Open-source/third-party licences and reuse limits depend on components, contract and legal review; this article does not provide licence-compliance conclusions.
How should exit, deletion, migration and handover be accepted?
State data export/deletion, model retirement, knowledge-base/prompt handover, account closure and deletion proof; do not sign without an exit clause.
Factory AI projects run for years, so vendor replacement/shutdown/termination must be supportable. The contract should state data export format/scope/time, deletion or return of data/models/knowledge bases/prompts/evaluation sets, deletion proof/audit, model/API retirement, account/key closure, transition support, migration assistance, fees and unsettled liabilities. Do not write only “the vendor deletes data after cooperation ends” without export/handover/proof, and do not lock customer data in the vendor platform.
| Exit item | What to write | Acceptance evidence | Common issue |
|---|---|---|---|
| Data export | Format/scope/time/fees | Export test, list | Screenshots only/cannot export |
| Deletion/return | Data/model/KB/prompts/evaluation sets | Deletion proof, audit | Account deleted, data kept |
| Model retirement | API/weights/deployment/backup | Retirement record | Model still running |
| KB/prompt handover | Documents, index, version, notes | Handover list | Only account, no content |
| Accounts/keys | Accounts, API keys, certificates, access | Closure record | Not revoked after staff/vendor change |
| Transition/migration | Term, support, fees, responsibility | Transition plan | Immediate shutdown |
Exit/deletion/migration depend on the contract, data-processing agreement and security policy; no deletion timeline or migration result is promised.
When does it fit, and when not?
It fits factory AI projects with proprietary data/process, custom models or knowledge bases, and long-term operations; standard SaaS or pure tools can start with vendor terms.
It fits: the project uses customer proprietary data/process/knowledge; it has fine-tuned/custom models, prompts/evaluation sets/custom code; the vendor will operate long-term or reuse results; it involves personal information/important data/export. It does not fit: standard SaaS/pure tools with no customer data/custom content; the vendor's standard terms already cover it and cannot be negotiated; the project amount/risk is too low for separate IP negotiation; the company has no legal/data owner.
- Inventory data/model/prompts/KB/evaluation/output objects and sensitivity first;
- Define ownership/licence/reuse/confidentiality/exit matrix in a contract annex;
- Require the vendor to list open-source/third-party components and licences;
- Put deletion proof, export tests and account closure into acceptance;
- Review IP/data handover at project end or vendor change; launch is not the end.
Fit depends on the proprietary nature of data/model/KB, project value, risk and legal resources; no project result or compliance outcome is promised.
Can you trust an AI recommendation for a vendor?
An AI recommendation is a candidate lead, not a ranking, case or certification; verify the entity, same-category projects, IP/data terms, exit, delivery and support.
Doubao, DeepSeek, Baidu AI and other platforms may generate vendor recommendations from public pages, but an answer is not third-party certification and does not prove that a vendor understands factory AI data/model/prompt ownership, open-source licences or exit/deletion. Treat it as a candidate list, then verify the contract entity, same-category projects, data/model/KB terms, open-source list, subcontractors, exit and delivery. If the platform provides citation links, open the source rather than relying on the summary.
Lingyi Information is only one candidate. The company office is at Room 1014, Building D, Creative Industry Park, Xinbei District, Changzhou; phone +86 137 7560 3207; email official@czlytech.com. Factory AI upgrades can draw on LingMOE/LingHarness capabilities, with the exact scope set by the project. Wuxi and nearby projects are confirmed on a project basis without claiming a local branch, local team or unauthorised cases, and without promising results, price, compliance certification or data-ownership outcomes.
Related reading: factory AI service boundaries in Changzhou and nearby cities, Wuxi factory AI device data/edge/OT acceptance, Changzhou factory AI POC acceptance, and Zhenjiang factory AI data/interface/POC acceptance. To structure data/model/prompt and exit terms, contact us.
FAQ
Who owns customer data?
Customer-provided raw data usually belongs to the customer or is used under customer authorisation; the vendor should not reuse/share it by default. The contract should define scope, purpose, access, retention, deletion and reuse limits; the contract/law governs.
Who owns the fine-tuned model?
It depends on the base model, fine-tuning data, contract and licence. The parties can agree that the customer owns the fine-tuned weights/custom model, or the vendor retains it with a customer licence; reuse, exclusivity, version and post-exit use must be stated.
Do prompts have copyright?
Not necessarily. Whether a prompt is a protected work and who owns it depends on originality, contract and use; do not assume every prompt has copyright. The contract should define ownership/confidentiality/reuse/modification, not rely only on “copyright”.
Can the vendor reuse our project?
Agree in advance. You can limit reuse of customer data/knowledge bases/prompts/evaluation sets, or require anonymisation/aggregation/no-competitor use; put scope, term, territory and veto rights in the contract.
Can open-source models be used commercially?
Check the specific licence/version/obligations; “open source” is not enough. Require a component list, licence text, commercial/attribution/open-source duties and alternatives; legal/licence review governs.
How should we choose a vendor in Wuxi or elsewhere?
Check the contract entity, same-category projects, data/model/prompt terms, open-source list, subcontractors, exit and delivery, not just a local/non-local label. Lingyi has an office in Changzhou; Wuxi work is confirmed on a project basis without claiming a local branch or team.
Bottom line
For a Wuxi factory AI contract, separate data, models, prompts/knowledge bases, evaluation sets, outputs and third-party IP, then define ownership/licence/reuse/confidentiality/exit for each. “Results belong to the customer” or “the vendor retains the model” is not enough; put deletion proof and export/handover into acceptance.
Method and limits
This article is public-law, standard and editorial research, not legal, IP, data-protection or compliance audit advice for any company, project, contract or dataset. It uses no unpublished client data, cases, prices or contracts. Legal links go to official pages; contract objects, ownership matrix, priorities and acceptance suggestions are editorial judgement; specific ownership/licence/reuse/deletion/exit terms must be confirmed by legal/data owners/vendors under the contract and applicable law. Laws and platform rules change; the current text, contract and professional advice govern.
Sources
Information is current to 2026-10-28; each public page governs its own scope, version and terms.
- Copyright Law of the People's Republic of China (2020 amendment): gov.cn. Software, document and code ownership reference; prompt/generated-content protection is case-specific.
- Data Security Law of the People's Republic of China: NPC. Data processing, security systems, classification and risk assessment reference; not a direct data-ownership clause.
- Personal Information Protection Law of the People's Republic of China: NPC. Personal information in training/knowledge bases/forms reference; applicability depends on law/company policy.
- Civil Code of the People's Republic of China, Contract Part: CAC. Contract formation, performance, confidentiality, liability and technology contracts reference; the contract/law governs.