Was on-premise KI wirklich kostet — vier Säulen und eine ehrliche Vollkostenrechnung

In Kürze

Über Token-Preise lässt sich on-premise KI nicht rechtfertigen. Über vier Säulen schon, die jeder CTO in einer regulierten Industrie kennt:

• Datenhoheit — Inhalte verlassen den eigenen Stack nicht
• Konstante, kalkulierbare Kosten — Fixkosten statt nutzungsabhängiger Tokenrechnung
• Stabile LLM-Ergebnisse — gepinnte Modelle, reproduzierbare Läufe über Monate
• EU-Compliance — EU AI Act, NIS2, DSGVO ohne Sub-Processor-Ketten

Die Vollkostenrechnung dahinter ist transparent: Hardware-Server, Strom, Wartung, Personalanteil, Plattform-Software. Eine 1:1-Vergleichsrechnung gegen Hyperscaler-Token-Pricing führen wir bewusst nicht. Beide Modelle sind strukturell inkompatibel: On-premise heißt überwiegend fixe Kosten, Cloud-API heißt variable Kosten, die linear mit der Nutzung wachsen. Was sich seriös vergleichen lässt, sind die Vollkosten der manuellen Arbeit, die durch automatisierte Workflows ersetzt wird — und die Compliance-Overhead-Kosten, die in einer Hyperscaler-Architektur dazukommen.

Die vier Säulen, die on-premise KI tragen

Säule 1 — Datenhoheit

Enterprise-Workflows enthalten Customer-Daten, Sicherheitsanforderungen, Geschäftslogik, Architektur-Details. In regulierten Industrien sind das oft die wertvollsten Assets des Unternehmens. Eine Cloud-API verlangt, dass jede Inferenz diese Inhalte an einen Drittanbieter überträgt — auch wenn der Anbieter sie nicht trainiert, sie passieren seine Infrastruktur.

Selbst bei EU-Region-Hyperscalern wie Azure EU oder Google Cloud EU bleibt die Frage: Wer hat technischen Zugriff auf die Runtime-Umgebung? Customer-Managed Keys helfen, eliminieren das Risiko aber nicht. Der Provider hält die Compute-Umgebung. Bei On-premise mit lokaler Inferenz verlässt kein einziger Token den eigenen Stack — und das verschiebt die Architektur-Diskussion in eine andere Kategorie, nicht nur eine andere Konfiguration.

Säule 2 — Konstante, kalkulierbare Kosten

Cloud-API-Pricing ist ein bewegliches Ziel. Token-Preise ändern sich, neue Modellklassen kommen mit anderem Pricing, Quotas werden angepasst, Reasoning-Tokens werden zusätzlich abgerechnet. Wer einen Workflow mit 500.000 Token pro Lauf budgetiert und dann auf ein Reasoning-Modell wechseln muss, sieht die Kosten um Faktor 3–10 steigen.

On-premise heißt das Gegenteil: Hardware-Abschreibung läuft linear über 36 Monate, Plattform-Software-Lizenz ist ein Jahresbetrag, Strom skaliert minimal mit Auslastung, Personal ist konstant. Das Monatsbudget steht. Der CFO weiß im Januar, was im Dezember anfällt. Diese Kalkulierbarkeit ist in regulierten Industrien kein Komfort, sondern Voraussetzung für mehrjährige Projektplanung.

Säule 3 — Stabile LLM-Ergebnisse

Cloud-API-Anbieter aktualisieren Modelle laufend. Versionen werden deprecated, Quotas und Verhalten verschieben sich, manchmal ohne explizite Ankündigung. Jede dieser Änderungen kann Workflow-Output verschieben. In regulierten Umgebungen heißt das: Audit-Trail bricht, alte Runs lassen sich nicht 1:1 reproduzieren, Validierung muss neu gefahren werden.

On-premise mit gepinntem Open-Weight-Modell bleibt über Monate identisch. Ein Lauf vom Januar produziert im November dasselbe Ergebnis auf demselben Input. Reproduzierbarkeit ist hier nicht Komfort, sondern Audit-Anforderung — ISO 26262, MedSPICE, DO-178C, ASPICE verlangen Reproduzierbarkeit über den Lebenszyklus. Auch Azure OpenAI und Google Vertex deprecaten Modelle. EU-Region ändert daran nichts.

