Anforderungen an einen KI-Agenten erheben: ein Leitfaden für die Business-Analyse

Man hat Ihnen aufgetragen, sich mit KI-Agenten zu befassen, und irgendwo auf dem Weg sind Sie zu der Person geworden, bei der die Anforderungen liegen. Die Anforderungen an einen KI-Agenten sind die Entscheidungen, die bestimmen, was er im Gespräch sagt und tut: die Aufgabe, die er erledigt, die Systeme hinter jeder Antwort, die Daten, die er berührt, die Grenze, an der ein Mensch übernimmt, und wer das alles abnimmt. Eine Vorlage kann nichts davon liefern. Sie bekommen es, indem Sie die Menschen befragen, denen jede einzelne Entscheidung gehört, und ihre Antworten dann in einer Form aufschreiben, gegen die jemand ein Veto einlegen kann.

Was müssen Sie wissen, bevor jemand baut?

Sieben Dinge. Wenn Sie alle sieben beantworten können, kann ein Entwicklungsteam oder ein Anbieter den Agenten bauen, ohne an Ihrer Stelle Verhalten zu erfinden. Wenn nicht, erfinden sie es trotzdem, und Sie entdecken ihre Entscheidungen im Abnahmetest (UAT), wenn eine Änderung teuer ist.

1. Die Aufgabe (Job-to-be-done)

„Kundenfragen beantworten“ ist ein Wunsch. Eine Aufgabe ist konkret und hat einen Endzustand: zum Beispiel eine Kartenreklamation von der ersten Nachricht bis zum angelegten Fall aufzunehmen oder einen Liefertermin zu verschieben und den neuen zu bestätigen. Wählen Sie für den ersten Agenten eine Aufgabe. Alles andere in den Anforderungen hängt an dieser Entscheidung, denn ein Gespräch Turn für Turn lässt sich nur über eine Aufgabe mit Anfang und Ende schreiben.

2. Das System hinter jeder Antwort und wer dafür zuständig ist

Alles Nützliche, was ein Agent sagt, stützt sich auf ein System: Der Bestellstatus liegt im Bestellmanagementsystem, der Kontostand im Kernbankensystem, das Lieferfenster beim Zustelldienst. Für jede Antwort, die der Agent geben wird, brauchen Sie das System, aus dem sie stammt, die Information, ob es eine API dazu gibt, und den Namen der Person, die dafür zuständig ist. Die zuständige Person zählt mehr als die API. APIs werden gebaut; ob es dazu kommt, entscheiden die Zuständigen, und genau diese Menschen fehlen in den meisten Kickoff-Meetings.

3. Sensibilität der Daten

Listen Sie auf, was der Agent liest, und getrennt davon, was er schreibt. Einen Kontostand abzufragen und eine Adresse zu ändern sind verschiedene Risikoklassen, und die Teams für Sicherheit und Recht behandeln sie unterschiedlich. Kennzeichnen Sie schon jetzt alles, was personenbezogen, reguliert oder destruktiv ist. Eine Datenfrage, die im vierten Monat auftaucht, kann ein Projekt anhalten; dieselbe Frage in der zweiten Woche ist ein Tagesordnungspunkt.

4. Die Eskalationsgrenze

Legen Sie genau fest, wo der Agent aufhört und ein Mensch übernimmt: auf ausdrücklichen Wunsch, bei erkanntem Ärger, bei juristischen Stichwörtern, nach einer festgelegten Zahl gescheiterter Versuche. Entscheiden Sie dann, was die Übergabe mitnimmt, denn wer dem Menschen die eigene Geschichte noch einmal erzählen muss, hat das Scheitern des Agenten gerade zweimal erlebt. Die Aufgabe des Agenten endet bei der Übergabe. Schreiben Sie die Seite des Menschen nicht vor.

5. Was der Agent nie tun darf

