On-prem AI
AI az ügyfél ökoszisztémáján belül
Mikor éri meg a sovereign vagy air-gapped fejlesztés, és hogyan néz ez ki a gyakorlatban?
2026. augusztus 18.
5 perc olvasás
A Glosternél évek óta foglalkozunk legacy rendszerek modernizációjával, és az utóbbi fél évben elkezdtünk ehhez aAgentic AI toolokat is felhasználni. A különbség érezhető, egy régi, sokszor dokumentálatlan kódbázist így jóval gyorsabban értünk meg és írunk át. Az emberi felügyelet és ellenőrzés pedig garantálja a megszokott minőséget.
Csak van egy kérdés, ami minden komolyabb ügyfélnél előbb-utóbb előkerül: kiléphet-e egyáltalán a kód az ügyfél saját környezetéből? A legtöbb helyen a válasz igen, és akkor a felhő tökéletes megoldás. De nem mindenhol. Ahol nem, ott jön képbe a lokális AI.
Ez a kérdés 2026-ban már nem elméleti. Az európai adatszuverenitási vita eljutott a beszerzési űrlapokig is, egyre több tenderben szerepel külön sorként, hogy hol fut a modell, ki fér hozzá a kódhoz, és mi történik a promptokkal.
Sokan úgy gondolnak rá, mintha csak két opció lenne: vagy felhő, vagy lokális. A valóságban van köztük átmenet. Segít, ha a rendszert két rétegre bontjuk.
A harness, vagyis a fejlesztői élmény. Ezzel dolgozik ténylegesen a fejlesztő: slash-parancsok, agent-módok, diffek, eszközök, MCP-integráció. Lehet saját fejlesztésű, de kész termék is.
A modellréteg, vagyis maga a nyelvi modell. Ez adja a választ, és adatvédelmi szempontból ez a réteg számít igazán, mert ez dönti el, hol fut.
A lényeg, hogy a harness nagyjából ugyanaz maradhat, miközben a mögötte futó modellt máshová tesszük. Így egy skála rajzolódik ki. Az egyik végén a minőség, a másikon a kontroll és az izoláció:
Nem kell mindent egyszerre feladni, mindig azt a fokozatot kell keresni, ami az ügyfél kockázati profiljához illik. Minél szigorúbb fokozatot választunk, annál nagyobb kompromisszumot kell kötnünk fejlesztői oldalon, és annál meredekebben nő az ár is.
A legtöbb ügyfélnek a menedzselt felhő vagy az Azure PaaS bőven elég. EU-s adatrezidencia, szerződéses garanciák, auditálhatóság, és mellé ott a frontier modellek teljes tudása. Nincs miért drágább, bonyolultabb irányba indulni.
Van viszont pár szektor, ahol ez nem járható út. Ott az izoláció nem extra, hanem alapfeltétel:
Náluk nem az a kérdés, hogy melyik a legjobb modell, hanem az, hogy egyáltalán bekerülhet-e az AI a folyamatba anélkül, hogy az adat kiszivárogna. Ilyenkor a lokális, akár teljesen air-gapped megoldás az egyetlen, ami szóba jöhet.
A fokozatok között ritkán technológiai érv dönt. Öt kérdést érdemes még a technikai vita előtt letenni az asztalra, mert a válaszok általában gyorsan kizárnak két-három opciót.
Ha mind az öt kérdésre megengedő a válasz, az első vagy a második fokozat a helyes döntés, és minden továbblépés fölösleges költség. Ha legalább kettőre szigorúbb, akkor érdemes a harmadik és a negyedik fokozatot komolyan megvizsgálni.
Az a mondat, hogy a DORA és a NIS2 miatt lokálisan kell futtatni a modellt, így, ebben a formában nem igaz. Van viszont mögötte négy konkrét, megfogható hivatkozás.
A GDPR V. fejezete és a CLOUD Act. Ha az adathoz elvben hozzáférhet egy nem EU-s joghatóság alá tartozó szereplő, transzferhatás-vizsgálat kell akkor is, ha az adat fizikailag EU-s adatközpontban van. Ez a gyakorlatban a legerősebb érv a sovereign vagy on-prem irány mellett.
A NIS2 és az ellátási lánc. A 21. cikk a beszállítói lánc biztonságát kötelező kockázatkezelési területté teszi, és a külföldi kormányzati befolyást is kockázati tényezőként kezeli. Egy AI-kódasszisztens beszállítója ebből a szempontból ugyanolyan beszállító, mint bárki más.
A DORA 28. cikke. Pénzügyi szereplőnél minden kritikus ICT-szolgáltatóra dokumentált, tesztelt kilépési tervet kell tudni felmutatni. Kockázat, ha a fejlesztési folyamat szorosan ráépül egy szolgáltató saját, zárt API-jára. A nyílt súlyú, hordozható modellréteg viszont éppen ezt a kitettséget csökkenti.
Az AI Act. A 2026. augusztus 2-ától élő átláthatósági kötelezettségek, vagyis az 50. cikk előírásai, valósak. A magas kockázatú, Annex III alá eső rendszerek kötelezettségeit viszont a Digital Omnibus 2027. december 2-ára tolta ki.
Egy belső fejlesztést segítő kódasszisztens ráadásul önmagában általában nem magas kockázatú rendszer. Ne az AI Act legyen tehát a hivatkozási alap, ha igazából a GDPR és a szerződéses lánc dönt.
Jönnek ezeken felül az ágazati előírások is, amik sokszor még ennél is szigorúbbak. Ilyen a gyógyszeriparban a validált rendszerekhez való hozzáférés szabályozása, a védelmi iparban és a minősített adatok kezelésénél pedig az air-gap.
Erről esik a legritkábban szó, pedig a gyakorlatban általában ezen csúszik el egy projekt. Attól, hogy a modell lokálisan fut, a rendszer még nem izolált. A harness ugyanúgy tud adatot kiengedni, és a felelősség szempontjából ez semmivel sem jobb.
Öt pont, amit minden ilyen bevezetésnél végig kell néznünk:
Ezért mondjuk azt, hogy air-gapped bevezetésnél nem a modellt, hanem a teljes láncot kell auditálni.
Nem szépítjük: a helyben futó, nyílt modellek ma nem érik el a frontier modellek szintjét. Egy air-gapped környezet sosem lesz olyan gördülékeny, mint egy felhős megoldás, és lényegesen drágább is, mint egy egyszerű Claude-előfizetés. Ezt az ügyfélnek is nyíltan megmondjuk.
Két dolog viszont árnyalja a képet.
A technológia fejlődik, a rés zárul. Csak az a fontos, hogy mit mihez hasonlítunk. A legjobb nyílt modellek 2026 közepén a SWE-bench Verified mérésen valóban 80% körül teljesítenek. Ezek azonban billiós nagyságrendű MoE-modellek. A kiszolgálásukhoz 300–400 GB VRAM-tól több teljes GPU-szerverig terjedő infrastruktúra kell, tehát ezek ugyanúgy adatközponti kategóriát jelentenek, mint a frontier modellek. Ami reális áron beszerezhető és egy-két kártyás szerverbe befér, az ma nagyjából 65–72% körül teljesít. On-prem fejlesztésnél ez a releváns szám.
Hardveroldalról a nagyságrendek így néznek ki. Egy 24 GB-os kártyán elfut egy 27–30B körüli kódmodell 4 bites kvantálással, ez a belépőszint. Egy 48 GB-os konfiguráción egy 30B körüli sűrű modell fut kényelmesen, valós kontextusmérettel. A jelenlegi mezőny legjobb, önállóan üzemeltethető modelljei viszont, például a Qwen3-Coder vagy a Devstral újabb verziói, már inkább a 96 GB-os kategóriát kívánják, mert az agentic munka hosszú kontextusa és a párhuzamos használat a súlyokon felül is jelentős memóriát eszik.
Az ökölszabály: FP16-on nagyjából 2 GB VRAM kell milliárd paraméterenként, 4 biten 0,5 GB, és ehhez jön még 30–100% a kontextusra és a párhuzamos használatra. Egy 96 GB-os gép nagyságrendileg 5–15 fejlesztőt tud kiszolgálni, de ez erősen függ a modellmérettől, a válaszidő-elvárástól és főleg a memória sávszélességétől, ezért ezt mindig mérni kell, nem becsülni.
A módszertan legalább annyit ér, mint a modell. Az emberi felügyelet, a jól felépített agent-folyamatok és a modernizációs keretrendszerünk a nyers modellképességtől függetlenül is komoly értéket adnak. Egy dokumentálatlan kódbázis feltérképezésénél nem a modell képessége a szűk keresztmetszet, hanem az, hogy milyen sorrendben, milyen kontextussal és milyen ellenőrzési pontokkal futtatjuk végig a folyamatot.
A legtöbb kalkuláció itt hibázik, mert csak a GPU árát nézi. A hároméves teljes költségben a szerver mellé kell tápellátás és hűtés, hálózat, tárhely, tartalék alkatrész és mindenekelőtt egy ember, aki érti és karbantartja. Egy fejlesztőcsapatot kiszolgáló, egy-két kártyás gépnél egy félállásnyi üzemeltetői kapacitás három év alatt többe kerül, mint maga a vas. Nagyobb, több GPU-s klasztereknél ez az arány megfordul.
A második, még fontosabb tényező a kihasználtság. Egy saját GPU csak akkor gazdaságos, ha ténylegesen dolgozik. A megtérülési pont nagyjából 50–80%-os kihasználtságnál van, attól függően, milyen felhőárral hasonlítjuk össze. A gyakorlatban a legtöbb szervezet ennél jóval alacsonyabban üzemel, egy tízfős fejlesztőcsapat munkaideje pedig természeténél fogva hullámzik.
A lényeg tehát: az on-prem és az air-gapped AI nem költségoptimalizálás, hanem megfelelési költség. Aki azért vinné házon belülre a modellt, hogy olcsóbb legyen, az szinte biztosan rosszul jár. Aki azért, mert a kód nem hagyhatja el a környezetét, annak viszont ez az egyetlen működő út, és onnantól a kérdés már csak az, hogyan lehet ezt a költséget észszerű szinten tartani.
A gyakorlatban ritkán kell egyetlen fokozat mellett dönteni. A legjobb eredményt általában a keverés adja, kétféle logika mentén.
Szétválasztás érzékenység szerint. Nem minden kódbázis egyformán érzékeny. A minősített vagy szabályozott rendszer kódja helyben marad, a belső eszközök, a frontend, a dokumentáció és a tesztek pedig mehetnek felhőbe, frontier modellel. Itt jön jól a harness és a modell szétválasztása, mert a fejlesztő ugyanazt az eszközt használja, csak a mögötte lévő végpont más.
Szétválasztás feladattípus szerint. A napi belső ciklus a munka nagy részét kiteszi: kiegészítés, kisebb refaktor, tesztírás, kódmagyarázat. Erre a lokális modellek ma is bőven jók. A nehéz 5%-ra, a nagy architekturális átalakításokra pedig ott van a frontier modell, ahol ezt a szabályozás engedi.
Ennek van egy hozadéka is: nem egyetlen szolgáltatóra épül a teljes fejlesztési folyamat, ami a DORA hatálya alá tartozó ügyfélnél önmagában is érv.
Folyamatosan keressük a megfelelő on-premise fejlesztői eszközöket, és több PoC-t is végigvittünk már. A legutóbbi az Shaide nevű tool volt az Axemtőlm-tőlt, amit egy belső, zöldmezős Python-projekten próbáltunk ki. Arra voltunk kíváncsiak, mennyire áll közel a megszokott, Claude Code-os munkafolyamatunkhoz.
Hat szempontot nézünk az ilyen eszközöknél: telepítés és beüzemelés, agent-módok használhatósága, kontextuskezelés nagyobb kódbázison, generált diffek minősége, hosszabb feladatok stabilitása, üzemeltethetőség saját infrastruktúrán. Ez a kör az első kettőre és a diffek minőségére adott választ, a többit a következő lépésre hagytuk.
A telepítés nagyon egyszerű. A VS Code extension fent van a marketplace-en, a konfiguráción pedig maga a tool vezetett végig. A beüzemelés zökkenőmentes volt.
Használat szempontjából az élmény meglepően közel áll a Claude Code-hoz. : Uugyanúgy vannak slash-parancsok, és a kimenet is hasonlóan néz ki. A napi kódoláshoz elég eszköz van benne, több agent-mód (plan, coding) is mentelérhető, a felület pedig személyre és projektre szabható.
Az első benyomás jó. Pont ott tűnik reális alternatívának, ahol a frontier modelleket felhőből nem használhatjuk. A következő lépés egy alaposabb technikai kiértékelés saját, menedzselt GPU-s szerveren, konkrét modellváltozattal, valós legacy kódbázison, mért válaszidőkkel és több fejlesztő párhuzamos használatával. Erről egy következő posztban külön is írunk.
A lokális AI nem a frontier modellek helyettesítője, hanem azok kiegészítője. Ott jelent valódi értéket, ahol az adatok, a forráskód vagy a szabályozási környezet nem engedi a felhős modellek használatát. Ilyenkor viszont ez az egyetlen járható út.
A döntés nem két opció közötti választás, hanem négy fokozat közötti. A lokálisan futó modell önmagában még nem izoláció, a teljes láncot kell nézni. Az izoláció pedig költség, nem megtakarítás.
Nem az a célunk, hogy mindenhol lokális AI-t használjunk, hanem az, hogy a teljes skálán tudjunk megoldásokat biztosítani, és ott is legyen kipróbált utunk, ahol a frontier modellek fel sem merülhetnek. Ezeket saját infrastruktúrán teszteljük, hogy ügyfeleinknek ne ígéreteket, hanem kipróbált megoldásokat tudjunk ajánlani.
Ha az öt kérdés közül legalább kettőre szigorúbb a válasz, érdemes végigbeszélnünk a részleteket. Egy rövid felmérés alapján meg tudjuk mondani, melyik fokozat illik a szervezethez, mit jelent ez költségben és fejlesztői élményben, és hogyan néz ki egy kéthetes PoC.
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)
