Enterprise open source AI: choosing between open source and proprietary

Open source, open weights, proprietary: what do we actually mean?

An open-weight model, a so-called open-source model, and a proprietary model differ in what the vendor gives the company: the model itself, its training recipes, or only API access.

Family	What the company gets	Mode of use
Open weight	A downloadable model [35]	Running on personal or cloud infrastructure [35]
Open source	The weights and, generally, the training recipes [24]	Self-hosting and extensive customization [24]
Proprietary	Access without visibility into the underlying code [23]	API or SaaS [24]

Open weight: the model can be downloaded

An open-weight model can be downloaded and run on personal or cloud infrastructure [35]. In practice, the company can install it on its own servers and use it without going through an external provider's API [34].

Open source: the weights, and often the recipes

Open-source models provide their weights and, generally, their training recipes [24]. This openness makes self-hosting and extensive customization possible [24]. Meta, with Llama, and Mistral AI, with Mistral 7B and Mixtral, claim this category [37].

Proprietary: a single vendor keeps control

A proprietary model is controlled by a single company. It is generally accessed via an API, without the user being able to see or modify the underlying code [23]. Legal literature also refers to "closed" or proprietary models [9].

Two reading cautions

• The source's examples [24] are dated. It cites Llama 3, Mistral 7B and Qwen2 on the open side, and GPT-4o and Claude 3.5 on the proprietary side [24]. They illustrate the categories, not the current state of the offering.
• The "open source" label is a vendor claim [37], and real openness varies from one model to another. The section on licenses covers this point in detail.

What are the fundamental differences between the two families?

The two families differ in what the company can see, modify and host: proprietary models are used as ready-made services, while open-source models are deployed and adapted. An open-source model (Mistral 7B, Llama 3, Qwen2 for example) provides its weights, and generally its training recipes, freely available. Proprietary models (GPT-4o, Claude, Gemini) are offered as APIs or SaaS [24].

Criterion	Proprietary model	Open source / open-weight model
Transparency	Black box: the company sends its data via API, with no visibility into internal operation [21]. The underlying code can be neither seen nor modified [23].	Weights and, in general, training recipes accessible [24].
Customization	Limited without additional cost [25].	Extensive [24].
Standardization	Ready to use, minimal configuration [25].	Not specified by the sources consulted.
Hosting	API or SaaS [24].	Self-hosting possible [24].
Support	Commercial offerings bring simplicity and professional assistance [11].	Not specified by the sources consulted.

A reading to qualify

Several of the sources behind this table are agency or vendor blogs, not institutional texts or research papers. Their descriptions are consistent with one another, but they rest on no measurement. Two cells remain empty for lack of reliable information: standardization on the open-source side and support on the open-source side. These points should be verified with the provider or host you choose.

These differences structure the following sections: cost, data protection and vendor dependence depend on where the model runs and on what can be changed in it. Oupi lets you use both families within the same tool, which avoids deciding between them a priori (see the product).

Do open-weight models close the performance gap with proprietary models?

Yes, the gap is narrowing, but the file does not allow us to conclude that open-weight and proprietary models are equivalent in general. Three findings are established.

• The level reached: open-source models such as Meta's Llama-3 reach the state of the art set by proprietary models [1].
• Market weight: the rise of open-source models is a major factor in the generative AI market [9].
• The offering: Chinese players are making their models more accessible, sometimes all the way to open source [3].

Models you can host yourself

Llama (Meta) and Mistral are among the most widely used models in the category that can be installed on one's own servers, without going through an external provider's API [34]. Meta with Llama, and Mistral AI with Mistral 7B and Mixtral, claim to offer open-source models [37]. The term is debated: section 1 distinguishes open source from open weights, and section 6 addresses licenses.

What the file does not say

The claim about Llama-3 [1] is a qualitative observation. The file contains no quantified comparative benchmark. It therefore does not allow us to say, task by task (writing, extraction, code, French), which model wins or by what margin. "Reaching the state of the art" does not mean being equivalent everywhere, and a given model may lag on a specific use case.

The practical consequence: test on your own cases

