Closed Models, Open Weights and Open Source in the Enterprise

When I discuss AI models with companies, product names such as GPT or Claude usually come up first. Open source and open weights are also regularly treated as interchangeable. That quickly leads to incorrect assumptions about hosting, control and data security.

Before choosing a specific model, a company needs to understand its own data flows: What data does the system process? Where is it transferred? Who operates the platform, and which laws apply to the company behind it? Only then can it make a sound decision between a closed model, open weights and a fully open system.

A model should not be selected by name. It needs to prove that it meets the requirements of the actual process.

Closed models: powerful and fully managed

With a closed model, its essential components remain under the provider’s control. Companies access it through an application or an API. The weights, training code and training data are not available for download.

OpenAI’s GPT models and Anthropic’s Claude models can deliver excellent results. The provider takes care of infrastructure, scaling, security updates and new model versions. This makes it possible to get started quickly. In return, the provider decides which versions, features, limits and prices apply. The model cannot be moved to the company’s own infrastructure.

Applications and APIs provide different levels of access. ChatGPT and Claude allow users to define instructions, projects or configured assistants. Through an API, a company can also set its own system instructions (prompts), configure parameters and process outputs in a structured way. The provider’s internal system context, the model weights and the trained alignment nevertheless remain outside the company’s control.

API usage is billed separately and based on consumption. Intensive use of powerful models can become considerably more expensive than a flat application subscription. Companies planning production workloads should therefore calculate with their actual inputs, outputs and context lengths. I examine why application subscriptions and API costs can differ so dramatically in “AI Subscriptions, Token Prices and API Costs: What Do You Get for Your Money?”.

For data security, the specific product matters more than the brand name. OpenAI does not use data from its business products and API for training by default. Anthropic makes a comparable commitment for Claude for Work and its API. These commitments are relevant. With a closed service, however, the customer still has to trust that the contractual and technical rules are being followed. It has no direct control over model operation or data processing.

Closed models are a sensible option when rapid adoption, high model quality and a fully managed service are the main priorities. Once personal data or sensitive company information is involved, the actual data flow, the operator and the legal jurisdiction must also become part of the architecture decision.

Open weights: more deployment options and more responsibility

The main advantage of open-weight models is the additional choice of where and how they can be operated. Combined with the model architecture and suitable inference software, a company can run the model independently of its original provider.

Possible deployment models include:

• the company’s own data centre,
• a private cloud,
• a European cloud provider,
• or a managed service operated by a specialised provider.

The data no longer has to be sent to the original model developer. Depending on the licence, the company can retain a specific model version, choose its inference software and quantisation method, and adapt the model.

Examples include DeepSeek-V3, models from the GLM family and OpenAI’s gpt-oss. They provide weights and additional technical artefacts. That does not automatically make them fully open models.

An open-weight model is not automatically uncensored or free from political bias. When self-hosting, the company controls the system prompt, chat template, inference parameters and any additional filters in its own runtime. The alignment learned during training remains embedded in the weights.

A recent EACL study using 36,000 test prompts found that both the origin of a model and the language of a request can influence political responses. Research on DeepSeek-R1 also documents omissions and refusals around politically sensitive topics related to China. This is not limited to Chinese models. Companies should therefore test bias and refusal behaviour with their own cases, in the languages and subject areas they will actually use.

The licence also needs to be checked before enterprise use. Weights and code can be subject to different terms. The ability to download a model does not automatically permit every form of commercial use, modification or redistribution.

Open weights consequently increases the company’s own responsibility. Anyone who self-hosts takes responsibility for updates, access control, monitoring, scaling, evaluation and secure operation. These models are a sensible choice when a company needs greater control over its data and operations and can take on the necessary technical responsibility.

Open source: transparency and practical verifiability

The term open source is often applied too generously to AI models. A public GitHub repository is not enough. A model’s behaviour emerges from its architecture, training data, data preparation, training process and the resulting weights.

