On-Prem-KI
KI innerhalb des Ökosystems des Kunden
Wann lohnt sich souveräne oder air-gapped Entwicklung – und wie sieht das in der Praxis aus?
18. August 2026
5 Minuten Lesezeit
Bei Gloster beschäftigen wir uns schon seit Jahren mit der Modernisierung von Legacy-Systemen, und seit einem halben Jahr setzen wir hierfür auch die AI-Tools von aAgentic ein. Der Unterschied ist deutlich spürbar: So können wir eine alte, oft undokumentierte Codebasis wesentlich schneller verstehen und umschreiben. Die menschliche Überwachung und Kontrolle garantiert dabei die gewohnte Qualität.
Es gibt jedoch eine Frage, die bei jedem ernstzunehmenden Kunden früher oder später auftaucht: Kann der Code überhaupt die eigene Umgebung des Kunden verlassen? In den meisten Fällen lautet die Antwort „Ja“, und dann ist die Cloud die perfekte Lösung. Aber nicht überall. Wo dies nicht der Fall ist, kommt die lokale KI ins Spiel.
Diese Frage wird im Jahr 2026 keine theoretische mehr sein. Die Debatte um die Datensouveränität in Europa hat mittlerweile auch die Ausschreibungsunterlagen erreicht: In immer mehr Ausschreibungen wird in einer eigenen Zeile festgelegt, wo das Modell läuft, wer Zugriff auf den Code hat und was mit den Prompts geschieht.
Viele glauben, es gäbe nur zwei Optionen: entweder Cloud oder lokal. In Wirklichkeit gibt es dazwischen einen Übergang. Es ist hilfreich, das System in zwei Ebenen zu unterteilen.
Das „Harness“, also die Entwicklerumgebung. Damit arbeitet der Entwickler tatsächlich: Slash-Befehle, Agent-Modi, Diffs, Tools, MCP-Integration. Es kann sich um eine selbst entwickelte Lösung handeln, aber auch um ein fertiges Produkt.
Die Modellschicht, also das Sprachmodell selbst. Dieses liefert die Antwort, und aus datenschutzrechtlicher Sicht ist diese Schicht wirklich entscheidend, da sie bestimmt, wo die Verarbeitung stattfindet.
Das Wesentliche ist, dass der Harness im Großen und Ganzen derselbe bleiben kann, während wir das dahinterstehende Modell an eine andere Stelle verlegen. So ergibt sich eine Skala. An dem einen Ende steht die Qualität, am anderen die Kontrolle und die Isolation:
Man muss nicht alles auf einmal aufgeben, sondern sollte stets die Stufe suchen, die zum Risikoprofil des Kunden passt. Je strenger die gewählte Stufe ist, desto größere Kompromisse müssen wir auf der Entwicklerseite eingehen, und desto steiler steigt auch der Preis.
Für die meisten Kunden reicht die Managed Cloud oder Azure PaaS völlig aus. Datenspeicherung in der EU, vertragliche Garantien, Nachvollziehbarkeit und dazu noch das umfassende Know-how zu den Frontier-Modellen. Es gibt keinen Grund, einen teureren und komplizierteren Weg einzuschlagen.
Es gibt jedoch einige Bereiche, in denen dies kein gangbarer Weg ist. Dort ist die Isolation keine Besonderheit, sondern eine Grundvoraussetzung:
Bei ihnen geht es nicht darum, welches das beste Modell ist, sondern darum, ob KI überhaupt in den Prozess integriert werden kann, ohne dass Daten nach außen gelangen. In diesem Fall kommt nur eine lokale, möglicherweise sogar vollständig „air-gapped“ Lösung in Frage.
Zwischen den verschiedenen Stufen ist es selten ein technisches Argument, das den Ausschlag gibt. Es lohnt sich, vor der technischen Diskussion fünf Fragen auf den Tisch zu legen, da die Antworten in der Regel schnell zwei bis drei Optionen ausschließen.
Wenn alle fünf Fragen mit „zulässig“ beantwortet werden können, ist die erste oder zweite Stufe die richtige Entscheidung, und jeder weitere Schritt verursacht unnötige Kosten. Wenn mindestens zwei Fragen mit „streng“ beantwortet werden, lohnt es sich, die dritte und vierte Stufe ernsthaft in Betracht zu ziehen.
Die Aussage, dass das Modell aufgrund von DORA und NIS2 lokal ausgeführt werden muss, ist in dieser Form nicht richtig. Dahinter stehen jedoch vier konkrete, greifbare Verweise.
Kapitel V der DSGVO und der CLOUD Act. Wenn ein Akteur, der nicht der Rechtshoheit der EU unterliegt, grundsätzlich Zugriff auf die Daten hat, ist eine Prüfung der Auswirkungen der Datenübermittlung auch dann erforderlich, wenn sich die Daten physisch in einem Rechenzentrum in der EU befinden. Dies ist in der Praxis das stärkste Argument für den „Sovereign“- oder „On-Prem“-Ansatz.
NIS2 und die Lieferkette. Artikel 21 macht die Sicherheit der Lieferkette zu einem obligatorischen Bereich des Risikomanagements und behandelt auch den Einfluss ausländischer Regierungen als Risikofaktor. Ein Lieferant eines KI-Code-Assistenten ist in dieser Hinsicht ein Lieferant wie jeder andere auch.
Artikel 28 der DORA. Finanzakteure müssen für jeden kritischen IKT-Dienstleister einen dokumentierten und getesteten Ausstiegsplan vorlegen können. Es besteht ein Risiko, wenn der Entwicklungsprozess eng an die proprietäre, geschlossene API eines Dienstleisters gebunden ist. Die offene, portierbare Modellschicht hingegen verringert genau diese Anfälligkeit.
Das KI-Gesetz. Die ab dem 2. August 2026 geltenden Transparenzpflichten, d. h. die Bestimmungen in Artikel 50, sind bereits in Kraft. Die Verpflichtungen für Systeme mit hohem Risiko, die unter Anhang III fallen, wurden hingegen durch das Digital-Omnibus-Gesetz auf den 2. Dezember 2027 verschoben.
Ein Code-Assistent, der die interne Entwicklung unterstützt, stellt zudem an sich in der Regel kein System mit hohem Risiko dar. Das AI-Gesetz sollte daher nicht als Bezugsgrundlage dienen, wenn letztlich die DSGVO und die Vertragskette ausschlaggebend sind.
Hinzu kommen noch die branchenspezifischen Vorschriften, die oft noch strenger sind. Ein Beispiel hierfür ist in der Pharmaindustrie die Regelung des Zugriffs auf validierte Systeme, in der Rüstungsindustrie sowie beim Umgang mit klassifizierten Daten hingegen der Air-Gap.
Darüber wird am seltensten gesprochen, obwohl ein Projekt in der Praxis meist genau daran scheitert. Nur weil das Modell lokal läuft, ist das System noch lange nicht isoliert. Der Harness kann genauso gut Daten nach außen weitergeben, und was die Verantwortlichkeit angeht, ist das keineswegs besser.
Fünf Punkte, die wir bei jeder derartigen Einführung beachten müssen:
Deshalb sagen wir, dass bei einer Air-Gapped-Implementierung nicht das Modell, sondern die gesamte Kette geprüft werden muss.
Wir wollen nichts beschönigen: Die lokal betriebenen, offenen Modelle erreichen heute nicht das Niveau der Frontier-Modelle. Eine Air-Gapped-Umgebung wird niemals so reibungslos funktionieren wie eine Cloud-Lösung und ist zudem deutlich teurer als ein einfaches Claude-Abonnement. Das sagen wir dem Kunden auch ganz offen.
Zwei Dinge trüben jedoch das Bild.
Die Technologie entwickelt sich weiter, die Lücke schließt sich. Wichtig ist nur, womit wir sie vergleichen. Die besten offenen Modelle erreichen Mitte 2026 beim SWE-bench Verified-Test tatsächlich eine Leistung von rund 80 %. Dabei handelt es sich jedoch um MoE-Modelle in der Größenordnung von Billionen. Für ihren Betrieb ist eine Infrastruktur erforderlich, die von 300–400 GB VRAM bis hin zu ganzen GPU-Servern reicht; sie gehören also ebenso zur Kategorie der Rechenzentren wie die Frontier-Modelle. Was zu realistischen Preisen erhältlich ist und in einen Server mit ein oder zwei Grafikkarten passt, erreicht heute eine Leistung von etwa 65–72 %. Bei der On-Prem-Entwicklung ist dies die relevante Zahl.
Was die Hardware angeht, sehen die Größenordnungen wie folgt aus: Auf einer 24-GB-Karte lässt sich ein Codemodell von etwa 27–30B mit 4-Bit-Quantisierung ausführen – das ist das Einstiegsniveau. Auf einer 48-GB-Konfiguration läuft ein dichtes Modell von etwa 30B problemlos mit realistischen Kontextgrößen. Die derzeit besten, eigenständig betreibbaren Modelle auf dem Markt, wie beispielsweise Qwen3-Coder oder die neueren Versionen von Devstral, erfordern jedoch eher die 96-GB-Kategorie, da der lange Kontext der agentenbasierten Verarbeitung und die parallele Nutzung neben den Gewichten auch erhebliche Speicherressourcen beanspruchen.
Als Faustregel gilt: Bei FP16 benötigt man etwa 2 GB VRAM pro Milliarde Parameter, bei 4 Bit 0,5 GB, dazu kommen noch 30–100 % für den Kontext und die parallele Nutzung. Ein Rechner mit 96 GB kann in der Größenordnung von 5 bis 15 Entwicklern bedient werden, was jedoch stark von der Modellgröße, den Anforderungen an die Antwortzeit und vor allem von der Speicherbandbreite abhängt; daher sollte dies immer gemessen und nicht geschätzt werden.
Die Methodik ist mindestens genauso viel wert wie das Modell. Die menschliche Überwachung, die gut strukturierten Agentenprozesse und unser Modernisierungsrahmen bieten auch unabhängig von der reinen Modellleistung einen erheblichen Mehrwert. Bei der Erfassung einer undokumentierten Codebasis ist nicht die Leistungsfähigkeit des Modells der Engpass, sondern die Frage, in welcher Reihenfolge, in welchem Kontext und mit welchen Kontrollpunkten wir den Prozess durchlaufen.
Die meisten Berechnungen gehen hier daneben, weil sie nur den Preis der GPU berücksichtigen. Zu den Gesamtkosten über drei Jahre müssen neben dem Server auch Stromversorgung und Kühlung, Netzwerk, Speicherplatz, Ersatzteile und vor allem eine Person hinzugerechnet werden, die sich damit auskennt und die Wartung übernimmt. Bei einem Rechner mit ein oder zwei Grafikkarten, der ein Entwicklerteam versorgt, kostet eine halbtagsbeschäftigte Betriebskraft über drei Jahre hinweg 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 im Einsatz ist. Die Rentabilitätsschwelle liegt bei einer Auslastung von etwa 50–80 %, je nachdem, mit welchem Cloud-Angebot man sie vergleicht. In der Praxis arbeiten die meisten Unternehmen weit unter diesem Wert, und die Arbeitszeit eines zehnköpfigen Entwicklerteams unterliegt naturgemäß Schwankungen.
Das Fazit lautet also: On-Prem- und Air-Gapped-KI sind keine Kostenoptimierung, sondern Compliance-Kosten. Wer das Modell ins eigene Haus verlagert, um Kosten zu sparen, wird mit ziemlicher Sicherheit den Kürzeren ziehen. Wer dies jedoch tut, weil der Code seine Umgebung nicht verlassen darf, für den ist dies hingegen der einzige gangbare Weg, und ab diesem Punkt stellt sich nur noch die Frage, wie sich diese Kosten auf einem vernünftigen Niveau halten lassen.
In der Praxis muss man sich selten für eine einzige Stufe entscheiden. Das beste Ergebnis erzielt man in der Regel durch eine Kombination verschiedener Ansätze, die auf zwei unterschiedlichen Logiken beruhen.
Trennung nach Sensitivitätsgrad. Nicht jeder Code ist gleich sensibel. Der Code des zertifizierten oder regulierten Systems bleibt vor Ort, während interne Tools, das Frontend, die Dokumentation und die Tests nach dem Frontier-Modell in die Cloud verlagert werden können. Hier kommt die Trennung von Harness und Modell zum Tragen, da der Entwickler dasselbe Tool verwendet, nur der dahinterliegende Endpunkt ist ein anderer.
Aufteilung nach Aufgabentypen. Der tägliche interne Arbeitsablauf macht den Großteil der Arbeit aus: Ergänzungen, kleinere Refactorings, das Schreiben von Tests und die Erläuterung des Codes. Dafür sind lokale Modelle auch heute noch völlig ausreichend. Für die schwierigen 5 % – also die großen architektonischen Umgestaltungen – gibt es das Frontier-Modell, sofern die Vorschriften dies zulassen.
Das hat auch einen Vorteil: Der gesamte Entwicklungsprozess stützt sich nicht auf einen einzigen Dienstleister, was für Kunden, die unter den Geltungsbereich von DORA fallen, an sich schon ein Argument ist.
Wir sind ständig auf der Suche nach geeigneten On-Premise-Entwicklertools und haben bereits mehrere PoCs durchgeführt. Das jüngste war das Tool „Shaide“ von Axemtőlm, das wir im Rahmen eines internen Python-Projekts von Grund auf getestet haben. Wir wollten herausfinden, inwieweit es unserem gewohnten Arbeitsablauf mit Claude Code entspricht.
Bei solchen Tools betrachten wir sechs Aspekte: Installation und Inbetriebnahme, Nutzbarkeit der Agent-Modi, Kontextverwaltung in größeren Codebasen, Qualität der generierten Diffs, Stabilität bei längeren Aufgaben sowie Betriebsfähigkeit in der eigenen Infrastruktur. Diese Runde lieferte Antworten auf die ersten beiden Aspekte und die Qualität der Diffs; die übrigen Punkte haben wir für den nächsten Schritt zurückgestellt.
Die Installation ist sehr einfach. Die VS Code-Erweiterung ist im Marketplace verfügbar, und das Tool selbst hat mich durch die Konfiguration geführt. Die Inbetriebnahme verlief reibungslos.
Was die Nutzung angeht, ähnelt das Erlebnis überraschend stark dem von Claude Code: Es gibt ebenso Slash-Befehle, und auch die Ausgabe sieht ähnlich aus. Für das tägliche Programmieren bietet es genügend Funktionen, mehrere Agent-Modi (Plan, Coding) lassen sich speichern, und die Benutzeroberfläche kann individuell und projektbezogen angepasst werden.
Der erste Eindruck ist gut. Gerade dort, wo die Frontier-Modelle nicht aus der Cloud genutzt werden können, scheint es eine realistische Alternative zu sein. Der nächste Schritt ist eine gründlichere technische Bewertung auf einem eigenen, verwalteten GPU-Server mit einer konkreten Modellvariante, einer echten Legacy-Codebasis, gemessenen Antwortzeiten und der parallelen Nutzung durch mehrere Entwickler. Darüber werden wir in einem nächsten Beitrag gesondert berichten.
Lokale KI ist kein Ersatz für „Frontier“-Modelle, sondern ergänzt diese. Sie bietet einen echten Mehrwert dort, wo Daten, Quellcode oder rechtliche Rahmenbedingungen den Einsatz von Cloud-Modellen nicht zulassen. In solchen Fällen ist sie jedoch der einzige gangbare Weg.
Bei dieser Entscheidung geht es nicht um die Wahl zwischen zwei Optionen, sondern zwischen vier Stufen. Ein lokal betriebenes Modell bedeutet für sich genommen noch keine Isolation; man muss die gesamte Kette betrachten. Und Isolation bedeutet Kosten, keine Einsparungen.
Unser Ziel ist es nicht, überall lokale KI einzusetzen, sondern über das gesamte Spektrum hinweg Lösungen anbieten zu können und auch dort bewährte Verfahren zu haben, wo „Frontier“-Modelle gar nicht erst in Frage kommen. Diese testen wir auf unserer eigenen Infrastruktur, damit wir unseren Kunden keine leeren Versprechungen, sondern bewährte Lösungen anbieten können.
Wenn mindestens zwei der fünf Fragen mit „streng“ beantwortet wurden, lohnt es sich, die Details zu besprechen. Anhand einer kurzen Umfrage können wir feststellen, welche Stufe zur Organisation passt, was dies in Bezug auf Kosten und Entwicklererfahrung bedeutet und wie ein zweiwöchiger PoC aussieht.
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)
