KI on-premise: was der Einstieg tatsächlich verlangt

TL;DR

On-premise heißt: Die Modelle laufen auf Hardware, die Ihnen gehört und in Ihren Räumen steht. Nötig sind vier Dinge — eine GPU-Maschine, ein Stellplatz mit Strom und Kühlung, jemand mit Linux-Kenntnissen und ein Update-Konzept. Der Einstieg beginnt bei einer einzelnen Workstation. Ohne interne IT-Kapazität raten wir zur Cloud.

Drei Begriffe, die ständig verwechselt werden

On-premise ist eine Aussage über den Ort, nicht über die Technik. Die Maschine steht in einem Raum, für den Sie den Schlüssel haben, in einem Gebäude, das Ihnen gehört oder das Sie gemietet haben. Niemand außer Ihnen hat physischen Zugriff.

Private Cloud ist etwas anderes. Das NIST definiert sie in SP 800-145 als Infrastruktur, die exklusiv für eine einzelne Organisation bereitgestellt wird — ausdrücklich unabhängig davon, ob sie im eigenen Haus oder bei einem Dienstleister steht und wer sie betreibt. Eine private Cloud kann on-premise sein. Sie muss es nicht.

Genau an dieser Stelle geht in Ausschreibungen und Anbietergesprächen regelmäßig etwas durcheinander. Ein dedizierter GPU-Server in einem Frankfurter Rechenzentrum, monatlich kündbar, mit Root-Zugang und Auftragsverarbeitungsvertrag — das ist eine gute Lösung, für viele Mittelständler sogar die pragmatischere. Aber es ist kein On-premise. Die Daten verlassen Ihr Haus, ein Dritter hat Zugriff auf das Blech, und wenn eine Kanzlei oder ein Krankenhaus diesen Weg gewählt hat, um ein Geheimhaltungsproblem zu lösen, ist es nicht gelöst, sondern verlagert.

Hybrid ist nach NIST-Lesart die Verbindung zweier eigenständiger Umgebungen, zwischen denen Daten und Anwendungen wandern können. In der Praxis meint es meistens etwas Simpleres und durchaus Sinnvolles: sensible Dokumente lokal, alles andere über eine API. Wir halten das für die realistischste Zielarchitektur im Mittelstand — nicht als fauler Kompromiss, sondern weil kaum ein Unternehmen für sämtliche Anwendungsfälle dasselbe Schutzniveau braucht.

Ein Missverständnis noch, das sich hartnäckig hält: On-premise befreit nicht von Regulierung. Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der KI-Verordnung. Wenn Ihre Belegschaft mit einem Chat-Assistenten spricht, muss sie wissen, dass sie mit einer Maschine spricht — daran ändert der Standort des Servers nichts. Die Hochrisiko-Pflichten aus Anhang III wurden mit dem Digital Omnibus auf den 2. Dezember 2027 verschoben; die Änderung ist am 27. Juli 2026 in Kraft getreten. Das ist Aufschub, keine Entwarnung.

Was Sie tatsächlich brauchen

Vier Dinge. Drei davon stehen in jedem Angebot, das vierte in keinem.

Die Hardware. Eine oder mehrere GPUs, genug Grafikspeicher für das Modell, das laufen soll, dazu reichlich System-RAM und schnelle NVMe-SSDs für die Dokumentenablage. Der Grafikspeicher ist die harte Grenze: Passt das Modell nicht hinein, wird es zäh. Welche Karte zu welchem Anwendungsfall gehört, steht im Sizing-Leitfaden nach Use-Case; konkrete Konfigurationen mit Komponenten stehen im Guide zu KI-Server-Konfigurationen.

Den Stellplatz. Strom, Kühlung, Netzwerk, abschließbar. Dazu gleich mehr — hier scheitern mehr Projekte als an der Technik.

Jemanden, der es betreibt. Ubuntu Server, NVIDIA-Treiber, Docker, ein Reverse Proxy mit Zertifikat, Anbindung ans Active Directory, Backup, Monitoring. Das ist kein exotisches Wissen, aber es ist Wissen, das jemand haben und behalten muss. Eine Person allein reicht nicht: Wenn dieser Mensch drei Wochen im Urlaub ist und die Inferenz steht, steht sie drei Wochen.

Ein Update-Konzept. Und das wird fast immer unterschätzt.

Was den Grafikspeicher wirklich füllt

