Znuny-LLM: Praxis-Guide für selbst gehostete KI in Znuny

Znuny-LLM bringt Unterstützung durch Large Language Models (LLMs) direkt in die Agenten- und Administrationsoberfläche von Znuny. Das freie Open-Source-Add-on verbindet Znuny mit Ollama oder einem anderen OpenAI-kompatiblen Endpunkt und ergänzt Klassifizierung, Zusammenfassungen, bessere Tickettitel, Datenextraktion, Schreibhilfe und Wissensvorschläge – ohne eine gemeinsam genutzte KI-SaaS-Plattform vorauszusetzen.

Das ist besonders für Service-Desks relevant, die Znuny wegen der Kontrolle über Daten und Betrieb gewählt haben und nun praktische generative KI einsetzen möchten. Dieser Guide erklärt, was Znuny-LLM leistet, wie die Betriebsmodelle funktionieren, welche Sicherheitsmaßnahmen wichtig sind und wie Teams das Add-on einführen können, ohne ein LLM als unfehlbare Automatisierungsinstanz zu behandeln.

Sie optimieren bereits Ihre Znuny-Prozesse? Beginnen Sie mit unserem Überblick zur Automatisierung im Znuny Ticket-System oder informieren Sie sich über die OTAI-Integration für Znuny.

Was ist Znuny-LLM?

Znuny-LLM ist ein Add-on für Znuny 7.3 oder neuer. Znuny kündigte es als freies Open-Source-Paket an, das einen vom Betreiber ausgewählten Modell-Endpunkt verwendet. Ollama wird direkt unterstützt; außerdem lassen sich OpenAI-compatible Endpunkte einschließlich Azure OpenAI konfigurieren.

Diese Wahlmöglichkeit ist wichtig. „Self-hosted AI“ kann unterschiedliche Architekturen beschreiben:

• Znuny und das Modell laufen vollständig in der eigenen Infrastruktur.
• Znuny läuft On-Premises, während ein OpenAI-kompatibler Endpunkt in einer kontrollierten Private Cloud betrieben wird.
• Znuny verbindet sich mit einem verwalteten Endpunkt wie Azure OpenAI innerhalb des bestehenden Mandanten und seiner Richtlinien.

Znuny-LLM schreibt keine dieser Varianten vor. Die Organisation entscheidet weiterhin selbst, wo die Inferenz stattfindet, welche Daten eine Netzwerkgrenze überschreiten und wie der Modell-Endpunkt abgesichert wird.

Die wichtigsten Funktionen von Znuny-LLM

Das Add-on konzentriert sich auf Aufgaben im bestehenden Ticket-Workflow der Agenten.

• Ticket-Klassifizierung: schlägt Queue, Typ, Service und SLA aus den zulässigen Werten vor und reduziert repetitive Erst-Triage.
• Mehrsprachige Zusammenfassungen: erleichtern Agenten das Erfassen langer oder mehrsprachiger Verläufe.
• Titeloptimierung: ersetzt schwache E-Mail-Betreffzeilen durch aussagekräftige Titel und macht Queue-Ansichten übersichtlicher.
• Extraktion in dynamische Felder: liest Werte wie Bestell- oder Seriennummern anhand natürlichsprachlicher Regeln aus und reduziert die Pflege eigener Parser.
• Textüberarbeitung: verbessert markierten Text beim Verfassen einer Antwort.
• Vorlagen- und FAQ-Vorschläge: ordnen semantisch ähnliche Inhalte nach Relevanz und bringen vorhandenes Wissen in den Bearbeitungsprozess.
• FAQ-Entwürfe: machen eine gelöste Konversation nach redaktioneller Prüfung als Wissensartikel wiederverwendbar.

Diese Funktionen betreffen drei verschiedene Arbeitsbereiche: Tickets verstehen, Agenten beim Antworten unterstützen und Wissen wiederverwenden. Sie sollten nicht alle gleich behandelt werden. Ein vom Agenten geprüfter Formulierungsvorschlag birgt andere Risiken als eine automatische Änderung von SLA oder Queue.

