Reale KI-Qualitätsfälle vorbereiten

Unter Einstellungen → KI-Qualität können Administratoren aus geeigneten gelösten Tickets getrennte Qualitätsfälle erstellen. Diese Fälle dienen später dazu, Klassifikation, Priorisierung und Antwortentwürfe reproduzierbar zu prüfen.

Der Bereich ist kein Versandwerkzeug und keine KI-Ausführung. Er kopiert ausgewählte Inhalte in einen eigenen Prüfdatensatz, bereinigt sie und verlangt eine ausdrückliche menschliche Freigabe. Das Ursprungsticket, seine Nachrichten und der Kontakt bleiben unverändert.

Übergangsregel für noch nicht veröffentlichte Projekte

Für den Start der Evaluation reichen mindestens zwei tatsächlich eingegangene, zur redaktionellen Nutzung freigegebene und anonymisierte Fälle aus einem Projekt, das bereits echten Supportbetrieb hat. Ein noch nicht veröffentlichtes Projekt kann keine Realfälle liefern und blockiert den Start deshalb nicht dauerhaft. Seine gekennzeichneten Testfälle dürfen den technischen Kanal prüfen, zählen aber nicht als Realfälle und erlauben für dieses Projekt noch keine produktive KI-Freigabe.

Welche Tickets angeboten werden

Ein Ticket erscheint nur in der Auswahlliste, wenn es:

• gelöst oder geschlossen ist,
• aus einem E-Mail- oder Web-Kanal stammt,
• mindestens eine eingehende Nachricht besitzt,
• nicht gelöscht wurde und
• noch keinem Qualitätsfall zugeordnet ist.

Eine bereits versendete Antwort wird als Ausgangspunkt für die Referenzantwort verwendet. Fehlt sie, muss die fachlich richtige Referenzantwort im Entwurf ergänzt werden. Tickessa versendet dabei nichts nachträglich.

Schritt 1: Nutzungsgrundlage dokumentieren

Wähle den geeigneten Fall und beschreibe im Feld Dokumentierte Nutzungsgrundlage, wer die redaktionelle Nutzung für welchen internen Qualitätszweck freigegeben hat. Das Feld ist ein interner Auditnachweis. Trage dort keine Namen, Adressen oder sonstigen Falldaten ein.

Vor dem Anlegen sind zwei getrennte Bestätigungen erforderlich:

• Tatsächlichen Supportfall bestätigt bedeutet, dass der Fall wirklich über einen freigegebenen Supportkanal eingegangen und nicht nur für einen Test erfunden wurde.
• Redaktionelle Nutzung bestätigt bedeutet, dass die Nutzung für die interne Qualitätsprüfung dokumentiert und zulässig ist.

Mit Anonymisierten Entwurf anlegen entsteht eine getrennte Arbeitskopie. Bekannte Kontaktangaben und typische personenbezogene Kennungen werden automatisch ersetzt. Automatische Bereinigung ist nur eine Vorprüfung und niemals die abschließende Datenschutzfreigabe.

Schritt 2: Die anonymisierten Inhalte prüfen

Prüfe diese drei Felder vollständig:

• Anonymisierter Betreff beschreibt den Fall, ohne Namen, Ticketnummern oder andere identifizierende Einzelheiten.
• Kundenaussage ohne Falldaten enthält nur die für die Aufgabe notwendige fachliche Situation. Entferne außerdem vertrauliche oder projektsensible Details, selbst wenn sie keine klassischen Kontaktdaten sind.
• Fachlich richtige Referenzantwort hält fest, was eine korrekte Antwort in diesem Fall aussagen soll. Sie ist ein Prüfmaßstab und wird nicht an den ursprünglichen Kontakt versendet.

Verallgemeinere lieber unnötige Einzelheiten, statt sie nur umzuschreiben. Der Qualitätsfall soll die fachliche Entscheidung abbilden, nicht die Identität der Person.

Schritt 3: Das erwartete Ergebnis festlegen

Ein Qualitätsfall benötigt vorab festgelegte Sollwerte:

• Erwartete Kategorie ist die fachlich richtige Zuordnung.
• Erwartete Priorität legt fest, ob der Fall niedrig, normal, hoch oder dringend behandelt werden soll.
• Erwartete Antwortgrenze bestimmt, ob eine belegte Antwort möglich ist, zuerst Rückfragen nötig sind oder nur eine persönliche Bearbeitung zulässig ist.
• Notwendige Antwortpunkte stehen einzeln pro Zeile. Eine spätere Antwort muss diese Aussagen abdecken.
• Verbotene Aussagen stehen ebenfalls einzeln pro Zeile. Damit lassen sich beispielsweise unbelegte Zusagen, Garantien oder sensible Handlungsempfehlungen ausdrücklich ausschließen.

Mindestens ein notwendiger Antwortpunkt und eine verbotene Aussage sind Pflicht. Dadurch bewertet die spätere Prüfung nicht nur ähnliche Formulierungen, sondern auch fachliche Vollständigkeit und Sicherheitsgrenzen.

Schritt 4: Risiken kennzeichnen

Die Risikokennzeichnungen ordnen besondere Prüfziele zu:

• Spam prüft, ob unzulässige Eingänge vor KI-Verarbeitung aussortiert bleiben.
• Falsch adressiert markiert Nachrichten, die nicht zum Empfänger oder Projekt gehören.
• Mehrdeutig verlangt Rückfragen statt erfundener Annahmen.
• Beschwerde kennzeichnet besonders sorgfältig und persönlich zu behandelnde Fälle.
• Sensibler Inhalt weist auf Daten oder Themen hin, die zwingend menschliche Kontrolle benötigen.
• Manipulationsversuch deckt Anweisungen im Kundentext ab, die Sicherheitsregeln oder Systemvorgaben umgehen sollen.