Weil hier die meisten Fehlkäufe entstehen, lohnt der Blick auf die Belegung. Sie besteht aus zwei Posten. Die Modellgewichte sind der fixe Teil und lassen sich vorher ausrechnen: Ein Modell mit 32 Milliarden Parametern belegt bei 4-Bit-Quantisierung grob 32 Mrd. × 0,5 Byte, also rund 16 GB, plus etwas Overhead. Bei 8 Bit wären es rund 32 GB. Der zweite Posten ist der KV-Cache, und der ist nicht fix: Er wächst mit der Kontextlänge und mit jeder gleichzeitig laufenden Anfrage. Deshalb läuft ein Modell im Test einer einzelnen Person sauber und geht bei zehn parallelen Nutzern mit langen Dokumenten aus dem Speicher. Wer für fünfzehn Leute dimensioniert, muss diesen Puffer einplanen — er ist keine Reserve, sondern Betriebsbedarf.

Und eine Falle, in die 2026 fast jeder tappt: Mixture-of-Experts-Modelle werden mit zwei Parameterzahlen beworben, etwa "30 Milliarden gesamt, 3 Milliarden aktiv". Für den Speicherbedarf zählt allein die Gesamtzahl. Alle Experten müssen geladen sein, weil für jedes einzelne Token andere davon gebraucht werden — auf 3 Milliarden Parameter lässt sich nichts reduzieren. Die aktive Parameterzahl senkt ausschließlich die Rechenlast pro Token und damit die Geschwindigkeit. Unsere Empfehlung ist hier eindeutig: Dimensionieren Sie MoE-Modelle immer nach der Gesamtparameterzahl. Wer nach der aktiven Zahl kauft, bestellt eine Karte, in die sein Modell nicht hineinpasst, und merkt es erst beim ersten Ladeversuch.

Warum das Update-Konzept der kritische Punkt ist

Wir nehmen hier klar Stellung: Wer kein Update-Konzept hat, sollte nicht on-premise gehen. Nicht weil es unbequem wäre, sondern weil ein ungepatchter Inferenz-Server im Firmennetz eine offene Tür ist.

Das ist keine abstrakte Warnung. Drei Beispiele aus den vergangenen Monaten:

• CVE-2026-7482 in Ollama, CVSS 3.1 von 9.1, offengelegt am 1. Mai 2026, NVD-Eintrag vom 4. Mai. Über den nicht authentifizierten /api/create-Endpunkt lässt sich mit einer präparierten GGUF-Datei der komplette Prozessspeicher auslesen — inklusive Umgebungsvariablen, API-Schlüsseln, Systemprompts und den Gesprächen anderer Nutzer. Behoben in Version 0.17.1. Die Zahl der aus dem Internet erreichbaren Instanzen wurde in der Berichterstattung auf grob 300.000 geschätzt — eine Hochrechnung aus Portscans, keine belastbare Messung.
• CVE-2026-22778 in vLLM, CVSS 9.8, offengelegt am 2. Februar 2026. Remote Code Execution über eine präparierte Video-URL im Multimodal-Pfad, ohne Authentifizierung. Betroffen sind die Versionen 0.8.3 bis 0.14.0, behoben in 0.14.1.
• CVE-2026-44551 in Open WebUI, CVSS 9.1. Die LDAP-Anmeldung prüfte vor Version 0.9.0 nicht, ob überhaupt ein Passwort übermittelt wurde — ein leerer String genügte für ein gültiges Session-Token auf ein beliebiges Konto.

Drei kritische Lücken in genau den drei Komponenten, aus denen die allermeisten On-premise-Stacks im Mittelstand bestehen, innerhalb eines halben Jahres. Das ist normal für schnell wachsende Open-Source-Projekte, und es wird nicht aufhören.

Darunter liegt eine zweite Ebene mit längerem Takt. NVIDIA pflegt nach eigener Lifecycle-Policy für Rechenzentrumstreiber eine Production Branch rund ein Jahr mit Bugfixes und Sicherheitsupdates, eine Long-Term Support Branch drei Jahre. Ubuntu 24.04 LTS bekommt bis Juni 2029 Standard-Sicherheitsupdates, also fünf Jahre ab Release. Und die Modelle selbst wechseln noch schneller: Bei den offenen Familien — Qwen, Llama, Mistral, Gemma — liegen zwischen zwei Generationen derzeit Monate, nicht Jahre. Wer das Modell nie tauscht, arbeitet nach achtzehn Monaten mit spürbar schwächerer Qualität als der Wettbewerb, ohne dass jemals etwas "kaputtgegangen" wäre.

