Irgendwann hatte ich ein Problem, das ich nicht ignorieren konnte.
Ich saß an einem Forensik-Fall. Ransomware, mittelständisches Unternehmen, klassisches Szenario. Ich hatte Logs, ich hatte Artefakte, ich hatte Fragen, und ich hatte ein KI-Modell, das mir helfen konnte, Muster schneller zu erkennen.
Aber die Daten, um die es ging, gehörten meinem Kunden. Sie enthielten interne Netzwerkstrukturen, Benutzernamen, Prozessnamen, Zeitstempel von Aktionen, die niemand außerhalb des Unternehmens hätte kennen sollen.
Diese Daten in GPT-4 einzutippen wäre so gewesen, als hätte ich die Akte auf einem Café-Tisch liegen gelassen.
Das Cloud-Problem ist kein theoretisches
Viele Kollegen sehen das anders. "OpenAI hat Enterprise-Verträge. Deine Daten werden nicht trainiert." Das stimmt, heute. Mit dem richtigen Vertrag. Für den richtigen Tarif.
Aber das ist nicht der einzige Punkt.
Als jemand, der Incident Response macht, weiß ich: Der Angriff auf einen Cloud-Anbieter ist attraktiver als der Angriff auf einen einzelnen Kunden. Die Angriffsfläche ist kleiner aus meiner Sicht, aber die Angriffsfläche des Anbieters ist riesig. Und ich habe keine Kontrolle darüber.
Dazu kommen regulatorische Anforderungen. DSGVO ist klar: personenbezogene Daten dürfen nicht ohne Weiteres in US-Cloud-Dienste übertragen werden. Für meine Kunden in der Versicherungsbranche, in der öffentlichen Verwaltung, in regulierten Industrien ist das kein akademisches Problem.
Und dann ist da noch die Frage der Souveränität. Ich möchte wissen, was mit meinen Anfragen passiert. Ich möchte das Modell inspizieren können. Ich möchte im Zweifel offline arbeiten.
Das alles führt an denselben Ort: lokale Modelle.
Ollama: der Einstieg, der einfacher war als erwartet
Ich hatte erwartet, dass der Einstieg in lokale Modelle schmerzhaft sein würde. Hardware, Konfiguration, Performance-Probleme.
Es war überraschend unkompliziert.
Ollama ist im Prinzip ein Paketmanager für Sprachmodelle. Ich installiere es, ich lade ein Modell, ich spreche mit ihm, lokal, im Terminal, ohne Internetverbindung. Mein erster Test war llama2, damals noch einer der besten frei verfügbaren Modelle. Die Antwortqualität war schlechter als GPT-4. Die Datenkontrolle war absolut.
Das war der Deal.
Für viele Aufgaben reicht ein gutes kleineres Modell vollständig aus: Zusammenfassungen, Strukturierung von Informationen, Code-Review für einfache Skripte, Klassifizierung von Ereignissen. Für diese Aufgaben brauche ich GPT-4 nicht. Ich brauche ein Modell, das zuverlässig, schnell und lokal ist.
Was "Air-Gapped" wirklich bedeutet
In meiner Arbeit bauen wir KI-Infrastruktur, die in vollständig isolierten Umgebungen läuft. Kein Internetanschluss. Keine Cloud-API. Das Modell liegt auf einem Server, der physisch vom Internet getrennt ist.
Das klingt extrem. In bestimmten Kontexten ist es das Einzige, was vertretbar ist.
Denken Sie an eine Behörde, die sensitive Bürgerdaten verarbeitet. An ein Unternehmen, das Geschäftsgeheimnisse hat, die wirklich geheim sein müssen. An kritische Infrastruktur, wo ein Datenleck nicht nur teuer, sondern gefährlich wäre.
Für diese Umgebungen ist die Frage nicht "Cloud oder lokal?" Die Frage ist: "Welches lokale Modell ist gut genug für unseren Anwendungsfall?" Und die Antwort hat sich in den letzten zwei Jahren drastisch verändert.
Die Modellqualität lokaler Systeme ist explodiert. Mistral, Llama 3, Phi-3, Qwen, Modelle, die auf einem normalen Server laufen und Aufgaben lösen, für die man vor zwei Jahren noch GPT-4 gebraucht hätte.
Die technische Entscheidung hinter dem Prinzip
Mein erstes Testing-Skript für lokale Modelle, testing_local_model.py in meinem myscripts-Repository, war bewusst simpel gehalten. Es schickt Anfragen an ein lokales Ollama-Modell und speichert die Ausgaben. Kein Schnickschnack.
Der Grund: Ich wollte vergleichen. Gleiche Fragen, gleiches Szenario, unterschiedliche Modelle. Was kann das kleine lokale Modell, was kann es nicht, wo liegen die Grenzen?
Das ist keine einmalige Übung. Ich mache das bei jedem neuen Modell, das für meinen Einsatzbereich relevant sein könnte. Die Bewertungskriterien sind operational:
- Wie zuverlässig extrahiert das Modell strukturierte Informationen aus unstrukturierten Logs?
- Halluziniert es bei Security-spezifischen Begriffen?
- Wie verhält es sich, wenn die Eingabe unvollständig oder widersprüchlich ist?
- Wie schnell ist es auf meiner Hardware?
Das letzte Kriterium ist nicht unwichtig. Ein Modell, das drei Minuten für eine Antwort braucht, ist kein produktives Werkzeug.
Was sich dadurch verändert hat
Seitdem ich lokale Modelle ernsthaft einsetze, hat sich meine Arbeit an drei Stellen verändert:
In der Forensik: Ich kann Rohdaten direkt analysieren, ohne sie anonymisieren oder herausfiltern zu müssen. Das spart Zeit und vermeidet Fehler durch unvollständige Filterung.
In der Beratung: Wenn ich Kunden erkläre, wie sie KI sicher einsetzen können, kann ich jetzt aus eigener Erfahrung sprechen, nicht aus Theorie. Ich weiß, was es kostet, ein lokales System aufzubauen. Ich weiß, welche Kompromisse es gibt. Ich kann ehrliche Empfehlungen geben.
In der eigenen Infrastruktur: Mein KI-System läuft auf lokalen Docker-Containern. Die Daten bleiben dort. Das ist kein Komfort, das ist eine bewusste Architekturentscheidung.
Die unbequeme Wahrheit
Lokale Modelle sind nicht kostenlos. Sie brauchen Hardware. Sie brauchen Wartung. Sie sind in der Spitzenqualität noch hinter den großen Cloud-Modellen.
Aber die Frage ist nicht: "Ist das beste lokale Modell so gut wie GPT-4?" Die Frage ist: "Ist das beste lokale Modell gut genug für meinen konkreten Anwendungsfall, bei gleichzeitiger Datenkontrolle?"
Für viele Security-Anwendungsfälle ist die Antwort: Ja.
Die nächste Episode zeigt, wie aus dieser Erkenntnis ein echtes System wurde, kein Skript mehr, sondern eine Architektur.
Gregor Lyttek ist Security Architect und AI Strategist.