This is why companies are now relying on open-weight from China: The stealthy AI transformation

Xpert Pre-Release

Available in 27 languages 📢

Published on: August 25, 2026 / Updated on: August 25, 2026 – Author: Konrad Wolfenstein

The stealthy AI transformation: Why companies are now relying on open-weight from China

The stealthy AI transformation: Why companies are now relying on open-weight technology from China – Image: Xpert.Digital

Goodbye, US monopoly: Does Chinese AI offer more data security?

Cheaper and more powerful: How Chinese open-weight models are shaking up the market

Cost gap in AI: How companies can save massively through local operation

The dominance of US tech giants in the field of artificial intelligence long seemed unassailable – until now. With the rapid rise of extremely powerful Chinese open-weight models like GLM 5.2, a completely new strategic window has suddenly opened for European companies. These models promise the technical sophistication of industry leaders at a fraction of the cost and, moreover, can be run locally on a company's own servers, creating entirely new possibilities for data sovereignty. But what at first glance appears to be the perfect escape from dependence on expensive cloud services often turns out to be a highly complex undertaking in practice. From the deceptive ease of a quickly built pilot project to the strict regulatory requirements of the European AI Act and the multifaceted geopolitical dimension: the use of open-weight models is far more than just a technical update. Anyone who focuses solely on benchmark results and neglects organizational maturity is heading straight for a cost trap. The following article examines in detail why the move to local open-weight AI represents a tremendous opportunity – and how companies can avoid typical implementation mistakes from the outset.

A silent transformation with loud consequences

Few topics are currently occupying European IT departments as much as the question of whether to run high-performance Chinese language models in-house. With models like GLM 5.2 from Zhipu AI, released under an MIT license in June 2026, a technological window has opened that was unthinkable just a few years ago. Companies can now download a model with approximately 744 to 753 billion parameters, of which around 40 billion are actively used per query, free of charge and run it on their own or trusted infrastructure. The model has a context window of one million tokens and was specifically designed for multi-stage tasks, programming work, and the standalone use of tools. On benchmarks like SWE-bench Pro or Terminal-Bench 2.1, it achieves scores that put it close to top-tier closed models like GPT-5.5 or Claude Opus 4.8, at a fraction of the cost per processed token. This combination of technological maturity, open licensing, and low price fundamentally changes the calculations of many companies, because suddenly it is no longer just one American provider competing with the next, but a completely new geopolitical element is mixing into a technology architecture that was previously dominated by a few players.

From laboratory demonstrator to robust enterprise solution

The real challenge, however, lies not in the model itself, but in the gap between a successful test run and a production-ready system. An open-weight model is not a ready-made tool that can be taken out of the box and immediately deployed for business-critical applications. Simply uploading model weights to a GPU server and adding a basic chat interface creates a demonstrator, but not a production-ready platform. This confusion between technical feasibility and organizational maturity is one of the most common reasons why AI pilot projects in companies fail or remain stuck in the testing phase. Therefore, the implementation sequence should not begin with the model, but with the specific use case, followed by architecture, data connectivity, security model, evaluation, and ongoing operation. Adhering to this sequence avoids the most typical pitfalls: oversized infrastructure that no one actually needs, unclear responsibilities between IT, business units, and management, and AI agents with far more privileges than their actual task requires.

The smart approach: Start small to think big

Every successful implementation begins with selecting a task whose benefits can be quantified and whose risks can be limited. Processes with clear inputs, verifiable results, and manageable consequences in case of errors are suitable, such as searching technical maintenance documentation, automatically classifying internal requests, or supporting software code analysis. Less suitable for initial implementations are applications that directly control production facilities, trigger payment transactions, or help prepare personnel decisions. The basic rule is: the more difficult it is to verify a result afterward, the greater the risk of a pilot project that can no longer be controlled. Therefore, before any technical work even begins, each use case needs a concise but binding profile. What specific task is to be solved, what data may be used, how will the quality of the results be measured, what types of errors are acceptable, who bears the technical responsibility, and under what clearly defined conditions will operations be stopped immediately if necessary? Without this preliminary work, every subsequent technical detail becomes improvisation.

Size is not an end in itself when choosing a model

