Alle Beiträge

Wer besitzt den Agenten, wenn die Agentur geht?

Die Frage wird oft nicht im Vertrag beantwortet und entscheidet, ob ihr ein System oder ein Abonnement gekauft habt. Sechs Dinge, die euch gehören müssen, und der Test, der vor der Unterschrift funktioniert.

Die Frage, wem der Agent nach dem Projekt gehört, wird in vielen Angeboten gar nicht beantwortet, und sie entscheidet darüber, ob ihr ein System oder ein Abonnement gekauft habt.

Dieser Artikel benennt die sechs Dinge, die euch gehören müssen, damit die Antwort „uns“ lautet, den Test dafür vor der Unterschrift, und die zwei Fälle, in denen es vernünftig ist, bewusst darauf zu verzichten.

Warum die Frage schwerer ist als bei klassischer Software

Bei einem klassischen Entwicklungsprojekt ist die Sache übersichtlich: Es gibt Quellcode, es gibt eine Rechteklausel, und der Code liegt am Ende in einem Repository, auf das ihr Zugriff habt.

Ein KI-Agent besteht dagegen aus sechs Bestandteilen, die meist an verschiedenen Orten liegen und selten alle im Vertrag stehen:

  • die Anweisungen an das Modell, also die Prompts
  • die Konfiguration der Kette: Auslöser, Reihenfolge, Bedingungen, Schwellen
  • die Zugänge zu euren Systemen, also API-Schlüssel und Rechte
  • die Daten, die der Agent erzeugt oder anreichert
  • der Testrahmen, an dem man erkennt, ob er noch richtig arbeitet
  • das Wissen, warum er so gebaut ist und nicht anders

Der Besitz an fünf dieser sechs Dinge nützt nichts. Wer die Konfiguration hat, aber nicht die Prompts, hat eine Kette ohne Inhalt. Wer beides hat, aber keinen Testrahmen, kann nichts ändern, ohne zu riskieren, dass es unbemerkt schlechter wird.

Der Bestandteil, den fast alle vergessen

Der sechste Punkt ist der, der in keiner Übergabeliste steht: die Begründung.

Ein Agent enthält Entscheidungen, die man ihm nicht ansieht. Warum die Klassifikation vor der Generierung läuft. Warum ein bestimmter Fall an einen Menschen geht statt beantwortet zu werden. Warum ein Schwellenwert bei 0,7 steht und nicht bei 0,8.

Jede dieser Entscheidungen war ein Fehler, den jemand einmal gemacht hat.

Ohne die Begründung wird sie beim nächsten Umbau rückgängig gemacht, und der Fehler passiert erneut. Das fällt in der Regel drei Monate später auf.

Was das praktisch heißt: Eine Übergabe, die aus einem Zugang zu einem Repository besteht, ist keine. Die Dokumentation muss die Warums enthalten, nicht die Was.

Ein Tresor aus grünem Glas auf einer Wolkendecke
Sechs Bestandteile, verteilt auf mehrere Orte, und ein Vertrag, in dem oft nur ein Teil davon vorkommt.

Die sechs Fragen vor der Unterschrift

Jede lässt sich mit ja oder nein beantworten, und jedes Nein ist verhandelbar, solange noch nichts unterschrieben ist.

Liegen die Prompts bei uns, im Klartext? Nicht „wir stellen sie auf Anfrage zur Verfügung“. Im System, das euch gehört, jederzeit lesbar.

Läuft die Orchestrierung in unserem Konto? Ein Automatisierungswerkzeug im Konto der Agentur ist ein Schalter, den jemand anders umlegen kann. Dasselbe Werkzeug in eurem Konto ist Infrastruktur. Der Unterschied kostet nichts und ist am Tag der Trennung alles.

Gehören uns die Zugänge? API-Schlüssel auf euren Namen, in eurem Passwortspeicher, mit euren Kosten. Wenn der Modellzugang über die Agentur abgerechnet wird, endet der Agent mit dem Vertrag.

Bekommen wir den Testrahmen? Ohne ihn könnt ihr nichts ändern, ohne blind zu sein. Das ist der Punkt, an dem Abhängigkeit tatsächlich entsteht, nicht beim Code, sondern bei der Fähigkeit, eine Änderung zu bewerten.

Enthält die Dokumentation die Begründungen? Siehe oben.

Gibt es bei uns eine Person mit Namen? Keine Rolle, keine Abteilung. Ein Name, vor dem Projektstart. Das ist die Bedingung, an der die meisten übergebenen Systeme später scheitern, und sie liegt vollständig bei euch.

Der Test, der wirklich funktioniert

Alle sechs Fragen lassen sich mit einem einzigen Vorgang beantworten, und zwar bevor das Projekt endet:

Lasst euer Team eine kleine Änderung selbst machen, während die Agentur noch da ist.

Ein Schwellenwert, ein zusätzlicher Empfänger, eine geänderte Formulierung. Nicht als Übung, sondern als echte Änderung, die produktiv geht. Die Agentur sitzt daneben und greift nicht ein.

Was dabei herauskommt, ist die ehrlichste Auskunft über den Zustand der Übergabe, die es gibt. Wenn es zwanzig Minuten dauert, gehört euch das System. Wenn es nicht geht, weil ein Zugang fehlt, ein Werkzeug im falschen Konto liegt oder niemand weiß, welcher Prompt der aktive ist, wisst ihr das jetzt statt in acht Monaten.

Bei uns ist dieser Vorgang der Kern der Übergabe, und die Länge des Zeitraums ist der unwichtigere Teil davon: was in eine Übergabe gehört, steht ausführlich hier (in English).

Woran man Lock-in erkennt, bevor er entsteht

Drei Muster, die alle mit guten Absichten daherkommen:

Die eigene Plattform. „Wir betreiben das auf unserem Framework, das nimmt Ihnen die Komplexität ab.“ Kann stimmen und macht euch zum Mieter. Die Frage, die das klärt: Läuft das weiter, wenn wir kündigen?

Der Betreuungsvertrag als Voraussetzung. Ein Betrieb ist sinnvoll und sollte eine Option sein. Wenn er Bedingung dafür ist, dass das System läuft, kauft ihr kein System.

Die Weigerung beim Testrahmen. Der subtilste. Alles wird übergeben, nur die Bewertungsgrundlage nicht, mit dem Argument, das sei zu speziell. Ohne sie könnt ihr das System besitzen und trotzdem nicht anfassen.

Wann Verzicht die richtige Entscheidung ist

Der Vollständigkeit halber, weil Eigentum nicht immer das Ziel ist.

Wenn es Standardsoftware ist. Bei einem Werkzeug, das zehntausend Firmen identisch nutzen, ist Eigenbesitz sinnlos. Ihr kauft ein Produkt und kündigt es, wenn es nicht mehr passt. Der Unterschied zwischen den drei Modellen ist an anderer Stelle sauber getrennt (in English).

Wenn der Prozess ohnehin ausläuft. Für eine Kette, die eine bekannte Übergangszeit überbrückt, ist Übergabe unnötiger Aufwand.

In beiden Fällen ist der Verzicht eine Entscheidung. Der Normalfall ist, dass er keine ist, sondern schlicht nie besprochen wurde, und das ist der Zustand, in dem man ihn zwei Jahre später bemerkt.

Häufig gestellte Fragen

Gehören uns die Prompts automatisch?

Nein. Nach deutschem Recht ist das Urheberrecht selbst nicht übertragbar (§ 29 Abs. 1 UrhG), eingeräumt werden können nur Nutzungsrechte. Und wenn der Vertrag die Nutzungsarten nicht einzeln benennt, bestimmt sich nach dem Vertragszweck, welche Nutzung er überhaupt abdeckt (§ 31 Abs. 5 UrhG), was genau die Auslegungsfrage ist, die man ungern im Streit klärt. Eine Zeile im Vertrag, die euch die inhaltlich, räumlich und zeitlich unbeschränkten Nutzungsrechte an Prompts, Konfiguration und Dokumentation einräumt und deren Herausgabe im Klartext regelt, erledigt das.

Was ist wichtiger, Quellcode oder Testrahmen?

Der Testrahmen. Den Code kann man neu schreiben. Das Wissen darüber, ob eine Änderung das System verbessert oder verschlechtert, muss man sich sonst über Monate im Betrieb neu erarbeiten.

Reicht ein Übergabedokument?

Selten. Ein Dokument beweist, dass jemand geschrieben hat. Erst die selbst durchgeführte Änderung beweist, dass jemand kann.

Wer sollte intern zuständig sein?

Wer den Prozess ohnehin verantwortet, nicht die IT. Die IT verantwortet Zugänge und Sicherheit. Die fachliche Zuständigkeit gehört dorthin, wo die Arbeit anfällt.

Und wenn wir niemanden dafür haben?

Dann ist ein Betreuungsvertrag die richtige Wahl, und das ist völlig in Ordnung: solange er als Entscheidung getroffen wird und nicht als Folge einer Übergabe, die nie stattgefunden hat.

Passend dazu