Bei einem damaligen, hier bewusst nicht näher dokumentierten Ransomware-Fall lagen vor mir Logs und Artefakte eines Kunden. Ein Sprachmodell hätte beim Sortieren und Vergleichen helfen können. Die Rohdaten enthielten jedoch interne Netzwerkstrukturen, Benutzernamen, Prozessnamen und sensible Zeitstempel.
Ich wollte diese Akte nicht aus Bequemlichkeit an einen externen Dienst übergeben. Damit begann meine Arbeit mit lokalen Modellen.
Cloud-Nutzung ist eine Datenentscheidung
Bei OpenAIs Business-Produkten und der API werden Ein- und Ausgaben nach Angaben des Anbieters standardmäßig nicht zum Modelltraining verwendet. Das ist relevant, ersetzt aber keine Prüfung von Datenklasse, Aufbewahrung, Auftragsverarbeitung, Datenresidenz und möglichen Drittlandübermittlungen. Auch ein guter Vertrag nimmt mir diese Entscheidung nicht ab.
Ein externer Dienst verlagert Teile von Angriffsfläche, Kontrolle und Nachweisführung außerhalb meiner Umgebung. Das kann vertretbar sein. Bei Forensikdaten muss ich es jedoch für den konkreten Fall begründen können. Zu prüfen sind insbesondere Zweck und Rechtsgrundlage, Datenminimierung, Zugriffsschutz sowie gegebenenfalls ein Auftragsverarbeitungsvertrag und die Voraussetzungen einer Drittlandübermittlung.
Lokale Inferenz ist deshalb für mich keine Glaubensfrage. Sie ist eine Option im Threat Model: nützlich, wenn Daten die Umgebung nicht verlassen sollen oder ein Betrieb ohne externe Verbindung gefordert ist.
Der erste lokale Test
Ollama senkte damals die Einstiegshürde. Mein erster nicht standardisierter Vergleich lief mit llama2. Es blieb bei meinen Aufgaben hinter dem damaligen Cloud-Spitzenmodell GPT-4 zurück, war aber lokal nutzbar. Von da an ließ sich die Frage testen: Reicht dieses Modell für diesen Arbeitsgang?
Für klar abgegrenzte Aufgaben wie Extraktion, Klassifikation oder das Strukturieren eines Textes können kleinere Modelle ausreichen. Das gilt erst nach einem Test mit den eigenen Daten, der eigenen Sprache und einer festgelegten Fehlertoleranz.
Ollama kann Modelle lokal über CLI und API ausführen. Inzwischen bietet es auch Cloud-Modelle und Websuche an. Für einen belastbaren Offline-Betrieb muss das Modell daher vorab bereitgestellt und der Local-only-Modus aktiviert werden, etwa über OLLAMA_NO_CLOUD=1. Lokalität ist eine Konfiguration, kein Versprechen des Produktnamens.
Offline ist eine eigene Betriebsform
Ich habe an KI-Infrastruktur für vollständig isolierte Umgebungen gearbeitet. Dort gibt es keine Cloud-API; Modelle und benötigte Artefakte werden kontrolliert eingebracht. Diese Architektur kann bei hohen Schutzanforderungen sinnvoll sein. Sie folgt aus Datenklasse, Bedrohungsmodell und regulatorischen Vorgaben, nicht aus einer allgemeinen Pflicht zum Air Gap.
Zwischen 2023 und 2025 wurden lokal ausführbare Modelle deutlich leistungsfähiger. Daraus folgt noch keine pauschale Rangliste. Modellgröße, Quantisierung, Hardware und Aufgabe bestimmen gemeinsam, ob eine lokale Lösung einen früheren Cloud-Workflow ersetzen kann.
Die technische Entscheidung hinter dem Prinzip
Mein frühes Lernskript testing_local_model.py schickt dieselben deutschen Aufgaben an zwei Ollama-Modelle und speichert die Ausgaben. Es ist kein Benchmark und wird nicht als aktuelles Werkzeug gepflegt. Sein Wert lag in der Vergleichbarkeit.
Für ausgewählte Modelle nutzte ich Kriterien, die sich aus der Arbeit ableiten:
- 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?
Die Laufzeit gehört zur Abnahme. Ein fachlich brauchbares Modell kann für einen interaktiven Arbeitsgang trotzdem ungeeignet sein, wenn jede Antwort mehrere Minuten dauert.
Was davon geblieben ist
Lokale Verarbeitung kann verhindern, dass Rohdaten an einen externen Modellanbieter gehen. Rechtsgrundlage, Zweckbindung, Datenminimierung, Zugriffsschutz und Löschfristen bleiben trotzdem bestehen. „Lokal“ ist keine Abkürzung zu Datenschutzkonformität.
Die praktische Erfahrung hat meine Beratung verbessert: Ich kenne Hardware-, Energie- und Betriebsaufwand ebenso wie die Vorteile. Mein heutiger Stack ist allerdings kein reines Lokalsystem mehr. Im aktuellen Stand ist Hermes Agent der aktive Harness; lokale Inferenz bleibt ein Test- und Spezialpfad. Diese Entwicklung gehört zur ehrlichen Architekturgeschichte.
Die Entscheidung
Lokale Inferenz kostet Hardware, Energie und Wartung. Die Qualität gegenüber Cloud-Modellen lässt sich nur für eine konkrete Aufgabe beurteilen. Ich entscheide deshalb nicht nach Modellranglisten, sondern nach Datenklasse, benötigter Leistung, Betriebskosten und einem reproduzierbaren Aufgabentest.
Wo ein kleineres lokales Modell den Test besteht und sensible Daten die Umgebung nicht verlassen sollen, ist es die bessere Wahl. Wo es scheitert, brauche ich eine andere Architektur oder muss auf die Funktion verzichten.
Quellen und Projektstand
- OpenAI: Enterprise privacy and data controls
- Ollama FAQ: lokale Verarbeitung und Cloud-Modus
- EDPB: internationale Datenübermittlungen
- Lyttek AI Journey: aktueller Projektstand
Die nächste Episode zeigt, wie aus den einzelnen Versuchen schrittweise eine Architektur wurde.
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.