Alle Referenzen / Produktiv
IT-Service-Automatisierung für eine Behörde, vollständig On-Premises.
Eine nationale Behörde, die KI-gestützte Ticket-Triage brauchte, ohne dass Daten in die Cloud gelangen.
- Kunde
- Eine nationale Digitalisierungsbehörde
- Branche
- Öffentlicher Sektor, IT-Betrieb
Wachstumsziel
Das Routing am Service-Desk einer nationalen Behörde automatisieren, ohne dass Daten das eigene Netz verlassen.
Betriebliche Einschränkung
Übliche KI-Werkzeuge basieren auf Cloud-APIs. Für sensible Daten im öffentlichen Sektor kam das nicht infrage.
Messbares Ergebnis
Tickets werden automatisch vorsortiert und geroutet, vollständig im eigenen Rechenzentrum, ohne Abhängigkeit von einem externen Modellanbieter.
Die ausführliche Beschreibung
- Ausgangslage
- Jedes Ticket wurde manuell gelesen und geroutet, Cloud-KI war per Vorgabe ausgeschlossen.
- System
- Ein vollständig lokales Triagesystem auf On-Premises-Modellen, containerisiert für die vorhandene Infrastruktur der Behörde und geeignet für isolierte Netze.
- Kontrollen
- Keine Cloud-Aufrufe und keine Daten, die das Netz verlassen. Routing-Entscheidungen werden protokolliert und der Service-Desk kann jede davon übersteuern.
- Ergebnis
- Automatische Triage und Routing, bei denen sensible Daten das Netz der Behörde nicht verlassen und keine Abhängigkeit von einem externen Modellanbieter besteht.
Im Detail
Wachstum bedeutete mehr Tickets mit strengen Datenvorgaben
Die nationale Digitalisierungsagentur hatte ein klares Mandat: mehr öffentliche Services online bringen. Jeder neue Onlinedienst erhöhte das Volumen auf einem ohnehin ausgelasteten IT-Servicedesk. Jedes Ticket, Störung, Berechtigungsanfrage oder Änderung, musste von Hand gelesen und weitergeleitet werden. Die Arbeit war wiederkehrend und zeitkritisch, gleichzeitig enthielt sie sensible Daten aus dem öffentlichen Bereich, die das Netz nicht verlassen durften. Vorgaben schlossen Cloud-KI von Anfang an aus, obwohl die Führung Wege suchte, die Nachfrage zu bedienen, ohne die Einführung neuer Services auszubremsen.
Das Team erkannte, welches Potenzial in KI-gestützter Triage steckte. Sie brauchten ein System, das Freitext lesen, das Anliegen verstehen und Tickets dem richtigen Team zuordnen konnte. Gleichzeitig mussten sie die Hoheit über ihre Daten vollständig behalten. Keine Cloud-APIs, keine externe Verarbeitung, keine verdeckte Ablage. Nur ein On-Premises-System, das zu den bestehenden Sicherheitsvorgaben passte, wäre für interne Risikoverantwortliche und Aufsichtsgremien akzeptabel. Die Wahl war deutlich: Entweder man akzeptiert manuelle Triage als dauerhafte Grenze, oder man findet einen anderen Weg, KI in den Servicedesk zu bringen.
Manuelle Triage begrenzte die aufnehmbare Nachfrage
Der Servicedesk war die zentrale Anlaufstelle für Anliegen aus mehreren Behörden und Systemen. Analystinnen und Analysten lasen jedes Ticket, interpretierten die Beschreibung, prüften Anhänge und wählten Kategorie und zuständige Gruppe. Einfache Fälle kosteten Zeit, komplexe Fälle hingen von Erfahrung und lokalem Wissen ab. Mit zunehmender Online-Nutzung wuchsen die Warteschlangen, Reaktionsziele wurden schwieriger zu halten. Triage band qualifizierte Mitarbeitende an das Sortieren von Tickets statt an die Lösung von Störungen. Die Leitung brauchte mehr Kapazität, ohne die Kontrolle über vertrauliche Daten zu lockern.
Da Cloud-KI-Tools ausgeschlossen waren, beschränkten sich frühere Automatisierungsversuche auf regelbasierte Weiterleitung. Solche Regeln konnten Schlagwörter oder Felder abgleichen, kamen aber mit der Vielfalt der Sprache von Bürgern und internen Nutzern in Tickets schlecht zurecht. Aufbau und Pflege neuer Regeln erzeugten mehr Arbeit statt sie zu reduzieren. Dem Team war klar, dass es nur einen Bruchteil der Informationen pro Ticket nutzte, eingeengt durch das, was die Regelengine lesen konnte. Sie brauchten einen Ansatz, der die Vorgaben respektierte und gleichzeitig echte Sprache verarbeiten konnte.
SIEL entwarf einen vollständig lokalen KI-Triage-Workflow
SIEL arbeitete mit den IT- und Sicherheitsteams der Agentur an einem Triage-System, das vollständig in ihrer Infrastruktur lebte. Der Fokus lag zuerst auf der Arbeit, dann auf der Technologie. Gemeinsam wurden bestehende Routing-Entscheidungen, Zuweisungsqueues und Freigabeschritte kartiert, in denen menschliche Prüfung weiter Pflicht bleiben würde. Daraus ergab sich ein greifbares Zielbild. Das neue System musste eingehende Tickets aus den vorhandenen Werkzeugen lesen, Kategorie und Zielqueue bestimmen, seine Begründung protokollieren und das Ticket zurückgeben, ohne ein einziges Byte das Netz der Agentur verlassen zu lassen.
Technisch nutzte das System On-Premises-Modelle, die in den eigenen Rechenzentren der Agentur liefen. SIEL verpackte Modelle und Anwendungslogik in Container, die zur bestehenden Plattform der Agentur passten. So ließ sich in die Standardumgebungen deployen, inklusive abgeschotteter Segmente. Die Agentur konnte einsehen, was bereitgestellt wurde, Zugriffe steuern und das Hosting in ihre eigene Überwachung integrieren. Modellupdates und Konfigurationsänderungen liefen über dieselben Change-Prozesse wie andere interne Systeme, ein Vorgehen, das Risikoverantwortlichen Sicherheit gab.
Der Triage-Dienst lief im abgeschotteten Netz
Sicherheitsanforderungen bestimmten jede Designentscheidung. Der Triage-Dienst akzeptierte Tickets ausschließlich aus dem vertrauenswürdigen Netz. Er stellte keine ausgehenden Verbindungen zu externen APIs her. Protokolle, Konfiguration und Modelle wurden lokal gespeichert. Wo ein Air-Gap galt, wurden Updates über etablierte Prozesse in die Umgebung eingebracht. Die Rolle von SIEL war, ein System zu bauen, das sich innerhalb dieser Vorgaben betreiben ließ, ohne Sondergenehmigungen oder spezielle Verbindungen.
Jede Deployment-Einheit war in sich geschlossen. Die Container enthielten Modell, Routinglogik und Schnittstellen zur bestehenden Ticketing-Plattform. Wollte die Agentur dieselbe Triage-Funktion in einem anderen Netzsegment nutzen, konnte sie eine identische Einheit deployen, ohne den Workflow neu zu entwickeln. So konnte die zentrale IT den Triage-Dienst wie jeden anderen internen Service behandeln, mit klaren Grenzen und vorhersehbarem Verhalten statt als Sonderfall wegen KI-Anforderungen.
Menschen blieben entscheidend für Routing und Freigaben
Von Beginn an war klar, dass der Servicedesk die Steuerung behalten musste. SIEL entwickelte das System so, dass jede Routing-Entscheidung mit genügend Kontext protokolliert wurde, um sie zu prüfen. Teamleitungen konnten sehen, wie ein Ticket klassifiziert und an welche Queue es gesendet worden war. Wenn die Entscheidung nicht passte, konnten sie sie übersteuern und das Ticket umleiten. Diese Korrekturen wurden aufgezeichnet und flossen über Konfiguration und Modellpflege in bessere Routing-Ergebnisse ein.
Das Team konnte zudem Schwellenwerte festlegen, wann automatische Weiterleitung erlaubt war und wann ein Ticket in einer Prüfschleife bleiben sollte. Für Kategorien mit höherem Risiko oder komplexeren Vorgaben konnte das System eine Route vorschlagen, aber auf menschliche Bestätigung warten. So konnte die Agentur Automatisierung dort einsetzen, wo die Sicherheit hoch war, und sensible Pfade stärker überwachen. Mit wachsendem Vertrauen in das Verhalten des Systems ließ sich der Umfang vollautomatischer Routen schrittweise erweitern, im Einklang mit der eigenen Risikoneigung.
Festpreis, vereinbart bevor wir anfangen. Ein Senior Engineer antwortet innerhalb von zwei Werktagen.