Automatische Klassifizierung und Agenten-Feedback

Nach der ersten Kundennachricht kann Znuny-LLM eine Queue, einen Typ, einen Service und ein SLA vorschlagen. Die Auswahl ist auf Werte beschränkt, die für das jeweilige Ticket zulässig sind. Die Ergebnisse erscheinen in einem Seitenleisten-Widget und können pro Feld mit positivem oder negativem Feedback bewertet werden.

Bestätigtes Feedback wird gespeichert und kann bei späteren Anfragen als Few-Shot-Beispiel in den Prompt aufgenommen werden. Das allgemeine Modell erhält dadurch konkrete frühere Entscheidungen als Orientierung; das Basismodell selbst wird nicht neu trainiert.

Dieser Ansatz passt ein allgemeines LLM pragmatisch an den Service-Desk an. Er benötigt keine eigene Trainingspipeline und macht Korrekturen unmittelbar nutzbar. Vor dem Rollout sollten Teams dennoch einige Fragen beantworten:

• Wer darf Klassifizierungsfeedback bestätigen?
• Wie werden schlechte oder widersprüchliche Beispiele entfernt?
• Bleibt die Qualität über Queues, Sprachen und Ticket-Arten stabil?
• Welche Felder bleiben Vorschläge, und welche lösen Folgeprozesse aus?
• Wie misst das Team falsches Routing und ungeeignete SLA-Empfehlungen?

Bei kritischen Feldern sollte der Einstieg über Empfehlungen statt unbeaufsichtigter Änderungen erfolgen. Eine Human-in-the-Loop-Phase liefert belastbare Erkenntnisse über die Modellqualität, bevor Ergebnisse Eskalationswege oder Queue-Verantwortung beeinflussen.

Mehrsprachige Zusammenfassungen und bessere Tickettitel

Znuny-LLM erzeugt kurze Ticket-Zusammenfassungen und aktualisiert sie, wenn neue Artikel oder Ticketdaten hinzukommen. Laut Znuny können Zusammenfassungen auf Englisch, Deutsch, Französisch, Spanisch, Italienisch, Niederländisch und Portugiesisch gespeichert und entsprechend der bevorzugten Agentensprache angezeigt werden.

Das Add-on kann außerdem eingehende E-Mail-Betreffzeilen in kurze, aussagekräftige Tickettitel in der Sprache des Kunden umformulieren. Telefon- und interne Tickets werden von dieser Funktion nicht verändert.

Beide Funktionen adressieren ein bekanntes Service-Desk-Problem: Die erste Nachricht und ihr Betreff geben das eigentliche Anliegen oft nur unzureichend wieder. Eine gute Zusammenfassung verkürzt die Einarbeitung in lange Verläufe; ein präziser Titel macht Ticketlisten leichter erfassbar.

Die Ausgabe bleibt dennoch eine generierte Interpretation. Eine Zusammenfassung kann eine Einschränkung auslassen oder die jüngste Nachricht überbewerten. Bei sicherheitskritischen, vertraglichen oder besonders sensiblen Vorgängen muss der vollständige Verlauf verfügbar bleiben; die Zusammenfassung sollte nie die einzige Entscheidungsgrundlage sein.

Dynamische Felder ohne eigene Regex für jedes Format

Administratoren können in natürlicher Sprache beschreiben, welche Information Znuny-LLM aus einem Artikel extrahieren und in ein dynamisches Feld schreiben soll. Beispiele sind Rechnungsnummern, Bestellnummern, Asset-IDs oder Seriennummern.

Das kann leichter zu pflegen sein als eine Sammlung regulärer Ausdrücke, vor allem bei uneinheitlichen Kundenformulierungen. Es ist jedoch nicht automatisch deterministischer. Bevor ein extrahierter Wert einen Folgeprozess steuert, sollte geprüft werden:

1. ob der erwartete Wert tatsächlich im Quellartikel vorkommt;
2. ob das Modell genau einen Wert zurückgegeben hat;
3. ob das Format zum Zielfeld passt;
4. was bei fehlenden oder mehrdeutigen Ergebnissen geschieht; und
5. ob ein Agent den Wert sehen und korrigieren kann.

Bei Kennungen, die finanzielle Vorgänge, Provisionierung oder Zugriffsrechte beeinflussen, gehören Formatvalidierung und menschliche Freigabe zusätzlich zum LLM in den Prozess.

Schreibhilfe und Wissensvorschläge

Mit Compose Selection Rewrite kann ein Agent Text im Antworteditor markieren und vom Modell überarbeiten lassen. Laut Znuny berücksichtigt die Anfrage den Antwort-Prompt der Queue, die erkannte Sprache und den Ticketkontext. Die endgültige Nachricht bleibt unter Kontrolle des Agenten.

Znuny-LLM verwendet außerdem Embeddings, um Vorlagen und FAQ-Einträge nach semantischer Ähnlichkeit zu sortieren. Bestehende Inhalte werden bei Erstellung oder Änderung eingebettet und anschließend in der Antwortansicht vorgeschlagen. Das ist Retrieval statt freier Generierung: Das System hilft, bereits gepflegtes Organisationswissen zu finden.

Aus gelösten Tickets kann ein Administrator einen FAQ-Entwurf erstellen. Ähnliche vorhandene FAQs fließen in den Kontext ein, um Dopplungen zu reduzieren; der Entwurf kann mit dem Quellticket verknüpft werden. So wird aus einer guten Lösung schneller ein wiederverwendbarer Wissensartikel. Eine redaktionelle Prüfung bleibt notwendig, denn Ticketverläufe können kundenspezifische Details, temporäre Workarounds oder Annahmen enthalten, die nicht in allgemeine Dokumentation gehören.

Betrieb und Datenkontrolle

Bei der Installation legt das Add-on die erforderlichen dynamischen Felder, Datenbanktabellen und Webservices an. Einzelne Funktionen lassen sich deaktivieren, was einen schrittweisen Rollout ermöglicht.

Die wichtigste Architekturentscheidung liegt außerhalb des Pakets: Wo läuft der Modell-Endpunkt?

Lokales Ollama

Mit Ollama kann die Modell-Inferenz in der eigenen Infrastruktur bleiben. Das bietet direkte Kontrolle über Ticketinhalte, bringt aber eigene Betriebsverantwortung mit sich:

• GPU- oder CPU-Kapazität;
• Modellauswahl und Updates;
• Verfügbarkeit und Monitoring;
• Netzwerkisolierung;
• Zugriffskontrolle;
• Sicherung relevanter Konfiguration und Vektordaten; sowie
• Performance bei parallelen Anfragen.

Privater OpenAI-kompatibler Endpunkt

Eine OpenAI-kompatible API erlaubt den Einsatz eines anderen selbst betriebenen Serving-Stacks, ohne den Integrationsvertrag zu ändern. Das ist sinnvoll, wenn ein zentrales Plattformteam bereits freigegebene Modelle betreibt.

Verwalteter Endpunkt

Ein Managed Endpoint reduziert den Aufwand für Hardware und Model Serving, verändert aber den Datenfluss. Zu prüfen sind Mandantenkonfiguration, Verarbeitungsort, Aufbewahrung, Logging, Vertragsbedingungen und die Ticketdaten, die das Znuny-Netzwerk verlassen dürfen.

„Kompatibel“ beschreibt nur die API-Form, nicht das Datenschutzniveau. Die Betriebsentscheidung gehört weiterhin in das Bedrohungsmodell und die Datenschutzprüfung der Organisation.

Prompt Injection: Sinnvolle Kontrollen, aber keine Garantie

Tickets enthalten nicht vertrauenswürdigen Text von Kunden, E-Mail-Absendern und möglicherweise kompromittierten Systemen. Dadurch wird prompt injection zu einem realen Designrisiko: Eine Nachricht kann Anweisungen enthalten, die das LLM manipulieren sollen, statt ein Support-Anliegen zu beschreiben.