The only defensible approach is to evaluate candidates from both families on your own data. A minimal protocol has a few steps:

1. build a set of real, representative requests, in the working language;
2. submit the same requests to a proprietary model and to an open-weight model;
3. have the responses rated by the relevant business teams;
4. record the observed latency and cost, since performance alone does not settle the question.

Oupi lets you use both model families within the same tool, which makes this kind of comparison on identical requests easier (see the product).

How much does an AI model really cost: API or self-hosting?

The cost of an AI model depends on the volume processed and the skills available internally: the sources do not agree on which option is cheapest.

Two opposing readings

According to Tizy, a self-hosted open-source model would cost 5 to 10 times less than a proprietary model accessed via API, at comparable volume [10]. This figure is cited from "Tech Insider," a secondary source. The file provides no calculation details, and Tizy is a commercial player: it should be treated with caution. Another piece of content qualifies its scope: open source offers significant savings mainly to companies with in-house technical expertise [13].

Other sources point out that the models are free to download, but that computing and storage remain the company's responsibility [11]. For standard use, a proprietary API, or an open-source model hosted by an inference provider, would often remain more economical and more reliable [22].

These positions do not directly contradict each other: they describe different situations (high volumes and a technical team on one side, everyday use on the other).

The cost items to include

Self-hosting requires accounting for [12]:

• suitable computing infrastructure;
• update management;
• performance monitoring;
• securing the AI pipeline.

The last three items consume team time, which does not appear in a per-token price.

Reasoning in full costs

Comparing the per-token price of an API with the cost of a server is not enough: one must reason in terms of full costs [40]. For an API, this means projecting actual consumption. For self-hosting, one adds up hardware or GPU rental, operations and skills.

What to take away

The sources in the file do not allow us to set a universal break-even point. Everything depends on volume and skills: self-hosting becomes relevant when volumes are high and the team knows how to operate it, while the API remains the simplest choice for standard use. To decide, calculate these two scenarios on your own volumes and use cases.

Open source or proprietary: which better protects data and sovereignty?

A model installed on one's own servers offers the most direct control over data. Open source alone does not guarantee sovereignty, however, and a proprietary model is not excluded on principle.

What self-hosting changes. A company can install an open-source model on its own servers and use it without going through an external provider's API [34]. This setup makes it possible to keep control of data [18]. With a proprietary model, the company sends its data via API and has no visibility into the model's internal operation [21].

Why sovereignty weighs in the choice. Digital sovereignty and compliance, reinforced by the European AI Act, push companies to seek solutions where they control their infrastructure and avoid dependence on American or Chinese giants [31]. This source is an agency blog: it describes a market trend, not a legal analysis.

The European model is not enough. Choosing a European model only addresses part of the question, since sovereignty also depends on other factors, such as hosting [22]. An open model operated by an inference provider therefore does not offer the same level of control as a model run on one's own infrastructure. It is necessary to verify where the model actually runs.

What the AI Act changes depending on the model family. Regulation (EU) 2024/1689, in force since August 1, 2024, introduces a distinction between open source and proprietary [26]. For purely internal use, without making the system available to outside users, the obligation indicated is limited to informing employees that they are interacting with an AI [26]. This example applies to tools such as ChatGPT, Claude or Mistral [26].

To verify: this claim comes from a blog that refers to service-public.fr [26]. Before any compliance decision, check it against the official text of the regulation.

A decision per use case. Confidentiality requirements vary depending on the use case. In Oupi, both model families can be used within the same tool (see the product), which avoids imposing a single choice on the entire company.

Does "open source" always mean free to use? What licenses say

No: "open source" alone does not tell you what the company is allowed to do with a model. The license determines this, and it varies from one model to another. According to an overview by Lebigdata, no single license prevails [33]:

License	Models cited
Apache 2.0	Gemma 4, Qwen3.8‑27B, Meta's Muse Glimmer [33]
MIT	DeepSeek, GLM‑5.2 [33]
Custom license	Qwen3.8‑2.4T‑A95B (Qwen3.8‑Max license) [33]
Proprietary tiered license	Kimi K3 [33]

Conditions can also change from one version to another. Meta chose Apache 2.0 for Muse Glimmer, moving away from its historical community license [33].

