How do I choose between cloud, on-premises and source code?

Three conditions: high data sensitivity (customer information, process formulations, financial detail) favours on-premises; ordinary sensitivity with a need to validate quickly favours metered cloud service; only take source code when you have in-house development and operations capability and a genuine long-term need to modify it. The three are matched to situations, not ranked — choose wrong and every later adjustment costs.

What does on-premises deployment cost?

Publicly listed appliances and machines for local inference range from a few hundred thousand to several million RMB, depending on compute scale, concurrency and whether training capability is needed. Beyond hardware, add facility conditions, power, operations staff and spares. What usually decides the question is data sensitivity and network conditions, not performance.

Does owning the source code give more freedom?

Not necessarily. With the source comes three responsibilities: tracking runtime and dependency upgrades yourself, running model updates and effect regression yourself, and having no vendor to fall back on when something breaks. Source handover is followed by quiet abandonment more often than expected — usually not because the code is unreadable but because nobody owns it long term.

Can the models be mixed?

Yes, and most real projects are. Tier the data first — keep sensitive detail on-premises, let aggregated conclusions and metrics use cloud services, or keep data access local while calling models on a metered basis. Decide by sensitivity level rather than fixing the delivery model first.

Manufacturing

AI agent delivery models: cloud, on-premises or source code

Updated 2026-10-17All figures from public sources

There are three main delivery models for AI agents: metered cloud service, on-premises deployment and source-code handover. They are not ranked but matched: data sensitivity decides where the data sits, in-house IT capability decides whether you take it over, and long-term cost expectations decide whether you buy a service or run your own. Settle those three and the model picks itself.

Comparison of the three delivery models

Model	What it is	Best for	The trade-off
Metered cloud service	Charged by usage; features and models maintained by the provider	Fast scenario validation, ordinary data sensitivity, volatile volumes	Data leaves the network; high steady usage needs the total cost worked out
On-premises deployment	Software and hardware run locally; data stays inside	Sensitive data, constrained network, steady volume	Large upfront spend; needs facilities and operations capacity
Source-code handover	Code and deployment method delivered for you to modify	In-house development and operations teams with a genuine long-term need to modify	Running, upgrades and regression testing all become yours

Three criteria

Data sensitivity. Customer lists, process formulations, financial detail and drawings carry high risk once they leave the network — favour on-premises. Generic internal policy documents and public material are fine on cloud services.
IT capability. Someone must own running and upgrading it long term. Without that, source code is not freedom but a liability.
Long-term cost expectations. With steady, high volume, three-to-five-year on-premises cost can be lower; with volatile volume and an unproven scenario, metered service is easier to stop.

Three hidden costs of taking the source code

Environment and dependencies. Operating systems, drivers and model runtimes all update. Fall behind and the code is there but will not run.
Model updates and effect regression. Output changes when models change; the evaluation set must be rerun to confirm nothing degraded, and that work is rarely planned for.
No fallback. When something fails, the people who can diagnose it turn out not to be in-house. Quiet abandonment within six months of source handover is not rare in public projects.

The conclusion is not "never take the source" but "confirm someone owns it long term first". If that does not hold, handing operations to the provider and writing down data ownership and definitions is the steadier choice.

On-premises: when it is worth it

On the public market, appliances and machines for local inference list from a few hundred thousand to several million RMB depending on compute scale and concurrency. Three signals justify it:

The data classification says core data may not leave the network — and that comes from compliance or a customer requirement, not internal preference.
Facilities and operations staff already exist, so nothing is built from scratch.
Steady long-term volume means three years of metered calling already exceeds the one-off and operational cost of local deployment.

Conversely, if the concern is merely a general unease about cloud data with no specific risk category named, on-premises is usually unnecessary — producing the data classification first is the better spend.

How to tier data: one table

Tiering need not be elaborate. Five columns suffice: data category, sensitivity, permitted location, who may access it, and logging requirements. Four levels are common: public (marketing material, general policies) may use public cloud; internal (production plans, non-sensitive reports) may use cloud services with account and permission controls; sensitive (customer lists, quotations, financial detail) prefers local or private environments; and core (process formulations, drawings, source code) stays local, with external help granted per request, logged and revoked afterwards. Once this table exists, the delivery model is largely settled — and the table can serve as a contract annex.

Hybrid: handle data by tier

Given the tiering above, most real projects end up hybrid: conclusions use cloud services, de-identified structured information (document numbers, quantity ranges, role codes) enters cloud analysis, and original documents, photographs and formulations stay local, viewed through a single-use authorisation when needed. That keeps neither everything locked inside the plant nor sensitive originals sent out. The mapping from tier to delivery model belongs in the plan as a table, not as a sentence saying data is secure.

Writing the model into the contract

Where data is stored, the network path, who may access it, and whether access is logged.
Ownership of running and upgrading: model versions, interface changes, operating system and dependency updates.
Exit: export format, account return, system shutdown and destruction of copies.

On data-access routes and acceptance criteria, see our enterprise AI agent deployment and custom delivery pages. If you are unsure which model fits, send us your data categories and concurrency (contact) and we will give a view, at no cost.

In one line: classify the data first, then choose the delivery model. Where the data sits, who runs it and how it ends — state those three and the model cannot be chosen wrongly.

Sources: Cailianshe and other outlets on publicly listed appliance price ranges and rising demand for private deployment; 21st Century Business Herald and Zhidx on changes to model service pricing; the Action Plan on "AI + Manufacturing" issued in December 2025 by the Ministry of Industry and Information Technology and seven other departments, on data and industry applications. The model comparison and contract points summarise public practice and state no specific vendor's commercial terms.

FAQ

How do I choose between cloud, on-premises and source code?: Three conditions: high data sensitivity (customer information, process formulations, financial detail) favours on-premises; ordinary sensitivity with a need to validate quickly favours metered cloud service; only take source code when you have in-house development and operations capability and a genuine long-term need to modify it. The three are matched to situations, not ranked — choose wrong and every later adjustment costs.
What does on-premises deployment cost?: Publicly listed appliances and machines for local inference range from a few hundred thousand to several million RMB, depending on compute scale, concurrency and whether training capability is needed. Beyond hardware, add facility conditions, power, operations staff and spares. What usually decides the question is data sensitivity and network conditions, not performance.
Does owning the source code give more freedom?: Not necessarily. With the source comes three responsibilities: tracking runtime and dependency upgrades yourself, running model updates and effect regression yourself, and having no vendor to fall back on when something breaks. Source handover is followed by quiet abandonment more often than expected — usually not because the code is unreadable but because nobody owns it long term.
Can the models be mixed?: Yes, and most real projects are. Tier the data first — keep sensitive detail on-premises, let aggregated conclusions and metrics use cloud services, or keep data access local while calling models on a metered basis. Decide by sensitivity level rather than fixing the delivery model first.