E-Mails und Tickets lokal mit KI klassifizieren: Entscheidungsmodelle, LLM oder Klassifikator

Anfragen im Postfach oder Ticketsystem automatisch zuordnen? WZ-IT baut die Klassifikation als Ticket- und Postfach-Pilot mit lokaler Inferenz und kontrollierten Freigaben auf, siehe auch den KI-Hub. Termin vereinbaren

Ein Service-Postfach oder eine Ticket-Queue wird meist von Hand sortiert: Jemand liest jede Anfrage, ordnet sie einem Thema zu, setzt die Priorität und gibt sie an das zuständige Team weiter. Diese Zuordnung ist eine klar umrissene Aufgabe mit festen Antwortmöglichkeiten und damit gut für KI geeignet. Weil E-Mails und Tickets fast immer personenbezogene Daten und oft Geschäftsgeheimnisse enthalten, liegt es nahe, die Klassifikation lokal zu betreiben.

Seit Ende September 2026 gibt es dafür eine neue Option: Ollama 0.35.0 unterstützt sogenannte Entscheidungsmodelle, die keine Texte schreiben, sondern Optionen mit Wahrscheinlichkeiten zurückgeben. Dieser Beitrag ordnet die Neuerung ein, vergleicht sie mit zwei etablierten Wegen (kleines LLM mit strukturierter Ausgabe, Embedding-Modell mit Klassifikator) und beschreibt, wie eine Pipeline vom Postfach bis ins Ticketsystem aussieht und wie die Qualität gemessen wird. Alle Versions- und Modellangaben haben den Stand Oktober 2026.

Inhaltsverzeichnis

1. Was die Klassifikation leisten soll
2. Drei Wege zur lokalen Klassifikation
3. Neu in Ollama 0.35: Entscheidungsmodelle über /v1/systemone
4. Was die veröffentlichten Benchmarks aussagen
5. Kleines LLM mit strukturierter Ausgabe
6. Embedding-Modell mit trainiertem Klassifikator
7. Die Pipeline vom Postfach ins Ticketsystem
8. Qualität messen, bevor automatisiert wird
9. Datenschutz, Sicherheit und KI-Verordnung
10. Hardware für die lokale Klassifikation
11. Unser Vorgehen bei WZ-IT
12. Weiterführende Guides

Was die Klassifikation leisten soll

Bevor ein Modell ausgewählt wird, steht fest, welche Fragen es zu jeder Anfrage beantworten soll. In der Praxis sind es meist dieselben vier Arten:

Zwei Dinge gehören nicht in diese Aufgabe. Spam- und Phishing-Erkennung bleibt beim Mailserver oder Gateway, weil dort Header, Reputation und Anhänge geprüft werden. Antwortentwürfe sind ein eigener Schritt, der ein generatives Modell und eine Freigabe braucht. Die Klassifikation selbst entscheidet nur, wohin eine Anfrage gehört und wie sie markiert wird.

Eine Kategorie „Sonstiges" oder „keine passende Option" ist Pflicht. Ohne sie ordnet jedes Modell auch unpassende Anfragen der ähnlichsten Kategorie zu.

Drei Wege zur lokalen Klassifikation

Die Wege schließen sich nicht aus. Ein Embedding-Klassifikator kann die eindeutigen Fälle übernehmen und unsichere Fälle an ein Entscheidungsmodell oder ein LLM weitergeben. Welcher Weg passt, hängt vor allem davon ab, ob gelabelte historische Daten vorhanden sind und wie oft sich die Kategorien ändern.

Neu in Ollama 0.35: Entscheidungsmodelle über /v1/systemone

Ollama hat am 28. September 2026 die Version 0.35.0 veröffentlicht (GitHub Release v0.35.0), die zugehörige Ankündigung folgte am 29. September (Ollama Blog). Der neue Endpunkt /v1/systemone folgt dem Jev-API-Format von TypeSafe. Der zu bewertende Text steht im Feld state, die Fragen im Feld questions. Das Modell liefert zu jeder Frage eine typisierte Antwort statt freiem Text.

Quellen: Ollama API-Referenz System One, Ollama Decision Guide, Model Card nimble.

Zum Start stehen drei Modelle bereit:

Quellen: Ollama Library nimble, Ollama Library tev1, Hugging Face Bespoke-Nimble-9B, Hugging Face Tev1-4B-experimental.

Ein Request für ein deutsches Service-Postfach mit drei Fragen sieht so aus:

curl http://localhost:11434/v1/systemone -d '{
  "model": "nimble",
  "state": {
    "betreff": "Rechnung 2026-1043 doppelt abgebucht",
    "text": "Guten Tag, der Betrag wurde zweimal von unserem Konto eingezogen. Bitte erstatten Sie die zweite Abbuchung."
  },
  "questions": {
    "kategorie": {
      "type": "choice",
      "instructions": "Welche Kategorie passt zu dieser Anfrage?",
      "criteria": {
        "rechnung": "Rechnungen, Zahlungen und Erstattungen",
        "technik": "Störungen und technische Fragen",
        "vertrag": "Vertragsänderungen und Kündigungen",
        "sonstiges": "Keine der genannten Kategorien"
      }
    },
    "erstattung": {
      "type": "noul",
      "instructions": "Verlangt der Absender ausdrücklich eine Erstattung?"
    },
    "dringlichkeit": {
      "type": "score",
      "instructions": "Wie dringend ist die Anfrage?",
      "criteria": ["Routine", "zeitnah", "dringend"]
    }
  }
}'

Die Antwort enthält für kategorie die gewählte Option, die Wahrscheinlichkeit jeder Option und einen confidence-Wert, für erstattung eine Wahrscheinlichkeit zwischen 0 und 1 und für dringlichkeit den wahrscheinlichkeitsgewichteten Mittelwert der Stufen 0 bis 2. Das Format zeigt die Ollama-Dokumentation mit englischen Beispielen.

Drei Punkte sind für den Betrieb wichtig:

• confidence ist keine Trefferquote. Der Wert beschreibt, wie stark sich die Wahrscheinlichkeiten auf eine Option konzentrieren. Ein Wert von 0,9 heißt nicht, dass die Antwort auf Ihren Daten in 90 Prozent der Fälle richtig ist (Model Card nimble).
• Fragen werden unabhängig bewertet. Wenn zwei Antworten zusammenpassen müssen, etwa Kategorie „Vertrag" und Bedingung „Kündigung liegt vor", prüft das der aufrufende Code.
• Der Kontext ist klein. Die Ollama-Bibliothek zeigt für beide Modelle ein Kontextfenster von 256K, nutzbar sind laut Model Cards aber 8.192 Token (Nimble) beziehungsweise etwa 2.000 Token (Tev1). Lange Verläufe müssen vorher gekürzt werden.

Was die veröffentlichten Benchmarks aussagen

Ollama und Bespoke Labs veröffentlichen eine Auswertung über 13 öffentliche Datensätze mit menschlich vergebenen Labels, insgesamt 3.880 Entscheidungen. Nimble und Tev1 liefen dabei auf Ollama, der Wert für Jev stammt aus einem Lauf von Bespoke Labs über die TypeSafe-API (Model Card nimble, Public Benchmarks).

Für Postfächer relevanter sind die Teilergebnisse zum Intent-Routing auf dem MASSIVE-Datensatz von Amazon (Hugging Face):

Daraus lassen sich drei Schlüsse ziehen. Erstens funktioniert Nimble auch mit deutschen Texten, liegt dort aber einige Punkte unter dem englischen Ergebnis. Zweitens sind diese Werte an kurzen Sprachbefehlen mit festen Intents gemessen, nicht an E-Mails mit Verläufen, Signaturen und mehreren Anliegen. Drittens gibt Together AI für Tev1 ausdrücklich an, Prompt Injection, andere Sprachen als Englisch und die Kalibrierung der Wahrscheinlichkeiten nicht vollständig getestet zu haben (Model Card tev1). Die Benchmarks zeigen, dass der Ansatz trägt. Ob er für ein bestimmtes Postfach reicht, zeigt nur ein Test mit eigenen Daten.

Kleines LLM mit strukturierter Ausgabe