A common misconception is to automatically opt for the largest available model simply because it performs best in benchmarks. GLM 5.2 was specifically designed for long, multi-stage tasks, programming, and the use of external tools, but its size also places high demands on memory, graphics accelerators, and distributed computing. The vendor suggests, among other things, the vLLM and SGLang runtime environments as suitable technical foundations, as these frameworks can distribute the model across multiple GPUs and provide a programming interface compatible with common standards. However, for many everyday business tasks, such a flagship model is not the most economical choice. For simple classification, the extraction of structured information, or standardized responses, a significantly smaller and less expensive model is often perfectly adequate. Therefore, concrete tests with representative business data and hard metrics such as response time, throughput, memory requirements, and ongoing operating costs are crucial. While quantized, or computationally streamlined, model variants can significantly reduce hardware requirements, they may alter the quality or stability of the outputs in ways that are not always immediately apparent. Even a particularly long context window is no excuse for negligence: the more documents are crammed unfiltered into a single request, the greater the costs and latency, and the greater the risk that crucial information will simply get lost in the data deluge.

Architecture determines future viability

A robust enterprise architecture clearly separates at least five layers: the model server, the integration layer, access to enterprise knowledge, tool execution, and finally, the actual user application. The model should never be accessed directly and uncontrolled from any individual business application. Instead, a central integration layer handles tasks such as authentication, usage quotas, logging, standardized input templates, routing between different models, and enforcement of security rules. This intermediate layer makes it possible to replace an open-weight model later without having to rewrite all business applications. In practice, an internal service can then flexibly switch between GLM 5.2, a smaller locally operated model, and a shared cloud model, depending on the specific task, without end users even noticing. Equally important is the consistent separation of development, test, and production environments. Model weights, container images, and configuration files must never be transferred directly from a single developer's laptop to the production environment without verification. Every productive artifact must be versioned, tested, and distributed via a controlled release process, as is already standard practice in traditional software development.

Smartly integrate existing company knowledge instead of expensively retraining new skills

For the vast majority of use cases, Retrieval-Augmented Generation (RAG) is more practical than the complex and expensive process of retraining the model. In this method, the system first searches a shared knowledge base for relevant information and then passes only the text snippets actually found to the language model. This allows manuals, internal guidelines, technical specifications, or support tickets to be used without having to modify the underlying model itself. However, the quality of such a RAG application depends almost entirely on the careful preparation of the underlying documents. Outdated document versions, missing metadata, and poor content segmentation almost inevitably lead to unreliable and sometimes contradictory responses. Therefore, every document requires a clearly defined owner, binding validity information, and proper access rights. Under no circumstances should a model find and output information that the respective user is not authorized to view in the original source system. Answers should always cite their specific sources, as this significantly facilitates expert review and reveals whether a statement is actually based on reliable company knowledge or merely derived from general, unverifiable model parameters. For particularly sensitive use cases, the system can also be explicitly instructed not to provide a definitive answer without a suitable and verifiable source, but instead to openly acknowledge any uncertainty.

Our China expertise in business development, sales and marketing

Our China expertise in business development, sales and marketing - Image: Xpert.Digital

Industry focus areas: B2B, digitalization (from AI to XR), mechanical engineering, logistics, renewable energies and industry

More information here:

A thematic hub offering insights and expertise:

Knowledge platform covering global and regional economies, innovation and industry-specific trends
A collection of analyses, insights, and background information from our key areas of focus
A place for expertise and information on current developments in business and technology
A hub for companies seeking information on markets, digitalization, and industry innovations

EU AI Regulation and in-house operation: Why companies underestimate regulatory obligations

The geopolitical dimension of model choice

What appears in the previous sections to be a purely technical implementation problem has a second, far less technical dimension that has been neglected in many previous discussions. Chinese providers are subject to Chinese law, including national security legislation, which may require cooperation with government authorities under certain circumstances. This risk primarily concerns the use of a Chinese provider's cloud-based API, where requests and sometimes sensitive company data are processed via servers abroad. However, this risk shifts considerably when operating open weights locally on European infrastructure, because the actual data processing then takes place entirely within the company's own control. A Munich-based consultant at the consulting firm Arthur D. Little puts this idea into an interesting formula: A Chinese-developed open model operated on European infrastructure can, in some respects, even offer more operational sovereignty than a proprietary foreign model whose terms, prices, or availability can be changed at any time without the company's control. This perspective deserves serious consideration because it fundamentally challenges the widespread but simplistic equation "American equals secure, Chinese equals risky." At the same time, the question of long-term model maintenance remains open: Who guarantees that security gaps will be reliably closed in future versions, and how reliable is a provider whose economic and political environment differs fundamentally from the European legal and value system?

Regulatory framework as an underestimated cost factor