Säule 4 — EU-Compliance ohne Sub-Processor-Ketten

Drei Regelwerke treffen on-premise KI direkt — alle drei mit konkreten Hebeln, die EU-Hyperscaler-Cloud nicht beseitigt:

EU AI Act. Für High-Risk-Systeme verlangt Art. 10 (Daten-Governance), Art. 12 (Record-Keeping), Art. 14 (menschliche Aufsicht) durchgehende Nachweisbarkeit über den Lebenszyklus. Bei Cloud-API liegt das Logging im Vendor-Konto, kontrolliert durch dessen Aufbewahrungs- und Zugriffs-Policies. Bei On-premise liegen Logs lokal, in einem Format, das ein Auditor direkt liest. Provider/Deployer-Rollenverteilung nach Art. 25 ist ebenfalls schärfer: Bei Open-Weight on-premise sind Sie Provider mit voller Kontrolle über die technische Dokumentation, bei Cloud-API sind Sie Deployer und auf die Compliance-Roadmap des Vendors angewiesen.

NIS2. Art. 21 Abs. 2 lit. d verlangt Lieferketten-Risikomanagement. Jeder Cloud-Vendor ist Teil dieser Lieferkette — auch EU-gehostet. Sicherheitsmaßnahmen müssen bewertet, Sub-Processor-Wechsel nachverfolgt, Vendor-Incidents in die eigene Risiko-Berichterstattung eingerechnet werden. Azure OpenAI lief lange auf US-OpenAI-Backbone als Sub-Processor. Wer NIS2-pflichtig ist, hat bei jeder solchen Architektur-Änderung Bewertungsaufwand. On-premise eliminiert diesen Posten.

DSGVO. Selbst EU-Region-Cloud unterliegt dem US CLOUD Act und FISA 702, wenn der Mutterkonzern in den USA sitzt. Das Trans-Atlantic Data Privacy Framework (2023) wird juristisch angegriffen, der Ausgang ist offen. Wer heute eine Architektur baut, die in zwei Jahren auf einem ungültigen Angemessenheitsbeschluss stehen könnte, baut Risiko ein. On-premise mit lokaler Inferenz hat dieses Risiko nicht.

Keine dieser drei Säulen zwingt zu on-premise. Aber wer in einer Industrie unter ASPICE, MedSPICE, DO-178C, ISO 26262 oder vergleichbarem Compliance-Druck arbeitet, kennt den Aufwand, den eine Cloud-Architektur in der Audit-Dokumentation auslöst. Das ist die eigentliche TCO-Frage, die selten in der Tabelle steht.

Eine Infrastruktur, mehrere Workflow-Klassen — der Multi-Workflow-Effekt

Die zentrale Eigenschaft einer on-premise KI-Architektur: Eine GPU-Infrastruktur, ein Plattform-Stack, mehrere Workflow-Klassen. Jede einzelne rechtfertigt das Setup nicht zwingend. Mehrere zusammen verändern die Vollkostenrechnung grundlegend. Drei typische Klassen:

1. Agentische Automatisierung in operativen Systemen

ERP, ITSM, CRM oder vergleichbare Geschäftssysteme. Workflows wie Ticket-Triage, Stammdaten-Pflege, Master-Data-Audits, regelbasierte Pre-Approvals. Voraussetzungen: API-Zugang oder Script-Execution-Pfad ins Zielsystem, dokumentierte Geschäftsregeln, klare Eingangs- und Ausgangs-Artefakte. Function Calling, strukturierte JSON-Ausgaben und stabiles Intent-Reasoning sind die LLM-Fähigkeiten, die hier zählen.

2. Auditierbare Spezifikations- und ALM-Workflows

Coverage-Checks, semantische Drift-Erkennung, Requirements-Konformität, Test-Case-Synthese, Change-Impact-Analysen. Typisch in regulierten Industrien wie Automotive, MedTech, Aerospace oder Defense unter ASPICE, MedSPICE, DO-178C oder ISO 26262. Voraussetzungen: strukturierte Requirements-Quellen, Audit-Trail-Anforderung, ein Human-in-the-Loop-Approval-Schritt für jede automatische Anpassung. Konkreter Benchmark in dieser Klasse: siehe den verlinkten Polarion-Blog am Ende des Artikels.

