Bevor ein KI-Assistent live geht, muss jemand eine Frage beantworten: "Liegt er bei unseren Fragen oft genug richtig?" Anbieter und IT können das nicht wissen, die Menschen, die die Arbeit machen, schon. Ein Testsatz aus 50-100 realistischen Fragen mit erwarteten Antworten, von Fachexperten in einer Tabelle geschrieben, macht aus Meinungen ("wirkt gut") eine messbare Bestehensquote und hält die Qualität nach jedem Modellupdate, jeder Prompt-Änderung und jedem neuen Dokument sichtbar.
Problem & Nutzen
- Heute: Piloten werden anhand weniger eindrucksvoller Demos oder des lautesten Skeptikers beurteilt. Nach dem Go-live merkt niemand, dass die Antworten schlechter wurden, als der Anbieter das Modell wechselte oder die Wissensbasis wuchs.
- Warum Experten: Nur die Buchhalterin, der Servicetechniker oder die Personalsachbearbeiterin kennt die echten Grenzfälle, die richtige Antwort und welche falsche Antwort gefährlich ist. Die IT kann den Test ausführen, aber nicht schreiben.
- Nutzen: ein objektives Go/No-go-Kriterium (GUIDE-009), frühe Erkennung von Rückschritten, eine gemeinsame Sprache zwischen Fachbereich und IT und Akzeptanz bei den Mitarbeitenden, weil ihre Expertise definiert, was "gut" ist. Testsätze sind außerdem der günstigste Schritt der Datenaufbereitung: einige Stunden Expertenzeit statt Wochen an Nacharbeit später.
Varianten
- RAG-Assistent / Chatbot: Frage, erwartete Antwort, Quelldokument.
- Extraktion / Klassifikation: Dokument plus bekannte richtige Felder oder Kategorie (zum Beispiel Rechnungen, siehe DOC-001).
So funktioniert es
- collect real questions & documents
- experts write expected answers + sources
- tag (topic, difficulty, risk)
- run against the AI (manual or automated)
- score (pass / partly / fail, optional LLM as judge)
- fix causes
- re-run on every change
- Mischung: typische Fragen (60 Prozent als Faustregel, kein gemessener Wert), schwierige Grenzfälle, Fragen, die die KI ablehnen oder mit "Ich weiß es nicht" beantworten soll, und Fangfragen (veraltete Richtlinie, ähnliche Produktnamen).
- Bewertung: Zuerst bewerten Menschen; ein LLM als Richter kann große Sätze vorbewerten, muss aber von einer Expertin oder einem Experten stichprobenartig geprüft werden.
- Mensch-in-der-Schleife (Human-in-the-Loop): Die Experten verantworten die erwarteten Antworten; sie prüfen Abweichungen zwischen KI-Richter und Mensch.
Datenaufbereitung
Welche Daten: echte Fragen, Beispieldokumente, die maßgebliche Quelle für jede Antwort.
Wo sie liegen: Helpdesk- oder Ticket-Werkzeug, gemeinsame Postfächer, Teams- oder WhatsApp-Gruppen, Richtlinien-PDFs in SharePoint, Nextcloud oder auf Dateiablagen und in den Köpfen der Experten.
Typische Lücken: kein einzelnes maßgebliches Dokument je Thema, widersprüchliche Versionen, niemand verantwortet die Antwort, personenbezogene Daten in echten Tickets und Mails.
Aufbereitungsschritte: 1. Ziehen Sie 100-200 Kandidatenfragen aus Tickets und Mails; entfernen Sie Namen, Kundennummern und andere personenbezogene Daten (PREP-022). 2. Legen Sie zuerst die Kategorien fest (PREP-019). 3. Jede Expertin und jeder Experte schreibt die erwartete Antwort plus die Quellenpassage; kennzeichnen Sie das maßgebliche Dokument (PREP-013, PREP-016). 4. Halten Sie einen zurückgehaltenen Teil (etwa 20 Prozent) bereit, der nie zum Abstimmen von Prompts verwendet wird, damit die Ergebnisse ehrlich bleiben. 5. Speichern Sie den Satz in einer Tabelle mit den Spalten: ID, Frage, erwartete Antwort, Quelle, Kategorie, Schwierigkeit, Risiko, Autor, Datum, Version.
Werkzeuge: Excel oder Google Sheets, SharePoint-Liste, Microsoft Forms zum Sammeln von Fragen, Nextcloud mit gemeinsamer Tabelle (in der EU gehostet, selbst betreibbar). Siehe GUIDE-003.
Aufwand: etwa 2-4 Stunden je Experte für 25-30 Fälle; ein erster Satz mit 50-100 Fällen braucht 2-4 Arbeitstage Kalenderzeit.
Umsetzungswege
Welcher Weg für wen
- KMU - Weg C: Es ist kein Produkt nötig; eine Tabelle plus ein kleiner Open-Source-Runner auf einem Laptop oder kleinen Server (HW1) leistet das Nötige, und derselbe Satz dient jedem künftigen Assistenten (Baukasten-Effekt). Testdaten enthalten oft Kunden- oder Geschäftsgeheimnisse, was für die Haltung im eigenen Haus spricht.
- Großunternehmen - Weg B: Eine gemeinsame Bewertungsplattform oder Cloud-Dienste mit API-Zugang passen, wenn viele Teams viele Assistenten betreiben und zentrale Berichte brauchen.
- Entwickler - Weg C: Open-Source-Werkzeuge in der CI-Pipeline geben volle Kontrolle und reproduzierbare Läufe.
Weg A — Kaufen (Standardsoftware)
Für den von Experten verfassten Teil gibt es kaum kaufbare Produkte; er ist überwiegend Prozess. Eingebaute Funktionen helfen: Die Agentenbewertung in Microsoft Copilot Studio importiert eine CSV mit Fragen und erwarteten Antworten, bis zu 100 Fälle je Satz [1], und Bewertungsmodule in kommerziellen LLM-Ops-Plattformen existieren. Prüfen Sie EU-Hosting und AVV. Nutzen Sie A, wenn Sie bereits Copilot-Studio-Agenten betreiben und nur eine schnelle Prüfung brauchen.
Weg B — Auf Cloud-KI-Diensten aufbauen
Lassen Sie den Testsatz über die Modell-API laufen, die Sie produktiv nutzen (Azure OpenAI in EU-Regionen, Mistral (EU-Anbieter) oder andere Endpunkte in EU-Regionen), mit einem n8n- oder Power-Automate-Ablauf, der die Tabelle liest, den Assistenten aufruft und Antwort und Bewertung zurückschreibt. Ein LLM-Richter kann ein zweites, stärkeres Modell aus einer EU-Region sein. Wählen Sie B, wenn der Assistent selbst auf Cloud-APIs läuft und die Ergebnisse in SharePoint oder Excel landen sollen.
Weg C — Selbst betreiben (Open Source)
- Promptfoo (MIT) liest Testfälle aus CSV- oder Excel-Dateien und unterstützt Prüfungen auf erwartete Werte je Zeile [2]; läuft auf jedem Laptop mit Node.
- Langfuse (MIT, selbst betreibbar; alle Funktionen im Juni 2025 als Open Source veröffentlicht) bietet Datensätze, Experimente und Annotationswarteschlangen für die Expertenprüfung [3]; benötigt Docker und eine Datenbank, planen Sie daher 1-2 Tage für die Einrichtung und eine Administration.
- n8n selbst betrieben (EU) als Bindeglied, um nächtliche Läufe zu planen.
- Lokales Richtermodell über Ollama (zum Beispiel ein 7-14B-Modell) auf HW1/HW2, wenn Testinhalte das Unternehmen nicht verlassen dürfen; die Richterqualität kleiner Modelle ist begrenzt, behalten Sie menschliche Stichproben bei.
Weg D — Eigenes Training
Für den Testsatz selbst nicht nötig. Später kann ein gut kuratierter Satz (und seine Korrekturen) Daten für das Feintuning liefern (PREP-020), doch dafür sind einige hundert hochwertige Beispiele nötig, und der zurückgehaltene Satz muss getrennt bleiben.
Stand der Technik (2026)
- LLM-als-Richter ist verbreitet und günstig, bevorzugt aber ausführliche Antworten und die eigene Modellfamilie; kalibrieren Sie anhand von Expertenbewertungen.
- Grenzen: Kleine Testsätze liefern verrauschte Prozentwerte (ein Fall bei n=50 entspricht 2 Punkten); nicht deterministische Modelle brauchen wiederholte Läufe; Testsätze altern, wenn sich Richtlinien ändern, daher brauchen sie eine verantwortliche Person und einen Prüftermin (PREP-017).
- Ein Testsatz misst, was Sie hineingeschrieben haben; er ist keine Sicherheits- oder Red-Team-Bewertung (siehe SEC-014, CODE-018).
Gemeinsame Bausteine & Kombinationen
- Derselbe Satz, viele Verwendungen: PREP-013 Wissensbasis, DOC-001 Extraktion, jeder Chatbot; eine Tabelle und ein Runner bedienen alle.
- Speist: PREP-021 (Korrekturen von Nutzern werden zu neuen Testfällen) und PREP-020 (Labels aus Geschäftsdaten).
Aufwand, Kosten & Kennzahlen
- Weg B: 1-3 Tage für den Bau des n8n-Ablaufs; die API-Kosten für 100 Fälle sind gering.
- Weg C: 1-2 Tage für Promptfoo; 1-2 Tage plus Administration für Langfuse.
- Expertenzeit (Faustregel): 2-4 Stunden je Experte für die ersten 25-30 Fälle, danach 1-2 Stunden pro Monat für die Pflege.
- Kennzahlen: Bestehensquote je Kategorie, Anteil bestandener kritischer Fälle (Ziel 100 Prozent), Rückschritte je Release, Anteil echter Nutzerbeschwerden, die bereits von einem Testfall abgedeckt sind, Zahl der mitwirkenden Experten.
Menschen & Veränderung
Früh einbinden: Die Abteilungsleitung benennt 2-4 Fachexperten und gibt ihnen Zeit; Endnutzer liefern echte Fragen; die IT führt die Tests aus; Dateneigner bestätigen die maßgebliche Quelle; die Geschäftsführung akzeptiert die Bestehensschwelle für den Go-live. Die/der Datenschutzbeauftragte prüft, dass echte Tickets anonymisiert werden, bevor sie in den Satz gelangen, und dass für jedes externe Richtermodell ein AVV (Art. 28 DSGVO) besteht; eine DSFA ist für den Testsatz allein normalerweise nicht nötig (GUIDE-005).
Betriebsrat: Es kommt darauf an. Der Testsatz bewertet die KI, nicht Menschen, und ist daher selbst kein Überwachungssystem. Werden Ergebnisse nach Personen aufgeschlüsselt oder zeigen Protokolle, wer was gefragt hat, gilt §87 Abs. 1 Nr. 6 BetrVG; §90 Abs. 1 Nr. 3 verlangt rechtzeitige Information über KI-gestützte Arbeitsprozesse. Öffentliche Stellen beziehen den Personalrat ein. Vereinbaren Sie, dass Testergebnisse nie zur individuellen Leistungsbeurteilung verwendet werden (GUIDE-004).
KI-Kompetenz: Art. 4 KI-Verordnung (AI Act) verlangt Maßnahmen zur Förderung der KI-Kompetenz des Personals; Testfälle zu schreiben ist ein sehr wirksames praktisches Training, weil die Experten Stärken und Fehler selbst sehen (GUIDE-006).
Kommunikation: Laden Sie Experten als Mitgestalter ein: "Sie legen fest, wie gut aussieht". Starten Sie mit einem Team als Pilot, veröffentlichen Sie die Bestehensquote offen und lassen Sie Mitarbeitende Fälle ergänzen, wenn sie Fehler finden (GUIDE-008, GUIDE-009).
Risiken, Regulierung & Compliance
- KI-Verordnung (AI Act): Der Testsatz ist von minimalem Risiko. Bei Hochrisiko-Anwendungen (zum Beispiel Personalauswahl, Anhang III, Pflichten ab dem 2. Dez. 2027) werden Test- und Daten-Governance-Nachweise Teil der Dokumentation; siehe GUIDE-014.
- DSGVO: Echte Fragen und Dokumente enthalten oft personenbezogene Daten; anonymisieren, den Zugriff auf den Satz beschränken, löschen, wenn nicht mehr benötigt.
- Risiken: Überanpassung der Prompts an den Testsatz (zurückgehaltene Fälle nutzen), veraltete erwartete Antworten, trügerische Sicherheit durch einen kleinen Satz, Fehler des LLM-Richters, Geschäftsgeheimnisse im Satz, die in einer unkontrollierten Tabelle liegen.
- Gegenmaßnahmen: Versionskontrolle, verantwortliche Person und Prüftermin, auf die Projektgruppe beschränkter Zugriff, regelmäßige Auffrischung mit echten Fehlern (PREP-021).
Erste Schritte
- Benennen Sie 2-4 Fachexperten und eine verantwortliche Person für den Satz; blocken Sie je zwei Stunden.
- Sammeln Sie 100 echte Fragen aus Tickets und Mails und anonymisieren Sie sie.
- Schreiben Sie erwartete Antworten und Quellen in eine Tabelle mit der obigen Spaltenvorlage; kennzeichnen Sie etwa 10 kritische Fälle.
- Lassen Sie den Satz manuell gegen den Pilot-Assistenten laufen, halten Sie die Bestehensquote fest und vereinbaren Sie die Go-live-Schwelle mit der Geschäftsführung.
- Automatisieren Sie mit Promptfoo oder einem n8n-Ablauf und wiederholen Sie den Lauf bei jeder Änderung an Modell, Prompt oder Dokumenten.
Quellen
- Microsoft Learn - Create a test set for agent evaluation in Copilot Studio - https://learn.microsoft.com/en-gb/microsoft-copilot-studio/analytics-agent-evaluation-create
- Promptfoo documentation - Test cases (CSV / Excel) - https://www.promptfoo.dev/docs/configuration/test-cases/
- Langfuse - Open source LLM engineering platform (datasets, experiments, self-hosting) - https://langfuse.com/self-hosting
- Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj