Ausgangslage
Im Service Management liegt die relevante Diagnoseinformation selten an einer Stelle. Support-Mitarbeitende müssen historische Tickets, interne Dokumentation, Benutzer- und Tenant-Kontext sowie aktuelle Servicezustände zusammenführen. Besonders für neue Mitarbeitende ist schwer erkennbar, welche Quelle zuverlässig ist und ob ein Problem ein Einzelfall oder Teil einer wiederkehrenden Störung ist.
Warum kein gewöhnlicher Cloud-KI-Assistent?
Der Use Case verbindet interne Tickets, Dokumentation, Identitätskontext und Service-Health-Evidenz. Dafür genügt kein frei arbeitender Chat-Assistent: Quellenzugriff, Tenant- und Rollenbezug, Connector-Credentials, read-only Grenzen und Audit müssen technisch erzwungen werden. Die lokale Architektur wurde gewählt, um Inferenz, Wissensschicht und Tool-Nutzung in einem kontrollierten Betriebs- und Berechtigungsmodell zusammenzuführen – nicht, weil Cloud-KI pauschal ausgeschlossen wäre.
Gelieferte Lösung
Für Cross-Platform IT wurde ein lokales, browserbasiertes und testbares KI-Kundenpaket konzipiert und umgesetzt. Der Pilotpfad nimmt natürlichsprachliche Supportfragen entgegen, nutzt kontrollierte Recherchebausteine und bereitet Quellen, Befunde und mögliche nächste Schritte strukturiert für Menschen im Support vor.
| Oberfläche | Open WebUI als zentrale Chat- und Admin-Frontdoor. |
|---|---|
| Kontrollschicht | Gateway für Rollen, Scopes, Quellenpflicht, Policy-Grenzen, No-answer-Regeln und Audit. |
| Wissensschicht | Qdrant-basiertes RAG mit Hybrid Retrieval, Reranking, Quellen- und Claim-Validierung sowie quellengebundenem LLM-Wiki. |
| Agents & Connectoren | Spezialisierte, read-only MCP-/Connector-Bausteine je Systemdomäne, unter anderem für Jira/Confluence und Microsoft Graph/Service Health. |
| Runtime | Lokale Inferenz über automatisierbare Runtimes wie Ollama oder llama.cpp; vLLM wurde als weitere lokale Runtime-Option bewertet. |
| Betrieb | Docker-/Containerisierungsansatz, wiederholbare Installation, Health-Prüfungen und Akzeptanzpfad für das pilotfähige Kundenpaket. |
Wie der Service-Assistent arbeitet
Sicherheits- und Governance-Grenzen
- Operative Integrationen arbeiten im Diagnosepfad read-only.
- Das Modell erhält keine frei nutzbaren Connector-Credentials.
- Unbekannte oder nicht erlaubte Tools werden durch die Gateway-Policy blockiert.
- Fehlt ausreichende Evidenz, soll das System eine No-answer-Antwort liefern, statt eine Lösung zu erfinden.
- Audit protokolliert Betriebsmetadaten, aber keine Rohprompts, Modell-Tokens oder Secrets.
Pilot-Abnahme und öffentlich belegter Stand
Geliefert wurde ein installierbares und testbares Pilotpaket mit browserbasierter Oberfläche, lokaler Runtime, Qdrant-RAG, Agent-/Connector-Bausteinen, Quellenvalidierung, Policy und Audit. Damit lässt sich der zentrale Service-Management-Use-Case reproduzierbar demonstrieren und entlang klarer Akzeptanzkriterien prüfen.
| Abnahmekriterium | Öffentlich belegter Stand |
|---|---|
| Reproduzierbare Installation | Setup-, Diagnose- und Browser-Akzeptanzpfade sind Bestandteil des Pilotpakets; ein kundenspezifisches öffentliches Laufprotokoll wird nicht behauptet. |
| Kontrollierter Systempfad | Open WebUI, Gateway, lokale Modellliste, RAG und Health-Prüfungen sind als prüfbarer Pilotpfad definiert. |
| Quellengebundene Antwort | Quellen- und Claim-Validierung sowie ein entsprechender Live-Check sind umgesetzt; eine öffentliche Quellenquote liegt noch nicht vor. |
| Korrektes No-answer | Fehlende oder schwache Evidenz soll fail-closed zu No-answer führen; eine veröffentlichte Treffer- oder Fehlerquote liegt noch nicht vor. |
| Read-only Tool-Grenze | Der Planner ist auf eine read-only Allowlist begrenzt; die Zahl produktiv angebundener Kundensysteme wird nicht behauptet. |
| Audit ohne sensible Inhalte | Audit protokolliert Betriebsmetadaten ohne Rohprompts, Tokens oder Secrets; ein externes Audit oder Zertifikat wird nicht behauptet. |
Noch zu messende Kundenergebnisse
Für eine spätere Ergebnisbewertung sind insbesondere Recherchezeit, Retrieval-Trefferquote, Quellenquote, korrekte No-answer-Entscheidungen, akzeptierte nächste Schritte und erkannte Störungscluster vorgesehen. Diese Kennzahlen werden erst veröffentlicht, wenn eine belastbare Messung und Kundenfreigabe vorliegen.
Rolle von Slavko Klincov
Slavko Klincov verantwortete Konzeption und Programmierung der Gateway-, RAG-, MCP-/Connector- und Agentenbausteine, die lokale Runtime-Bewertung, Containerisierungs- und Betriebsarchitektur sowie Quellen-, Policy- und Auditgrenzen.