Der etablierte Weg nutzt ein allgemeines Sprachmodell mit erzwungenem Ausgabeformat. Ollama unterstützt über den Parameter format ein JSON-Schema, an das sich die Antwort halten muss (Ollama Structured Outputs). vLLM bietet dieselbe Funktion für den Betrieb mit höherer Last. Im Schema steht die Kategorie als Aufzählung (enum) der erlaubten Werte, dazu Felder für Priorität oder Ja-Nein-Prüfungen.

Gegenüber einem Entscheidungsmodell hat dieser Weg Vor- und Nachteile:

Fertige Bausteine gibt es in den gängigen Werkzeugen. Der Knoten Text Classifier in n8n nimmt Kategorien mit Beschreibung entgegen, kann mehrere Kategorien zulassen und Fälle ohne klare Zuordnung in einen eigenen Zweig „Other" leiten. Als Modell lässt sich über den Ollama-Chat-Knoten ein lokales Modell anbinden. Zammad bringt eigene KI-Agenten mit, darunter einen Ticket Categorizer, einen Group Dispatcher und einen Prioritizer, die über Trigger, Scheduler oder Makros ausgelöst werden. Als Anbieter unterstützt Zammad unter anderem Ollama und OpenAI-kompatible Endpunkte (Zammad AI Agents, Zammad AI Provider).

Dieser Weg passt, wenn die Klassifikation Teil eines größeren Schritts ist, etwa wenn zusätzlich Kundennummer, Vertragsnummer oder Termin aus der E-Mail extrahiert werden sollen. Wie solche Extraktionen bei Dokumenten abgesichert werden, beschreibt der Beitrag zur Dokumentenverarbeitung mit KI.

Embedding-Modell mit trainiertem Klassifikator

Der dritte Weg kommt ohne generatives Modell aus. Ein Embedding-Modell wie BGE-M3 wandelt jede Anfrage in einen Vektor um. Ein Klassifikator, etwa eine logistische Regression, lernt aus historischen, korrekt zugeordneten Anfragen, welche Vektoren zu welcher Kategorie gehören. SetFit verfeinert zusätzlich das Embedding-Modell und kommt mit wenigen Beispielen je Kategorie aus.

Der Vorteil liegt im Betrieb: Embedding und Klassifikation brauchen sehr wenig Rechenleistung, das Verhalten ist reproduzierbar, und Wahrscheinlichkeiten lassen sich an Testdaten kalibrieren. Wer ohnehin ein Ticketsystem mit jahrelang gepflegten Kategorien hat, besitzt die Trainingsdaten bereits. Welche Embedding-Modelle mit deutschen Texten gut umgehen, vergleicht der Beitrag zu Embedding-Modellen für Deutsch.

Die Pipeline vom Postfach ins Ticketsystem

Unabhängig vom Modell besteht eine Klassifikationsstrecke aus denselben Schritten. Mit einem selbst gehosteten n8n lässt sich jeder Schritt als Knoten abbilden.

Die Vorverarbeitung entscheidet oft mehr über die Qualität als die Modellwahl. Eine E-Mail mit fünf zitierten Vorgängernachrichten enthält mehrere Anliegen, und das Modell bewertet im Zweifel das falsche. Bei Nimble und Tev1 ist das Kürzen außerdem technisch notwendig, weil zu lange Prompts mit einem Fehler abgelehnt werden.

Die Prüfwarteschlange in Schritt 4 ist kein Provisorium, sondern Teil des Entwurfs. Die Fälle, die dort landen, sind die Datengrundlage für bessere Kategorienbeschreibungen und für ein späteres Training. Wer Zammad als Ticketsystem nutzt, findet den Vergleich mit anderen Systemen im Beitrag Zammad, FreeScout, osTicket und Chatwoot. WZ-IT betreibt Zammad als Managed Zammad.

Qualität messen, bevor automatisiert wird

Eine Klassifikation wird erst automatisch wirksam, wenn ihre Fehlerquote bekannt ist. Das Vorgehen ist bei allen drei Wegen gleich:

