KI-Assistent abnehmen: Testfälle vor dem Livegang

Ein Kontaktformular nimmt man ab wie ein Bauteil: ausfüllen, abschicken, prüfen, ob die Mail ankommt, Haken dran. Bei einem KI-Assistenten scheitert dieses Vorgehen schon am ersten Schritt. Stellen Sie ihm zweimal dieselbe Frage, erhalten Sie zwei unterschiedlich formulierte Antworten. Beide können fachlich richtig sein, beide können danebenliegen. Der wortgleiche Soll-Ist-Vergleich, das Standardwerkzeug jeder Software-Abnahme, greift damit ins Leere. Wie ernst dieses Thema inzwischen genommen wird, zeigt der Blick auf die Risikowahrnehmung in Unternehmen: 74 Prozent (Stanford HAI — AI Index Report 2026) der Befragten stufen Ungenauigkeit als relevantes KI-Risiko ein, ein Anstieg um 14 Punkte (Stanford HAI — AI Index Report 2026) gegenüber dem Vorjahr, womit Ungenauigkeit noch vor Cybersicherheit rangiert. Parallel stieg die Zahl dokumentierter KI-Vorfälle auf 362 (Stanford HAI — AI Index Report 2026), nach 233 (Stanford HAI — AI Index Report 2026) im Jahr davor. Dieser Beitrag beschreibt ein praktikables Abnahmeverfahren für Projekte im Mittelstand: verhaltensbasiert statt wortgleich, mit Testfällen aus echten Anfragen, Freigabekriterien vor dem Bau, vier klaren Prüfdimensionen, einer Bewertungsrubrik, einem Zwei-Personen-Review und einem Regressionslauf nach jeder Änderung der Wissensbasis.

Grafik vergrößern

Beschriftungen der Abbildung

• Echte Anfragen
• Telefon · 20 Fragen
• E-Mail · 18 Fragen
• Suche & Chat · 12 Fragen
• Testfall-Katalog
• 50 Fragen
• 4 Prüfdimensionen
• Fachliche Richtigkeit
• nur belegte Aussagen
• 17/20
• Grenzen
• keine Rechts- oder Preiszusagen
• 12/12
• Eskalation
• rechtzeitig an Menschen
• 9/10
• Verhalten unter Störung
• Themenwechsel, Provokation
• 7/8
• Abnahme-Protokoll · Version 1 · Prüfer A und B
• Testfall
• Dimension
• Punkte
• Status
• TF-07 Lieferzeit
• Richtigkeit
• 3/3
• bestanden
• TF-19 Rabattzusage
• Grenzen
• 3/3
• bestanden
• TF-28 Vertragsfrage
• Eskalation
• 2/3
• Review B
• TF-41 Themenwechsel
• Störung
• 1/3
• Nacharbeit
• Freigabekriterium
• 90 %
• 45 von 50
• Schwelle 90 % erreicht
• Grenzen: 12 von 12 Pflicht
• 2 Testfälle in Nacharbeit
• Regressionslauf geplant
• Regressionslauf nach jeder Änderung der Wissensbasis · Abnahme ist ein wiederkehrender Lauf, kein Termin

Abnahme eines KI-Assistenten

Warum sich ein Assistent nicht wie ein Formular abnehmen lässt

Klassische Software ist deterministisch: gleiche Eingabe, gleiche Ausgabe. Genau darauf baut die übliche Abnahme auf. Man definiert einen Sollwert, vergleicht ihn mit dem Istwert und protokolliert die Abweichung. Ein Sprachmodell arbeitet anders. Es wählt jedes Wort aus einer Wahrscheinlichkeitsverteilung, weshalb dieselbe Frage zu unterschiedlich formulierten Antworten führt. Zwei Antworten können völlig verschieden klingen und trotzdem beide korrekt sein. Umgekehrt kann eine Antwort vertraut klingen und dennoch eine erfundene Frist enthalten. Wer hier auf Wortgleichheit prüft, misst die falsche Größe. Die Frage lautet nicht, ob der Assistent den erwarteten Satz ausgibt, sondern ob sein Verhalten in der jeweiligen Situation vertretbar ist.

Die zweite Besonderheit ist der offene Eingaberaum. Ein Formular hat acht Felder mit definierten Wertebereichen, ein Chat nimmt jeden denkbaren Satz entgegen, in jeder Formulierung, in jeder Laune, in jeder Sprache. Eine vollständige Abdeckung ist damit ausgeschlossen. Das ist kein Grund, auf Prüfung zu verzichten, sondern der Grund für eine bewusste Stichprobe mit Priorisierung. Das NIST AI Risk Management Framework formuliert genau diesen Gedanken in seiner MEASURE-Funktion: Metriken und Prüfmethoden werden zuerst für die höchstpriorisierten Risiken ausgewählt, nicht flächendeckend für alles (NIST AI Risk Management Framework). Übersetzt für ein Mittelstandsprojekt: Prüfen Sie das, was oft vorkommt, und das, was im Schadensfall wehtut. Die Reihenfolge ist wichtiger als die Menge.

Testfälle aus echten Anfragen ableiten

Der häufigste Fehler in der Abnahmevorbereitung ist harmlos gemeint und trotzdem folgenschwer: Ein Team setzt sich zusammen und denkt sich Dialoge aus. Was dabei entsteht, sind Wunschdialoge. Sie treffen den Ton, den man sich wünscht, und die Fragen, auf die man vorbereitet ist. Getestet wird am Ende das, was ohnehin gebaut wurde. Echte Anfragen sind unhöflicher, kürzer, mehrdeutiger und stellen genau die Fragen, die im Konzept fehlen. Ein Abnahmekatalog, der aus Wunschdialogen besteht, bescheinigt dem Assistenten eine Qualität, die er im Alltag nicht halten muss und deshalb auch nicht hält.

Die belastbare Alternative ist unspektakulär: Sammeln Sie die 50 häufigsten Fragen, die Ihr Betrieb tatsächlich bekommt, und zwar dort, wo sie ankommen. Telefonnotizen der letzten Wochen, das Sammelpostfach, die Suchbegriffe der internen Suche und die Anfragen, die Ihr Team am liebsten nicht schon wieder beantworten würde. Diese 50 Fragen sind Ihr Testfall-Katalog. Sie haben einen unschätzbaren Vorteil gegenüber jeder Erfindung: Sie sind bereits gestellt worden, in genau der Wortwahl, in der sie wieder gestellt werden. Welche Inhalte daraus in die Wissensbasis gehören, ordnet unser Beitrag zum Aufbau einer Wissensbasis ein.

Diese Quellen liefern nebenbei die Gewichtung. Wenn 20 der 50 Fragen aus dem Telefon stammen, 18 aus dem Postfach und 12 aus der Suche, dann kennen Sie die Verteilung Ihres realen Anfrageaufkommens. Ein bestehender Assistent liefert diese Daten fortlaufend selbst, worauf unsere Gesprächsanalyse zielt: Sie zeigt, welche Fragen tatsächlich gestellt werden und wo Antworten abbrechen. Für den ersten Livegang genügen die vorhandenen Kanäle.

• Sammeln: Anfragen der letzten vier bis acht Wochen aus Telefon, Mail und Suche zusammentragen, ohne zu filtern.
• Verdichten: Gleichbedeutende Fragen zu einem Testfall bündeln und die Häufigkeit notieren.
• Priorisieren: Nach Häufigkeit und nach Schadenspotenzial im Fehlerfall sortieren, nicht nach Bequemlichkeit.
• Wortlaut behalten: Den Originalton übernehmen, inklusive Tippfehler und halber Sätze, statt ihn glattzuziehen.
• Ergänzen: Bewusst Grenzfälle aufnehmen, die keine schöne Antwort haben, etwa Rechts- und Preisfragen.
• Einfrieren: Den Katalog versionieren, damit spätere Läufe mit demselben Maßstab messen.

Freigabekriterien vor dem Bau definieren

Wer Freigabekriterien erst nach dem Bau formuliert, formuliert sie unweigerlich entlang dessen, was das System kann. Das ist menschlich und macht die Abnahme wertlos. Die Reihenfolge ist deshalb keine Formalie, sondern der eigentliche Wirkmechanismus. ISO/IEC 42001, die internationale Norm für KI-Managementsysteme, hält im Control zu Verifikation und Validierung von KI-Systemen genau das fest: Abnahmekriterien sollen definiert sein, bevor die Prüfung beginnt, um subjektive Entscheidungen zu vermeiden (ISO/IEC 42001 — KI-Managementsysteme). Die Norm verlangt zudem Freigabekriterien, die ein System vor dem Einsatz erfüllen muss, einschließlich einer Festlegung, welche Fehlerquote im jeweiligen Kontext vertretbar ist (ISO/IEC 42001 — KI-Managementsysteme).

Konkret heißt das: eine Punkteschwelle über den gesamten Katalog, zum Beispiel 45 von 50 möglichen Punkten, plus harte K.-o.-Kriterien, die einzeln zur Nichtfreigabe führen. Ein Assistent, der bei 48 von 50 Punkten liegt, aber in einem Fall eine Preiszusage macht, ist nicht freigegeben. Die Punktzahl mittelt, das K.-o.-Kriterium tut es nicht. Diese Trennung ist der Unterschied zwischen einer Abnahme, die Risiken erfasst, und einer, die sie wegrechnet. Welche Fähigkeiten dabei überhaupt zur Debatte stehen, hängt vom Funktionsumfang ab, den wir unter individuelle Funktionen beschreiben.

Die vier Prüfdimensionen im Detail

Vier Dimensionen decken den praktisch relevanten Teil des Verhaltens ab. Sie sind bewusst so geschnitten, dass jede einzeln bewertbar ist und keine die andere kaschiert. Ein Assistent kann fachlich brillant sein und trotzdem durchfallen, weil er seine Grenzen nicht kennt. Die MEASURE-Funktion des NIST-Rahmenwerks widmet der Bewertung vertrauenswürdiger Eigenschaften eine eigene Kategorie mit mehreren Unterkategorien, von Leistung über Sicherheit bis Erklärbarkeit. Für ein Mittelstandsprojekt sind diese vier der tragfähige Kern.

Die zweite Dimension verdient besondere Aufmerksamkeit, weil sie den rechtlichen Rahmen berührt. Aussagen eines Assistenten können dem Betrieb zugerechnet werden, was unser Beitrag zur Chatbot-Haftung nach dem OLG-Hamm-Urteil einordnet. Der Testfall lautet deshalb nicht: Antwortet er hier klug? Sondern: Verweigert er die Zusage sauber und bietet den Weg zu einem Menschen an? Wo Assistenten darüber hinaus eigenständig handeln, etwa im Warenkorb, verschiebt sich diese Grenze noch einmal, wie unser Beitrag zu KI-Agenten im Shop zeigt.

Die vierte Dimension wird in Projekten regelmäßig unterschätzt. Ein Assistent, der auf saubere Fragen souverän antwortet, kann bei einem Themenwechsel mitten im Satz den Kontext verlieren oder auf eine Provokation mit einer Formulierung reagieren, die niemand veröffentlicht sehen möchte. Auch eine Frage in einer anderen Sprache ist ein realer Testfall, den unser mehrsprachiger Assistent planvoll abdeckt. Bewusst manipulative Eingaben sind ein eigenes Feld, das unser Beitrag zu Prompt Injection behandelt.

Bewertung per Rubrik statt Bauchgefühl

Sobald mehrere Personen Antworten beurteilen, driftet die Bewertung auseinander. Die eine findet eine Antwort zu knapp, der andere findet sie präzise. Ohne festgelegten Maßstab entscheidet, wer am längsten im Raum spricht. Eine Rubrik ersetzt diese Diskussion durch eine Skala, die vor dem Lauf festgeschrieben wird. Drei Punkte pro Testfall reichen völlig aus: 3 gleich vertretbar ohne Einschränkung, 2 gleich vertretbar mit kleiner Schwäche, 1 gleich problematisch, 0 gleich nicht akzeptabel. Entscheidend ist nicht die Feinheit der Skala, sondern dass die Stufen vorher mit Beispielen belegt sind.

Der Nebeneffekt ist der eigentliche Gewinn: Eine Rubrik macht Uneinigkeit produktiv. Wenn zwei Prüfende denselben Testfall unterschiedlich bewerten, liegt das in aller Regel daran, dass die Stufenbeschreibung zu vage ist. Diese Diskussion schärft das Kriterium, statt die Person zu überzeugen. Nach zwei, drei Läufen ist die Rubrik so präzise, dass die Bewertung selbst kaum noch Zeit kostet.

Zwei-Personen-Review bei kritischen Antworten

Nicht jeder Testfall braucht zwei Augenpaare, aber jeder kritische. Kritisch heißt: alles, was unter die Dimension Grenzen fällt, alles, was rechtlich oder finanziell bindend wirken könnte, und alles, was ein Prüfer mit weniger als der vollen Punktzahl bewertet hat. Das NIST-Rahmenwerk empfiehlt für die Bewertung ausdrücklich interne Fachleute, die nicht an der Entwicklung des Systems beteiligt waren, oder unabhängige Prüfende (NIST AI Risk Management Framework). Der Grund ist banal und wirksam: Wer eine Konfiguration gebaut hat, liest die Antwort mit dem Wissen, wie sie gemeint ist. Diese Nachsicht ist unvermeidbar und genau deshalb prüft man sie weg, statt gegen sie anzukämpfen.

Wer eine Antwort gebaut hat, liest ihre gute Absicht mit. Wer sie zum ersten Mal sieht, liest nur, was dasteht. Genau diese zweite Lesart bekommt Ihre Kundschaft.

In der Praxis genügt eine schlanke Regel: Prüfer A geht den gesamten Katalog durch, Prüfer B übernimmt die kritischen Fälle und alle Abwertungen. Bei Uneinigkeit entscheidet nicht der Kompromiss, sondern die strengere Bewertung, bis das Kriterium nachgeschärft ist. Prüfer B sollte aus dem Fachbereich kommen, nicht aus der Technik. Wer im Alltag am Telefon erklärt, warum eine Frist so und nicht anders läuft, erkennt eine schiefe Antwort schneller als jede Metrik. Wie die Übergabe an dieses Team technisch abläuft, beschreibt unser Beitrag zur Übergabe an Mitarbeitende.

Regressionslauf nach jeder Änderung der Wissensbasis

Hier liegt die Falle, die Projekte am häufigsten übersehen. Die Wissensbasis ist kein abgeschlossenes Artefakt, sondern wächst. Eine neue Preisliste kommt dazu, ein FAQ-Eintrag wird ergänzt, ein PDF wird nachgereicht. Jede dieser Ergänzungen kann Antworten kippen, die vorher sauber waren. Nicht weil die neue Quelle falsch wäre, sondern weil sie mit einer alten konkurriert, eine Passage besser zur Frage passt als die eigentlich gemeinte oder ein Detail eine allgemeine Aussage überschreibt. Ein Assistent, der gestern die Lieferzeit korrekt genannt hat, nennt heute die aus dem alten Datenblatt, weil dieses Datenblatt neu hinzugekommen ist.

Deshalb gilt: Jede Änderung der Wissensbasis löst einen Lauf gegen den bestehenden Katalog aus. Das ist der Regressionslauf, und er ist der Grund, warum sich der Aufwand für den Katalog überhaupt rechnet. Beim ersten Mal ist er Arbeit, ab dem zweiten Mal ist er ein Sicherheitsnetz. Das NIST-Rahmenwerk verlangt in seiner MEASURE-Funktion ausdrücklich Verfahren, Personen und Dokumentation, um bestehende, unerwartete und neu auftretende Risiken laufend zu identifizieren und nachzuverfolgen (NIST AI Risk Management Framework). Genau das leistet ein wiederholter Lauf gegen einen eingefrorenen Katalog. Warum die Quellenpflege für die Antwortqualität so zentral ist, vertieft unser Beitrag zu Halluzinationen und Wissensbasis.

• Neue oder geänderte Quelle in der Wissensbasis führt zu einem Lauf, nicht zu einer Annahme.
• Der Katalog bleibt unverändert, damit die Werte über die Läufe hinweg vergleichbar bleiben.
• Abweichungen gegenüber dem letzten Lauf werden einzeln geprüft, auch die Verbesserungen.
• Widersprüchliche Quellen werden im Bestand aufgelöst, nicht durch eine Zusatzregel überdeckt.
• Preise, Fristen und Verfügbarkeiten gelten als besonders kippanfällig und werden zuerst geprüft.
• Der Lauf wird mit Datum, Version und Punktstand protokolliert, auch wenn nichts auffällt.

Das Abnahme-Protokoll als Dokumentation

Ein Abnahme-Protokoll ist zunächst schlicht ein Arbeitsmittel: Es hält fest, was geprüft wurde, mit welchem Ergebnis und was offen blieb. Genau diese Nüchternheit macht es wertvoll. ISO/IEC 42001 verlangt im Control zu Verifikation und Validierung die Dokumentation von Auffälligkeiten, Testergebnissen, Korrekturmaßnahmen und Nachtests (ISO/IEC 42001 — KI-Managementsysteme). Die Norm umfasst insgesamt 38 Controls (ISO/IEC 42001 — KI-Managementsysteme), gegliedert in Themenbereiche von der KI-Politik bis zu Drittbeziehungen. Kein Mittelstandsprojekt braucht sie alle, aber das Muster ist übertragbar: Was Sie nicht aufgeschrieben haben, haben Sie im Zweifel nicht geprüft.

Dazu kommt der Blick auf die rechtlichen Pflichten. Nach Artikel 50 des EU AI Act müssen Systeme, die direkt mit Menschen interagieren, so gestaltet sein, dass Nutzende erkennen, dass sie mit einer KI sprechen, und zwar spätestens zum Zeitpunkt der ersten Interaktion (EU AI Act, Artikel 50). Die Transparenzpflichten gelten ab dem 2. August 2026 (EU AI Act, Artikel 113), die Hinweispflicht im Chat in der Regel auch für Systeme, die schon vorher in Verkehr gebracht wurden. Eine Übergangsfrist für solche älteren Systeme räumt die Digital-Omnibus-Verordnung nur für die maschinenlesbare Markierung KI-erzeugter Inhalte ein. Verstöße gegen Artikel 50 können mit bis zu 15 Millionen Euro (EU AI Act, Artikel 99) oder 3 Prozent (EU AI Act, Artikel 99) des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist; für kleine und mittlere Unternehmen sowie kleine Midcap-Unternehmen gilt der jeweils niedrigere Betrag. Ein Testfall, der die Kennzeichnung prüft, kostet zwei Minuten und gehört in jeden Katalog. Die Einordnung liefert unser Beitrag zur Kennzeichnungspflicht nach dem EU AI Act.

Abnahme ist kein Termin, sondern ein wiederkehrender Lauf

Die verbreitetste Fehlannahme im Projekt ist die Vorstellung, Abnahme sei ein Datum im Plan. Ein Termin, an dem man gemeinsam auf einen Bildschirm schaut, nickt und unterschreibt. Danach gilt das System als abgenommen und das Thema als erledigt. Bei einem KI-Assistenten hält diese Annahme keine drei Monate. Die Inhalte verschieben sich, das Angebot ändert sich, Fragen verschieben sich mit der Saison, und das zugrunde liegende Modell wird von seinem Anbieter weiterentwickelt. Ein Testfall, der im Januar bestanden wurde, kann im Juli scheitern, ohne dass jemand etwas falsch gemacht hätte.

Dass diese Beweglichkeit real ist, zeigt die Entwicklung der Fähigkeiten selbst: KI-Agenten sprangen bei realen Rechneraufgaben von 12 auf rund 66 Prozent (Stanford HAI — AI Index Report 2026) Erfolgsquote, während parallel die Zahl dokumentierter Vorfälle auf 362 (Stanford HAI — AI Index Report 2026) stieg. Fähigkeiten und Risiken wachsen gemeinsam, und beides bewegt sich schneller als ein Jahresrhythmus. Auch ISO/IEC 42001 legt seine Prüfstruktur deshalb als Kreislauf an: Klausel 9 fordert Überwachung, Messung und interne Audits in geplanten Abständen, Klausel 10 macht daraus fortlaufende Verbesserung (ISO/IEC 42001 — KI-Managementsysteme). Die Norm nennt bewusst kein Intervall, sondern verlangt eine risikobasierte Festlegung.

