Gastbeitrag von Arthur Teboul, Gründer von DokuTrak.
Bei den meisten Werkzeugen, die ein KI-Assistent nutzen kann, kostet ein Fehler wenig. Man fragt nach einem Aktienkurs, bekommt eine veraltete Zahl und fragt eben noch einmal. Einige Werkzeuge sind anders gelagert, weil ihr Ergebnis tatsächlich etwas in der Welt auslöst. Manches davon lässt sich nicht zurücknehmen, etwa eine Nachricht, die bei einem echten Menschen ankommt.
Wer Werkzeuge für Assistenten entwickelt, sollte diesem Unterschied einen eigenen Entwurfsschritt widmen. Dieser Beitrag stützt sich auf drei Beispiele: Marktdaten-Werkzeuge, deren aufgeführte Anwendungsfälle reine Lesezugriffe sind, ein erdachtes Benachrichtigungswerkzeug und ein reales Produkt, dessen Konnektor Anfragen an echte Mandanten verschickt. Offenlegung: Ich bin Arthur, Gründer von DokuTrak, und DokuTrak ist das dritte Beispiel.
Lesen verzeiht Fehler, Schreiben nicht
Ein Lesewerkzeug stellt eine Frage und liefert eine Antwort. Ruft man es zweimal auf, bleibt die Welt, wie sie war. Ruft man es mit dem falschen Tickersymbol auf, besteht der Schaden aus einem verwirrenden Absatz, den man sieht und korrigieren kann.
Die MCP-Seite von Leeway zeigt das recht anschaulich. Die dort genannten Beispiele sind Abfragen von Marktdaten: Kurse, Unternehmensmeldungen, der Verlauf der Marktkapitalisierung. Jedes davon ist ein Lesezugriff. Ich beschreibe hier nur, was auf dieser Seite steht, nicht den gesamten Server. Geprüft habe ich ihn nicht, und er kann sich ändern.
Auch Lesezugriffe sind nicht ganz ohne Risiko. Manche kosten pro Aufruf Geld, sodass ein Assistent, der in einer Schleife hängt, eine beachtliche Rechnung verursachen kann. Zudem kann der zurückgelieferte Inhalt nicht vertrauenswürdig sein, etwa Text von Dritten, der im Kontext des Assistenten landet. Diese Bedenken sind berechtigt, aber sie sind von anderer Art als ein Fehler, der sich nicht rückgängig machen lässt.
Als Gedankenexperiment stelle man sich einen Marktdaten-Konnektor vor, der um ein Werkzeug send_alert erweitert wurde. Es verschickt eine E-Mail oder SMS, sobald ein Kurs eine Schwelle überschreitet. Dieses Beispiel ist frei erfunden. Auf der zitierten Seite habe ich kein solches Benachrichtigungswerkzeug gefunden. Eine solche Benachrichtigung erreicht jemanden, der den Assistenten nie um etwas gebeten hat. Versteht der Assistent „Sag mir Bescheid, wenn er unter 40 fällt“ als „Sag meinem ganzen Team Bescheid“, ist der Schaden angerichtet, bevor es jemand bemerkt.
Ein zweites Beispiel: Mandanten um Unterlagen bitten
Ein reales Beispiel ist das Einsammeln von Mandantenunterlagen. DokuTrak richtet sich an Dienstleistungskanzleien in den USA, etwa Steuerberater, die in der Steuersaison ihren Mandanten wegen fehlender Belege hinterherlaufen.
Was das Produkt heute leistet:
- Die Kanzlei legt eine Anfrage mit einer Liste der benötigten Unterlagen an.
- Der Mandant lädt die Dateien über einen Link hoch, ganz ohne eigenes Konto.
- Erinnerungen halten den Mandanten in Bewegung.
- Auf Wunsch markiert eine KI in einer ersten Durchsicht Dateien, die fehlerhaft, unleserlich oder abgelaufen wirken.
- Jedes Dokument wird von einem Menschen angenommen. Die KI weist auf Auffälligkeiten hin, die Entscheidung trifft ein Mensch.
Über den Konnektor von DokuTrak kann ein Assistent eine Anfrage anlegen und verschicken, ihren Status abfragen, abgelehnte Dateien erneut anfordern und die Dateien als ZIP-Archiv herunterladen. Er kann kein Dokument annehmen oder ablehnen und hat keinen Zugriff auf Abrechnung, Arbeitsbereichseinstellungen oder API-Schlüssel.
Schon diese Grenze ist eine Lehre für den Entwurf, denn die eigentliche Ermessensentscheidung bleibt beim Menschen. Der Konnektor kann allerdings versenden, und mit jeder versandten Anfrage wird ein echter Mandant kontaktiert. Genau das ist der Schreibzugriff mit Folgen.
Bereit für bessere Investment-Entscheidungen?
Starten Sie noch heute mit Ihrer kostenlosen Testphase - Aktienanalyse mit künstlicher Intelligenz.
Volle Transparenz | Voller Zugriff | Jederzeit kündbar
Was bereits umgesetzt ist und was nur ein Vorschlag ist
Um es klar zu sagen: Alles Folgende ist ein Vorschlag. Der Konnektor von DokuTrak enthält derzeit keinen Bestätigungsschritt vor dem Versand. Heute legt er an und verschickt. Der Rest dieses Beitrags beschreibt, wie ein solches Werkzeug meiner Ansicht nach aufgebaut sein sollte.
1. Eine Vorschau ohne Nebenwirkungen
Die Aktion wird in zwei Schritte aufgeteilt. prepare stellt alles zusammen und verschickt nichts. Zurückgeliefert wird, was hinausgehen würde: Empfänger, Nachrichtentext, Unterlagenliste und Erinnerungsplan. Da dieser Schritt nichts in der Welt verändert, kann der Assistent ihn so oft aufrufen, wie er möchte.
2. Eine Freigabe, die durchgesetzt und nicht bloß erbeten wird
Eine Vorschau allein sichert nichts ab. Kann der Assistent send direkt nach prepare aufrufen, ist die Vorschau reine Dekoration. Ebenso wenig genügt es, wenn das Modell fragt „Soll ich das abschicken?“ und das eigene „Ja“ im Text als Zustimmung wertet. Das Modell kann sich verlesen oder sich ausgerechnet von dem Inhalt lenken lassen, den es gerade verarbeitet.
Die Freigabe muss von einer Instanz geprüft werden, die sich vom Modell nicht überreden lässt. Zwei Ansätze kommen dafür infrage:
- Eine Freigabesperre auf Seiten der Host-Anwendung. Die Client-Anwendung zeigt dem Nutzer die Vorschau und blockiert den Aufruf von
send, bis der Nutzer auf „Freigeben“ klickt. - Ein vom Server ausgestelltes, einmalig verwendbares Freigabe-Token. Der Server erzeugt das Token erst nach einem menschlichen Freigabeschritt, auf den das Modell keinen Einfluss hat. Das Token ist an eine unveränderliche Vorschau, den Empfänger, den genauen Inhalt und eine Ablaufzeit gebunden.
senderwartet dieses Token, keine neuen Parameter.
Diese Bindung ist entscheidend. Ändert der Assistent nach der Freigabe den Empfänger oder bearbeitet den Text, passt das Token nicht mehr, und send schlägt fehl. Läuft die Vorschau ab oder ändert sich auch nur ein Teil davon, verfällt die Freigabe, und der Mensch bekommt die neue Fassung zu sehen.
„Einmalig verwendbar“ verdient allerdings eine genauere Betrachtung. Gemeint ist, dass das Token genau eine Wirkung auslösen darf, nicht dass ein zweiter Aufruf zwingend mit einem Fehler enden muss. Geht die Antwort auf den ersten Aufruf verloren und wiederholt der Assistent die Anfrage mit demselben Token, sollte der Server das gespeicherte Ergebnis des ersten Versands zurückgeben, ohne ein zweites Mal etwas auszulösen. Eine Wiederholung erhält dann eine Antwort statt eines rätselhaften Fehlschlags.
3. Idempotente Wiederholungen
Netzwerke fallen aus, und Assistenten versuchen es erneut. Deshalb gehört an jeden vorbereiteten Vorgang ein Idempotenzschlüssel. Der erste send-Aufruf mit diesem Schlüssel erledigt die Arbeit und speichert das Ergebnis. Jeder spätere Aufruf mit demselben Schlüssel liefert dieses gespeicherte Ergebnis, statt erneut zu handeln. Das sollte auch gelten, solange der erste Aufruf noch läuft, damit nicht zwei fast gleichzeitige Wiederholungen beide ausgelöst werden. Für einen Mandanten, dem die Steuererklärung ohnehin im Nacken sitzt, ist eine doppelte Aufforderung, doch bitte die Unterlagen hochzuladen, mehr als nur ein Ärgernis.
4. Statusabfrage über den Vorgangsschlüssel
Bereit für bessere Investment-Entscheidungen?
Starten Sie noch heute mit Ihrer kostenlosen Testphase - Aktienanalyse mit künstlicher Intelligenz.
Volle Transparenz | Voller Zugriff | Jederzeit kündbar
Der schwierigste Fall ist Funkstille: Der Assistent ruft send auf, die Verbindung bricht ab, und es kommt nichts zurück. Ist die Nachricht nun raus oder nicht?
Der aktuelle Konnektor von DokuTrak kann den Status einer Anfrage abfragen. Mir ist jedoch nicht bekannt, dass er etwas über einen Idempotenzschlüssel oder eine Vorschau-ID nachschlagen kann. Angenommen also, bei einer Zeitüberschreitung hat der Assistent die Anfrage-ID nie erhalten. Eine Statusabfrage über diese ID hilft dann nicht weiter, weil der Assistent schlicht nichts in der Hand hat, wonach er suchen könnte. Eine Abfrage über den Vorgangsschlüssel würde diese Lücke schließen, denn diesen Schlüssel kennt der Assistent bereits. Die Antwort wäre „nicht gefunden“, „in Bearbeitung“ oder „versendet“, gegebenenfalls ergänzt um die Anfrage-ID.
Diese Abfrage dient der Transparenz. Da Wiederholungen idempotent sind, braucht der Assistent die Antwort nicht, um gefahrlos einen neuen Versuch zu starten. Sie erlaubt ihm aber, dem Menschen zu sagen, was tatsächlich passiert ist, statt zu raten.
Wie das aussehen könnte
Ein veranschaulichender Ablauf, keine ausgelieferte Schnittstelle. Namen und Felder sind erfunden.
# NUR ZUR VERANSCHAULICHUNG — keine echte DokuTrak- oder Leeway-API
preview = prepare_request(client="Dana", checklist=[...])
# -> preview_id, vollständiger Nachrichtentext, operation_key, expires_at. Versendet nichts.
# Der Host zeigt die Vorschau. Der Nutzer klickt auf „Freigeben“ (außerhalb des Modells).
token = <vom Server ausgestellt, einmalig verwendbar, gebunden an preview_id + Empfänger + Inhalt + Ablaufzeit>
result = send_request(approval_token=token, operation_key=preview.operation_key)
# -> Erfolg: request_id, Status "sent"
# -> Zeitüberschreitung: Ausgang unbekannt
status = get_operation_status(operation_key=preview.operation_key)
# sent / in_progress / not_found
# Ein erneuter Aufruf von send_request mit demselben Token und Schlüssel liefert das gespeicherte Ergebnis.Dasselbe Muster ließe sich auf das erdachte Benachrichtigungswerkzeug übertragen: vorbereiten, anzeigen, eine echte Freigabe einholen, genau einmal versenden und im Zweifel nachsehen statt raten.
Eine abschließende Prüfliste
Wenn ein Werkzeug etwas tut, das sich nicht rückgängig machen lässt, lohnt es sich, folgende Fragen zu stellen:
- Kann der Assistent die Aktion in einer Vorschau zeigen, ohne sie auszuführen?
- Wird die Freigabe von der Host-Anwendung oder dem Server durchgesetzt und nicht nur durch die Worte des Modells selbst?
- Ist die Freigabe an genau diesen Empfänger, diesen Inhalt und diese Ablaufzeit gebunden, und verfällt sie, sobald sich eines davon ändert?
- Liefert ein wiederholter Aufruf das gespeicherte Ergebnis, ohne ein zweites Mal etwas auszulösen, auch solange der erste Aufruf noch läuft?
- Kann der Assistent nach einer Zeitüberschreitung über einen Schlüssel, den er noch besitzt, nachsehen, was passiert ist?
- Bleiben Ermessensentscheidungen wie Annehmen, Ablehnen, Bezahlen oder Löschen einem Menschen vorbehalten?
Nichts davon macht einen Assistenten weniger nützlich. Es macht ihn zu einem Kollegen, den man guten Gewissens an die eigenen Mandanten heranlässt: einem, der seinen Entwurf vorlegt und erst auf „Senden“ drücken kann, wenn man zugestimmt hat.
Über den Autor
Arthur Teboul ist Gründer von DokuTrak, einer Software zum Einsammeln von Mandantenunterlagen für Dienstleistungskanzleien in den USA. Mandanten laden ihre Dateien über Links hoch, für die sie kein Konto benötigen, und DokuTrak stellt einen quelloffenen MCP-Konnektor bereit.
Dies ist ein Gastbeitrag. Die geäußerten Ansichten sind die des Autors.