1. Testsatz bilden. Eine repräsentative Auswahl historischer Anfragen, von Fachleuten mit der korrekten Kategorie versehen, einschließlich seltener Kategorien und unklarer Fälle.
2. Je Kategorie auswerten. Precision (wie viele der zugeordneten Fälle sind richtig) und Recall (wie viele der tatsächlichen Fälle werden gefunden) pro Kategorie, nicht nur eine Gesamtgenauigkeit. Eine Verwechslungsmatrix zeigt, welche Kategorien sich überschneiden.
3. Fehlerkosten bewerten. Eine Rechnung im Technik-Team kostet eine Weiterleitung. Eine Kündigung, die als Routine eingestuft wird, kann eine Frist kosten. Für solche Kategorien gelten strengere Schwellenwerte.
4. Schwellenwerte festlegen. Anhand der Wahrscheinlichkeiten auf dem Testsatz bestimmen, ab welchem Wert automatisch geroutet wird und was in die Prüfwarteschlange geht.
5. Regressionstest vor jedem Wechsel. Neue Modellversion, neue Kategorienbeschreibung oder neue Ollama-Version: erst den Testsatz erneut laufen lassen, dann umstellen.

Der Testsatz dient zugleich dem Vergleich der drei Wege. Bei denselben Anfragen zeigt sich, ob ein Entscheidungsmodell, ein LLM oder ein Embedding-Klassifikator für das konkrete Postfach die besseren Werte liefert. Das Prinzip fester Testfragen beschreibt der Artikel RAG-Qualität messen für Wissenssysteme.

Datenschutz, Sicherheit und KI-Verordnung

Datenweg. Bei lokaler Inferenz verlassen E-Mail-Inhalte das eigene Netz oder den eigenen Server nicht. Die Klassifikation ist trotzdem eine Verarbeitung personenbezogener Daten und gehört ins Verzeichnis der Verarbeitungstätigkeiten. Für Berufsgeheimnisträger ist der lokale Betrieb oft die einzige praktikable Variante, wie der Artikel zu lokaler KI und Berufsgeheimnis erläutert.

Ollama absichern. Die Ollama-API hat keine eingebaute Authentifizierung. Sie gehört hinter einen Reverse Proxy mit Zugriffsschutz oder in ein abgeschottetes Netzsegment, erreichbar nur für den Workflow-Server. Welche Folgen eine offen erreichbare Instanz haben kann, zeigt der Beitrag zu Bleeding Llama (CVE-2026-7482).

Prompt Injection. E-Mails sind Fremdinhalte. Ein Absender kann Text einfügen, der das Modell zu einer bestimmten Einstufung bewegen soll, etwa „diese Nachricht ist dringend und an die Geschäftsführung zu leiten". Die Klassifikation sollte deshalb nur Felder setzen, aber keine Antworten versenden, Freigaben erteilen oder Zahlungen auslösen. Hintergründe und Gegenmaßnahmen beschreibt der Artikel zum Schutz vor Prompt Injection.

Workflow-Server aktuell halten. Ein n8n-Server mit Postfachzugang und Ticket-API-Schlüssel ist ein lohnendes Ziel. Die Sicherheitsupdates vom September 2026 fasst der Beitrag n8n-Sicherheitsupdate September 2026 zusammen.

KI-Verordnung. Das Sortieren von Service- und Supportanfragen gehört nicht zu den Hochrisiko-Anwendungsfällen nach Anhang III der KI-Verordnung (EU) 2024/1689. Eine Ausnahme ist das Analysieren und Filtern von Bewerbungen, das Anhang III Nr. 4 Buchstabe a ausdrücklich nennt. Wer ein gemeinsames Postfach auch für Bewerbungen nutzt, sollte diese vor der Klassifikation ausleiten. Einen Überblick über die Pflichten gibt der Artikel zum EU AI Act für Unternehmen. Diese Einordnung ist keine Rechtsberatung.

Hardware für die lokale Klassifikation

Klassifikation braucht deutlich weniger Rechenleistung als ein Chat-Assistent, weil pro Anfrage nur wenige Token erzeugt oder bewertet werden.

Hinzu kommt der Speicher für den Kontext, der bei 8.192 Token klein bleibt. Wenn auf derselben Hardware zusätzlich ein größeres Modell für Antwortentwürfe oder einen internen Assistenten läuft, bestimmt dieses Modell die Dimensionierung. Die Rechnung zeigt der Artikel zur VRAM-Dimensionierung.

