On-Premise-KI als Sicherheitsstrategie: Was Gemma 4 für den Datenschutz bedeutet
7 Min. Lesezeit
Jede Anfrage an einen Cloud-KI-Dienst ist ein Datentransfer an einen Drittanbieter. Mit Open-Source-Modellen wie Googles Gemma 4 lässt sich KI erstmals in produktionsreifer Qualität vollständig On-Premise betreiben. Für Security-Teams ändert das die Risikobewertung fundamental: Kein Datenabfluss, keine Drittanbieter-Abhängigkeit, keine Compliance-Grauzone.
Das Wichtigste in Kürze
- Cloud-KI-Dienste übertragen bei jeder Anfrage Unternehmensdaten an Server in den USA oder China – ein permanentes Risiko für Vertraulichkeit und Compliance.
- Googles Gemma 4 (Apache-2.0-Lizenz) läuft vollständig lokal und erreicht Benchmark-Werte auf dem Niveau deutlich größerer Modelle.
- On-Premise-KI eliminiert den Datenabfluss an Dritte und vereinfacht die DSGVO-Konformität – kein Drittland-Transfer, kein Data Processing Agreement nötig.
- Für NIS2-pflichtige Unternehmen reduziert lokale KI die Angriffsfläche: keine zusätzlichen API-Schnittstellen, keine Abhängigkeit von externen Dienstverfügbarkeiten.
- Air-Gapped-Betrieb ist möglich – das Modell braucht nach dem Download keine Internetverbindung.
Das Risiko der Cloud-KI: Jede Anfrage ist ein Datentransfer
Wenn ein Mitarbeiter einen Vertragsentwurf von ChatGPT zusammenfassen lässt, eine Support-Anfrage durch einen Cloud-KI-Dienst klassifiziert oder ein internes Dokument analysieren lässt, geschieht immer dasselbe: Die Daten verlassen das Unternehmen. Sie werden an Server übertragen, die in der Regel in den USA stehen – bei Anbietern wie OpenAI, Google oder Anthropic.
Chinesische Alternativen wie DeepSeek verschärfen das Problem zusätzlich: Hier landen Daten in einer Jurisdiktion, deren Datenschutzstandards für europäische Unternehmen kaum überprüfbar sind.
Für IT-Security-Teams ist das keine theoretische Sorge. Die konkreten Risiken:
Vertraulichkeitsverlust: Geistiges Eigentum, Kundendaten, interne Strategiepapiere und Geschäftsgeheimnisse werden einem Drittanbieter zugänglich – unabhängig davon was in dessen Datenschutzrichtlinien steht. Die Kontrolle über die Datenverarbeitung liegt beim Anbieter, nicht beim Unternehmen.
Compliance-Risiko: Der Transfer personenbezogener Daten in Drittländer erfordert nach DSGVO zusätzliche Schutzmaßnahmen (Standardvertragsklauseln, Transfer Impact Assessments). Viele Unternehmen nutzen Cloud-KI ohne diese Maßnahmen formell umgesetzt zu haben.
Supply-Chain-Risiko: Jede API-Verbindung zu einem Cloud-KI-Dienst ist eine zusätzliche Angriffsfläche. API-Schlüssel können kompromittiert werden, der Anbieter kann Opfer eines Breaches werden, oder die API-Verfügbarkeit kann ausfallen. Für NIS2-pflichtige Unternehmen ist jede dieser Abhängigkeiten ein Punkt der dokumentiert, bewertet und überwacht werden muss.
Gemma 4: Was lokale KI jetzt leisten kann
Open-Source-Modelle gab es schon länger. Was sich mit Gemma 4 ändert: Die Modelle sind erstmals klein genug für Standardhardware und gut genug für produktive Anwendungsfälle, die bisher nur über Cloud-APIs möglich waren.
Das 31B-Dense-Modell belegt Platz 3 auf dem Arena AI Text Leaderboard (ELO 1452) – hinter Modellen die ein Vielfaches an Rechenleistung benötigen. Es unterstützt nativ Function Calling, strukturierten JSON-Output und verarbeitet bis zu 256.000 Token Kontext. Die kleineren Varianten (E2B, E4B) laufen auf Smartphones und IoT-Geräten.
Alle vier Modellgrößen stehen unter der Apache-2.0-Lizenz. Das bedeutet: keine Einschränkungen für kommerzielle Nutzung, keine Lizenzgebühren, keine Nachberichtspflicht an Google. Das Modell kann heruntergeladen, in eine Offline-Umgebung übertragen und dort unbegrenzt betrieben werden.
Security-Bewertung: Was On-Premise-KI besser macht
Für die Risikobewertung sind drei Aspekte entscheidend:
Datenhoheit: Bei lokaler Inferenz verlassen die Daten den Rechner nicht. Kein API-Call, keine Netzwerkkommunikation, keine Zwischenspeicherung auf fremden Servern. Das ist nicht nur ein Datenschutz-Argument – es eliminiert eine ganze Klasse von Angriffsvektoren (Man-in-the-Middle, API-Compromise, Drittanbieter-Breach).
Reduzierte Angriffsfläche: Cloud-KI-APIs erfordern Authentifizierung per API-Key, regelmäßige Kommunikation über das Internet und Vertrauen in die Sicherheitsmaßnahmen des Anbieters. Lokale KI braucht nichts davon. In Air-Gapped-Umgebungen lässt sich ein lokales Modell betreiben, das keinerlei Netzwerkzugang hat.
„Gemma 4 ist unter der kommerziell freizügigen Apache-2.0-Lizenz veröffentlicht. Nutzen Sie es.“
– Google, Gemma-4-Ankündigung (April 2026)
Compliance-Vereinfachung: Der gesamte Komplex des Drittland-Transfers nach Art. 44-49 DSGVO entfällt bei lokaler Verarbeitung. Kein Transfer Impact Assessment, keine Standardvertragsklauseln, kein Data Processing Agreement mit einem US-Anbieter. Für DSGVO-Beauftragte ist das eine massive Entlastung.
Relevanz für NIS2-pflichtige Unternehmen
NIS2 verpflichtet betroffene Unternehmen zur Risikobewertung ihrer gesamten Lieferkette – einschließlich digitaler Dienste. Jeder Cloud-KI-Anbieter ist ein Glied in dieser Kette. Jede API-Abhängigkeit muss dokumentiert, das Ausfallrisiko bewertet und Alternativmaßnahmen definiert werden.
Lokale KI vereinfacht diese Bewertung erheblich: Kein externer Dienst bedeutet kein Lieferkettenrisiko für diesen spezifischen Baustein. Die Verfügbarkeit liegt vollständig in der Hand des eigenen IT-Teams. Ein Ausfall bei OpenAI oder Google betrifft die eigene KI-Infrastruktur nicht.
Das heißt nicht, dass lokale KI keine eigenen Risiken hat. Die Hardware muss gewartet, die Modelle aktualisiert und der Zugriff kontrolliert werden. Aber diese Risiken sind intern steuerbar – und damit in der NIS2-Dokumentation deutlich einfacher abzubilden als externe Abhängigkeiten.
Was On-Premise-KI nicht löst
Lokale KI ist kein Allheilmittel. Drei Einschränkungen sollten Security-Teams kennen:
Modell-Sicherheit: Ein lokales Modell kann genauso halluzinieren, voreingenommene Outputs liefern oder manipuliert werden wie ein Cloud-Modell. Die Verantwortung für Output-Validierung liegt beim Betreiber – ohne den Sicherheitslayer den Cloud-Anbieter typischerweise vorschalten.
Update-Management: Cloud-KI-Dienste werden zentral aktualisiert. Bei lokalen Modellen liegt das Update-Management beim eigenen Team. Sicherheitsrelevante Patches für Inference-Frameworks (Ollama, vLLM) müssen zeitnah eingespielt werden.
Zugriffskontrolle: Ein lokal laufendes Modell ist nur so sicher wie die Infrastruktur auf der es läuft. Wer einen lokalen KI-Server betreibt, braucht Zugriffskontrolle, Logging und Monitoring – die gleichen Maßnahmen die für jeden internen Dienst gelten.
Handlungsempfehlung für Security-Teams
Die Kombination aus produktionsreifer Qualität, Apache-2.0-Lizenz und lokalem Betrieb macht Modelle wie Gemma 4 zu einer ernsthaften Option für Unternehmen, die KI nutzen wollen ohne ihre Sicherheitsanforderungen zu kompromittieren.
Drei konkrete Schritte:
1. Audit der bestehenden KI-Nutzung: Wo werden heute Cloud-KI-APIs genutzt? Welche Daten fließen dabei ab? Sind die Datenschutz-Maßnahmen (DPA, TIA) formell umgesetzt?
2. Pilot mit Gemma 4 On-Premise: Einen konkreten Use Case identifizieren (Dokumentenklassifizierung, E-Mail-Triage, Code-Review) und das Modell auf eigener Hardware testen. Qualität und Performance mit dem Cloud-Dienst vergleichen.
3. Hybride Architektur definieren: Für welche Aufgaben reicht lokale KI? Wo bleibt Cloud-KI nötig? Die Routing-Entscheidung nach Sensitivität der Daten treffen: Vertrauliche Daten lokal, unkritische Daten optional über Cloud-APIs.
Häufige Fragen
Ist lokale KI automatisch DSGVO-konform?
Die DSGVO-Konformität bezieht sich auf den Wegfall des Drittland-Transfers (Art. 44-49 DSGVO). Die übrigen DSGVO-Pflichten (Zweckbindung, Datenminimierung, Betroffenenrechte, Verzeichnis der Verarbeitungstätigkeiten) gelten weiterhin – unabhängig davon ob die Verarbeitung lokal oder in der Cloud stattfindet. Lokale KI vereinfacht die Compliance, ersetzt sie aber nicht.
Kann ein lokales KI-Modell gehackt werden?
Das Modell selbst ist eine statische Datei (Gewichte und Konfiguration). Es kann nicht im klassischen Sinn „gehackt“ werden. Angriffsszenarien betreffen die Infrastruktur drumherum: Prompt Injection (manipulierte Eingaben die das Modellverhalten ändern), Zugriff auf den Server auf dem das Modell läuft, oder Manipulation der Modell-Dateien. Die Schutzmaßnahmen sind dieselben wie für jeden internen Dienst: Zugriffskontrolle, Input-Validierung, Integritätsprüfung.
Muss ich bei On-Premise-KI trotzdem ein KI-Risiko-Assessment nach EU AI Act machen?
Das hängt vom Einsatzzweck ab, nicht vom Betriebsort. Wenn das KI-System in einen Anwendungsbereich fällt, den der AI Act als hochriskant klassifiziert (Personalwesen, Kreditvergabe, kritische Infrastruktur), gelten die Dokumentations- und Risikomanagement-Pflichten unabhängig davon ob das Modell lokal oder in der Cloud läuft. Der Vorteil lokaler KI: Sie haben volle Kontrolle über Dokumentation, Logging und Modellverhalten.
Welche Hardware braucht ein Security-Team für lokale KI?
Für das 31B-Modell: Eine GPU mit mindestens 24 GB VRAM (Nvidia RTX 4090 oder vergleichbar) und 64 GB System-RAM. Für Air-Gapped-Betrieb: Das Modell wird einmal auf einem internetfähigen Rechner heruntergeladen, auf einen USB-Stick oder ein Netzlaufwerk kopiert und auf dem Zielrechner ohne Internetverbindung installiert. Der laufende Betrieb erfordert keinen Netzwerkzugang.
Wie vergleicht sich die Antwortqualität mit Cloud-Diensten wie ChatGPT?
Für Standardaufgaben (Klassifizierung, Zusammenfassung, Datenextraktion, Übersetzung) ist die Qualität von Gemma 4 31B vergleichbar mit aktuellen Cloud-Diensten. Bei sehr komplexen Analyseaufgaben und hochkreativen Anwendungen haben Frontier-Modelle der Cloud-Anbieter noch einen Vorsprung. Für Security-spezifische Aufgaben (Log-Analyse, Regelgenerierung, Dokumentenprüfung) berichten erste Anwender von praxistauglichen Ergebnissen.
Quelle Titelbild: Pexels
