KI kann eine Supportanfrage schneller erfassbar machen: Anliegen zusammenfassen, fehlende Angaben erkennen und passende freigegebene Hinweise vorbereiten. Der Nutzen entsteht, wenn daraus ein gut prüfbarer Bearbeitungsstand wird. Ob eine Antwort versendet oder eine Änderung ausgeführt wird, ist eine eigene Entscheidung.
Für einen ersten Einsatz bietet sich ein begrenzter Aufgabenbereich an. Beispielsweise bereitet der Assistent interne Ticketentwürfe vor, ohne selbst Nachrichten zu versenden oder Systeme zu verändern. So lassen sich Qualität und Nacharbeit am tatsächlichen Arbeitsablauf beurteilen.
Was ein brauchbarer Vorschlag enthalten sollte
Eine kurze Zusammenfassung nennt die beobachtete Störung, die betroffenen Arbeitsmittel und den bisherigen Verlauf. Davon getrennt stehen Vermutungen und noch offene Fragen. Wenn ein Zeitpunkt, eine Fehlermeldung oder der Umfang der Beeinträchtigung fehlt, wird das sichtbar gemacht.
Ein Antwortentwurf sollte erklären, welche Information noch benötigt wird oder welcher freigegebene Schritt sinnvoll erscheint. Eine vorgeschlagene Lösung erhält eine nachvollziehbare Grundlage. Ein ähnlich klingendes altes Ticket reicht nicht als Beleg, wenn Umgebung oder Ursache anders sind.
Beispiel: „Die Anwendung ist langsam“
Der Assistent bereitet Rückfragen zu Zeitpunkt, betroffenen Nutzern, konkreter Funktion und Fehlermeldungen vor. Er kann bereits vorhandene Angaben aus dem Ticket zusammenführen und einen passenden freigegebenen Dokumentationsabschnitt verlinken.
Er behauptet dabei keine bereits durchgeführte Serverprüfung und keine bestätigte Ursache. Eine technische Maßnahme wird erst vorgeschlagen, wenn der verfügbare Befund sie trägt. Dies ist ein mögliches Prozessbeispiel, keine Kundenreferenz.
Ticket- und Dokumentrechte bleiben maßgeblich
Ein Supportassistent benötigt nicht automatisch Zugriff auf jedes Ticket und jede Dokumentation. Die Suche wird auf den jeweiligen Benutzer, den vereinbarten Aufgabenbereich und die passenden Objekte beschränkt. Das gilt auch für Anhänge, interne Notizen und Informationen anderer Auftraggeber.
Bei einer Wissenssuche mit RAG müssen diese Rechte bereits bei der Trefferauswahl berücksichtigt werden. Unberechtigte Inhalte gehören auch nicht in einen später verworfenen Modellkontext. Die technische Umsetzung von Dokumentzugriffen unterscheidet sich je nach Quelle; Microsoft beschreibt beispielsweise unterschiedliche Ansätze für Dokumentrechte in Azure AI Search (externer Link). Ein einfacher Filter ist nur dann wirksam, wenn Identität und Filterwerte vertrauenswürdig ermittelt werden.
Werden mehrere Kundenumgebungen betreut, gehören deren Trennung und die erlaubten Datenflüsse zum Integrationskonzept. Welche Protokolle und Inhalte gespeichert werden, wird nach Zweck und betrieblichem Bedarf festgelegt. Ein möglichst großer vollständiger Promptverlauf ist kein Selbstzweck.
Eingehende Inhalte sind Daten, keine Arbeitsanweisung
Ein Ticket kann Text enthalten, der den Assistenten zu einer unerlaubten Aktion auffordert. Gleiches gilt für Dokumente, E-Mails und Anhänge. Solche Inhalte dürfen weder Systemregeln verändern noch zusätzliche Werkzeuge oder Zugänge freischalten.
Die Anwendung begrenzt deshalb serverseitig, welche Quellen gelesen und welche Funktionen aufgerufen werden dürfen. Ein Modellvorschlag allein setzt diese Grenzen nicht außer Kraft. Für die Einbindung definierter Funktionen können kontrollierte MCP-Werkzeuge und bestehende APIs verwendet werden; die MCP-Sicherheitsdokumentation (externer Link) beschreibt dazu konkrete Angriffs- und Schutzbereiche.
Freigabe und Ausführung als zwei getrennte Schritte
Die bearbeitende Person sieht Zusammenfassung, Quellen und Antwortentwurf gemeinsam. Sie kann Angaben korrigieren, Rückfragen stellen oder den Vorschlag verwerfen. Ein Versandknopf muss klar zeigen, welche Nachricht an welchen Empfänger gesendet wird. Das Senden erfolgt über die dafür berechtigte Anwendung.
Für technische Änderungen ist eine weitere Trennung sinnvoll: Ein Diagnosevorschlag wird nicht allein dadurch zu einem administrativen Auftrag, dass er plausibel klingt. Zweck, Zielsystem, erlaubter Umfang und erforderliche Freigaben werden gesondert geprüft. Unklare oder riskante Fälle gehen an die zuständige Fachperson.
Ein Pilot braucht mehr als eine gute Vorführung
- Normale Fälle: Werden Anliegen und notwendige Rückfragen richtig erfasst?
- Fehlende Grundlage: Erkennt der Assistent, dass eine belegbare Antwort noch nicht möglich ist?
- Falsche oder alte Quelle: Werden Version und tatsächlicher Bezug zum Ticket geprüft?
- Rechtewechsel: Verschwinden Inhalte nach einem Entzug des Zugriffs aus Suche und Kontext?
- Manipulierte Eingaben: Bleiben Werkzeuggrenzen und Freigaben erhalten?
- Ausfall des Dienstes: Kann das Ticket weiterhin regulär bearbeitet werden?
Die Bewertung sollte auch die Zeit für das Lesen, Korrigieren und Nachprüfen erfassen. Ein langer Entwurf kann zusätzliche Arbeit schaffen. Ein kurzer, sauber belegter Bearbeitungsstand kann dagegen entlasten, selbst wenn die endgültige Entscheidung weiterhin bei einem Menschen liegt.
Vom einzelnen Entwurf zur betreubaren Integration
DAXS klärt den geeigneten Einstieg mit Ihrem Support und Ihrer IT, bindet freigegebene Datenquellen an und setzt einen begrenzten Pilot um. Bestehendes Ticketsystem, Identitäten und Dokumentation werden dabei gemeinsam betrachtet. Umfang und Ausbau folgen dem nachgewiesenen Nutzen.
KI-Einsatzfelder im Überblick · Einführung und Nutzungsregeln · IT im laufenden Betrieb