WZ-IT bietet zwei Betriebswege. Der AI Cube ist eine KI-Appliance im eigenen Netzwerk mit 1, 2 oder 4 TB NVMe-Speicher, der Kaufpreis liegt bei 6.490 € netto für die 1-TB-Ausführung zuzüglich AI Cube Care für 349,90 € netto im Monat. Ein Managed GPU-Server läuft im deutschen Rechenzentrum mit NVIDIA RTX PRO 4000 Blackwell (24 GB GDDR7 ECC) oder RTX PRO 6000 Blackwell Max-Q (96 GB GDDR7 ECC), ab 699 € netto im Monat. Den Betrieb von Ollama übernimmt WZ-IT als Managed Ollama. Die Unterschiede zwischen Ollama und vLLM für den produktiven Einsatz vergleicht der Beitrag vLLM, Ollama oder llama.cpp.

Unser Vorgehen bei WZ-IT

1. Eingang und Taxonomie. Kanal, Volumen, Kategorien, Zuständigkeiten und erlaubte Aktionen festlegen, einschließlich einer Kategorie für nicht passende Anfragen.
2. Testsatz. Repräsentative, bei Bedarf anonymisierte historische Anfragen mit dem Fachbereich labeln.
3. Vergleich der Wege. Entscheidungsmodell, LLM mit Structured Output und, wenn Daten vorhanden sind, Embedding-Klassifikator am selben Testsatz messen, Ergebnis je Kategorie.
4. Pipeline. Vorverarbeitung, Klassifikation, Schwellenwerte, Prüfwarteschlange und Anbindung an Postfach und Ticketsystem, auf Wunsch über n8n.
5. Freigabestufen. Erst Vorschläge im Ticket, dann automatisches Routing für sichere Kategorien, Produktivaktionen nur nach gesonderter Freigabe.
6. Betrieb. Protokollierung, Regressionstest vor Modell- und Versionswechseln, Updates von Ollama und n8n, Support, Beratung und Implementierung durch WZ-IT.

Den abgegrenzten Einstieg bildet der Ticket- und Postfach-Pilot ab 14.900 € netto mit einem Eingangskanal und bis zu 15 Kategorien. Der verbindliche Umfang steht im Angebot.

Weiterführende Guides

• Dokumente automatisch auslesen und prüfen mit KI, Extraktion und Validierung bei Rechnungen und Lieferscheinen.
• KI-Agenten-Frameworks im Vergleich, n8n, LangGraph und weitere Werkzeuge aus Betreibersicht.
• Geschäftsprozesse automatisieren mit n8n, von klassischen Workflows zu KI-Agenten.
• vLLM, Ollama oder llama.cpp, welcher Inferenz-Server für welchen Einsatz.
• KI-Agenten: Rechte und Freigaben, wie automatische Aktionen begrenzt werden.
• KI-Lösungen von WZ-IT, der Hub mit allen Angeboten zu lokaler KI.

Postfach oder Ticket-Queue lokal klassifizieren? Wir messen die Verfahren an Ihren historischen Anfragen und binden die Klassifikation mit Freigabestufen an Ihr Ticketsystem an. Termin vereinbaren

Quellen

• Ollama, Release v0.35.0
• Ollama Blog, Ollama now supports Jev-style decision models
• Ollama Dokumentation, Decision
• Ollama API-Referenz, System One
• Ollama Dokumentation, Structured Outputs
• vLLM, Structured Outputs
• Ollama Library, nimble
• Ollama Library, tev1
• Hugging Face, Bespoke-Nimble-9B
• Bespoke Labs, Nimble Public Benchmarks
• Hugging Face, Tev1-4B-experimental
• Together AI, How to train your own Jev
• Amazon Science, MASSIVE-Datensatz
• n8n, Text Classifier Node
• n8n, Ollama Chat Model Node
• n8n, Email Trigger (IMAP)
• n8n, Zammad Node
• Zammad Admin-Dokumentation, AI Agents
• Zammad Admin-Dokumentation, AI Provider
• Zammad, Ticket-API
• Hugging Face, BAAI/bge-m3
• Hugging Face, SetFit
• scikit-learn, LogisticRegression
• Verordnung (EU) 2024/1689 (KI-Verordnung), EUR-Lex