Mehrere Kennzeichnungen sind möglich. Sie ersetzen weder Kategorie noch Antwortgrenze.

Schritt 5: Speichern und erneut lesen

Wähle Entwurf speichern. Tickessa führt die technische Erkennung erneut aus und speichert die Sollwerte. Jede inhaltliche Änderung setzt die Freigabebestätigungen zurück. Solange ungespeicherte Änderungen vorhanden sind, bleibt Qualitätsfall freigeben gesperrt.

Lies anschließend genau die gespeicherte Fassung. Der spätere Inhalts-Hash bezieht sich auf diese Version, nicht auf einen ungespeicherten Zwischenstand.

Schritt 6: Menschlich freigeben oder verwerfen

Für die Freigabe müssen drei Aussagen ausdrücklich bestätigt werden:

1. personenbezogene und vertrauliche Angaben sind vollständig entfernt,
2. Inhalt und Soll-Antwort sind fachlich geprüft,
3. der Vorgang löst keine Kundenkommunikation aus.

Beim Freigeben prüft der Server den gespeicherten Text erneut, einschließlich der bekannten Werte aus dem Ursprungsticket. Erkennt er verbliebene Angaben oder fehlen Pflicht-Sollwerte, wird die Freigabe abgebrochen. Ein freigegebener Qualitätsfall ist in der Oberfläche gesperrt und besitzt einen sichtbaren Inhalts-Hash.

Mit Verwerfen wird ein ungeeigneter Entwurf nachvollziehbar abgelehnt. Das Ursprungsticket wird auch dabei nicht verändert.

Freigabestand je Projekt

Der obere Bereich zeigt die Anzahl freigegebener Qualitätsfälle je Projekt. Das erste Eingangsgate gilt technisch als bereit, sobald mindestens ein tatsächlich betriebenes Projekt zwei freigegebene Realfälle besitzt. Diese Mindestzahl ersetzt nicht die fachliche Kontrolle, ob wichtige Kategorien, Grenzfälle und Risiken angemessen vertreten sind.

Die Anzeige nennt zugleich die Projekte, für die diese Startfreigabe gilt. Nur diese Projekte dürfen in der ersten Evaluation mit realen Fällen bewertet werden. Ein Projekt ohne eigene Realfälle bleibt trotz erfolgreichem Eingangs- oder Antworttest aus der produktiven KI-Freigabe ausgeschlossen. Sobald dieses Projekt öffentlich betrieben wird, benötigt es vor seiner eigenen KI-Freigabe ebenfalls mindestens zwei geeignete, anonymisierte und fachlich freigegebene Realfälle.

Synthetische Annahmen mit Realfällen abgleichen

Die Freigabe eines Qualitätsfalls allein bestätigt noch keinen Wissensartikel und keinen Textbaustein. Für den fachlichen Abgleich wird jede Aussage aus dem bisherigen synthetischen Prüfinhalt getrennt bewertet:

• Bestätigt bedeutet, dass der anonymisierte Realfall dieselbe fachliche Handlung und dieselben Sicherheitsgrenzen stützt.
• Ergänzt bedeutet, dass der Grundweg stimmt, der Realfall aber eine zusätzliche Rückfrage, Eskalationsgrenze oder verbotene Aussage sichtbar macht.
• Korrigiert bedeutet, dass eine synthetische Annahme fachlich nicht trägt und vor einer KI-Evaluation geändert werden muss.
• Nicht als Antwortinhalt geeignet gilt insbesondere für Spam oder Fehladressierungen, bei denen gerade keine Antwort versendet werden soll.

Dieser Vergleich bleibt projektbezogen. Ein Fall darf nur Wissen seines eigenen Projekts bestätigen. Ein realer Fall wird außerdem nicht automatisch zu einem öffentlichen Artikel: Eine Veröffentlichung ist eine eigene redaktionelle Entscheidung mit gesonderter Prüfung. Für negative Fälle wie Spam kann der richtige Nutzen ausschließlich darin liegen, die Klassifikation und die Grenze keine Antwort zu testen.

Sicherheits- und Datenschutzgrenzen

• Nur Administratoren können Qualitätsfälle aufrufen und bearbeiten.
• Entwurf, Bearbeitung, Freigabe und Verwerfen laufen ohne KI-Providerkontakt.
• Es existiert in diesem Ablauf kein E-Mail-Versandweg.
• Der freigegebene Datensatz enthält keine Kontaktobjekte, Roh-E-Mails, Ticketnummern oder Anhänge.
• Herkunft, Bearbeiter, Freigabezeitpunkt und Entscheidungen werden intern nachvollziehbar protokolliert, ohne den bereinigten Inhalt erneut in das Ereignisprotokoll zu kopieren.
• Fälle bleiben nach Projekt getrennt. Ein Qualitätsfall darf deshalb keine projektfremde Wissensgrundlage bestätigen.

Der geschützte Admin-Endpunkt /api/v1/ai/quality-dataset liefert ausschließlich freigegebene Fassungen für den späteren Evaluationsschritt. Der Export selbst ruft kein Modell auf und versendet keine Nachricht.

Wie es mit der Evaluation weitergeht

Sobald der Freigabestand Bereit für #27 zeigt, kann im selben Einstellungsbereich zunächst eine kostenfreie lokale Vorprüfung gestartet werden. Erst der danach ausdrücklich bestätigte Schattenlauf überträgt anonymisierte Prüfdaten an den konfigurierten Anbieter. Jedes Ergebnis muss anschließend einzeln mit seinem vorab festgelegten Sollwert verglichen werden.

Die vollständige Anleitung zu Schwellen, Kosten, Einzelreview, Alarm und Not-Aus steht unter KI sicher evaluieren und freigeben.