3. Internes Chat-Frontend für Mitarbeiter

Ein authentifiziertes Chat-Frontend mit Rollen- und Rechtemanagement, das dieselbe Inferenz-Infrastruktur nutzt. Use Case: Mitarbeitern Zugang zu einem leistungsfähigen Modell geben, ohne dass Firmendaten in Hyperscaler-APIs wandern. Datenresidenz und Audit-Trail bleiben im Haus. RBAC steuert, wer welche Modelle und welche internen Quellen ansprechen darf.

Der Punkt für die Vollkostenrechnung: Die zweite und dritte Klasse laufen ohne nennenswerte Mehrkosten auf einer Infrastruktur, die bereits steht. Hardware, Strom und Personal sind weitgehend amortisiert, die zusätzliche Last passt in die vorhandene GPU-Kapazität.

Die Komponenten der Vollkostenrechnung

Wir gliedern das Modell in vier Blöcke. Alle Hardware- und Betriebs-Zahlen basieren auf aktuellen Marktpreisen für einen dedizierten Inferenz-Server, der mehrere Workflow-Klassen parallel bedient.

Block 1 — Plattform-Software

Eine Agent-Plattform für regulierte Enterprise-Workflows besteht im Kern aus drei Schichten: dem Inferenz-Layer mit gepinnten Open-Weight-Modellen, dem Skill- und Function-Calling-Layer mit der jeweiligen Workflow-Logik, und dem Audit- und Bedien-Layer (Run-IDs, Tool-Call-Logs, Human-in-the-Loop, internes Chat-Frontend mit RBAC). Updates und Support laufen über die Plattform-Lizenz.

Was den Aufwand treibt, sind die üblichen Verdächtigen: Workflow-Anzahl, Domänen-Tiefe, Drittsystem-Integrationen, Compliance-Anforderungen. Setup-Aufwand für ein mittleres Single-Workflow-Setup liegt erfahrungsgemäß bei 9–12 Personentagen. Konkrete Lizenz- und Setup-Konditionen für ISUDO Camemi nennen wir auf Anfrage — Listenpreise verändern sich mit dem Modul-Portfolio und sollen in einem Architektur-Blog keine Halbwertszeit haben.

Block 2 — On-Premise Hardware

Die Plattform läuft prinzipiell auf Bestandshardware. Wir empfehlen für regulierte Kunden trotzdem den dedizierten Inferenz-Server, weil Datenresidenz und Audit-Trail dann sauber im Haus bleiben.

Monatlicher Hardware-Anteil: (25.000 / 36) + 144 + 146 ≈ ~984 €/Monat

Block 3 — Personalanteil

Konservative Annahme: Ein DevOps-Engineer bzw. ein Solution-Architect verbringt im Schnitt 2 Stunden pro Monat mit Wartung, Updates und Skill-Anpassungen.

Block 4 — Gesamtsumme

Der Plattform-Software-Anteil P ist der einzige Hebel, der wesentlich variiert — je nach Anbieter, Workflow-Anzahl und Domänen-Tiefe. In einem mittleren Setup mit einem aktiven Workflow-Schwerpunkt liegt P typischerweise im mittleren vierstelligen Bereich pro Monat. Für die folgenden Skalierungs-Rechnungen nutzen wir einen illustrativen Mittelwert von 5.500 €/Monat für P, woraus sich Monatsvollkosten von rund ~6.700 € ergeben. Dieser Wert ist kein Listenpreis — er ist eine Rechengröße, damit der Skalierungseffekt sichtbar wird.

Vollkosten pro Lauf — Skalierungs-Tabelle

Die monatlichen Vollkosten verteilen sich auf alle Workflow-Läufe im Monat, unabhängig von der Workflow-Klasse. Ein agentischer Lauf in einem operativen System, ein Spezifikations-Audit, eine Chat-Session. Jeder Aufruf zieht aus derselben Infrastruktur.