Znuny gibt an, dass Znuny-LLM eingehende Artikel vor dem Modellaufruf mit einer gewichteten mehrsprachigen Musterliste prüft. Zu den Signalen gehören Modell-Steuertokens, Anweisungen zum Überschreiben vorheriger Regeln, erzwungene Rollen und bekannte Jailbreak-Muster. Wird der konfigurierte Schwellenwert überschritten, kann das Ticket markiert und die LLM-Verarbeitung bis zur Prüfung durch einen Agenten ausgesetzt werden.

Die Standard-Prompts trennen vertrauenswürdige Metadaten außerdem durch Begrenzungsmarker vom kundenseitig geschriebenen Inhalt, weisen das Modell an, Anweisungen im nicht vertrauenswürdigen Bereich nicht zu befolgen, und begrenzen die Artikellänge.

Das sind sinnvolle Defense-in-Depth-Maßnahmen. Keine Musterliste und keine Prompt-Anweisung kann Prompt Injection jedoch vollständig verhindern. Administratoren sollten zusätzlich:

• dem Modell-Endpunkt nur notwendige Berechtigungen geben;
• generierte Ergebnisse von privilegierten Werkzeugen trennen, solange sie nicht gesondert validiert wurden;
• Entscheidungen und Modellfehler protokollieren, ohne unnötig sensible Inhalte offenzulegen;
• Erkennungsschwellen und Fehlalarme regelmäßig prüfen;
• mehrsprachige und verschleierte Angriffe testen; und
• vor Änderungen mit hoher Auswirkung eine Freigabe verlangen.

Eine robuste Architektur geht davon aus, dass Modellergebnisse falsch oder manipuliert sein können, und begrenzt deren Folgen.

Znuny-LLM und OTAI adressieren unterschiedliche Ebenen

Znuny-LLM ist ein nativer Assistent innerhalb von Znuny. Seine Stärke liegt in der Breite: Ein Paket ergänzt mehrere LLM-gestützte Arbeitsabläufe direkt in der Agentenoberfläche.

OTAI konzentriert sich auf eine separate Automatisierungsebene für Ticket-Klassifizierung und Routing über unterstützte Ticketsysteme hinweg. Beim datenschutzorientierten Ansatz kann ein kundenspezifisches Modell aus QueueSpec-Metadaten – Queue-Namen, Beschreibungen und selbst erstellten Beispielen – trainiert werden, während die Inferenz auf Produktionstickets On-Premises läuft. Unser Guide zur KI-Ticket-Klassifizierung ohne historische Ticketdaten beschreibt dieses Modell.

Beide Ansätze schließen sich nicht aus:

• Nutzen Sie Znuny-LLM, wenn Agenten Zusammenfassungen, Schreibhilfe, Wissensvorschläge, Extraktion und schnell verfügbare LLM-Klassifizierung direkt in Znuny benötigen.
• Prüfen Sie eine dedizierte Klassifizierungsschicht, wenn Routing einen eigenen Modell-Lebenszyklus, messbare Abnahmekriterien oder konsistente Integration jenseits einer einzelnen Ticketsystem-Oberfläche benötigt.
• Behalten Sie deterministische Znuny-Regeln für Fälle, die bereits eindeutig, stabil und nachvollziehbar sind.

Die passende Architektur kann alle drei Elemente kombinieren. Eine Mailbox-Regel übernimmt deterministischen Eingang, Znuny-LLM unterstützt den Agenten und ein spezialisierter Klassifikator bearbeitet eine klar definierte Routing-Aufgabe. Entscheidend sind klare Zuständigkeiten und nachvollziehbare Bewertung.

Ein kontrollierter Rollout in sechs Schritten

1. Datenflüsse erfassen

Dokumentieren Sie, welche Ticketfelder und Artikelinhalte das Modell erreichen, wo der Endpunkt läuft und was er protokolliert. Embeddings und generierte FAQ-Entwürfe gehören ebenfalls in diese Prüfung.

2. Mit reversibler Unterstützung beginnen