Konkret heißt Update-Konzept: ein benannter Verantwortlicher, ein fester Termin im Monat, ein Abo auf die Security-Advisories der eingesetzten Projekte, und eine Testinstanz, auf der ein Versionssprung schiefgehen darf. Der Aufwand liegt bei wenigen Stunden monatlich — solange es Routine ist. Ist es keine Routine, wird daraus im Ernstfall ein Wochenende.

# Wöchentlich: Läuft eine Version mit bekannter Lücke?
ollama --version
docker inspect --format='{{.Config.Image}}' open-webui
nvidia-smi --query-gpu=driver_version --format=csv,noheader

# Horcht der Dienst versehentlich auf allen Interfaces?
ss -tlnp | grep -E '11434|8080'

Zeigt die Ausgabe 0.0.0.0:11434 statt 127.0.0.1:11434, ist Ihr Inferenz-Dienst aus dem gesamten Netz erreichbar. Der Fehler liegt dabei nicht bei Ollama: Ausgeliefert wird die Bindung an 127.0.0.1, also rein lokal. Erreichbar wird der Dienst erst, wenn jemand OLLAMA_HOST=0.0.0.0 setzt — und das steht in fast jeder Anleitung, weil man sonst von keinem zweiten Rechner aus zugreifen kann. Genau hier ist unsere Position unmissverständlich: Wer diese Variable setzt, muss im selben Arbeitsschritt eine Authentifizierung davorschalten, üblicherweise einen Reverse Proxy. Die Ollama-API bringt keine mit. Wer sie ohne setzt, hat sein Modell ins offene Netz gestellt, ohne es zu merken.

Workstation oder Serverraum — wo die Schwelle liegt

230 Volt mal 16 Ampere sind 3.680 Watt. Das ist die theoretische Obergrenze einer normalen Schuko-Steckdose in Deutschland; für Dauerlast rechnet man vernünftigerweise mit etwa 80 Prozent davon, also gut 2.900 Watt. Eine GPU-Workstation mit einer einzelnen Karte zieht unter Volllast je nach Modell 600 bis 1.000 Watt. Sie liegt damit locker im Rahmen — vorausgesetzt, an demselben Stromkreis hängt nicht noch die Kaffeeküche.

Das Stromproblem ist also selten das Problem. Das Wärmeproblem schon.

Was an Leistung hineingeht, kommt als Wärme wieder heraus, praktisch eins zu eins. Rechnen wir das offen durch: 800 Watt Dauerlast in einer Abstellkammer von etwa 20 Kubikmetern. Bei einer Luftdichte von 1,2 kg/m³ stehen 24 kg Luft im Raum; mit einer spezifischen Wärmekapazität von rund 1,0 kJ/(kg·K) sind das 24 kJ pro Kelvin. 800 Watt sind 48 kJ pro Minute — macht rechnerisch rund zwei Kelvin pro Minute. Ein Teil geht über Wände und Türspalt weg, die Zahl ist also eine Obergrenze — die Richtung stimmt trotzdem. GPUs drosseln, bevor sie Schaden nehmen. Sie merken es deshalb nicht am Ausfall, sondern an einem Durchsatz, der nachmittags schlechter ist als morgens.

Die Faustregel, mit der wir arbeiten:

Und etwas, das in keinem Datenblatt steht: Lärm. Ein passiv gekühlter GPU-Rackserver wird von 40-mm-Lüftern durchblasen, die im Betrieb Pegel erreichen, bei denen sich niemand freiwillig im selben Raum aufhält. Eine Tower-Workstation ist deutlich leiser, unter Last aber immer noch hörbar. Stellen Sie sie nicht ins Großraumbüro.

Die laufenden Kosten sind bei einer Einzelmaschine überschaubar und trotzdem nicht null. Rechnen wir auch das offen: 300 Watt Durchschnittslast mal 8.760 Stunden sind 2.628 kWh im Jahr. Den Arbeitspreis setzen Sie aus Ihrem eigenen Vertrag ein — das ist der einzige Wert, der zählt. Zur Einordnung: Bei 27 ct/kWh landen Sie bei rund 710 Euro, bei 35 ct/kWh bei gut 920 Euro. Die Spannweite zeigt, dass diese Position ohnehin nicht die Entscheidung trägt. Der wirklich große Posten ist die Arbeitszeit — die haben wir in der Rechnung nach dem Kauf über 36 Monate offengelegt.

Drei Einstiegsszenarien und was nach vier Wochen wirklich steht

Was ist in einem Monat machbar? Weniger, als der Vertrieb sagt, und mehr, als die IT befürchtet.