The Open Source Initiative’s Open Source AI Definition 1.0 therefore requires more than downloadable weights. An open AI system must be available to use, study, modify and share. This requires access to the relevant code, model parameters and extensive information about the training data and how it was processed.

Complete training datasets may be unavailable for legal or privacy reasons. The documentation should nevertheless be detailed enough for specialists to investigate how the system was created and how it works.

The practical limitation remains: very few organisations could retrain a large model from scratch and verify that the published weights were actually produced by the process described. Transparency makes verification possible. It does not make that verification technically or economically feasible.

Open source is especially relevant when a company needs to understand, modify or independently develop a system over the long term. The additional insight is valuable. It does not replace an organisation’s own evaluation or the technical ability to examine the published information.

The model category changes hosting, control and operational responsibility. On its own, it guarantees neither data security nor compliance. Created with AI assistance.

Data security depends on the data flow

The openness of a model and the security of its processing are two separate questions. What matters is which data a system processes, how it moves through the architecture, where it is stored or logged, and who can access it.

A server in Frankfurt sounds reassuring at first. But how much European data sovereignty remains when the operator is subject to US law? Under certain conditions, the operator may have to disclose data, potentially without being allowed to notify the affected company.

The CLOUD Act does not override the GDPR. It can, however, create a legal conflict that a “GDPR-compliant” label alone does not resolve. When sensitive company data is involved, the provider, corporate structure, applicable jurisdiction and actual access options all need to be examined. The location of the data centre is only one part of the answer.

An open-weight model can run entirely at a European provider or on the company’s own infrastructure. The original developer then has no automatic access to inputs and outputs. The decisive party is the operator of the actual infrastructure: Who controls administrative access, logs, backups and data deletion?

For sensitive data, location, jurisdiction, access and contracts need to be assessed together. Created with AI assistance.

Self-hosting powerful models requires substantial computing capacity. Kimi K3 illustrates how quickly this can reach an entirely different scale: one possible configuration specifies 32 NVIDIA H100 GPUs. At publicly listed prices in July 2026, that amounts to roughly €1.7 million for the GPUs alone. Servers, networking, cooling and electricity are not included.

Smaller models and different levels of quantisation can reduce this requirement considerably. This raises another question: how does that reduction affect quality and results? I address the relationship between model size, quantisation, hardware, energy consumption and actual costs in a separate article.

The legal and technical details are covered in “GDPR and the CLOUD Act in the Age of AI: Data Security for Businesses”. It examines European hosting, US law, geopolitical risks and possible technical alternatives in greater depth.

Criteria for selecting an enterprise AI model

None of the three categories is universally best. A closed model can be the right choice when capability, rapid adoption and fully managed operation are the main priorities. Open weights provides more freedom in hosting and adaptation. An open-source system goes further in terms of transparency and modifiability.

Companies should therefore answer a set of concrete questions before selecting a model:

• What specific data does the system process?
• Where are inputs, context, outputs and logs transferred?
• Who operates the platform, and which legal jurisdiction applies to that company?
• Does the model need to run on the company’s own infrastructure or infrastructure controlled in Europe?
• How much control is needed over the model version, system instructions and additional filters?
• What do the licence and available technical artefacts permit in commercial use?
• Does the model meet or exceed the technical requirements in realistic tests using the company’s actual use cases?
• Who is responsible for security, updates, evaluation, cost control and a future change of provider?

My recommendation is not to begin model selection with a product name. First, determine what data is involved, how it moves through the system, where it is transferred and who operates the platform behind it. Then test the model with realistic tasks from its intended use. It needs to meet or exceed the required quality reliably. That does not automatically require the most expensive or most capable model.

Resource consumption also belongs in this decision. Large models require significant computing power and energy, whether they run in a company’s own data centre or at a cloud provider. AI can be used extensively when it genuinely improves quality, speed or economics. It should not be added to a process simply because it is technically possible.

More computing power only makes sense when it produces a better result.