Starten Sie mit Textüberarbeitung, Zusammenfassungen oder Vorschlägen, die ein Agent ausdrücklich prüft. Diese Funktionen schaffen Nutzen, ohne stillschweigend Ticketverantwortung zu ändern.

3. Ausgangswerte messen

Ermitteln Sie Bearbeitungszeit, Neuzuweisungsrate, Klassifizierungsqualität und Wissensnutzung vor Aktivierung der KI. Ohne Baseline lässt sich ein subjektiv hilfreiches System schwer operativ bewerten.

4. Klassifizierung als Empfehlung pilotieren

Aktivieren Sie Vorschläge für Queue, Service, Typ und SLA zunächst nur für ausgewählte Queues. Untersuchen Sie Fehler nach Feld und Ticketkategorie, statt alle Resultate zu einer einzigen Genauigkeitszahl zusammenzufassen.

5. Guardrails vor Automatisierung einführen

Validieren Sie Formate, definieren Sie Prüfregeln, beschränken Sie Berechtigungen und planen Sie die Korrektur falscher Ergebnisse, bevor ein generiertes Feld einen Folgeprozess auslöst.

6. Funktion für Funktion erweitern

Znuny-LLM erlaubt das getrennte Deaktivieren von Funktionen. Nutzen Sie das. Ein kontrollierter Rollout ist leichter zu analysieren und gibt Agenten Zeit, angemessenes Vertrauen aufzubauen.

Häufig gestellte Fragen

Ist Znuny-LLM kostenlos?

Znuny hat Znuny-LLM als freies Open-Source-Add-on angekündigt. Für den Betrieb des Modell-Endpunkts können dennoch Kosten für Hardware, Hosting, Energie, Monitoring und Administration entstehen.

Welche Znuny-Version wird benötigt?

Laut Znuny ist Znuny 7.3 oder neuer erforderlich.

Benötigt Znuny-LLM zwingend Ollama?

Nein. Ollama wird direkt unterstützt, das Add-on kann aber auch OpenAI-kompatible Endpunkte einschließlich Azure OpenAI verwenden.

Kann Znuny-LLM vollständig On-Premises laufen?

Ja. Wenn Znuny und der konfigurierte Modell-Endpunkt in der eigenen Umgebung laufen, kann die Inferenz On-Premises bleiben. Bei einem verwalteten Endpunkt folgen Ticketdaten dessen konfiguriertem Datenfluss und seinen Richtlinien.

Trainiert Agenten-Feedback das Modell neu?

Znuny beschreibt das Feedback als gespeicherte Beispiele für spätere Prompts. Das ist Few-Shot Prompting, kein Training des zugrunde liegenden Modells.

Macht die Prompt-Injection-Erkennung die LLM-Verarbeitung sicher?

Sie reduziert das Risiko, beseitigt es aber nicht. Mustersuche, Prompt-Grenzen, minimale Berechtigungen, Ausgabevalidierung, Logging und menschliche Freigabe sollten zusammenwirken.

Fazit

Znuny-LLM ist eine bedeutende Ergänzung für selbst gehostete Service-Desks. Das Add-on bringt nützliche LLM-Funktionen dorthin, wo Znuny-Agenten bereits arbeiten, und lässt Organisationen zwischen lokalem, privatem oder verwaltetem Modell-Endpunkt wählen.

Der Nutzen hängt weniger davon ab, alle Funktionen sofort einzuschalten, als von einer disziplinierten Einführung: Datenflüsse erfassen, mit überprüfbarer Unterstützung starten, Klassifizierungsqualität messen und die Folgen falscher Ausgaben begrenzen. So kann Znuny-LLM ein bewährtes Ticketsystem erweitern, ohne die Kontrolle aufzugeben, die Self-Hosting attraktiv gemacht hat.

Als nächsten Schritt können Sie OTAI für Znuny und unseren Ansatz zur datenschutzorientierten Ticket-Klassifizierung ansehen.

Quelle

• Znuny: „Znuny-LLM Add-on: Self-Hosted AI for Service Desks“