suche
ESC

LLMs im First-Level-Support

Sprachmodelle als Service-Desk-Assistenz regelkonform und datenschutzgerecht nutzen.

First-Level KI 30 Min +160 XP

Worum geht’s

Sprachmodelle (LLMs wie ChatGPT) sind im Service Desk verlockend: Sie formulieren in Sekunden eine freundliche Antwort, erklären eine Fehlermeldung laienverständlich oder entwerfen einen KB-Artikel. Aber sie sind Assistenten, keine Autoritäten — und sie können sensible Daten abfließen lassen. Dieses Modul zeigt, wie du LLMs im First-Level nutzbringend und regelkonform einsetzt.

Konzept

Wir betrachten LLMs entlang von fünf Aspekten — dem Raster für KI-Kompetenz:

1. Was funktioniert, was nicht. Ein LLM ist ein wahrscheinlichkeitsbasiertes Sprachmodell, kein Faktenspeicher und keine Logikmaschine. Stark bei: Umformulieren, Antwort-/E-Mail-Entwürfen, KB-Artikeln, Laien-Erklärungen. Schwach bei: verbindlichen Fakten, aktuellen Infos (Knowledge-Cutoff), exaktem Rechnen. Gefährlich: Halluzinationen — frei erfundene, aber überzeugend klingende Befehle oder Fakten.

2. Was du erwarten darfst. Eine schnellere Erstantwort und Hilfe bei Tonalität und Deeskalation. Aber: vor dem Versand fachlich und sprachlich prüfen. Das Modell ersetzt kein Fachwissen — die Verantwortung bleibt bei dir.

3. Sinnvoll prompten. Gib dem LLM anonymisierten Ticket-Kontext, nenne die Zielgruppe (Laie/Profi) und den gewünschten Tonfall, fordere Schritt-für-Schritt und ein klares Ausgabeformat an. Iteriere statt einen Versuch zu nehmen.

Prompt-Labor

4. Anwendungsfälle. Antwortentwurf, KB-Artikel, Übersetzung, Eskalations-Zusammenfassung, eine Fehlermeldung erklären lassen, Textbausteine — immer mit Prüfung.

5. Was du darfst — und was nicht.

Sicherheits- und Datenschutzgrundsatz: Keine Kundendaten, Passwörter oder personenbezogenen Daten in externe LLMs. Ein Ticket vor dem Prompt anonymisieren. Die betriebliche KI-Policy gilt. KI-Entwürfe nie ungeprüft versenden. Und: keine vom LLM vorgeschlagenen System-/Sicherheitsbefehle blind ausführen — halluzinierte Befehle können Schaden anrichten. Für sensible Kontexte sind lokale LLMs (z. B. Ollama) die datensparsame Alternative.

Daten-Freigabe-Check

Welche Inhalte dürfen in ein externes LLM, welche nicht?

Beispiel-Fall

Aufgabe: Du willst dir mit einem externen LLM einen Antwortentwurf für ein Ticket erstellen lassen. Das Ticket lautet: „Frau Petra Klein (petra.klein@kunde.de, Tel. 0151-…) kann sich nicht am Server SRV-FIBU01 (10.20.3.12) anmelden.”

  1. Anonymisieren: Name, E-Mail, Telefonnummer entfernen; Servername/IP durch Platzhalter ersetzen („eine Nutzerin”, „der Fachserver”).
  2. Prompt bauen (Aspekt 3): Rolle (freundlicher Support), Zielgruppe (Laiin), Tonfall, gewünschte Rückfragen, Format.
  3. Entwurf prüfen (Aspekt 2): Stimmen die fachlichen Aussagen? Keine erfundenen Befehle? Tonfall passend?
  4. Keine blinden Befehle (Aspekt 5): Schlägt das LLM ein Kommando vor, prüfst du es, bevor du es nutzt — curl … | bash o. Ä. niemals blind.
  5. Versenden + dokumentieren, dass ein (geprüfter) KI-Entwurf genutzt wurde.

So holst du das Tempo des LLM ab, ohne Daten oder Qualität zu riskieren.

Anwenden

▶ Am Tool ausprobieren

Der Token-Zähler zeigt, wie groß dein Prompt wirklich ist — wichtig für Kontextfenster und um Über-Teilen zu vermeiden.

  1. Füge einen anonymisierten Ticket-Kontext in den Token-Zähler ein.
  2. Lies, wie viele Tokens das ergibt — passt das in das Kontextfenster des Modells?
  3. Kürze überflüssige Details: weniger (irrelevanter) Kontext = klarere Prompts und weniger Datenpreisgabe.
Tool öffnen: /token-zaehler ↗

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Nimm ein (fiktives) Ticket mit Name, E-Mail und internem Servernamen. Anonymisiere es, baue einen strukturierten Prompt (Rolle, Zielgruppe, Tonfall, Format) und prüfe mit dem Token-Zähler die Promptgröße. Notiere dann drei Dinge, auf die du den fertigen LLM-Entwurf vor dem Versand kontrollierst — und welche Daten du nie eingegeben hast.

Tool öffnen: /token-zaehler ↗

Modul im Speedrun testen →