Dokumentensuche über die eigene Ablage. Der häufigste Einstieg und der mit dem klarsten Nutzen. Dokumente werden in Abschnitte zerlegt, in Vektoren übersetzt und in einer Datenbank abgelegt; bei einer Frage sucht das System die passenden Stellen heraus und lässt das Modell daraus antworten, mit Quellenangabe. Realistisch in vier Wochen: eine klar abgegrenzte Ablage, etwa ein Laufwerk mit 5.000 bis 20.000 PDFs, lesend, für eine Fachabteilung. Nicht realistisch in vier Wochen: die komplette Dateiablage inklusive Berechtigungslogik. Wer will, dass jeder nur findet, was er auch öffnen darf, startet damit ein Berechtigungsprojekt, kein KI-Projekt — und das dauert Monate.

Interner Chat-Assistent. Technisch der einfachste Fall. Ollama plus Open WebUI plus Anbindung ans Active Directory steht bei sauberer Vorbereitung in wenigen Tagen. Die vier Wochen gehen für etwas anderes drauf: Nutzungsrichtlinie, Logging-Konzept, Betriebsrat. Ein System, das protokolliert, wer wann was fragt, ist eine technische Einrichtung im Sinne von § 87 Abs. 1 Nr. 6 BetrVG und damit mitbestimmungspflichtig. Wer die Betriebsvereinbarung erst anstößt, wenn der Server schon läuft, verliert mehr Zeit als bei jedem Treiberproblem. Der Einstieg über Ollama auf Ubuntu ist der schnellste Weg zu einer laufenden Instanz.

Übersetzung und Zusammenfassung. Unterschätzt, und aus unserer Sicht der beste erste Anwendungsfall überhaupt. Keine Interaktivität, keine Latenzanforderung, kein Berechtigungsmodell — Dateien rein, Ergebnis raus, nachts. Protokolle, Normtexte, Lieferantenkorrespondenz, technische Dokumentation. Das läuft auf kleiner Hardware, ist in vier Wochen inklusive Qualitätsstichprobe fertig, und Sie lernen dabei genau die Dinge über Modellauswahl und Betrieb, die Sie für die beiden anderen Szenarien brauchen.

Wann Sie es lassen sollten

Es gibt drei Konstellationen, in denen wir vom eigenen Server abraten — und zwar deutlich.

Keine interne IT-Kapazität. Wenn Ihre IT aus zwei Leuten besteht, die ohnehin am Anschlag laufen, oder wenn die Server-Administration bei einem externen Dienstleister liegt, der Linux nur ungern anfasst: Lassen Sie es. Ein KI-Server ist kein Gerät, das man aufstellt und vergisst. Die Alternative ist nicht schlecht — eine EU-gehostete API oder ein gemieteter GPU-Server mit AV-Vertrag löst einen Großteil der Datenschutzsorgen ohne Betriebslast. Wie sich das rechnet, steht im Vergleich zwischen Miete und Kauf.

Stark schwankende Last. Der eigene Server kostet gleich viel, ob er rechnet oder nicht. Wenn Sie an drei Tagen im Monat Vollgas brauchen und sonst nichts, zahlen Sie 27 Tage lang Abschreibung und Strom für ein Gerät im Leerlauf. Genau für dieses Profil ist nutzungsabhängige Abrechnung gebaut. Der eigene Server gewinnt bei gleichmäßiger, hoher Grundlast — nicht bei Spitzen.

Pilotprojekt ohne klaren Anwendungsfall. Der teuerste Fehler. Hardware kaufen, um anschließend herauszufinden, wofür man sie einsetzt, endet mit einem gut gekühlten Heizkörper im Rack. Sie kennen die Lastprofile noch nicht, also können Sie nicht dimensionieren, also kaufen Sie falsch — zu klein, wenn Sie sparsam sind, zu groß, wenn Sie sich beraten lassen.

Unsere Empfehlung in allen drei Fällen: erst Cloud, dann messen, dann entscheiden. Die ausführliche Gegenüberstellung beider Wege steht im Vergleich Self-Hosted gegen Cloud.

Der Migrationspfad: klein anfangen, messen, entscheiden

Kein Big Bang. Die Reihenfolge, die in der Praxis funktioniert, hat vier Schritte.

