Klassische Spam- und Phishing-Filter arbeiten mit Reputationen, RBLs, SPF/DKIM/DMARC-Checks und Inhaltsregeln. Sie sind notwendig, aber gegen 2026er Phishing-Qualität reichen sie nicht: die Mail kommt von einer kompromittierten, validen Domain, ist DKIM-signiert, hat sauberen SPF, und der Text ist in flüssigem Deutsch ohne Tippfehler. Genau hier setzen LLM-basierte Klassifikatoren an.
Was ein LLM in einer Mail erkennt, das ein Regex nicht erkennt
- Tonalitäts-Anomalien: „Buchhaltung benötigt heute eine dringende Umbuchung von 87.500 € auf folgende IBAN" — semantisch passend zu Business-Email-Compromise (BEC), nicht durch Keywords erfassbar.
- Reply-Chain-Manipulation: eine gefälschte Mail-Historie wird vom LLM als „erscheint künstlich konstruiert" markiert.
- Pseudo-Branding: „We have detected unusual activity on your account" mit Microsoft-Layout, aber subtil falscher Sprach-Tonalität.
- Pressure & Urgency-Pattern: „bitte sofort", „streng vertraulich, niemandem mitteilen" – psychologische Trigger, die Awareness-Schulungen besprechen.
- Out-of-Context-Anhänge: ein Anhang in einer Mail-Konversation, deren Verlauf keinen Bezug zum Anhang-Thema hat.
Warum lokales LLM (Ollama) statt Cloud-API
Mails durch eine Cloud-LLM-API zu jagen ist eine DSGVO-Folgenabschätzung mit klarer Antwort: nein. Auch dann nicht, wenn der Anbieter eine EU-Region bietet. Daher: lokales LLM via Ollama mit einem optimierten Modell (Llama 3 oder kleineren BERT-Varianten):
- Datenhoheit: keine Mail-Inhalte verlassen die Infrastruktur.
- Offline-Fähig: der Mail-Filter bleibt verfügbar, auch wenn das Internet ausfällt.
- Kosten: keine Pro-Token-Pricing.
- Reproduzierbarkeit: Modell-Versionen sind festgenagelt; ein Mail-Verdict heute ist morgen noch dasselbe (anders als bei „GPT-4 Update killt Konsistenz").
Wie die Integration in die Mail-Pipeline aussieht
Eingehende Mail durchläuft die übliche Pipeline (RBL, SPF/DKIM/DMARC, Hash-Reputation, ClamAV, YARA, CAPE-Sandbox). Wenn die Mail bis zu diesem Punkt „clean" ist, aber bestimmte Heuristik-Triggers anschlagen (neuer Sender, externer Absender mit interner Empfänger-Action, Anhang-Typ Office-Maldoc), läuft die Mail durch das LLM:
- Mail-Body und Subject werden via Ollama-API an das lokale Modell geschickt.
- Prompt fragt: „Klassifiziere diese Mail – legitim, suspicious, phishing, BEC. Begründe in einem Satz."
- Output wird strukturiert zurückgegeben (JSON mit verdict + confidence + reasoning).
- Bei verdict ≠ „legitim" landet die Mail in der Quarantäne mit dem LLM-Reasoning als Begründungs-Anzeige für den Operator.
False-Positive-Tuning
Drei Mechanismen halten die FP-Rate handhabbar:
- Confidence-Schwelle: nur Verdikte über 75 % Confidence werden als Quarantäne-Trigger gewertet, der Rest wird mit Tag „LLM-uncertain" weitergeleitet.
- Sender-Reputation: ein etablierter Sender (über 6 Monate Mail-Verkehr ohne Beschwerden) bekommt einen Bonus.
- Manueller Override: Operator kann eine spezifische Sender-/Empfänger-Kombination dauerhaft whitelisten.
Performance-Realität
Llama-3-8B auf einer RTX 4090 schafft etwa 5–8 Mails pro Sekunde mit 200 ms Latenz. Bei einer typischen Mittelstands-Last von 5.000 Mails/Tag (≈ 0,06 Mails/Sek im Durchschnitt) ist das massiv überdimensioniert – passt aber für Spitzen-Zeiten morgens. CPU-only ist möglich, aber die Latenz steigt auf 2–4 s pro Mail.
Compliance-Mapping
LLM-basierte Klassifikation deckt explizit Anforderungen aus:
- NIS-2 Art. 21(2)(b): Maßnahmen zur Erkennung von Sicherheitsvorfällen.
- BSI IT-Grundschutz APP.5.3: zusätzliche Filter-Stufen für E-Mail-Sicherheit.
- ISO 27001 A.5.7: Threat Intelligence – Detection-Tiefe als Beleg.
Fazit
LLM-basierte Phishing-Klassifikation ist 2026 der Differenzierer zwischen „Spamfilter, sortiert nach Bauchgefühl" und „semantischem Verständnis der Mail". Lokal betrieben (Ollama) ist sie DSGVO-konform und reproduzierbar. In der SecTepe.Comm-Mail-Pipeline ist sie eine optionale Ergänzung – wer sie aktiviert, sieht typisch 30–50 % mehr Phishing-Detections bei marginal höherer FP-Rate.