One aspect that is almost entirely absent from the original technical analysis, but is crucial for every European company, concerns the European legal framework for artificial intelligence. Since August 2, 2025, mandatory obligations have applied to providers of general-purpose AI models, and since August 2, 2026, the vast majority of the regulation has been fully applicable, including comprehensive requirements for high-risk systems and extensive transparency obligations. For a self-operated open-weight model, this means that the deploying company, in its role as the so-called operator, assumes additional responsibilities, such as human oversight, logging, and ensuring sufficient AI expertise among its own employees. Furthermore, models whose cumulative training effort exceeds the threshold of 10 to the power of 25 floating-point operations are considered systemic risk models and are subject to additional, significantly stricter obligations regarding testing, risk assessment, and cybersecurity. Anyone using a Chinese open-weight model must therefore fully comply with these European obligations themselves, regardless of the model's origin, because the foreign developer is not automatically subject to European law. This dual responsibility, both technical and regulatory, is often underestimated in initial pilot projects and can later prove to be a significant and costly backlog.

What is missing in the pure implementation logic

Looking at the eight-stage implementation logic as a whole, it's clear that while technically compelling, it's incomplete in several key dimensions. First, it lacks a clear discussion of the model's lifecycle beyond the initial deployment. Chinese vendors release their models at a rapid pace; GLM 5.2 itself is already the third major step within just a few months, and it's unclear how long older versions will receive security updates. A company investing today must consider how often a migration to a new model will be necessary and what ongoing costs this will incur. Second, it lacks a genuine cost-benefit analysis that goes beyond mere token pricing. Operating a model of this scale in-house requires significant investments in graphics processors, cooling, power supplies, and specialized personnel—investments that would be unnecessary with pure cloud usage. Whether in-house operation is economically viable depends heavily on actual usage volume and should be objectively calculated before any fundamental decision is made. Third, the question of liability in the event of a failure remains unresolved. If a self-operated model contributes to a consequential error in decision-making, the European legal framework generally places the responsibility on the company that deployed the model, not the model developer, whose license terms typically exclude any warranty. Fourth, there is no statement regarding the transparency of the training data and potential biases, which could be particularly relevant for models originating from China in the context of politically sensitive topics and should be carefully examined in internal company applications. Fifth, the question of organizational integration is addressed too briefly: A pilot project needs not only technical managers but also an authority that decides on the expansion, discontinuation, or further development of the project before uncontrolled growth of individual departmental solutions occurs—a phenomenon often referred to in practice as shadow AI.

Cost advantage with strategic pricing

One reason for the rapid spread of such models lies in the simple price comparison. Using the provider's API costs approximately $1.40 per million input tokens and $4.40 per million output tokens, which is roughly one-sixth the cost of comparable closed, high-end models. With full self-hosting on in-house hardware, these ongoing token costs are eliminated entirely, enabling significant savings with high usage volumes—but only if the initial infrastructure investments can actually be recouped. This cost structure explains why medium-sized businesses with limited IT budgets are increasingly interested in such open models, as they promise access to cutting-edge technology that was previously reserved for large technology corporations with corresponding budgets.

Open-weight models: Opportunity or implementation trap for companies?

The availability of powerful Chinese open-weight models is significantly changing the strategic options for European companies in artificial intelligence, but it doesn't automatically solve any of the fundamental implementation problems. Anyone who wants to use such a model wisely must take the technical architecture as seriously as the regulatory obligations, the geopolitical risks, and the simple business reality of limited resources. The real opportunity lies less in the model itself than in the discipline with which a company consistently navigates the entire path from a small, verifiable use case to robust, compliant, and economically viable continuous operation.

📈🚀 From visibility to trust 👀🤝 Your scalable path with Xpert.Digital

From visibility to trust: Your scalable path with Xpert.Digital - Image: Xpert.Digital

In industrial B2B, sustainable business relationships rarely emerge overnight. They develop step by step – through visibility, professional relevance, recurring touchpoints, and growing trust. Xpert.Digital's 4-stage model addresses precisely this: It offers a structured path that begins with a manageable entry point and can evolve into deeper collaboration in business development if needed.

Instead of relying on loud marketing promises, this model puts the relationship at the forefront. Companies start with clearly defined, easily calculable measures and then decide, based on their own experience, how far they want to expand the collaboration. A key factor for this undisturbed trust-building process: The platform completely avoids annoying advertising ads, so the editorial focus remains solely on the companies' expertise.

More information here: