Leistungsbeschreibung für einen KI-Vorgang: was geschuldet ist, wenn Antworten schwanken

Mit der Leistungsbeschreibung vereinbaren beide Seiten, welche Beschaffenheit das Werk haben soll – sie ist der Maßstab, an dem Übergabe und Mängel gemessen werden. Für einen KI-Vorgang muss sie eine Besonderheit auffangen: Das Ergebnis ist keine feste Ausgabe, sondern ein Verhalten über viele Fälle, samt Regeln dafür, was das System allein entscheiden darf.

Warum die Leistungsbeschreibung bei KI den Streit entscheidet

§ 633 BGB misst ein Werk zuerst an der vereinbarten Beschaffenheit. Fehlt sie, kommt es darauf an, ob es sich für die nach dem Vertrag vorausgesetzte, sonst für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist. Für eine Buchhaltungssoftware lässt sich das Übliche noch umreißen. Für eine Funktion, die eingehende Schreiben liest und Vorgängen zuordnet, gibt es kaum einen gefestigten Maßstab – was nicht vereinbart ist, bleibt Auslegung.

Hinzu kommt die Vorgeschichte. Viele Pilotprojekte sind ohne schriftliche Grundlage entstanden, weil sie nur zeigen sollten, ob etwas geht. Wer einen solchen Vorgang in den Betrieb überführt, schreibt oft zum ersten Mal auf, was bisher nur vorgeführt wurde.

Was das System entscheiden darf – und was nie

Der Kern einer Beschreibung für den Betrieb ist keine Funktionsliste, sondern eine Ordnung der Befugnisse. Bewährt hat sich eine Einteilung in drei Stufen, für jede Fallgruppe des Vorgangs einzeln festgelegt:

• Selbst erledigen: Das System entscheidet und schreibt das Ergebnis in das Zielsystem, etwa die Zuordnung eines Schreibens zu einer bestehenden Akte.
• Vorschlagen: Das System bereitet eine Entscheidung vor, ein Mensch gibt sie frei, etwa eine Antwort an einen Kunden.
• Nie: Handlungen, die dem System ausdrücklich verschlossen bleiben, etwa Zahlungen anstoßen oder Fristen gegenüber Dritten setzen.

Zu jeder Stufe gehört, wer im Unternehmen verantwortlich ist und wie die freigebende Person erkennt, worauf ein Vorschlag beruht. Das Prinzip dahinter erklärt der Artikel Human in the Loop.

Das Ergebnis in der Leistungsbeschreibung: eine Verteilung über Testfälle

Weil dieselbe Eingabe unterschiedlich beantwortet werden kann, beschreibt der Vertrag das Ergebnis nicht am Einzelfall. Er legt einen Satz von Testfällen fest, deren richtige Lösung die Fachabteilung vorab bestimmt, und nennt für jede Fallgruppe drei Werte: den Mindestanteil richtig erledigter Fälle, den höchsten zulässigen Anteil falscher Entscheidungen ohne Kennzeichnung und den Anteil, der an einen Menschen gehen darf, ohne dass der Vorgang seinen Zweck verliert.

Der dritte Wert wird oft vergessen, dabei entscheidet er über den Nutzen: Ein System, das fast jede Akte zur Freigabe vorlegt, macht keine Fehler und entlastet trotzdem niemanden. Ebenso gehört hinein, was ausdrücklich nicht geschuldet ist – etwa eine bestimmte Formulierung einer Antwort oder ein bestimmter Modellstand des Anbieters.

Rahmen des Betriebs: Protokoll, Kosten, Daten, Abschalten

• Protokoll: welche Angaben zu jeder Ausgabe gespeichert werden, wie lange und wer sie einsehen darf.
• Kosten: eine Kostengrenze für Modellaufrufe und was geschieht, wenn sie erreicht ist.
• Daten: welche Daten ein externes Modell sieht, welche Anbieter als weitere Verarbeiter beteiligt sind und wo es einen Vertrag zur Auftragsverarbeitung bei KI-Diensten braucht.
• Abschalten: wer die Funktion stilllegen darf und wie der Vorgang danach von Hand weiterläuft.
• Mitwirkung: welche Testfälle, Zugänge und fachlichen Entscheidungen der Auftraggeber beisteuert und bis zu welchem Projektschritt.

Lücken, die erst im Betrieb auffallen

• Die Vorführung als Anlage. Bildschirmfotos aus dem Pilot zeigen, was an einem Tag funktioniert hat, nicht was geschuldet ist.
• Nur der Normalfall. Unleserliche Anhänge, doppelte Eingänge und Schreiben in fremder Sprache fehlen – genau sie landen im Betrieb bei den Menschen.
• Befugnisse ohne Namen. „Kritische Fälle gehen an die Fachabteilung“ nennt weder Fallgruppe noch Rolle.
• Keine Änderungsregel. Neue Fallgruppen tauchen erst im Betrieb auf; ohne vereinbarten Weg für Nachträge entfernt sich die gelebte Praxis still vom Vertrag.

Wie wir Beschreibungen für den Betrieb aufsetzen

Wir beginnen mit den Vorgängen, nicht mit dem Modell. Gemeinsam mit der Fachabteilung ordnen wir Fallgruppen, legen für jede die Stufe fest – selbst erledigen, vorschlagen, nie – und halten die Werte für die Testfälle im Angebot fest, bevor gebaut wird. Bei unserer eigenen KI arbeiten wir genauso: Sie führt Aktionen aus einem beschriebenen Katalog aus, und was dort nicht steht, gehört nicht zu ihren Befugnissen. Welche Daten ein Sprachmodell oder ein externer Dienst sieht, halten wir im Angebot fest; verarbeiten wir personenbezogene Daten im Auftrag, schließen wir einen Auftragsverarbeitungsvertrag. Wie solche Befugnisse in der Umsetzung aussehen, zeigt die Leistung KI-Agenten für Unternehmen.