Open-Source-Ticket- und Helpdesk-Systeme bleiben für viele Organisationen die Grundlage für Serviceprozesse. Gleichzeitig rücken KI-Unterstützung (Zusammenfassungen, Routing, Klassifikation, Antwortvorschläge) in den Fokus — oft kombiniert mit dem Wunsch nach Nachvollziehbarkeit, On-Prem- oder lokaler Inference und Unabhängigkeit von einzelnen Cloud-Anbietern. Dieser Text ordnet ein, welche Spielarten sich abzeichnen und worauf Teams bei Architektur und Governance achten sollten.
KI im Helpdesk: native Funktion, API-Anbindung oder eigene Automationsschicht?
In proprietären Suites sind KI-Funktionen häufig als Paket mit Lizenz und Datenverarbeitung verkoppelt. Bei offenen Systemen entsteht ein Spektrum:
- Im Produkt integrierte Funktionen (z. B. Zusammenfassung, Kategorisierung), ggf. mit konfigurierbaren Modellendpunkten.
- Über APIs und Webhooks angebundene Automatisierung (Orchestrierungstools, eigene Dienste), bei der das Ticketsystem die Quelle der Wahrheit bleibt.
- Separater Automation Layer, der mehrere Ticket-Backends vereinheitlicht — sinnvoll für Integratoren, MSPs oder gemischte Bestände.
Die folgenden Abschnitte beziehen sich überwiegend auf Zammad (gut dokumentierte öffentliche KI- und API-Einordnung) sowie auf ein Open-Source-Projekt für ticketübergreifende Pipelines; für Znuny- und OTOBO-orientierte Umgebungen gelten viele API- und Datenschutz-Prinzipien analog, auch wenn die konkrete Ausgestaltung je Instanz variiert.
Zammad 7 und KI: was offiziell geplant ist und was Communities heute schon bauen
Roadmap und native KI
Zammad beschreibt in einem Blogbeitrag aus dem Jahr 2025 ausdrücklich, dass native KI-Funktionen mit Zammad 7.0 eingeführt werden sollen — mit Zielen wie Zusammenfassungen, automatischer Kategorisierung sowie Sentiment- und Eskalationsindikatoren. Gleichzeitig wird betont, dass lokale Modelle (z. B. über Ollama) mitgedacht werden, um sensible Daten nicht zwingend an Drittanbieter senden zu müssen. Der Artikel verweist außerdem auf eine separate KI-Strategie auf dem Unternehmensblog und zeigt parallel, wie sich heute schon REST-API, Webhooks, Trigger und Scheduler mit Werkzeugen wie n8n für KI-gestütztes Routing oder Priorisierung kombinieren lassen.
- From API to AI: Streamline Support Operations with Zammad, n8n and Ollama (Zammad-Blog, Stand der Darstellung: siehe Seite)
- AI in Service of Support Agents (Strategieartikel, verlinkt vom obigen Beitrag)
Community: Erwartungsmanagement und Praxis
In der Zammad-Community wurde Mitte 2024 seitens des Core Teams auf den Stand „noch nicht viel“ an produktseitigen GenAI-Funktionen hingewiesen und auf die Diskussion zu GPT-Integration verwiesen — ein nützlicher Hinweis dafür, dass Forenbeiträge älteren Datums nicht immer den aktuellen Produktstand widerspiegeln, sobald Releases nachziehen.
Seit längerem diskutieren Nutzer:innen GPT-Anbindung, Anonymisierung und Kosten (tokenbasierte Preise, Aufwand für Indexierung großer Bestände). Ein Mitglied des Core Teams hebt u. a. DSGVO-Risiken und den Bedarf an starker Anonymisierung hervor, wenn Ticketinhalte für externe Modelle genutzt werden; in der Praxis wird unter anderem der Weg über Notizen im Ticket genannt, damit Agent:innen Vorschläge prüfen und teilweise übernehmen können, statt automatisch zu antworten.
In frei zugänglichen Antworten finden sich konkrete Tech-Stacks (z. B. Python, zammad_py, Vektor-/Retrieval-Komponenten, Microsoft Presidio für Identifikation und Anonymisierung sensibler Texte); das ist keine offizielle Zammad-Dokumentation, aber eine belastbare Beschreibung eines patterns, das Organisationen häufig variieren müssen — etwa hinsichtlich Retention von Embeddings.
Lokale LLMs (Ollama) im Ticketsystem: welches Modell, welche Risiken?
Nach dem Produktüberblick im Zammad-Blog ist Unterstützung für lokale Modelle explizit genannt — in der Betriebsparaxis zeigt ein aktiver Foren-Thread exemplarisch, dass „funktioniert lokal mit Ollama“ nicht automatisch jedes Modell ohne Weiteres bedeutet: Für Zusammenfassungen und strukturierte Antwortformate können JSON- oder Schema-Anforderungen scheitern, wenn das Modell oder die Laufzeitumgebung dort nicht konform liefern. Ein Core-Team-Mitglied verweist in diesem Kontext etwa auf einen Issue in den Ollama-Repositories, der strukturierte Ausgaben mit bestimmten Modellen betrifft — ein Reminder, solche Risiken bei Auswahl der Modellfamilie, Regressionstests und Monitoring zu verproben.
- Which model from Ollama works best for AI features?
- Structured output with OpenAI SDK and gpt-oss:20b not working (Ollama)
Open Ticket AI: eine neutrale Automationsschicht für Zammad, OTOBO und Znuny
Unabhängig von einem einzelnen Hersteller beschreibt das Projekt Open Ticket AI (LGPL-2.1, Code und Doku öffentlich) eine plugin-basierte, on-premisefähige Automation Engine mit vereinheitlichtem Ticketmodell und konfigurierbaren Pipelines (u. a. Klassifikation, Aktualisierung von Tickets, Anreicherung). Laut Repository-README und einführendem Artikel werden u. a. Anbindungen zur OTOBO-/Znuny-/OTRS-Familie sowie Zammad (mit Beta-Hinweis) genannt; Erweiterungen können über PyPI-Pakete mit Namenspräfix otai- verteilt werden.
Das ist kein Ersatz für ein Helpdesk-Backend, sondern ein Integrations- und Orchestrierungsrahmen — vergleichbar mit dem im Zammad-Blog skizzierten ETL-/Workflow-Ansatz, aber mit stärkerem Fokus auf wiederverwendbare Pipes und mehrere Systeme parallel.
- open-ticket-ai auf GitHub
- Dokumentation (openticketai.com)
- Einführender Artikel (Medium, Autor: Tobias Bück)
Hinweis zur Einordnung: Reifegrad, stabile Releases und Produktions-Erfahrungen variieren wie bei jedem Open-Source-Projekt — vor einer breiten Produktionsentscheidung lohnt ein Pilot mit Last- und DPIA-relevanten Szenarien.
DSGVO im KI-Helpdesk: Zweckbindung, Pseudonymisierung und Auftragsverarbeitung
Mit KI über Ticketsystemen rücken mehrere Punkte zusammen:
- Zweckbindung und Rechtsgrundlage: Welche Aufgaben darf Automatisierung wahrnehmen (nur Entwurf, nur internes Routing vs. Kommunikation nach außen)?
- Datenminimierung und Pseudonymisierung: Vor Übermittlung an Cloud-Endpoints oder sogar vor lokaler Langzeitspeicherung von Einbettungen (Embeddings).
- Auftragsverarbeitung und Unterauftragnehmer: Wenn APIs externer Anbieter genutzt werden, Verträge und Löschkonzepte prüfen; bei lokaler Inference dennoch Logging und Support-Zugriffe bedenken.
- Transparenz und menschliche Kontrolle: Arbeitsrechtliche und qualitative Aspekte (Haftung, Qualitätssicherung) sprechen oft für Human-in-the-loop, wie es in Community-Beispielen zu Zammad skizziert wird.
Dies ersetzt keine Rechtsberatung; die Umsetzung hängt von Branche, Betriebsrat/Arbeitnehmervertretung und konkreter Verarbeitung ab.
Konsequenzen für ein offenes Helpdesk-Plugin-Verzeichnis
Ein offenes Verzeichnis für Erweiterungen und kompatible Pakete (siehe Znuny-Plugins, Zammad-Plugins, OTOBO-Plugins) hilft, solche Integrationspfade sichtbar und vergleichbar zu machen — unabhängig davon, ob KI im Kernprodukt, über n8n & Co. oder über eine dedizierte Engine angebunden wird. Weitere Einordnungen finden Sie in der Blog-Übersicht.
Transparenz zu Unsicherheiten: Die genaue Funktionsliste und Stabilität von Zammad 7.x KI-Features sollten Sie anhand der Release Notes und Admin-Dokumentation Ihrer installierten Version gegenprüfen; Community-Threads spiegeln oft punktuelle Erfahrungen wider, nicht den vollständigen Produktumfang. Gleiches gilt für die Modell- und Ollama-Versionen im laufenden Betrieb — hier sind Reproduzierbarkeit und Regressionstests entscheidend.