Lesart: Schon ab moderater Multi-Workflow-Nutzung sinken die Per-Run-Kosten auf einen Bruchteil dessen, was eine vergleichbare manuelle Bearbeitung im jeweiligen Workflow kosten würde. Ein typisches Setup mit aktiver agentischer Automatisierung plus internem Chat-Frontend kommt schnell auf mehrere hundert Läufe pro Monat. Bei höherem oder niedrigerem Plattform-Anteil P verschieben sich die Absolutwerte linear, die Skalierungslogik bleibt identisch.

Größenklassen — Orientierungsgrößen

Bei mehreren Workflow-Schwerpunkten oder größeren Konzern-Setups verschiebt sich das Bild: Plattform-Anteil steigt, Hardware kann mehrere Workflow-Klassen gleichzeitig bedienen, Lauf-Volumen steigt überproportional. Drei typische Größenklassen als Anhaltspunkt:

Profile aus der Praxis: Single-Domain-Setups (z.B. nur ALM-Audits in einem Compliance-Bereich, oder nur agentische Automatisierung in einem operativen System) liegen meist in S oder M. Active Multi-Team-Setups mit zwei Workflow-Klassen in M oder L. Konzern-Setups mit mehreren Workflow-Klassen über verschiedene Domänen plus internes Chat-Frontend für mehrere hundert Mitarbeiter in L.

Was die Skalierungs-Tabelle nicht zeigt — und warum sie noch besser wird

Die Tabelle ist in drei Punkten konservativ:

1. Sekundäre Workflows kosten praktisch nichts extra. Sobald die Plattform steht, kostet jede zusätzliche Workflow-Klasse auf derselben Hardware kaum Marginalkosten. Agentische Automatisierung in einem operativen System, ein Audit-Workflow im Spezifikationssystem, ein internes Chat-Frontend mit Rollen- und Rechtemanagement. Alles läuft auf derselben Infrastruktur. Das ist die Kernlogik dieser Architektur: Die Vollkosten pro Lauf sinken, je mehr unterschiedliche Workflows auf einer Infrastruktur laufen.

2. Hardware-Amortisation. Ab Monat 37 fällt der Hardware-Anschaffungs-Anteil weg (25.000 € sind abgeschrieben). Übrig bleiben nur Strom + Wartung ≈ 290 €/Monat. Vollkosten sinken um den Anschaffungs-Anteil weiter.

3. Geteilte Hardware bei Multi-Workflow-Setups. Ein Inferenz-Server kann mehrere Workflow-Klassen parallel bedienen. Die Hardware-Kosten skalieren nicht linear mit der Workflow-Anzahl. In Multi-Workflow-Setups verschiebt sich das Verhältnis weiter zugunsten der Per-Run-Kosten.

Vergleich Cloud-API vs. On-Premise — und EU-Region-Cloud ist nicht die Antwort

Die häufige Gegenfrage: "Warum nicht einfach eine Cloud-API benutzen — oder Azure EU / Google Cloud EU, wenn EU-Region das Compliance-Thema löst?"

Vier Antworten, in Reihenfolge der Schwere:

Datenhoheit (auch gegen EU-Hyperscaler). Inhalte gehen entweder durch eigene Infrastruktur oder nicht. Customer-Managed Keys und EU-Region reduzieren das Risiko, eliminieren es aber nicht — der Provider hält die Runtime-Umgebung. Bei US-Mutterkonzernen kommen CLOUD Act und FISA 702 hinzu, unabhängig vom Hosting-Standort. On-premise eliminiert diese Kategorie komplett.

Modell-Stabilität und Audit-Reproduzierbarkeit. Auch Azure OpenAI und Google Vertex deprecaten Modelle und ändern Quotas. Was in Säule 3 oben beschrieben ist, gilt damit auch für EU-Region-Cloud — gepinnten Modell-Stand über mehrere Audit-Zyklen hinweg garantiert nur eine on-premise Architektur.

Compliance-Overhead-Kosten. NIS2 verlangt Lieferketten-Risikomanagement für jeden Cloud-Vendor in der Architektur. EU AI Act verlangt Provider/Deployer-Rollenklarheit und Record-Keeping über den Lebenszyklus. DSGVO verlangt laufende Bewertung der Angemessenheitsbeschlüsse. Jeder dieser Posten kostet Compliance-Personenzeit — Personentage pro Quartal, pro Vendor, pro Sub-Processor-Wechsel. Diese Kosten stehen in keiner Token-Preisliste, sind aber real.

