Die sicherste KI ist die, die gar nicht im Internet erreichbar ist. Das ist der fundamentale Vorteil der lokalen KI: Ihr Server hat keine öffentliche IP, kein Internet-Bein, keine externen API-Endpunkte. Aber – und das ist der Punkt – «nicht im Internet» allein reicht nicht. Sie brauchen ein sauberes Netzwerk-Setup, Zugangskontrolle und ein Patching-Regime, damit der Server im Inneren Ihres Netzwerks sicher bleibt.
Im Folgenden erklären wir konkret, wie LokaleKI Ihre lokale KI absichert: Firewall-Regeln, VLAN-Konfiguration, Zugangskontrolle, Patching, Monitoring. Alles, was Sie für ein seriöses Security-Setup brauchen – ohne dass Ihre IT-Arbeit dadurch explodiert.
Netzwerk-Isolation: die erste und wichtigste Schicht
Die wichtigste Regel: Ihr KI-Server ist nur aus Ihrem internen Netzwerk erreichbar, nicht vom Internet. In der Praxis heißt das:
- Keine öffentliche IP: Der Server hängt hinter Ihrer Firewall und ist nur intern erreichbar. Kein Port-Forwarding, kein DMZ-Bein, keine externe API.
- Dediziertes VLAN: Wir setzen den KI-Server in ein separates VLAN (eigenes Subnetz), isoliert vom restlichen Firmennetz. Wenn ein Angreifer einen anderen PC in Ihrem Netzwerk kompromittiert, hat er keinen direkten Zugriff auf den KI-Server – er muss erst die Firewall-Regeln überwinden.
- Firewall-Regeln: Die Firewall lässt nur Traffic vom internen VLAN zum KI-Server durch. Kein eingehender Traffic von außen. Ausgehend nur auf Port 443, wenn Sie RAG-Dokumente aus einer externen Quelle importieren wollen (optional, sonst auch das abschalten).
- Physische Sicherheit: Der Server steht in einem kontrollierten Raum (Serverraum oder abgetrennte Ecke). Kein physischer Zugang für Unbefugte. Optional: Kensington-Lock, Rack-Lock.
Genau das ist der Unterschied zu Cloud-KI: Bei der Cloud wissen Sie nie, wo die Daten liegen, wer physischen Zugang zum Rechenzentrum hat, welche Subkontractoren sie sehen. Bei der lokalen KI kontrollieren Sie das – Sie kennen den Raum, Sie kennen das Kabel, Sie können den Server physisch abschalten.
Zugangskontrolle: wer darf die KI nutzen
Open WebUI unterstützt Benutzerverwaltung – jeder Mitarbeiter hat seinen eigenen Account. In der Praxis setzen wir das so auf:
- SSO / LDAP / Active-Directory-Anbindung: Ihre Mitarbeiter loggen sich mit ihrem existierenden Firmen-Account ein (Azure AD, Google Workspace, lokales LDAP). Kein neues Passwort, keine zusätzliche Verwaltung. Wenn ein Mitarbeiter austritt, wird sein Zugang automatisch deaktiviert (über die AD-Policy).
- Rollen-basierte Zugangskontrolle (RBAC): Standard-User (Chat + RAG), Admin (Korpus verwalten, Modelle wechseln), Super-Admin (System-Konfiguration). Die meisten Mitarbeiter brauchen nur Standard-User.
- 2FA (optional): Für Admin-Accounts aktivieren wir Zwei-Faktor-Authentifizierung. Für Standard-User in der Regel nicht nötig (SSO reicht).
- Audit-Logs: Jeder Login, jede Anfrage wird geloggt. Sie können nachschauen, wer wann was gefragt hat – wichtig für Compliance und interne Audits.
Der Punkt ist: Sie haben Kontrolle darüber, wer Zugang hat. Bei der Cloud-KI haben Sie das auch – aber der Zugriff läuft über eine externe Plattform, die Sie nicht physisch kontrollieren. Bei der lokalen KI ist der Zugang 100 % in Ihrer Hand – über Ihre AD, Ihre Firewall, Ihren Raum.
Patching: wie der Server aktuell bleibt
Eine lokale KI ist ein Server – und Server brauchen Patches. Das Patching-Regime, das wir einrichten:
- OS-Patches (Windows/Ubuntu): monatlich, im Wartungsfenster (nachts/Wochenende). Automatisch via WSUS (Windows) oder unattended-upgrades (Ubuntu).
- Ollama & Open WebUI: monatlich, manuell geprüft. Wir testen das Update auf der Testinstanz, dann Cutover auf Produktion.
- GPU-Treiber: quartalsweise, nur wenn NVIDIA ein Security-Release herausgibt. Wir prüfen vor dem Update, ob die Kompatibilität mit Ollama gegeben ist.
- Modell-Updates: wie oben beschrieben – nicht automatisch, sondern bewusst und staged.
Das ist der Teil, den die meisten KMU unterschätzen: Ein Server, der nicht gepatcht wird, ist ein Sicherheitsrisiko – selbst wenn er nicht im Internet ist. Ein internes Malware-Befall kann den Server erreichen, wenn er nicht abgesichert ist. Unser Wartungsvertrag deckt das komplette Patching ab – Sie müssen sich nicht darum kümmern.
Monitoring und Logs: was Sie im Auge behalten
Ein sicherer Server ist ein überwachter Server. Wir richten ein Monitoring ein, das folgende Punkte abdeckt:
- Uptime & Erreichbarkeit: Läuft Ollama? Ist Open WebUI erreichbar? Ist die GPU in einem normalen Zustand?
- Security-Events: Fehlgeschlagene Logins, ungewöhnliche Zugriffs-Muster, Firewall-Events. Wenn etwas auffällt, bekommen Sie eine Benachrichtigung.
- Ressourcen: VRAM, CPU, RAM, Disk-Auslastung. Wenn der Disk über 85 % voll ist (RAG-Korpus wächst), bekommen Sie eine Warnung.
- Audit-Trail: Wer hat wann welche Dokumente in den RAG-Korpus geladen? Wer hat wann welche Modell-Konfiguration geändert? Das ist Ihr Nachweis für interne Audits und Compliance.
Die Logs bleiben lokal. Sie werden nicht in eine externe Cloud-Logging-Plattform geschickt – sie liegen auf dem Server selbst (oder auf einem separaten Log-Server im selben VLAN). Kein Datenabfluss, keine externe Abhängigkeit.
Was Sie selbst tun müssen – und was wir übernehmen
Unsere Verantwortung (im Wartungsvertrag):
- Firewall-Regeln einrichten und aktualisieren.
- VLAN-Konfiguration beim Go-Live.
- Patching (OS, Ollama, Open WebUI, GPU-Treiber) – monatlich, im Wartungsfenster.
- Monitoring und Benachrichtigung bei Auffälligkeiten.
- Zugangskontrolle (RBAC, SSO-Anbindung, Account-Verwaltung).
Ihre Verantwortung (oder die Ihrer IT):
- AD / SSO-Policy: Wenn ein Mitarbeiter eintritt/austritt, wird sein Account über die AD-Policy aktiviert/deaktiviert. Wir koordinieren das mit Ihnen.
- Physische Sicherheit: Zugang zum Serverraum kontrollieren (Schloss, Zugangskarte, Schlüsselverwaltung).
- Neue Dokumente: Wenn Sie neue Dokumente in den RAG-Korpus laden, tun Sie das über Ihre Open-WebUI-Instanz mit Ihrem Admin-Account. Prüfen Sie, dass das Dokument dort hinein darf – der RAG-Korpus ist nur so gut wie die Dokumente, die Sie darin haben.
Die klare Aufteilung: Wir machen das Technische, Sie machen das Organisatorische. Zusammen ergibt das ein Security-Setup, das besser ist als die Cloud-KI – weil Sie es kontrollieren, physisch und logisch.