Lokale KI und Datenschutz: Warum dein eigener Server nicht automatisch sicherer ist

"Lokale KI ist datenschutzfreundlicher." Diesen Satz liest du gerade in Dauerschleife, meistens unter einem Screenshot von Ollama oder einem selbstgehosteten Open WebUI. An der Idee ist auch etwas dran. Nur wird dabei fast immer Datenhoheit mit Datensicherheit verwechselt, und dieser Unterschied entscheidet darüber, ob dein Setup Kundendaten wirklich schützt oder sie einfach nur an einen anderen Ort verschiebt.

Datenhoheit heißt noch nicht Sicherheit

Datenhoheit bedeutet, dass du bestimmst, wo deine Daten liegen, wer sie verarbeitet und wer eben nicht. Kein Modelltraining mit deinen Inhalten, kein Transfer in ein Drittland, keine Abhängigkeit von Nutzungsbedingungen, die sich im nächsten Quartal ändern. Das ist ein starkes Argument für ein eigenes Setup, da gibt es nichts zu diskutieren.

Datensicherheit ist die andere Frage, nämlich ob jemand anderes an diese Daten kommt. Und dafür gibt es bei einer eigenen Maschine genau eine verantwortliche Person, dich. Die DSGVO nimmt dir das nicht ab, im Gegenteil. Artikel 32 verlangt angemessene technische und organisatorische Maßnahmen, und ein Server mit Passwort-Login, offenen Ports und einem Betriebssystem von vor acht Monaten erfüllt das nicht. Wenn dort Kundendaten abfließen, hast du nach Artikel 33 außerdem 72 Stunden, um das der Aufsichtsbehörde zu melden. Nicht dein Anbieter, du.

Bei einem Cloud-Dienst mit Auftragsverarbeitungsvertrag bleibst du rechtlich zwar auch in der Verantwortung, aber die Absicherung der Infrastruktur macht dort ein Team, das genau das den ganzen Tag tut. Das ist der Teil, der in der Diskussion meistens unter den Tisch fällt.

Dein VPS ist keine lokale Lösung

Noch ein Denkfehler, der sich hartnäckig hält. Ein VPS bei Ionos, Hetzner oder einem anderen Anbieter ist nicht "lokal". Das ist Cloud, nur mit dir als Administrator. Die Maschine hängt mit einer öffentlichen IP im Netz, und ab der ersten Minute probieren automatisierte Bots dort Benutzernamen und Passwörter durch. Das ist kein Angriff auf dich persönlich, das passiert bei jeder neuen IP.

Dazu kommt die Software, die du draufpackst. Ollama lauscht auf Port 11434 und bringt von Haus aus keine Authentifizierung mit. Lokal gebunden ist das unkritisch, aber viele Tutorials erklären dir, wie du den Dienst auf 0.0.0.0 öffnest, damit du vom Laptop oder Handy drankommst. Wenn dann die Firewall nicht sauber gesetzt ist, kann jeder mit deinem Modell sprechen und auf alles zugreifen, was du dort angebunden hast.

Sechs Schritte, mit denen du deinen Server härtest

Die gute Nachricht: Der größte Teil der Angriffsfläche verschwindet mit Maßnahmen, die du an einem Nachmittag umsetzt.

1. SSH nur per Schlüssel. Lege ein Schlüsselpaar an, hinterlege den öffentlichen Teil auf dem Server und schalte den Passwort-Login danach komplett ab. Ein Passwort lässt sich erraten, ein kryptografischer Schlüssel praktisch nicht.
2. Root-Login deaktivieren. Arbeite über einen normalen Benutzer mit sudo. Damit kennt ein Angreifer nicht mehr automatisch den halben Zugang, denn "root" heißt auf jedem Linux-Server gleich.
3. Firewall aktivieren. Fast jeder Anbieter liefert eine Firewall im Kundenmenü mit. Lass nur die Ports offen, die du wirklich brauchst, alles andere zu. Dein KI-Dienst gehört nicht ins offene Netz, sondern hinter einen Reverse Proxy mit TLS oder in ein VPN.
4. Fail2Ban installieren. Das Tool liest die Logs mit und sperrt IP-Adressen, die wiederholt erfolglos versuchen, sich anzumelden. Gegen das permanente Brute-Force-Rauschen ist das extrem wirksam.
5. Automatische Sicherheitsupdates einschalten. Wenn du nicht täglich selbst nachschaust, lass das System die kritischen Patches allein ziehen. Unter Debian und Ubuntu erledigt das unattended-upgrades.
6. Backups per Cronjob, verschlüsselt und getestet. Ein Backup-Skript schreibt dir jedes halbwegs brauchbare KI-Modell in wenigen Minuten, den Rhythmus legst du über einen Cronjob fest. Wichtig ist der Schritt, den fast alle überspringen: Spiel das Backup einmal probeweise zurück. Vorher weißt du nicht, ob es funktioniert.

Wann du sensible Daten besser nicht selbst hostest

Ich finde, jeder, der ernsthaft mit KI arbeitet, sollte ein eigenes Setup einmal aufgebaut haben. Du verstehst danach deutlich besser, was in so einem Modell eigentlich passiert. Ich teste lokale Modelle selbst auf einem Mac Mini, und für Experimente, interne Notizen oder Textarbeit ohne Personenbezug ist das völlig in Ordnung.

Sobald echte Kundendaten, Gesundheitsdaten oder Bewerbungsunterlagen durch die Maschine laufen, ist die Frage nicht mehr, welches Modell du nimmst, sondern wer den Server überwacht, Updates prüft und im Fall eines Vorfalls reagiert. Wenn du darauf keine klare Antwort hast, ist ein europäischer Anbieter mit saubererem Vertrag die ehrlichere Wahl als ein Server, den du nach dem Aufsetzen nie wieder angeschaut hast.

Fazit

Datenhoheit gewinnst du mit der Entscheidung für ein eigenes Setup. Datensicherheit gewinnst du erst mit der Arbeit danach, und die ist weniger aufwendig, als die meisten denken. Schlüssel statt Passwort, Root zu, Firewall an, Fail2Ban drauf, Updates automatisch, Backup getestet.

Hängst du bei einem dieser Schritte fest oder bist du unsicher, ob dein Setup Kundendaten verträgt? Schreib mir eine DM, dann gehen wir das gemeinsam durch. Und wenn du praxisnahe KI-Workflows ohne Fachgelaber suchst, folge mir hier, ich zeige regelmäßig, wie so etwas Schritt für Schritt aufgebaut wird.