The "open source" label does not always settle the question. A research publication raises the question of when one can speak of an open-source license, including regarding Mistral 7B [2]. For a CIO, a vendor's marketing description therefore does not replace reading the license text.

An open project can also change course. A research publication notes that it may take a proprietary turn [4]. Keeping the license that applies to the version actually deployed is a prudent habit, since the conditions of a later version may differ.

OSAID-compliant models are presented as legally safer. According to ZDNET, they offer organizations transparency, legal certainty and full customization capabilities [20]. The criterion remains a starting filter, not a guarantee: it does not exempt you from checking the license of the model you select.

Conversely, so-called closed or proprietary models do not provide access to their source code [9]. Their terms of use are then governed by the vendor's contract.

Before any commercial use, read the model's license, version by version, and have your legal department validate its terms. Oupi lets you use both model families within the same tool, which makes comparison on your use cases easier (see the product). License verification remains your responsibility.

What is the vendor lock-in risk depending on the model choice?

Vendor lock-in risk exists with both model families, but it takes different forms. Lock-in refers to a situation where switching providers costs too much in time, development or organization.

The risk with proprietary models

Once a proprietary model is deeply embedded in workflows and APIs, it becomes hard to replace [7]. The deeper the integration, the more costly the exit. This concern matters most at the design stage.

The risk is particularly clear for SMEs: a company that builds an offering on a proprietary AI model exposes itself to this risk [3]. Companies whose activity relies on proprietary APIs should therefore assess this risk [5].

The commercial context also plays a role. According to an analysis by the French Competition Authority, some providers may encourage young AI companies to choose their services [6]. An attractive entry offer says nothing about the cost of a later switch.

The risk with open source and hybrid offerings

Choosing an open model does not eliminate all dependence. Some vendors combine proprietary AI components with open-source platforms. This approach facilitates deployment and provides solid technical support, but it creates dependence on the provider, both in terms of costs and in terms of real understanding of how the models work [27]. This source is a specialized trade publication, not a study, but the mechanism it describes is clear: the platform's "open source" label does not prevent lock-in through the components surrounding it.

Questions to ask before committing

• Can the model be replaced without rewriting workflows and API integrations?
• Which components of the offering remain proprietary, even on an open platform?
• What would an exit cost, in development as well as in internal skills?

Limiting lock-in comes down above all to keeping the ability to change models. Oupi lets you use both model families, open source and proprietary, within the same tool (see the product). Usage is therefore not tied to a single family.

How to decide in practice: proprietary, open weights or hybrid?

The choice between proprietary and open weights is neither binary nor permanent: it depends on the company's level of technological maturity and its needs [15][29]. A decision made today can therefore be revisited when volumes, skills or constraints change.

Decision grid

Situation	Suggested direction	Why
Standard use cases, rapid implementation	Proprietary model	Immediate and high-performing solution [29], simplified deployment [14]
In-house technical expertise, high volumes	Self-hosted open weights	Significant savings possible when expertise exists internally [13]
Mixed constraints (security, costs, sovereignty, compliance)	Hybrid approach	The choice depends on these criteria, and the hybrid approach is one of them [12]

The hybrid approach consists of distributing uses between the two families, task by task. It is also realistic on the supply side: some providers already offer both proprietary and open-source models [6].

A simple architecture to get started

A commercial source, gensai.ai, argues that a well-chosen open-weight model, a RAG on one's own documents and an application memory cover the vast majority of needs, for a fraction of the cost of proprietary development [30]. This claim comes from a player that sells this type of solution: it offers a starting point, not proof.

Comparing on your own use cases

Oupi lets you use both model families within the same tool. A team can thus submit the same use case to a proprietary model and to an open-weight model, without changing interface, and compare the results (see the product).

Testing on your real volumes

Generic figures do not replace measurement. Before deciding, it is recommended that you:

1. select two or three representative use cases;
2. run them through both families on volumes close to production;
3. compare response quality, full cost (including infrastructure and operating time) and implementation lead time;
4. revisit the decision at regular intervals, since the choice is not permanent [15].