Kostenmodell. Eine ehrliche 1:1-Rechnung gegen Hyperscaler ist strukturell nicht möglich. On-premise heißt überwiegend fixe Plattform- und Hardware-Kosten, danach pro Lauf nahezu unverändert. Cloud-API heißt variable Token-Kosten, die linear mit der Nutzung wachsen. Sie kaufen entweder Vorhersagbarkeit (on-premise) oder Skalierungs-Elastizität (API). Was sich seriös vergleichen lässt, sind die Vollkosten pro Lauf gegen die Kosten der manuellen Arbeit. Das ist die Rechnung, die wir oben aufgemacht haben.

Indirekte Effekte, die in keine Tabelle passen

Drei Effekte sind real, aber lassen sich nur grob beziffern:

Audit-Vorbereitungs-Zeit: Ein Assessor will eine reproduzierbare Datenlage. Wenn die im Audit-Trail schon vorliegt, sparen Compliance-Teams nach unserer Erfahrung mehrere Personentage pro Audit-Zyklus.

Restrisiko übersehener Findings: Ein in einem Audit gefundener "missed impact" oder ein nachträglich entdeckter Daten-Fehler kostet Nachprüfung, Korrektur, ggf. Re-Approval. Ein einziger solcher Vorgang kostet schnell mehrere Tausend Euro.

Kapazität für Senior-Profile: Wer mehrere Stunden operative Analyse-Arbeit pro Workflow nicht mehr selbst macht, kann strategische Reviews, Risiko-Analysen oder Architektur-Arbeit ziehen, die vorher liegen blieb. Schwer zu monetarisieren, aber im Vorgesetzten-Gespräch oft das beste Argument.

Was wir nicht versprechen

On-premise KI ersetzt keine Fach-Expertin. Sie nimmt Reibung weg, nicht Verantwortung.

Bench-Werte sind Bench-Werte. Auf realen Datenlagen mit unsauberen Strukturen, abweichenden Formulierungen und Domain-Mischungen erwarten wir niedrigere Erkennungs-Raten als auf einer kontrollierten Test-Datenlage. Wir empfehlen jedem Pilotkunden, gegen eigene Vergleichsdaten zu validieren. Setup dauert unter einer Stunde.

Plattform-Vollkosten sind keine Magie. Bei sehr kleiner Last (≤2 Läufen/Monat) und nur einem isolierten Workflow-Schwerpunkt lohnt sich on-premise nicht. Wir empfehlen in solchen Fällen aktiv den Verzicht oder ein Shared-Tenancy-Modell.

Wann sich die Rechnung trägt — und wann nicht

Die vier Säulen tragen on-premise KI nur, wenn ein konkretes Setup darauf passt. Unsere Erfahrung aus mehreren Pilot-Projekten:

Wann sich on-premise KI lohnt:

Mindestens ein laufender Workflow mit signifikantem Volumen (~5 Läufe/Monat aufwärts)

Plus die Option, weitere Workflow-Klassen auf derselben Infrastruktur aufzubauen

Compliance-Druck, Datenresidenz-Anforderung oder Audit-Trail-Pflicht

Wann nicht:

Ad-hoc-Nutzung ohne Skalierungs-Perspektive

Reine Cloud-Strategie ohne Compliance-Pflicht

Kein klar definierter Workflow-Schwerpunkt

Abschließend: Die Vollkostenrechnung dieses Modells umfasst Plattform-Software-Anteil, Inferenz-Server inkl. Strom und Wartung, sowie Personalanteil. Keine versteckten Posten — auch keine Compliance-Overhead-Kosten, weil die im on-premise Setup gegen Null gehen. Wer das Modell auf das eigene Setup anwenden will, kann sich melden — wir rechnen es gemeinsam durch und sagen offen, ob sich on-premise im jeweiligen Fall lohnt. Die Antwort ist nicht immer "ja".

ISUDO Camemi — eine Agenten-Plattform für Enterprise-Workflows mit eingebautem Human-in-the-Loop und auditierbarem Trail. Demo-Anfragen und konkrete Konditionen: c.muelder@isu-do.com