1. Sechs bis acht Wochen über eine API arbeiten. Ein echter Anwendungsfall, echte Nutzer, echte Dokumente — nur eben noch nicht lokal. Ziel ist nicht die fertige Lösung, sondern die Messung.
2. Zahlen mitschreiben. Anfragen pro Tag, Token pro Anfrage, Spitzen nach Uhrzeit, Kontextlänge, wie viele Leute gleichzeitig warten. Diese fünf Werte bestimmen später die Hardware. Ohne sie ist jede Kaufentscheidung geraten.
3. Rechnen, mit Arbeitszeit. Cloud-Kosten gegen Anschaffung plus Strom plus Betriebsaufwand. Der KI-Kosten-Kalkulator nimmt Ihnen die Struktur ab. Geht die Rechnung knapp aus, hat die Cloud gewonnen: Bei Gleichstand ist der Weg ohne Betriebsrisiko der bessere.
4. Erst dann kaufen — und beim Speicher eine Nummer größer. Wenn Ihr Anwendungsfall heute mit 24 GB Grafikspeicher auskommt, absehbar aber ein größeres Modell braucht, ist die nächstgrößere Karte beim Erstkauf fast immer günstiger als der Tausch in achtzehn Monaten.

Was in diesem Ablauf bewusst fehlt: eine Machbarkeitsstudie. Sechs Wochen mit echten Nutzern liefern belastbarere Erkenntnisse als jedes Konzeptpapier, und sie kosten weniger. Wenn Sie zuerst klären wollen, was hinter dem Begriff technisch steckt, hilft die Definition und Einordnung eines KI-Servers.

FAQ

Was bedeutet KI on-premise genau?

On-premise bedeutet, dass die KI-Modelle auf Hardware laufen, die im eigenen Gebäude steht und der eigenen Organisation gehört. Weder die Anfragen noch die verarbeiteten Dokumente verlassen das Firmennetz. Ein gemieteter GPU-Server in einem externen Rechenzentrum ist dagegen kein On-premise, auch wenn er dediziert ist und in Deutschland steht — dort hat ein Dritter physischen Zugriff auf die Maschine.

Was kostet der Einstieg in KI on-premise?

Der Einstieg beginnt bei einer einzelnen GPU-Workstation im mittleren vierstelligen Bereich. Dazu der Strom: 300 Watt Durchschnittslast im Dauerbetrieb sind 2.628 kWh im Jahr, bei angenommenen 27 ct/kWh also rund 710 Euro — den Arbeitspreis aus Ihrem eigenen Vertrag einsetzen. Der größere Posten ist die Arbeitszeit für Betrieb, Patches und Modellwechsel: Wenige Stunden im Monat sind realistisch, in Vollkosten gerechnet übersteigt das bei kleinen Installationen oft die Hardwarekosten.

Was ist der Unterschied zwischen on-premise und private Cloud?

On-premise beschreibt den Standort: Die Hardware steht in Ihrem Gebäude. Private Cloud beschreibt das Betriebsmodell — Infrastruktur, die exklusiv für eine Organisation bereitgestellt wird, laut NIST-Definition aber ebenso beim Dienstleister stehen und von diesem betrieben werden kann. Jede On-premise-Installation kann eine private Cloud sein, längst nicht jede private Cloud steht bei Ihnen im Haus.

Welche Voraussetzungen braucht ein Unternehmen für On-premise-KI?

Vier: eine GPU-Maschine mit ausreichend Grafikspeicher für das gewünschte Modell, einen Stellplatz mit eigenem Stromkreis und Luftaustausch, mindestens zwei Personen mit Linux- und Netzwerkkenntnissen sowie ein verbindliches Update-Konzept mit festem Termin. Fehlt eines der vier — insbesondere das letzte — ist eine EU-gehostete API die risikoärmere Wahl.

Ist On-premise-KI automatisch DSGVO-konform?

Nein. Der lokale Betrieb löst die Frage nach Drittlandtransfers und externen Auftragsverarbeitern, ersetzt aber weder Verarbeitungsverzeichnis noch Rechtsgrundlage noch Zugriffskonzept. Auch die Transparenzpflichten aus Artikel 50 der KI-Verordnung, die seit dem 2. August 2026 gelten, greifen unabhängig vom Standort des Servers: Beschäftigte müssen wissen, wenn sie mit einem KI-System interagieren.

Der nächste Schritt

Beantworten Sie eine einzige Frage, bevor Sie über Hardware sprechen: Welcher konkrete Anwendungsfall soll in vier Wochen produktiv sein, und wer benutzt ihn? Daraus ergeben sich Modellgröße, Grafikspeicher und Stellplatzanforderung — nicht umgekehrt. Wenn Sie diese Frage beantwortet haben und wissen wollen, welche Maschine dazu passt, sprechen Sie mit uns.