Governance-Rahmen auf Mittelstandsgröße

Zwei Rahmenwerke prägen die Diskussion. Das NIST AI Risk Management Framework gliedert sich in die vier Funktionen GOVERN, MAP, MEASURE und MANAGE (NIST AI Risk Management Framework), wobei MEASURE genau die Prüfung abdeckt, um die es hier geht. ISO/IEC 42001 ist die zertifizierbare Norm für KI-Managementsysteme und arbeitet risikobasiert: Anwendbare Controls werden in einer Erklärung zur Anwendbarkeit dokumentiert und begründet, Annex A ist ausdrücklich ein Referenzkatalog und keine Pflichtliste (ISO/IEC 42001 — KI-Managementsysteme). Diese Konstruktion ist der Grund, warum sich beide Rahmen herunterbrechen lassen, ohne dass ein Zertifizierungsprojekt daraus wird.

Der Aufwand ist geringer als sein Ruf, und die Entwicklung geht ohnehin in diese Richtung: Der Anteil der Unternehmen ganz ohne Richtlinien für verantwortungsvolle KI fiel von 24 auf 11 Prozent (Stanford HAI — AI Index Report 2026). Das größte Hindernis bei der Umsetzung sind dabei nicht Kosten, sondern Wissens- und Schulungslücken, genannt von 59 Prozent (Stanford HAI — AI Index Report 2026) der Befragten, vor Ressourcen- oder Budgetengpässen mit 48 Prozent (Stanford HAI — AI Index Report 2026) und technischen Grenzen mit 38 Prozent (Stanford HAI — AI Index Report 2026). Übersetzt: Es scheitert seltener am Budget als daran, dass niemand das Verfahren kennt. Ein dokumentiertes Abnahmeverfahren schließt genau diese Lücke, und zwar in Tagen, nicht in Quartalen.

So setzen wir die Abnahme im Projekt um

Wir bauen Assistenten nicht nach dem Muster einschalten und hoffen. Bevor die erste Konfiguration entsteht, stehen die Freigabekriterien schriftlich fest: die Punkteschwelle über den Katalog, die K.-o.-Kriterien für Grenzen und die Regel, wann eskaliert werden muss. Den Testfall-Katalog leiten wir gemeinsam mit Ihnen aus Ihren echten Anfragen ab, nicht aus Wunschdialogen. Was der Assistent inhaltlich überhaupt sagen darf, kommt aus Ihrer freigegebenen Wissensbasis; wo er handeln soll, etwa beim Abruf von Verfügbarkeiten, greift die Tool-Steuerung mit klar umrissenen Rechten.

• Freigabekriterien und K.-o.-Fälle vor dem Bau, schriftlich und mit Ihnen abgestimmt.
• Testfall-Katalog aus echten Anfragen Ihres Betriebs, versioniert und eingefroren.
• Bewertung nach fester Rubrik über alle vier Prüfdimensionen hinweg.
• Zwei-Personen-Review für Grenzen, Eskalation und jede Abwertung.
• Regressionslauf nach jeder Änderung der Wissensbasis, protokolliert.
• Abnahme-Protokoll mit Punktstand, Nacharbeiten und Freigabeentscheidung.

Eine ehrliche Einordnung gehört dazu: Testen senkt das Risiko, es beseitigt es nicht. Ein Assistent kann auch nach einer bestandenen Abnahme eine Frage bekommen, die im Katalog fehlt, und eine unglückliche Antwort geben. Genau deshalb sind Grenzen, Eskalation an Ihr Team und der wiederkehrende Lauf keine Zusatzoptionen, sondern Teil des Verfahrens. Wie ein Projekt insgesamt abläuft, beschreibt unser Beitrag von der Idee zum fertigen Assistenten; wo wir arbeiten und mit welchen Ansätzen, zeigt die Übersicht unserer Referenzen. Für eine Einschätzung Ihres Falls genügt ein Gespräch über die Abnahme Ihres Assistenten.

Häufige Fragen