Alle Stakeholder haben eine kurze Liste von Katastrophen im Kopf: nie einen Erstattungsbetrag nennen, bevor das System ihn bestätigt, nie über eine Gebühr spekulieren, nie einen Rückruftermin versprechen, den niemand halten kann. Diese Regeln sind im Interview günstig einzusammeln und im Produktivbetrieb teuer zu entdecken. Schreiben Sie jede als ausdrückliche Vorgabe mit angehängter Begründung auf, damit die nächste Person, die sie liest, versteht, warum es die Regel gibt.

6. Volumen und Kanäle

Klären Sie, wie viele dieser Gespräche pro Woche stattfinden, in welchen Kanälen, und wie die schlimmste Woche aussieht. Der Kanal prägt das Design unmittelbar: Ein Agent im SMS-Kanal kann kein Formular und keine Karte zeigen, und ein Sprachagent kann gar nichts zeigen. Das Volumen macht aus Prozenten Menschen. Ein Fehlerpfad, der zwei Prozent der Gespräche auffängt, betrifft bei zweitausend Gesprächen vierzig Personen pro Woche, und auf diese Zahl kann eine Sponsorin oder ein Sponsor reagieren.

7. Die Abnahmekette

Finden Sie heraus, wer Formulierungen per Veto stoppen kann, wer die Daten genehmigt, die der Agent berührt, und wer das Risiko trägt, wenn sich ein Satz als falsch herausstellt. Besorgen Sie Namen, keine Rollenbeschreibungen. Die Kette ist nur echt, wenn die letzte Person darin tatsächlich liest, was der Agent sagt, und das ist ein weiteres Argument dafür, Anforderungen als Gespräch aufzuschreiben.

Was sollten Sie Ihre Stakeholder fragen?

Fragen Sie kollegial. Mit diesen Fragen bekommen Sie die meisten der sieben Antworten, ohne jemanden zu bitten, „Anforderungen zu definieren“.

• „Erzählen Sie mir vom letzten Mal, als jemand aus der Kundschaft das gebraucht hat. Was ist tatsächlich passiert, Nachricht für Nachricht?“
• „Woher kommt diese Antwort heute? Wer schlägt sie nach, und in welchem System?“
• „Was passiert, wenn dieses System langsam ist oder ausfällt?“
• „Was sollte dieser Agent nie sagen, selbst wenn die Kundschaft direkt danach fragt?“
• „Wenn die Kundschaft heute wütend wird, wer übernimmt dann, und was muss diese Person in dem Moment wissen, in dem sie übernimmt?“
• „Wenn sich ein Satz in diesem Gespräch als falsch herausstellte, wer bekommt dann den Anruf?“
• „Wie viele dieser Gespräche finden in einer normalen Woche statt? Wie sah die schlimmste Woche aus?“
• „Was bräuchten Sie, um Ihren Namen guten Gewissens darunterzusetzen?“

Halten Sie die Antworten, wo immer es geht, als Gespräch fest. Wenn jemand den Fall der verärgerten Kundschaft beschreibt, schreiben Sie nicht „Agent reagiert einfühlsam“, sondern den Satz, den sich die Person vom Agenten wünscht, und lesen Sie ihn ihr vor. Das Vorlesen ist die schnellste Prüfschleife, die Sie haben. Menschen, die bei einem Stichpunkt nicken, unterbrechen bei einem Satz.

Wo geht die Erhebung von Anforderungen schief?

Drei Fallen richten den meisten Schaden an.

Falle eins: Intents statt Gespräche sammeln

Das Chatbot-Standardvorgehen aus der Klassifizierer-Ära lautet, Intents zu sammeln: check_balance, dispute_charge, cancel_card, jeweils mit einem Stapel Beispieläußerungen. Eine Intent-Liste beschreibt, was Ihre Kundschaft will; sie sagt nichts darüber, was der Agent als Nächstes tut, erfragt oder antwortet. Einen Intent können Sie keiner Sponsorin und keinem Sponsor zur Abnahme vorlegen, und wer ihn in der Hand hält, muss das gesamte Gespräch trotzdem erfinden. Sammeln Sie stattdessen Gespräche: die tatsächliche Abfolge von Turns, einschließlich der Seite der Kundschaft.

Falle zwei: Fließtext schreiben, gegen den niemand ein Veto einlegen kann

„Der Agent soll einfühlsam reagieren und bei Bedarf eskalieren.“ Gegen diesen Satz hat in keiner Prüfung je jemand Einwände erhoben, und genau das ist sein Fehler: Einer Anforderung, die sich nicht ablehnen lässt, kann man auch nicht zustimmen. Vergleichen Sie ein Beispiel, das als tatsächlicher Turn geschrieben ist: „Wenn der zweite Zahlungsversuch scheitert, sagt der Agent: ‚Diese Karte wurde erneut abgelehnt. Ich kann Ihre Bestellung 48 Stunden für Sie zurücklegen, während Sie das klären. Soll ich?‘“ Stakeholder können das lesen und Nein sagen. Frühe Ablehnung ist das Ergebnis guter Anforderungen, denn jedes Nein, das Sie in einem Dokument einsammeln, ist ein Nein, das Sie nicht im Produktivbetrieb einsammeln mussten.

Falle drei: die Fehlerpfade überspringen

Der Regelfall schreibt sich von selbst; das Design steckt in den Abzweigungen. Was sagt der Agent, wenn das Reklamationssystem mitten beim Anlegen des Falls in ein Timeout läuft? Wenn das Konto markiert ist? Wenn die Kundschaft schon im zweiten Turn nach einem Menschen fragt? Beantworten die Anforderungen das nicht, beantwortet es die Entwicklung bei der Umsetzung, allein und undokumentiert, und der Lenkungsausschuss erfährt es in dem Moment, in dem es die Kundschaft erfährt. Dazu haben wir einen eigenen Beitrag geschrieben: Der Regelfall ist kein Design.

Warum ist ein Gesprächsdesign das Anforderungsdokument?

Weil es das eine Format ist, das beide Seiten nutzen können. Ein Gesprächsdesign ist das Verhalten des Agenten, Turn für Turn aufgeschrieben: Beispiel-Turns für jede Situation, der Werkzeugaufruf hinter jeder Antwort mit der zuständigen Person und dem Verhalten im Fehlerfall, die Abzweigungen für die Pfade, auf denen etwas schiefgeht, und der ausdrückliche Turn, in dem ein Mensch übernimmt. Ihre Sponsorin oder Ihr Sponsor kann es von oben nach unten wie ein Transkript lesen und einzelne Sätze per Veto stoppen. Ihr Entwicklungsteam kann daraus bauen, ohne dass es ein Klärungsmeeting braucht, weil die Fragen, die es gestellt hätte, in der Struktur beantwortet sind.

Die sieben Kategorien lassen sich direkt darauf abbilden. Die Aufgabe und die Kanäle stehen im Brief des Projekts. Jedes System hinter einer Antwort wird zu einem spezifizierten Werkzeugaufruf, der die zuständige Person, die Sensibilität der Daten und das Verhalten bei Timeout mitbringt. Die Liste dessen, was der Agent nie tun darf, wird zu Verhaltens-Guidelines, die mit den Turns verknüpft sind, die sie veranschaulichen. Die Eskalationsgrenze ist ein markierter, abschließender Turn. Und die Abnahmekette wird zu einer echten Abnahme: Eine namentlich benannte Person liest das Design und hält ihre Abnahme in der Zeitleiste des Designs fest, bevor jemand baut. Die Methode Schritt für Schritt steht in der Anleitung zum Entwerfen eines Gesprächs für einen KI-Agenten, die Mechanik der Abnahme im Beitrag zur Abnahme eines Agent-Designs durch das Kundenunternehmen.

Klate hält Turns, Abzweigungen, Werkzeugaufrufe, Briefs und Abnahmen an einem Ort. Der Tarif Free genügt, um das Ganze zu entwerfen: Schreiben Sie die Interviewantworten als Beispiel-Turns, zweigen Sie die Fehlerpfade ab und hängen Sie das System hinter jeder Antwort als Werkzeugaufruf an. Das Ergebnis der Person vorzulegen, deren Name daruntersteht, erfordert einen kostenpflichtigen Tarif.