Illustratives Szenario. Der Dienstleister zeigt den Support-Agenten: Er beantwortet sechs Fragen gut, der Raum applaudiert. Der Meilenstein wird abgerechnet. Drei Wochen später sagt die Leiterin des Kundenservice, das sei „nicht fertig“, weil er bei retournierten Bestellungen den Faden verliert; der Dienstleister antwortet, das sei nie Teil des Umfangs gewesen. Keiner lügt. Niemand hat aufgeschrieben, was „fertig“ heißen soll.
Die These in einer Zeile: Ein KI-Agent ist nicht geliefert, wenn er in der Demo funktioniert, sondern wenn er Abnahmekriterien erfüllt, die vor dem Start aufgeschrieben und von jemandem aus dem Fachbereich unterschrieben wurden. Ohne dieses Papier endet das Projekt nie – oder aus Erschöpfung.
Was sind Abnahmekriterien für einen KI-Agenten, und warum reicht die Demo nicht?
Abnahmekriterien für einen KI-Agenten sind die messbaren Bedingungen, die der Agent an echten Fällen und über einen vereinbarten Zeitraum erfüllen muss, damit der Kunde ihn als geliefert akzeptiert. Bei einem Webformular ist „es funktioniert“ binär: Es speichert die Daten oder nicht. Ein Agent antwortet jedes Mal anders und liegt nur in einem Teil der Fälle richtig – „es funktioniert“ ist also immer eine unvollständige Frage: Wie oft, bei welchen Fällen und mit welchen Kosten, wenn er scheitert?
Die Demo beantwortet keine der drei, denn sie wird von dem gewählt, der verkauft: die besten Fälle am besten Tag (mehr dazu in die Demo nutzte deine besten Fälle). Und das eigentliche Problem ist nicht technisch. Die RAND-Analyse dazu, warum KI-Projekte scheitern, gestützt auf Interviews mit Ingenieuren und Data Scientists, nennt als eine der häufigsten Ursachen, dass das zu lösende Problem falsch verstanden oder falsch kommuniziert wurde (RAND, 2024). Abnahmekriterien sind genau dieses Gespräch, schriftlich festgehalten, mit Datum und Namen.
Was gehört in das Abnahmedokument eines Agenten?
Sechs Dinge, und alle sechs passen auf eine Seite. Wenn eines nicht draufpasst, wisst ihr noch nicht, was ihr kauft.
- Testfälle aus deinem Betrieb, nicht aus dem des Dienstleisters. Ein geschlossener Satz echter Fälle, mit den schwierigen und den Ausnahmen darin, vor dem Start eingefroren. Ändert sich der Satz mitten im Projekt, sind die Ergebnisse nicht vergleichbar. Wie man bewertet: die Qualität von KI-Agenten bewerten und Evals: Ohne Messung weißt du nicht, ob es funktioniert.
- Der tolerierte Fehler, je Fehlerart. Keine globalen „95 % Trefferquote“: Beim Ton danebenzuliegen kostet nicht dasselbe wie eine Erstattung zu versprechen, die die Richtlinie nicht erlaubt. Warum der Durchschnitt täuscht: 95 % Trefferquote reichen in der Produktion nicht.
- Was er tut, wenn er etwas nicht weiß. Eskalationskriterien: In welchen Situationen er an einen Menschen übergibt, mit welchem Kontext und wie schnell. Das Design steht in was ein Agent tut, wenn er etwas nicht weiß.
- Was er anfassen darf und wie weit. Welche Systeme er liest, in welche er schreibt und welche Aktionen eine menschliche Freigabe brauchen, nach den Autonomiestufen eines Agenten.
- Wie gemessen wird und wie lange. Eine beaufsichtigte Testphase im echten Betrieb, mit vorab definierter Kennzahl. Was man messen sollte, ohne sich selbst zu täuschen: die Leistung deiner Automatisierungen messen.
- Wer unterschreibt. Ein Name und eine Funktion aus dem Fachbereich, keine Abteilung.
Wer muss unterschreiben, dass der Agent fertig ist?
Die Person, die die Folgen trägt, wenn er scheitert: der Prozessverantwortliche. Nicht, wer die Technologie einkauft, und nicht, wer sie baut. Der Dienstleister schlägt die Kriterien vor und zeigt, dass sie erfüllt sind; der Fachbereich entscheidet, ob sie ihm genügen. Unterschreibt nur die IT, wird akzeptiert, dass das System läuft – nicht, dass die Arbeit gut erledigt wird.
Zur Unterschrift gehört das Recht, abzulehnen. Ein Dokument, das man nur unterschreiben kann, ist eine Formalität. Und eine zweite Unterschrift hilft: die der Person, die den Agenten danach betreibt. Etwas abzunehmen, das niemand betreiben kann, verschiebt das Problem nur auf den nächsten Monat (siehe wer KI-Agenten im Betrieb wartet).
| Was vor dem Start aufgeschrieben wird | Was passiert, wenn nicht | Wer es festlegt |
|---|---|---|
| Ein Satz echter Fälle | Der Dienstleister testet mit dem, was nachweislich läuft | Der Fachbereich liefert, der Dienstleister hilft, Lücken zu schließen |
| Tolerierter Fehler je Art | Ein schöner Durchschnitt versteckt den teuren Fehler | Der Fachbereich, nach den Kosten jedes Fehlers |
| Wann er an einen Menschen eskaliert | Der Agent improvisiert genau dort, wo er es nicht soll | Fachbereich und Dienstleister gemeinsam |
| Berechtigungen und freigabepflichtige Aktionen | Der echte Umfang zeigt sich am Tag des Vorfalls | Fachbereich und Sicherheitsverantwortliche |
| Testphase und Kennzahl | „Fertig“ wird nach Bauchgefühl gemessen | Der Fachbereich, der Dienstleister berät |
| Unterschrift | Das Projekt endet nie oder aus Erschöpfung | Eine Funktion im Fachbereich mit Namen |
Was passiert ohne Abnahmekriterien?
Es gibt zwei mögliche Enden, und keines ist gut. Im ersten endet das Projekt nie: Jeder neue Wunsch wird als Fehler des Agenten erlebt, der Dienstleister sieht den Umfang grenzenlos wachsen, und der Kunde hat das Gefühl, für die Reparatur des Gekauften zu zahlen. Im zweiten endet es aus Erschöpfung: Es wird für gut befunden, weil niemand ein weiteres Meeting erträgt, und der Agent geht in Produktion, ohne dass jemand seine echte Fehlerquote kennt.
Das zweite Ende ist das schlimmere, weil es wie ein Erfolg aussieht. Es ist die vertragliche Fassung dessen, was wir in warum KI-Automatisierungsprojekte scheitern erklären: Das Projekt scheitert nicht in der Demo, sondern in der Lücke zwischen dem, was jede Seite für selbstverständlich hielt.
Wie formuliert man ein Kriterium, das sich wirklich prüfen lässt?
Mit drei Zutaten: einem Fallsatz, einem Schwellenwert und einer Ausschlussbedingung, über die nicht verhandelt wird. Ein Formulierungsbeispiel (die Zahlen sind illustrativ; deine legst du danach fest, was dich jeder Fehler kostet):
Achte auf die Asymmetrie: Der Schwellenwert wird verhandelt, die Ausschlussbedingung nicht. Manche Fehler werden anteilig toleriert, andere gar nicht. Das aufzuschreiben erspart die teuerste Diskussion des Projekts – die, die entsteht, wenn der Fehler schon bei einem Kunden angekommen ist.
Wann braucht man kein formales Abnahmedokument?
Wenn es ein als solcher deklarierter Prototyp ist, ein internes Experiment ohne Kunden und ohne personenbezogene Daten, oder ein Fall, in dem ein Irrtum billig und umkehrbar ist. Dann genügen ein Satz und ein Datum: „Das ist ein Test, Review am Tag X.“ Sobald der Agent Kunden, Geld oder personenbezogene Daten berührt, wird die Seite geschrieben.
Läuft bei dir schon ein Agent und niemand weiß mehr, was abgenommen wurde, ist jetzt der Moment, das Dokument zu schreiben – vor der nächsten Erweiterung. Und wenn du gerade einen beauftragen willst: die Qualität von KI-Agenten bewerten ist die Arbeit, die aus dieser Seite einen ausführbaren Fallsatz mit Schwellenwert macht.
Die Zeile zum Mitnehmen: Ein Agent ist nicht fertig, wenn er beeindruckt, sondern wenn jemand aus dem Fachbereich, mit Namen und Funktion, unterschreibt, dass er erfüllt, was vor dem Start aufgeschrieben wurde.
Quellen (abgerufen am 27. Oktober 2026): „The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed“, RAND Corporation (2024). Das Eingangsszenario und die Zahlen im Beispiel sind illustrativ, kein realer Fall.