On-prem AI
AI inside the client's own ecosystem
When is sovereign or air-gapped development worth it, and what does it look like in practice?
August 18, 2026
5-minute read
At Gloster, we’ve been modernizing legacy systems for years, and over the past six months, we’ve started using aAgentic AI tools for this purpose as well. The difference is noticeable—we’re able to understand and rewrite an old, often undocumented codebase much more quickly this way. And human oversight and verification ensure our usual high quality.
There’s just one question that every serious client eventually asks: Can the code actually leave the client’s own environment? In most cases, the answer is yes, and in those cases, the cloud is the perfect solution. But not everywhere. Where it isn’t, that’s where local AI comes into play.
By 2026, this question will no longer be purely theoretical. The European debate on data sovereignty has even reached procurement forms; an increasing number of tenders include a separate line item specifying where the model runs, who has access to the code, and what happens to the prompts.
Many people think there are only two options: either cloud-based or on-premises. In reality, there’s a spectrum between them. It helps to break the system down into two layers.
The harness, or the developer experience. This is what the developer actually works with: slash commands, agent modes, diffs, tools, and MCP integration. It can be a custom-built solution or an off-the-shelf product.
The model layer—that is, the language model itself. This is what provides the answer, and from a data protection perspective, this is the layer that really matters, because it determines where it runs.
The point is that the harness can remain largely the same, while we move the model behind it to a different place. This creates a spectrum. At one end is quality, and at the other are control and isolation:
You don't have to give up everything at once; you should always look for the security level that matches the client's risk profile. The stricter the security level you choose, the greater the compromise you'll have to make on the development side, and the steeper the price increase will be.
For most customers, a managed cloud or Azure PaaS is more than enough. It offers EU data residency, contractual guarantees, auditability, and, on top of that, full access to cutting-edge models. There’s no reason to go down a more expensive, more complicated path.
However, there are a few sectors where this is not a viable option. In those sectors, isolation is not an extra but a basic requirement:
For them, the question isn't which model is best, but whether AI can be integrated into the process at all without data leaks. In such cases, a local solution—even one that is completely air-gapped—is the only viable option.
Technological considerations rarely tip the scales when choosing between options. There are five questions worth putting on the table before the technical discussion begins, because the answers usually quickly rule out two or three options.
If the answer to all five questions is “permissive,” then the first or second level is the right choice, and any further steps would be an unnecessary expense. If the answer to at least two of them is “stricter,” then it is worth seriously considering the third and fourth levels.
The statement that the model must be run locally because of DORA and NIS2 is not true in this form. However, there are four specific, concrete references to support it.
Chapter V of the GDPR and the CLOUD Act. If, in principle, an entity subject to a non-EU jurisdiction can access the data, a transfer impact assessment is required even if the data is physically located in an EU data center. In practice, this is the strongest argument in favor of a sovereign or on-premises approach.
NIS2 and the supply chain. Article 21 makes supply chain security a mandatory area of risk management and treats foreign government influence as a risk factor. From this perspective, a supplier of an AI code assistant is just as much a supplier as anyone else.
Article 28 of DORA. Financial institutions must be able to present a documented, tested exit plan for every critical ICT service provider. It poses a risk if the development process is tightly coupled to a service provider’s proprietary, closed API. An open, portable model layer, on the other hand, reduces precisely this exposure.
The AI Act. The transparency requirements—that is, the provisions of Article 50—will take effect on August 2, 2026. However, the Digital Omnibus has postponed the requirements for high-risk systems covered by Annex III until December 2, 2027.
Furthermore, a code assistant designed to support in-house development is generally not, in and of itself, a high-risk system. Therefore, the AI Act should not be the basis for decision-making when the GDPR and the contractual chain are actually the determining factors.
In addition to these, there are also industry-specific regulations, which are often even stricter. Examples include the regulation of access to validated systems in the pharmaceutical industry, and the use of air gaps in the defense industry and in the handling of classified data.
This is the aspect that’s rarely mentioned, even though in practice this is usually where a project goes wrong. Just because the model runs locally doesn’t mean the system is isolated. The harness can still leak data, and from a liability standpoint, this isn’t any better.
Five points we need to review for every implementation of this kind:
That is why we say that when implementing an air-gapped system, it is not the model but the entire chain that must be audited.
Let’s not sugarcoat it: the on-premises, open-source models available today don’t measure up to the Frontier models. An air-gapped environment will never be as seamless as a cloud-based solution, and it’s also significantly more expensive than a simple Claude subscription. We’re upfront with our clients about this.
However, two factors complicate the picture.
Technology is advancing, and the gap is closing. What matters is what we’re comparing it to. By mid-2026, the best open-source models will indeed perform at around 80% on the SWE-bench Verified benchmark. However, these are MoE models on the order of trillions. Running them requires infrastructure ranging from 300–400 GB of VRAM to full GPU servers, so they fall into the data center category just like frontier models. Models that are available at a realistic price and fit into a server with one or two graphics cards currently perform at around 65–72%. This is the relevant figure for on-premises development.
From a hardware perspective, the orders of magnitude look like this. A 24 GB card can run a code model of around 27–30B with 4-bit quantization—that’s the entry level. On a 48 GB configuration, a dense model of around 30B runs comfortably with real-world context sizes. However, the best standalone models currently available—such as Qwen3-Coder or the newer versions of Devstral—require the 96 GB category, because the long context of agentic work and parallel processing consume significant amounts of memory in addition to the weights.
The rule of thumb: On FP16, you need roughly 2 GB of VRAM per billion parameters; on 4-bit, 0.5 GB; and add another 30–100% for context and parallel processing. A 96 GB machine can support roughly 5–15 developers, but this depends heavily on model size, response time requirements, and—most importantly—memory bandwidth, so it should always be measured, not estimated.
The methodology is at least as valuable as the model itself. Human oversight, well-structured agent processes, and our modernization framework provide significant value regardless of the raw capabilities of the model. When mapping an undocumented codebase, the bottleneck isn’t the model’s capabilities, but rather the order in which we run the process, the context in which we do so, and the checkpoints we use along the way.
Most calculations go wrong here because they only consider the price of the GPU. The total cost over three years includes not only the server itself but also power supply and cooling, networking, storage, spare parts, and—above all—a person who understands the system and maintains it. For a machine with one or two GPUs serving a development team, the cost of a part-time operator over three years will exceed the cost of the hardware itself. For larger clusters with multiple GPUs, this ratio is reversed.
The second, even more important factor is utilization. A dedicated GPU is only cost-effective if it’s actually working. The break-even point is roughly at 50–80% utilization, depending on which cloud service we’re comparing it to. In practice, most organizations operate at a much lower rate than that, and the workload of a ten-person development team naturally fluctuates.
So the bottom line is this: on-premises and air-gapped AI aren’t about cost optimization—they’re about compliance costs. Anyone who brings the model in-house just to save money will almost certainly end up worse off. However, for those who do so because the code cannot leave its environment, this is the only viable option, and from that point on, the only question is how to keep these costs at a reasonable level.
In practice, it is rare to have to choose just one approach. The best results are usually achieved by combining approaches, based on two different lines of reasoning.
Separation based on sensitivity. Not all codebases are equally sensitive. The code for classified or regulated systems remains on-premises, while internal tools, the frontend, documentation, and tests can be moved to the cloud using the frontier model. This is where the separation of the harness and the model comes in handy, because the developer uses the same tool—only the endpoint behind it is different.
Breakdown by task type. The daily internal cycle accounts for most of the work: additions, minor refactoring, writing tests, and explaining code. Local models are still more than adequate for this. For the challenging 5%—the major architectural overhauls—there’s the frontier model, where regulations permit it.
This also has an added benefit: the entire development process does not rely on a single service provider, which is an argument in itself for clients subject to DORA.
We are constantly on the lookout for the right on-premise development tools, and we’ve already completed several proofs of concept. The most recent one was a tool called Shaide from Axemt, which we tested on an internal, greenfield Python project. We were curious to see how closely it aligned with our usual Claude Code workflow.
We evaluate such tools based on six criteria: installation and setup, usability of agent modes, context management in larger codebases, quality of generated diffs, stability during longer tasks, and operability on our own infrastructure. This round addressed the first two criteria and the quality of the diffs; we left the rest for the next step.
Installation is very simple. The VS Code extension is available on the Marketplace, and the tool itself guided me through the configuration process. The setup went smoothly.
In terms of usability, the experience is surprisingly similar to Claude Code: It has slash commands just like Claude Code, and the output looks similar as well. It offers plenty of tools for daily coding, allows you to save multiple agent modes (such as “plan” and “coding”), and the interface can be customized for individual users and projects.
First impressions are good. It seems like a viable alternative precisely in situations where we can’t use frontier models from the cloud. The next step is a more thorough technical evaluation on our own, managed GPU server, using a specific model variant, a real legacy codebase, measured response times, and parallel use by multiple developers. We’ll cover this in more detail in a future post.
Local AI is not a replacement for frontier models, but rather a complement to them. It provides real value in situations where data, source code, or the regulatory environment do not permit the use of cloud-based models. In such cases, however, it is the only viable option.
The decision is not a choice between two options, but between four levels. A locally running model does not in itself constitute isolation; one must consider the entire chain. And isolation is a cost, not a savings.
Our goal is not to use local AI everywhere, but rather to be able to provide solutions across the entire spectrum and to have a proven track record even in areas where cutting-edge models may not even be an option. We test these solutions on our own infrastructure so that we can offer our clients proven solutions rather than just promises.
If the answer to at least two of the five questions is “stricter,” it’s worth discussing the details. Based on a brief assessment, we can determine which tier is right for the organization, what that means in terms of cost and developer experience, and what a two-week PoC would look like.
At Gloster we have spent years modernising legacy systems, and over the past six months we have started bringing agentic AI tools into that work. The difference is tangible: an old, often undocumented codebase becomes far easier to understand and rewrite. The human oversight and review still guarantee the quality we and our clients are used to.
There is one question, though, that comes up sooner or later with every serious client: is the code even allowed to leave the client's own environment? In most places the answer is yes, and then the cloud is a perfect fit. But not everywhere. Where it is not, local AI comes into play.
In 2026 this is no longer a theoretical question. The European data-sovereignty debate has reached the procurement forms: more and more tenders now carry a separate line asking where the model runs, who can access the code, and what happens to the prompts.
Many people think of it as a binary: either cloud or local. In reality there is a spectrum in between. It helps to split the system into two layers.
The harness, meaning the developer experience. This is what the developer actually works with: slash commands, agent modes, diffs, tools, MCP integration. It can be built in-house or bought off the shelf.
The model layer, meaning the language model itself. The desicion depends on this, and from a data-protection point of view this is the layer that really matters, because it decides where things run.
The key point is that the harness can stay roughly the same while you move the model behind it somewhere else. That draws out a scale. At one end sits quality, at the other control and isolation:
You do not have to give everything up at once. The aim is always to find the gradation that fits the client's risk profile. The stricter the gradation you choose, the bigger the compromise you have to make on the developer side, and the more steeply the price climbs.
For most clients, managed cloud or Azure PaaS is more than enough. EU data residency, contractual guarantees, auditability, and alongside them the full knowledge of the frontier models. There is no reason to head in a more expensive, more complicated direction.
There are, however, a few sectors where that route is closed. For them, isolation is not an extra option but a baseline requirement:
For them the question is not which model is best, but whether AI can enter the process at all without the data leaking out. In that case a local, even fully air-gapped solution is the only one worth considering.
Between the gradations, a technical argument rarely decides the matter. There are five questions worth putting on the table before the technical debate begins, because the answers usually rule out two or three options quickly.
If the answer to all five questions is permissive, the first or second gradation is the right call, and anything beyond that is wasted cost. If at least two of them are stricter, then the third and fourth gradations are worth examining seriously.
The claim that DORA and NIS2 require you to run the model locally is, to put like that, simply not true. Behind it, though, sit four concrete, tangible references.
Chapter V of the GDPR and the CLOUD Act. If the data could in principle be accessed by a party under a non-EU jurisdiction, a transfer impact assessment is needed even when the data physically sits in an EU data centre. In practice this is the strongest argument for the sovereign or on-prem direction.
NIS2 and the supply chain. Article 21 makes supply-chain security a mandatory area of risk management, and it also treats foreign government influence as a risk factor. From this point of view, a supplier of an AI code assistant is a supplier like any other.
Article 28 of DORA. For a financial player, a documented, tested exit plan must be available for every critical ICT provider. It is a risk if the development process is tightly built on a provider's own, closed API. An open-weight, portable model layer, by contrast, is precisely what reduces that exposure.
The AI Act. The transparency obligations that take effect from 2 August 2026, that is the requirements of Article 50, are real. The obligations for high-risk systems falling under Annex III, however, were pushed by the Digital Omnibus to 2 December 2027.
On top of that, a code assistant that supports internal development is generally not in itself a high-risk system. So do not make the AI Act your point of reference when it is really the GDPR and the contractual chain that decide.
Beyond these comes the sector-specific rules too, which are often stricter. In pharmaceuticals that means the regulation of access to validated systems, and in the defence sector and classified data handlers, the air gap.
This gets talked about least of all, yet in practice it is usually where a project fails. The fact that the model runs locally does not make the system isolated. The harness can just as easily let data out, and from a liability point of view that is no better at all.
Five points to work through at every such rollout:
That is why we say that at an air-gapped rollout you audit not the model but the whole chain.
We will not dress it up: the locally running, open models today do not reach the level of the frontier models. An air-gapped environment will never be as smooth as a cloud solution, and it is also considerably more expensive than a simple Claude subscription. We tell the client that openly too.
Two things, though, add nuance to the picture.
The technology is advancing, the gap is closing. What matters is only what you compare with what. The best open models in mid-2026 do indeed score around 80% on SWE-bench Verified. But these are trillion-parameter MoE models. Serving them requires infrastructure ranging from 300–400 GB of VRAM to several full GPU servers, so they are just as much data-centre category as the frontier models. What you can buy at a realistic price and fit into a one- or two-card server today scores roughly around 65–72%. For on-prem development, that is the relevant number.
On the hardware side the orders of magnitude look like this. A 24 GB card runs a code model of around 27–30B with 4-bit quantisation; that is the entry level. A 48 GB configuration runs a dense model of around 30B comfortably, at a real context size. The current field's best, self-hostable models, however, such as the newer versions of Qwen3-Coder or Devstral, tend to want the 96 GB category, because the long context of agentic work and concurrent use eat significant memory on top of the weights.
The rule of thumb: at FP16 you need roughly 2 GB of VRAM per billion parameters, at 4 bits 0.5 GB, and on top of that add 30–100% for context and concurrent use. A 96 GB machine can serve on the order of 5–15 developers, but this depends heavily on model size, response-time expectations and above all memory bandwidth, so it must always be measured, not estimated.
The methodology is worth at least as much as the model. Human oversight, well-built agent processes and our modernisation framework add real value regardless of raw model capability. When mapping out an undocumented codebase, the bottleneck is not the model's capability but the order, the context and the checkpoints with which we run the process through.
Most calculations go wrong here, because they look only at the price of the GPU. In the three-year total cost, alongside the server you need power and cooling, networking, storage, spare parts and, above all, a person who understands and maintains it. For a one- or two-card machine serving a development team, half a role's worth of operations capacity costs more over three years, than the metal itself. On larger, multi-GPU clusters that ratio reverses.
The second, still more important factor is utilisation. A GPU of your own only pays off if it is actually working. The break-even point sits at roughly 50–80% utilisation, depending on which cloud price you compare against. In practice most organisations run well below that, and the working hours of a ten-strong development team fluctuate by their very nature.
So the crux is this: on-prem and air-gapped AI is not cost optimisation, it is a compliance obligation. Anyone taking the model in-house to make it cheaper will almost certainly be worse off. Anyone doing it because the code cannot leave the environment, on the other hand, has this as the only option, and from there the only question is how to keep that cost at a sensible level.
In practice you rarely have to settle on a single gradation. The best result usually comes from mixing, along two kinds of logic.
Splitting by sensitivity. Not every codebase is equally sensitive. The code of the classified or regulated system stays on-premises, while the internal tools, the front end, the documentation and the tests can go to the cloud, with a frontier model. This is where separating the harness and the model pays off, because the developer uses the same tool; only the endpoint behind it is different.
Splitting by task type. The daily internal cycle makes up most of the work: completion, small refactors, writing tests, explaining code. Local models are more than good enough for this today. And for the hard 5%, the big architectural rebuilds, there is the frontier model, where the regulation allows it.
There is a knock-on benefit here too: the entire development process does not rest on a single provider, which for a client under DORA is an argument in itself.
We are continually on the lookout for the right on-prem developer tools, and we have already seen several PoCs through. The latest was a tool called Shaide, from Axem, which we tried out on an internal, greenfield Python project. What we wanted to know was how close it comes to our usual, Claude Code-based workflow.
We look at six aspects with tools like this: installation and setup, the usability of the agent modes, context handling on a larger codebase, the quality of the generated diffs, stability on longer tasks, and operability on your own infrastructure. This round answered the first two and the quality of the diffs; we left the rest for the next step.
Installation is very simple. The VS Code extension is up on the marketplace, and the tool itself walked us through the configuration. Setup was smooth.
In terms of use, the experience is surprisingly close to Claude Code. There are slash commands in the same way, and the output looks similar too. It has enough tools for day-to-day coding, several agent modes (plan, coding) are available, and the interface can be tailored to the person and the project.
The first impression is good. It looks like a realistic alternative for exactly where we cannot use the frontier models from the cloud. The next step is a more thorough technical evaluation on our own managed GPU server, with a specific model variant, on a real legacy codebase, with measured response times and several developers using it concurrently. We will write about that separately in a future post.
Local AI is not a replacement for the frontier models but a complement to them. It delivers real value where the data, the source code or the regulatory environment does not allow cloud models to be used. In that case, though, it is the only viable route.
The decision is not a choice between two options, but between four gradations. A locally running model is not yet isolation in itself; you have to look at the whole chain. And isolation is a cost, not a saving.
Our aim is not to use local AI everywhere, but to be able to provide solutions across the entire scale, and to have, a tried-and-tested route even where the frontier models could never be on the table. We test these on our own infrastructure so that we can offer clients not promises but proven solutions.
If the answer to at least two of the five questions is stricter, it is worth talking the details through. On the basis of a short assessment we can tell you which gradation fits the organisation, what that means in cost and developer experience, and what a two-week PoC looks like.
Bei Gloster modernisieren wir seit Jahren Legacy-Systeme, und seit einem halben Jahr setzen wir dafür auch agentische KI-Tools ein. Der Unterschied ist spürbar: Eine alte, oft undokumentierte Codebasis verstehen wir damit deutlich schneller – und schreiben sie auch schneller um. Menschliche Aufsicht und Kontrolle garantieren dabei die gewohnte Qualität.
Nur eine Frage taucht bei jedem ernstzunehmenden Kunden früher oder später auf: Darf der Code die Umgebung des Kunden überhaupt verlassen? In den meisten Fällen lautet die Antwort Ja, und dann ist die Cloud die perfekte Lösung. Aber nicht überall – und genau dort kommt die lokale KI ins Spiel.
Diese Frage ist 2026 nicht mehr theoretisch. Die europäische Debatte um Datensouveränität hat es bis in die Beschaffungsformulare geschafft. In immer mehr Vergabeverfahren steht als eigener Punkt, wo das Modell läuft, wer Zugriff auf den Code hat und was mit den Prompts geschieht.
Viele stellen sich das so vor, als gäbe es nur zwei Optionen: entweder Cloud oder lokal. In Wirklichkeit gibt es einen Übergang dazwischen. Es hilft, wenn wir das System in zwei Schichten zerlegen.
Die Harness, also die Entwicklererfahrung. Damit arbeitet der Entwickler tatsächlich: Slash-Befehle, Agent-Modi, Diffs, Werkzeuge, MCP-Integration. Sie kann selbst entwickelt sein, aber auch ein fertiges Produkt.
Die Modellschicht, also das Sprachmodell selbst. Sie liefert die Antwort, und aus Sicht des Datenschutzes zählt diese Schicht wirklich, denn sie entscheidet, wo verarbeitet wird.
Der Kernpunkt: Die Harness kann in etwa dieselbe bleiben, während wir das dahinter laufende Modell woanders platzieren. So zeichnet sich eine Skala ab. Am einen Ende die Qualität, am anderen die Kontrolle und die Isolation:
Man muss nicht alles auf einmal aufgeben, sondern immer die Abstufung suchen, die zum Risikoprofil des Kunden passt. Je strenger die gewählte Abstufung, desto größer die Kompromisse auf der Entwicklerseite – und desto steiler steigt auch der Preis.
Den meisten Kunden reicht die Managed Cloud oder Azure PaaS völlig aus. EU-Datenresidenz, vertragliche Garantien, Auditierbarkeit und dazu das gesamte Wissen der Frontier-Modelle. Es gibt keinen Grund, in eine teurere, kompliziertere Richtung zu gehen.
Es gibt jedoch einige Branchen, in denen dieser Weg nicht gangbar ist. Dort ist die Isolation kein Extra, sondern Grundvoraussetzung:
Bei ihnen lautet die Frage nicht, welches das beste Modell ist, sondern ob die KI überhaupt in den Prozess gelangen darf, ohne dass die Daten nach außen dringen. Dann ist die lokale, unter Umständen vollständig air-gapped Lösung die einzige, die infrage kommt.
Zwischen den Abstufungen entscheidet selten ein technologisches Argument. Fünf Fragen sollte man noch vor der technischen Debatte auf den Tisch legen, denn die Antworten schließen meist rasch zwei bis drei Optionen aus.
Fallen alle fünf Antworten unkritisch aus, ist die erste oder die zweite Abstufung die richtige Entscheidung, und jeder weitere Schritt verursacht nur überflüssige Kosten. Fällt die Antwort bei mindestens zwei Fragen strenger aus, dann lohnt es sich, die dritte und die vierte Abstufung ernsthaft zu prüfen.
Der Satz, dass man das Modell wegen DORA und NIS2 lokal betreiben müsse, ist in dieser Form nicht zutreffend. Dahinter stehen jedoch vier konkrete, greifbare Bezüge.
Kapitel V der DSGVO und der CLOUD Act. Wenn ein Akteur unter der Rechtshoheit eines Nicht-EU-Staates prinzipiell auf die Daten zugreifen kann, ist eine Transfer-Folgenabschätzung (TIA) nötig, auch wenn die Daten physisch in einem EU-Rechenzentrum liegen. Das ist in der Praxis das stärkste Argument für die Sovereign- oder On-Prem-Richtung.
NIS2 und die Lieferkette. Artikel 21 macht die Sicherheit der Lieferkette zu einem verpflichtenden Bereich des Risikomanagements; ausländischer staatlicher Einfluss wird im Rahmen der koordinierten Risikobewertungen auf EU-Ebene ausdrücklich als Risikofaktor behandelt. Der Lieferant eines KI-Codeassistenten ist aus dieser Sicht genauso ein Lieferant wie jeder andere.
Artikel 28 der DORA. Ein Finanzunternehmen muss für jeden kritischen IKT-Drittdienstleister einen dokumentierten, getesteten Ausstiegsplan vorlegen können. Ein Risiko besteht, wenn sich der Entwicklungsprozess eng auf die proprietäre, geschlossene API eines Dienstleisters stützt. Eine Modellschicht mit offenen Gewichten und Portabilität verringert genau diese Abhängigkeit.
Der AI Act. Die ab dem 2. August 2026 geltenden Transparenzpflichten, also die Vorgaben des Artikels 50, sind verbindlich. Die Pflichten für Hochrisiko-KI-Systeme nach Annex III sollen nach dem Digital-Omnibus-Vorschlag hingegen auf den 2. Dezember 2027 verschoben werden.
Ein Codeassistent, der die interne Entwicklung unterstützt, ist zudem für sich genommen in der Regel kein Hochrisiko-KI-System. Man sollte sich also nicht auf den AI Act berufen, wenn in Wahrheit die DSGVO und die vertragliche Kette entscheiden.
Hinzu kommen die branchenspezifischen Vorschriften, die oft noch strenger sind: in der Pharmaindustrie die Regelung des Zugriffs auf validierte Systeme, in der Verteidigungsindustrie und bei der Verarbeitung von Verschlusssachen der Air-Gap.
Darüber wird am seltensten gesprochen, obwohl in der Praxis meist genau daran ein Projekt scheitert. Nur weil das Modell lokal läuft, ist das System noch nicht isoliert. Die Harness kann Daten genauso nach außen geben, und aus Sicht der Verantwortung ist das um keinen Deut besser.
Fünf Punkte, die wir bei jeder solchen Einführung durchgehen müssen:
Deshalb sagen wir: Bei einer air-gapped Einführung muss man nicht das Modell, sondern die gesamte Kette auditieren.
Wir beschönigen es nicht: Die lokal laufenden, offenen Modelle erreichen heute nicht das Niveau der Frontier-Modelle. Eine air-gapped Umgebung wird nie so reibungslos sein wie eine Cloud-Lösung, und sie ist auch wesentlich teurer als ein einfaches Claude-Abonnement. Das sagen wir auch dem Kunden offen.
Zwei Dinge relativieren das Bild jedoch.
Die Technologie entwickelt sich, die Lücke schließt sich. Wichtig ist nur, was wir womit vergleichen. Die besten offenen Modelle erreichen Mitte 2026 im SWE-bench-Verified-Benchmark tatsächlich rund 80 %. Das sind allerdings MoE-Modelle mit mehreren hundert Milliarden Parametern. Für ihren Betrieb ist eine Infrastruktur von 300–400 GB VRAM bis hin zu mehreren vollständigen GPU-Servern nötig; sie gehören also genauso in die Rechenzentrumsklasse wie die Frontier-Modelle. Was zu einem realistischen Preis beschaffbar ist und in einen Server mit ein bis zwei Karten passt, erreicht heute etwa 65–72 %. Bei der On-Prem-Entwicklung ist das die relevante Zahl.
Auf der Hardwareseite sehen die Größenordnungen so aus. Auf einer 24-GB-Karte läuft ein Codemodell mit etwa 27–30 Mrd. Parametern bei 4-Bit-Quantisierung – das ist die Einstiegsstufe. Auf einer 48-GB-Konfiguration läuft ein dichtes Modell mit rund 30 Mrd. Parametern bequem, mit realer Kontextgröße. Die besten eigenständig betreibbaren Modelle des aktuellen Angebots, etwa die neueren Versionen von Qwen3-Coder oder Devstral, benötigen jedoch eher die 96-GB-Kategorie, denn der lange Kontext agentischer Arbeit und die parallele Nutzung beanspruchen über die Gewichte hinaus erheblichen Speicher.
Die Faustregel: Bei FP16 braucht es etwa 2 GB VRAM pro Milliarde Parameter, bei 4 Bit 0,5 GB – und dazu kommen noch 30–100 % für den Kontext und die parallele Nutzung. Eine 96-GB-Maschine kann größenordnungsmäßig 5–15 Entwickler bedienen, aber das hängt stark von der Modellgröße, der Erwartung an die Antwortzeit und vor allem von der Speicherbandbreite ab – weshalb man das immer messen sollte, nicht schätzen.
Die Methodik ist mindestens so viel wert wie das Modell. Menschliche Aufsicht, gut aufgebaute Agent-Abläufe und unser Modernisierungs-Framework liefern unabhängig von der reinen Modellfähigkeit erheblichen Wert. Beim Kartieren einer undokumentierten Codebasis ist nicht die Fähigkeit des Modells der Engpass, sondern die Frage, in welcher Reihenfolge, mit welchem Kontext und mit welchen Kontrollpunkten wir den Prozess durchlaufen.
Die meisten Kalkulationen greifen hier zu kurz, weil sie nur den Preis der GPU betrachten. In den Gesamtkosten über drei Jahre kommen neben dem Server Stromversorgung und Kühlung, Netzwerk, Speicher, Ersatzteile und vor allem ein Mensch hinzu, der ihn versteht und wartet. Bei einer Maschine mit ein bis zwei Karten, die ein Entwicklerteam versorgt, kostet eine halbe Stelle an Betriebskapazität über drei Jahre mehr als die Hardware selbst. Bei größeren Clustern mit mehreren GPUs kehrt sich dieses Verhältnis um.
Der zweite, noch wichtigere Faktor ist die Auslastung. Eine eigene GPU ist nur dann wirtschaftlich, wenn sie tatsächlich arbeitet. Der Amortisationspunkt liegt etwa bei 50–80 % Auslastung, je nachdem, mit welchem Cloud-Preis wir vergleichen. In der Praxis arbeiten die meisten Organisationen deutlich darunter, und die Arbeitszeit eines zehnköpfigen Entwicklerteams schwankt naturgemäß.
Der Kernpunkt also: On-Prem- und Air-gapped-KI ist keine Kostenoptimierung, sondern ein Compliance-Kostenfaktor. Wer das Modell ins Haus holt, damit es billiger wird, fährt fast sicher schlecht. Wer es aber tut, weil der Code die Umgebung nicht verlassen darf, für den ist das der einzige gangbare Weg – und von da an lautet die Frage nur noch, wie sich diese Kosten auf einem vernünftigen Niveau halten lassen.
In der Praxis muss man sich selten für eine einzige Abstufung entscheiden. Das beste Ergebnis liefert meist die Mischung, nach zweierlei Logik.
Trennung nach Sensibilität. Nicht jede Codebasis ist gleich sensibel. Der Code des klassifizierten oder regulierten Systems bleibt vor Ort; die internen Werkzeuge, das Frontend, die Dokumentation und die Tests können mit Frontier-Modell in die Cloud migriert werden. Hier kommt uns die Trennung von Harness und Modell gelegen, denn der Entwickler nutzt dasselbe Werkzeug – nur der Endpunkt dahinter ist ein anderer.
Trennung nach Aufgabentyp. Der tägliche Entwicklungszyklus macht den Großteil der Arbeit aus: Vervollständigung, kleinere Refactorings, Tests schreiben, Codeerklärung. Dafür sind die lokalen Modelle auch heute gut genug. Für die schweren 5 %, für die großen architektonischen Umbauten, steht das Frontier-Modell bereit – wo die Regulierung dies zulässt.
Das hat auch einen Zusatznutzen: Der gesamte Entwicklungsprozess baut nicht auf einem einzigen Dienstleister auf, was bei einem Kunden im Geltungsbereich der DORA für sich genommen schon ein Argument ist.
Wir suchen fortlaufend nach passenden On-Prem-Entwicklerwerkzeugen und haben schon mehrere PoCs durchgeführt. Zuletzt haben wir ein Tool namens Shaide von Axem an einem internen Greenfield-Python-Projekt ausprobiert. Uns interessierte, wie nahe es unserem gewohnten Arbeitsablauf mit Claude Code kommt.
Bei solchen Werkzeugen betrachten wir sechs Gesichtspunkte: Installation und Inbetriebnahme, Brauchbarkeit der Agent-Modi, Kontextverwaltung bei größerer Codebasis, Qualität der generierten Diffs, Stabilität bei längeren Aufgaben und Betreibbarkeit auf eigener Infrastruktur. Diese Runde gab Antwort auf die ersten beiden und auf die Qualität der Diffs; den Rest haben wir dem nächsten Schritt überlassen.
Die Installation war sehr einfach. Die VS-Code-Erweiterung ist im Marketplace vorhanden, durch die Konfiguration führte das Tool selbst. Die Inbetriebnahme verlief reibungslos.
Aus Sicht der Nutzung liegt die Erfahrung überraschend nahe an Claude Code. Es gibt genauso Slash-Befehle, und auch die Ausgabe sieht ähnlich aus. Für das tägliche Codieren sind ausreichend Werkzeuge enthalten, mehrere Agent-Modi (plan, coding) sind ebenfalls verfügbar, und die Oberfläche lässt sich auf Person und Projekt zuschneiden.
Hinzu kommen:
Der erste Eindruck ist gut. Gerade dort erscheint es als realistische Alternative, wo wir die Frontier-Modelle nicht aus der Cloud nutzen dürfen. Der nächste Schritt ist eine gründlichere technische Auswertung auf eigenem, gemanagtem GPU-Server – mit konkreter Modellvariante, an einer realen Legacy-Codebasis, mit gemessenen Antwortzeiten und paralleler Nutzung durch mehrere Entwickler. Darüber schreiben wir in einem der nächsten Beiträge gesondert.
Die lokale KI ist kein Ersatz für die Frontier-Modelle, sondern deren Ergänzung. Sie schafft dort echten Mehrwert, wo die Daten, der Quellcode oder das regulatorische Umfeld die Nutzung der Cloud-Modelle nicht zulassen. Dann aber ist sie der einzige gangbare Weg.
Die Entscheidung ist keine Wahl zwischen zwei Optionen, sondern zwischen vier Abstufungen. Das lokal laufende Modell ist für sich genommen noch keine Isolation – man muss die gesamte Kette betrachten. Und Isolation kostet, sie spart nicht.
Unser Ziel ist nicht, überall lokale KI zu nutzen, sondern auf der gesamten Skala Lösungen bereitstellen zu können und auch dort einen erprobten Weg zu haben, wo die Frontier-Modelle gar nicht erst in Betracht kommen. Diese Wege testen wir auf eigener Infrastruktur, damit wir unseren Kunden keine Versprechen, sondern erprobte Lösungen anbieten können
Wenn bei mindestens zwei der fünf Fragen die Antwort strenger ausfällt, sprechen wir die Details gemeinsam durch: Auf Basis einer kurzen Erhebung sagen wir Ihnen, welche Abstufung zu Ihrer Organisation passt, was das an Kosten und Entwicklererfahrung bedeutet und wie ein zweiwöchiger PoC aussieht.
.avif)
.webp)
