Kategorie: Erklärer

Föderiertes Lernen gilt als datenschutzfreundlich, weil die Trainingsdaten das Gerät der Nutzer gar nicht erst verlassen müssen. Nur Modellupdates gehen zum Server, so die verbreitete Darstellung. Der Beitrag „Toward provably private learning from federated data“, den Katharine Daly und Daniel Ramage von Google Research auf dem Forschungsblog des Unternehmens veröffentlicht haben, zeigt aber, dass dieses Versprechen über Jahre auf Vertrauen gebaut war und nicht auf Nachprüfbarkeit: Ob die hochgeladenen Daten tatsächlich nie zwischengespeichert oder eingesehen wurden, konnte von außen niemand belegen. Genau darum geht es im Folgenden – föderiertes Lernen war nie automatisch datenschutzfreundlich, es musste erst überprüfbar gemacht werden. Warum plötzlich von Trusted Execution Environments, Transparenz-Logs und reproduzierbaren Builds die Rede ist, klärt dieser Überblick.

Föderiertes Lernen, vier Prinzipien und eine nachgeschärfte Definition

Google stellte das föderierte Lernen 2017 als Verfahren vor, das Modelle über verteilte, private Daten trainiert, ohne diese zusammenzuführen. Laut Unternehmen kam es unter anderem bei der Wortvorhersage und Smart Compose auf Gboard zum Einsatz, bei Antwortvorschlägen in Google Messages sowie bei der intelligenten Textauswahl unter Android. Das Team nennt vier Prinzipien, an denen es sich orientiert: Datenminimierung, Anonymisierung, Transparenz und Kontrolle sowie Verifizierbarkeit und Auditierbarkeit. Der vierte Punkt ist der entscheidende, denn er verschiebt die Frage von „Ist das datenschutzfreundlich?“ zu „Kann jemand von außen nachprüfen, dass es das ist?“. An dieser Verschiebung hängt der Rest des Beitrags.

2025 hat das Team eine überarbeitete Definition vorgelegt, die mehr festhält als die technische Grundidee. Föderiertes Lernen ist demnach eine Lernumgebung, in der mehrere Einheiten als Clients unter der Koordination eines Diensteanbieters zusammenarbeiten. Ein vollständiges System müsse den Clients die volle Kontrolle über ihre Daten geben: über die Menge der Arbeitslasten, die auf diese Daten zugreifen dürfen, und über die Anonymisierungseigenschaften dieser Arbeitslasten. Auch die Menschen, deren Daten von den Clients verwaltet werden, sollen angemessene Transparenz und Kontrolle erhalten. Das klingt nach einer Formalie, ist aber eine Machtverschiebung: Nicht der Betreiber legt fest, was mit den Daten passieren darf, sondern das Gerät führt eine Positivliste der erlaubten Berechnungen.

Trusted Execution Environments: versiegelte Räume mit beglaubigtem Siegel

Vorstellen kann man sich das wie einen Laborraum, in dem gearbeitet werden darf, aber niemand hineinsehen kann – nicht einmal der Hausherr. Trusted Execution Environments, kurz TEEs, sind abgeschottete Ausführungsumgebungen auf einem Prozessor. Sie bieten drei Eigenschaften, die hier zusammenwirken: Vertraulichkeit, weil der interne Zustand nicht beobachtet werden kann, Integrität, weil die Logik nicht unterbrochen oder verändert werden kann, und die Möglichkeit der Remote-Attestierung, bei der Dritte nachprüfen können, welcher Code dort tatsächlich läuft. Einschränkungen der aktuellen TEE-Generation gelten dabei ausdrücklich mit, wie die Autoren betonen.

Ein einzelner versiegelter Raum genügt aber nicht. Das neue System setzt viele solcher Umgebungen so zusammen, dass daraus ein durchgängig überprüfbarer Ablauf entsteht, vom Gerät bis zur fertigen Modellaktualisierung. Die Attestierung, die auf einer einzelnen Maschine nur eine Aussage über diese eine Maschine erlaubt, wird also zum Baustein einer Kette. Erst durch diese Verkettung entsteht, was der Beitrag verifizierbaren Datenschutz nennt – und erst dadurch werden Eigenschaften, die vorher Zusicherungen waren, zu überprüfbaren Tatsachen.

Vier Bausteine: Upload, Schlüsselverwaltung, Workload-Ausführung, Wiederherstellung

Der erste Baustein ist der Upload. Client-Geräte verschlüsseln Trainingsbeispiele lokal und laden sie hoch. Dabei autorisieren sie vorab eine Zugriffsrichtlinie, also die Menge der TEE-Berechnungen, die diese Daten verarbeiten dürfen, und diese Berechnungen geben ausschließlich anonymisierte Ergebnisse frei. Die Richtlinien müssen in einem öffentlichen Transparenz-Log veröffentlicht werden, sonst greift der Mechanismus nicht. Wer die Daten erzeugt, bestimmt also, welcher Code sie später überhaupt anfassen darf.

Der zweite Baustein ist die Schlüsselverwaltung. Ein Key Management System, das als Cluster von TEEs den Konsensalgorithmus RAFT umsetzt, gibt Entschlüsselungsschlüssel nur an serverseitige TEE-Arbeitslasten heraus, die exakt den Berechnungen aus der Zugriffsrichtlinie entsprechen. Ohne passende Richtlinie kein Schlüssel – die Policy ist damit keine Dokumentation, sondern eine technische Sperre. Der dritte Baustein ist die Ausführung: Eine Root-TEE startet ein Python-Programm mit der Trainingsschleife und delegiert parallelisierbare Teilaufgaben an einen Cluster von Worker-TEEs. Die verteilte Logik wird in Federated Language ausgedrückt, einer quelloffenen, framework-unabhängigen Orchestrierungssprache, die aus TensorFlow Federated hervorgegangen ist. Der vierte Baustein schließlich ist die Fehlertoleranz: Am Ende jeder Trainingsrunde speichert das Programm einen KMS-verschlüsselten Wiederherstellungszustand, mit dem sich Ausfälle von Root- oder Worker-TEEs überbrücken lassen, ohne zusätzliche privatheitsrelevante Informationen preiszugeben.

Verifizierbarer Datenschutz durch Transparenz-Log, reproduzierbare Builds und Sideloading

In älteren Systemen wurden Gerätedaten zum Zweck der unmittelbaren Aggregation hochgeladen, doch externe Beobachter konnten nicht prüfen, dass diese Daten nie protokolliert oder eingesehen wurden. Später schützte Secure Aggregation die Uploads kryptografisch, war aber nicht mit modernen zentralen Garantien differenzieller Privatsphäre vereinbar. Die neue Architektur ist nach Darstellung der Autoren ein weiterer Schritt auf dem Weg, das Vertrauen in den Serverbetreiber vollständig überflüssig zu machen. Sichtbar bleiben für die Betreiber der Arbeitslasten nur Metriken und differenziell private Modellgewichte. Verschlüsselte Trainingsdaten von Geräten lassen sich ausschließlich innerhalb von TEEs entschlüsseln und verarbeiten, die den in der Richtlinie hinterlegten Python-Programmen entsprechen, und das nur für eine begrenzte Zeit nach dem Upload.

Die Zugriffsrichtlinien werden in Rekor veröffentlicht, einem öffentlichen Transparenz-Log, in dem externe Auditoren nachvollziehen können, welche serverseitigen Arbeitslasten ein Gerät potenziell unterstützt. Die Binärdateien von Schlüsselverwaltung und Datenverarbeitung lassen sich reproduzierbar aus offengelegtem Quellcode bauen, der im Repository Confidential Federated Compute auf GitHub liegt. Ein Detail verdient Aufmerksamkeit: Die TEEs unterstützen dynamisches Sideloading, mit dem zur Laufzeit serialisierte Informationen in das Python-Programm geladen werden. Proprietäre Modellarchitekturen und Vorverarbeitungslogik bleiben dadurch geschützt, während die privatheitsrelevante Logik fest im auditierten Programm verankert ist. Die Garantie hängt also daran, dass diese Trennung sauber eingehalten wird – ein Punkt, an dem Auditoren künftig genau hinschauen sollten.

Was Gboard konkret gewinnt: weniger Tagesrhythmus, deutlich kürzere Trainingsläufe

Gboard hat das TEE-basierte System bereits produktiv eingesetzt, um englische und japanische Modelle für die Wortvorhersage zu starten – mit stärkeren Datenschutzgarantien und besserer Genauigkeit. Die Autoren führen das auf mehrere Eigenschaften des neuen Designs zurück. Weil alle Geräte-Uploads gesammelt werden, bevor die serverseitige Trainingslast startet, müssen sie keine Rücksicht mehr auf tageszeitliche Schwankungen der Geräteverfügbarkeit nehmen. Der optimale Beteiligungsplan der Geräte lässt sich zur Ausführungszeit dynamisch berechnen und dazu nutzen, weitere Parameter der differenziellen Privatsphäre abzustimmen.

Der zweite Gewinn ist die Geschwindigkeit. Früher dauerten solche Trainingsläufe ein bis zwei Monate, begrenzt durch Geräteverfügbarkeit, Rechenleistung auf den Geräten und den Wettbewerb mehrerer Trainingslasten um dieselben Ressourcen. Im neuen System hat sich der Engpass auf die Serverseite verschoben, wo die Parallelisierung über viele Maschinen erheblich beschleunigt; begrenzend wirkt derzeit nur die Verfügbarkeit von TEE-Ressourcen. Für dich als Leser bedeutet das weniger eine technische Fußnote als eine Verschiebung der Machbarkeitsgrenze: Was vorher aus Praktikabilität klein bleiben musste, lässt sich nun größer denken. Ganz ohne Preis ist das nicht, denn die Rechenarbeit wandert vom Gerät in Rechenzentren, und die brauchen Strom und Hardware.

Wo die Grenzen liegen und was als Nächstes ansteht

Die Autoren benennen die Schwächen offen. TEEs bieten Schutz auf Basis aktueller Hardware, und Seitenkanalbeobachtungen bleiben ein Forschungsfeld, gegen das dynamisch geladene Arbeitslasten bislang weniger gut geschützt sind als fest eingebauter Code. Man erwartet, dass künftige TEE-Generationen hier tieferen Schutz bieten. Zudem verschiebt das neue System die Berechnung der Client-Gradienten auf den Server, wodurch Beschränkungen der Rechenleistung auf Endgeräten entfallen – der Weg zu größeren Modellen mit föderierten Verfahren wird damit frei. Die Integration von TEEs mit Beschleunigern spielt für solche Fälle eine zentrale Rolle.

Die Infrastruktur ist nicht auf föderiertes Lernen beschränkt, sondern führt beliebige in Python ausdrückbare Arbeitslasten verifizierbar aus. Das Team experimentiert unter anderem mit der Erzeugung synthetischer Daten und mit der Kombination von TEEs für allgemeine Datenverarbeitung und solchen, die auf Aufgaben wie LLM-Inferenz spezialisiert sind. Als Fernziel nennt der Beitrag vollständige Korrektheitsbeweise für die Softwareimplementierungen der DP-Algorithmen und Systemkomponenten. Konkret heißt das für die Praxis: Der Datenschutz bei föderiertem Lernen wird nicht dadurch besser, dass man es föderiert nennt, sondern dadurch, dass Geräte eine überprüfbare Positivliste erlaubter Berechnungen durchsetzen, dass Auditoren diese Listen einsehen können und dass der Code reproduzierbar aus offenen Quellen gebaut wird. Solange Seitenkanäle und proprietär nachgeladene Logik Restrisiken bleiben, ist das ein Fortschritt mit klaren Kanten – und so sollte man ihn auch lesen.

Quelle: research.google

„The 2026-07-28 revision of the Model Context Protocol took out the two things most servers were built around: the initialize handshake and the session.“ So beginnt ein Praxisbericht der Redaktion von ImportStatic über die aktuelle Fassung des Model Context Protocol, die im Juli als größtes Update des Protokolls angekündigt wurde. Wer in den vergangenen zwei Jahren einen MCP-Server gebaut hat, baute um zwei Dinge herum: den initialize-Handshake am Anfang und eine Session-ID, die an jeder weiteren Anfrage hing. Die Revision vom 28. Juli 2026 streicht beides. Übrig bleibt eine Spezifikation, in der jede HTTP-Anfrage alles mitbringen muss, was zu ihrer Beantwortung nötig ist.

Ein Amtsschalter, an dem niemand dich kennt, kommt der Sache näher. Früher bekamst du eine Vorgangsnummer, und jeder spätere Besuch klappte nur, wenn du an den Schalter zurückkamst, an dem deine Akte lag. Jetzt legst du bei jedem Besuch den vollständigen Vorgang auf die Theke, und es ist gleichgültig, wer Dienst hat. Daraus folgt fast jede Änderung für Server. Der Bericht ist mit Go 1.27.1 und go-sdk v1.8.0 entstanden, die Beispiele stammen aus zwei lokalen Handlern. ImportStatic entwirft seine Artikel nach eigener Angabe mit KI-Unterstützung, prüft sie gegen die Primärquellen und führt jedes Codebeispiel vor der Veröffentlichung aus.

Zustandsloses MCP: jede Anfrage trägt ihren eigenen Kontext

Bis zur Protokollversion 2025-11-25 begann jede Verbindung mit einem Handshake. Der Server antwortete auf ein initialize-POST mit Version, Fähigkeiten und einer Session-ID. Der Client schickte danach ein notifications/initialized hinterher und hängte die Session-ID an jede weitere Anfrage. Folge: Jede dieser Anfragen musste eine Instanz erreichen, die die Sitzung kannte. Das erzwang Sticky Sessions oder einen geteilten Sitzungsspeicher.

Die Revision 2026-07-28 entfernt den Handshake und die Session-ID. Protokollversion, Client-Identität und Client-Fähigkeiten reisen stattdessen in einem _meta-Block, den jede Anfrage mitführt. Die erste HTTP-Anfrage eines Clients darf damit direkt ein tools/call sein, und jede Instanz hinter einem Load Balancer kann sie beantworten. Für Serverautoren zerfällt die Arbeit in drei Teile: nicht mehr auf eine Sitzung bauen, die neuen Pflichtfelder senden, und jedes Tool umschreiben, das den Client mitten im Aufruf etwas fragt.

Auf dem Rückweg sind zwei Felder neu. Der Server identifiziert sich in _meta jedes einzelnen Ergebnisses, weil es keinen Handshake mehr gibt, in dem er das tun könnte. Und jedes Ergebnis trägt ein Pflichtfeld resultType, das im Normalfall complete lautet. Der zweite mögliche Wert kommt weiter unten vor, wenn ein Tool nachfragen muss.

MCP ohne Session: was nicht mehr in einer Sitzung liegen darf

Ob dein Server betroffen ist, entscheidet eine Frage: Was liegt bei mir zwischen zwei Aufrufen im Speicher? Ein Warenkorb, ein Dateihandle, ein Fortschrittszähler, ein angemeldeter Nutzer — all das hatte bisher seinen Platz in der Sitzung. Der fällt weg, damit auch die Annahme, dass der nächste Aufruf auf demselben Prozess landet. Die Spezifikation antwortet knapp: Solche Zustände werden zu expliziten Handles, die der Server ausstellt und die als Tool-Argumente durch den Dialog wandern.

Eine cart_id, die ein Tool zurückgibt und das nächste als Parameter verlangt, funktioniert auf jeder Instanz. Sie ist außerdem für das Modell sichtbar und damit Teil des Kontexts. Für alles, was nur für die Dauer eines Aufrufs gebraucht wird, gibt es den zweiten Ablageort requestState, dazu später mehr bei den Rückfragen. Wer Bestandsaufnahme machen will, fängt beim Code an, der heute Dinge in eine Session schreibt, nicht beim Protokollcode.

Mcp-Method und Mcp-Name: Header, die gegen den Body geprüft werden

Die Anfrage wiederholt Methode und Namen des Ziels in den HTTP-Headern Mcp-Method und Mcp-Name. Die Streamable-HTTP-Seite der Spezifikation macht sie verpflichtend, damit Gateways und Rate Limiter auf Basis der Header routen können, ohne den JSON-Body zu parsen. Wichtiger ist die zweite Regel: Der Server muss eine Anfrage ablehnen, bei der Header und Body sich widersprechen. Sonst könnte ein Proxy ein harmloses Tool autorisieren, während der Server ein anderes ausführt.

In den Tests von ImportStatic erzwingt das Go SDK diese Prüfung. Ein Request mit Mcp-Name: deploy und einem Body, der add aufruft, wurde mit dem Fehler -32020 abgewiesen, ein Request ohne Mcp-Method ebenso. Wer einen handgeschriebenen Client pflegt, sollte das zuerst nachrüsten: Eine Anfrage nach 2026-07-28 wird ohne diese Header abgelehnt, so korrekt ihr Body auch sein mag. Mcp-Name ist für tools/call, resources/read und prompts/get verpflichtend und trägt den Wert von params.name beziehungsweise params.uri.

Dieselbe Seite der Spezifikation streicht den eigenständigen GET-Stream und die fortsetzbaren Streams. Ein GET auf den stateless Handler im Test antwortete mit 405 Method Not Allowed. Eine abgerissene Antwortverbindung bedeutet jetzt, dass die laufende Anfrage verloren ist und der Client sie mit einer neuen Request-ID erneut senden muss. Änderungsbenachrichtigungen, die früher über den GET-Stream eintrafen, kommen nun als Antwort auf eine subscriptions/listen-Anfrage, die der Client öffnet, wenn er sie braucht.

Versionfehler -32022, server/discover und die neuen Cache-Felder

Es gibt keinen Aushandlungs-Handshake mehr. Jede Anfrage trägt ihre Protokollversion, und der Server akzeptiert oder verwirft sie einzeln. Ein Server, der die gewünschte Version nicht implementiert, antwortet mit dem Fehler -32022 und der Liste der unterstützten Versionen. Ein Client, der das vorab wissen will, ruft server/discover auf; für Server ist der Aufruf Pflicht, für Clients optional.

Neu und verpflichtend sind ttlMs und cacheScope in den Ergebnissen von tools/list, prompts/list, resources/list, resources/templates/list und resources/read. Sie sagen dem Client, wie lange er die Antwort wiederverwenden darf und ob ein gemeinsamer Zwischenspeicher das ebenfalls darf. Der Standardwert des SDK ist 0, also sofort veraltet; ein Client zieht daraus keinen Nutzen. Die Paketdokumentation beschreibt einen SetCacheable-Hook in den ServerOptions, über den sich echte Werte setzen lassen. Eine Toolliste, die sich nur bei einem Deployment ändert, verträgt eine lange TTL. Außerdem verlangt der Changelog, Tools in einer festen Reihenfolge auszuliefern, damit Clients und die Prompt-Caches der Sprachmodelle die Liste wiederverwenden können.

MCP Server auf stateless umstellen: eine Option und der Preis für alte Clients

Im Go-SDK hängt alles an einer Option. Wer der MCP-Server-Anleitung von ImportStatic gefolgt ist, hat seinen HTTP-Handler mit nil-Optionen erzeugt, und ein solcher Handler hält weiterhin Sitzungen. In v1.8.0 spricht ein sitzungshaltender Handler kein 2026-07-28: Ein moderner tools/call-Aufruf kam als Fehler zurück. SDK-Clients bemerken das kaum, weil sie auf den Handshake zurückfallen, aber man bleibt auf der alten Protokollversion stehen.

Entscheidend ist Stateless: true in den Streamable-HTTP-Optionen. Mit dieser Option handelte der SDK-Client 2026-07-28 aus, ohne sie 2025-11-25 — bei identischem Tool-Code. Der stateless Handler sperrt alte Clients nicht aus. Er beantwortete ein klassisches initialize weiterhin mit der Version 2025-11-25 und ohne Mcp-Session-Id, und er beantwortete auch ein 2025-11-25-tools/call, dem kein Handshake vorausging. Die Kompatibilitätsmatrix der Spezifikation ist bei der Alternative eindeutig: Ein alter Client gegen einen rein modernen Server scheitert, und alte Clients haben keine Möglichkeit, sich nach vorn zu hangeln.

input_required, signierter requestState und die Reihenfolge der Umstellung

Der unangenehmste Teil betrifft Tools, die den Client mitten im Aufruf etwas fragen. Elicitation, Sampling und Roots waren Anfragen des Servers an den Client, während ein Tool-Aufruf offen war. Das setzt einen offen gehaltenen Stream und eine Instanz voraus, die den Aufruf erinnert — beides gibt es nicht mehr. Mehrfach-Roundtrips drehen die Richtung um: Der Server beendet den Aufruf mit einem Ergebnis, das mitteilt, was er braucht, und der Client wiederholt den Aufruf mit den Antworten. Erlaubt ist das nur für tools/call, prompts/get und resources/read.

Konkret liefert der Handler beim ersten Aufruf InputRequests, das Ergebnis trägt resultType: input_required und eine Map mit den offenen Punkten. Der zweite Aufruf ist ein neues tools/call mit neuer ID, denselben Argumenten und zwei zusätzlichen Parametern: inputResponses und, falls der Server welchen mitgeschickt hat, der undurchsichtige requestState. Dort liegt das Gedächtnis des Servers, und weil es über den Client zurückkommt, gilt es laut Spezifikation als angreiferkontrolliert. Beeinflusst es Autorisierung oder Geschäftslogik, muss es integritätsgeschützt sein; empfohlen sind eine Bindung an den Aufrufer, eine kurze Gültigkeit und die Herkunftsanfrage. Das Beispiel signiert mit HMAC-SHA256 über Tool, Dienstnamen und Ablaufzeit, mit einem Schlüssel, den alle Instanzen teilen. Als die Redaktion den State des billing-Aufrufs in einen payments-Aufruf schob, antwortete der Server mit -32602 invalid requestState. Und weil all das den State nicht einmalig macht, braucht eine echte Einmalaktion weiterhin eine serverseitige Prüfung.

Den Retry-Loop muss niemand selbst im Client bauen. Der SDK-Client erledigte beide Roundtrips in einem einzigen CallTool und rief dazwischen den ElicitationHandler auf. In v1.8.0 bricht die Schleife nach zehn Runden ab, und MultiRoundTripOptions.Disabled schaltet sie ab, wenn man die Wiederholungen selbst fahren will. Der Haken liegt bei alten Clients auf dem stateless Handler: Ein auf 2025-11-25 festgelegter Client bekam die Meldung, der Client unterstütze kein Elicitation. Der Grund steht in der SDK-Dokumentation — ein stateless Handler benutzt pro Anfrage eine temporäre Sitzung mit Standard-Initialisierungsparametern, die Fähigkeiten aus dem initialize des alten Clients sind beim Ausführen des Tools also längst verschwunden. Schlichte Tools funktionieren für solche Clients weiter, Tools mit Rückfrage nicht.

Für die Umstellung ergibt sich daraus eine Reihenfolge. Zuerst suchst du alles, was dein Server zwischen zwei Aufrufen hält, und verschiebst es in explizite Handles als Tool-Argumente oder, für die Dauer eines Aufrufs, in requestState. Danach schreibst du die Tools um, die Elicitation, Sampling oder Roots mitten im Aufruf verwenden, und signierst jeden State, den du hinausgibst. Dann hebst du das SDK an und aktivierst den stateless Handler, in Go mit go-sdk ab v1.7.0 und Stateless: true. Falls alte Clients noch eine Rolle spielen und deine Tools von ihnen Eingaben brauchen, bleibt ein sitzungshaltender Endpunkt neben dem stateless einen bestehen, bis sie nachgezogen sind. In handgeschriebenen Clients kommen _meta, MCP-Protocol-Version, Mcp-Method und Mcp-Name dazu, ein fehlendes resultType von einem älteren Server wird als complete behandelt, und ein -32022 wird mit einer Version aus supported wiederholt. Zwei Kleinigkeiten am Rande: Ein nicht gefundenes Resource meldet jetzt -32602 statt -32002, und eine unbekannte Methode über HTTP ist ein 404 mit JSON-RPC-Body und -32601.

Zum Schluss die Deprecations. Roots, Sampling und Logging funktionieren weiter, und die Lebenszyklus-Politik dieser Revision garantiert abgekündigten Merkmalen mindestens zwölf Monate. Neue Implementierungen sollen sie laut Changelog trotzdem nicht mehr einbauen. Vorgeschlagen sind Tool-Parameter oder Resource-URIs statt Roots, ein direkter Aufruf des eigenen LLM-Anbieters statt Sampling und stderr oder OpenTelemetry statt Protokoll-Logging. ping und logging/setLevel sind dagegen ersatzlos entfernt, ein Keepalive auf Basis von ping muss beim Wechsel weichen. Überall gilt dasselbe Muster: Zustand und Nebenwirkungen verlassen den verborgenen Kanal und werden zu sichtbaren, prüfbaren Teilen des Aufrufs. Wer seinen MCP-Server auf stateless umstellen will, sollte das nicht als Protokollwechsel lesen, sondern als Frage, wo seine Daten künftig liegen — beim Client, im Aufruf oder in einem signierten Handle.

Quelle: importstatic.com

„APIs sind die natürliche Brücke, die agentische KI überhaupt erst handlungsfähig macht.“ So beschreibt Bill Doerrfeld in einem Beitrag für CIO die Rolle der Schnittstellen. Der Satz klingt einleuchtend. Für gewachsene Schnittstellenlandschaften ist er trotzdem ein Problem – denn die meisten wurden für Menschen entworfen, nicht für Software, die Ziele interpretiert und im Sekundentakt Entscheidungen trifft.

Die Zahlen aus Postmans State-of-the-API-Report stützen diese Spannung. 89 Prozent der Befragten nutzen generative KI-Werkzeuge im Arbeitsalltag. 60 Prozent entwerfen ihre API-Produkte aber weiterhin ausschließlich für menschliche Nutzung. Gleichzeitig äußern 50 Prozent Sorge über unautorisierte oder übermäßige API-Aufrufe, über Zugriff auf sensible Daten und über geleakte Credentials.

Am besten lässt sich das mit einem Straßennetz vergleichen. Wenn du heute eine API planst, baust du im Grunde eine Straße mit Fahrspuren, Schildern und Ampeln. Diese Infrastruktur wurde für Wesen entworfen, die Kontext verstehen: Sie lesen ein Schild und wissen, warum es dort steht. Agenten lesen dasselbe Schild und befolgen es, ohne den Grund zu kennen. Oder sie ignorieren es, wenn die Karte eine Abkürzung kennt. Genau diese Verschiebung spielt sich gerade in der API-Architektur ab.

Warum Agenten ein grundlegend anderer Konsumententyp sind

Der Übergang von der Chatbot-Ära zur agentischen Ära ist noch jung. Für aktive Nutzer von KI-Werkzeugen begann er spürbar erst in den letzten ein bis zwei Jahren, mit Systemen wie OpenAI Operator, Codex oder Cowork. Der Unterschied ist nicht graduell: Ein Chatbot antwortet, ein Agent handelt. Er interpretiert ein Ziel, sucht sich Werkzeuge, trifft Entscheidungen und verkettet Aufrufe zu Abläufen, die für menschliche Beobachter oft schwer nachvollziehbar sind.

Damit wird Software zu einem Konsumenten, der nicht mehr nur analysiert und empfiehlt, sondern ausführt. Über API-Integrationen koordiniert er Aktionen über mehrere Systeme hinweg und baut Workflows, die niemand explizit so programmiert hat. Art Anthony, der den zugrunde liegenden Beitrag für Nordic APIs geschrieben hat, formuliert es als unangenehme Wahrheit: Die meisten API-Ökosysteme wurden für menschliche Nutzer gebaut, nicht für autonome Agenten, die in hoher Frequenz arbeiten.

Ein Forschungspapier der When2Tool-Macher liefert dazu einen konkreten Hinweis. Die Autoren konnten die Zahl der API-Aufrufe agentischer Werkzeuge um 20 bis 56 Prozent senken, ohne dass die Genauigkeit litt. Das legt nahe, dass Agenten APIs eher zu viel als zu wenig aufrufen. Bei kostenpflichtigen Schnittstellen ist das keine theoretische Frage, sondern eine Rechnung. Anthony zieht dafür den Vergleich zu Indiana Jones auf der Suche nach dem echten Gral: Agenten müssen lernen, klug zu wählen.

Identität und Autorisierung: Agenten passen in kein klassisches Rollenmodell

Die zentrale Schwierigkeit liegt in der Identität. Ein Agent handelt selten für sich selbst, sondern für einen Menschen, eine Organisation oder ein anderes Stück Software. Wer also handelt eigentlich, wenn ein Aufruf eintrifft? Die traditionellen Modelle, die auf Personen und Rollen aufbauen, greifen hier zu kurz – eine Lücke, an der sich bereits eigene Start-ups wie Oak versuchen. Wer es sich einfach macht, gibt dem Agenten ein langlebiges Token mit weitreichenden Rechten. Wer es richtig macht, tut genau das nicht.

Übermäßige Privilegien führen zu unbeabsichtigten Aktionen. Schlimmer noch: Berechtigungen sammeln sich still an, alte werden selten entfernt. So entsteht, was in der Branche als Role Drift und Privilege Creep bekannt ist. Aktionen, die im Nachhinein unrechtmäßig wirken und ernste Zwischenfälle auslösen, liegen dann formal im Rahmen dessen, was der Agent durfte. Es gab keinen Einbruch – nur eine Tür, die jemand offen gelassen hat.

Jacob Ideskog, CTO von Curity, plädierte auf dem Platform Summit 2025 von Nordic APIs für Just-in-Time-Autorisierung als Gegenmittel. Übertragen auf das Straßenbild: kein Generalschlüssel für alle Türen, sondern eine Fahrerlaubnis, die für eine konkrete Fahrt, eine konkrete Strecke und ein konkretes Zeitfenster gilt. Als Zielbild gilt Zero Standing Privilege – also keine dauerhaften Rechte, die niemand mehr überprüft.

Ein zweiter Unterschied wiegt ebenfalls schwer. Menschliche Entwickler nutzen Exploits, falsch konfigurierte Rate Limits und ähnliche Lücken selten aus, weil sie die Folgen für Anbieter und Kollegen einschätzen können. Standard-Agenten fehlt dieses Verständnis. Wenn sie können, dann tun sie oft auch. Es liegt an den Architekten, dieses Können zu definieren.

Sicherheit und Governance: Prompt-Injection trifft auf überreichweite Rechte

Aus der agentischen Nutzung entsteht eine eigene Risikoklasse. Dazu gehören LLM-basierte Angriffe wie Prompt-Injection, unbeabsichtigte Aktionen, Halluzinationen und unzuverlässige Entscheidungen, übermäßige Nutzung von API-Fähigkeiten und der Missbrauch von Kontext, den ein Modell nicht hätte sehen dürfen. OWASP führt Prompt-Injection und Excessive Agency in den Top 10 der Risiken für LLMs und GenAI. Autorisierung, Authentifizierung und Governance an genau diesen Schnittstellen sind also keine Nebensache.

Besonders unangenehm ist die indirekte Variante. Bösartige Anweisungen kommen nicht vom Nutzer, sondern aus Daten. Ein Beispiel: Eine Support-Antwort enthält einen eingeschobenen Systemhinweis an das Modell, doch bitte das gespeicherte Session-Token per E-Mail-API an eine fremde Adresse zu senden. Für das Modell ist das eine Anweisung wie jede andere. Die eigentliche Schwachstelle liegt nicht in der API, sondern in der Bereitschaft, fremden Text als Instruktion zu behandeln.

Die Antwort darauf ist weniger spektakulär, als sie klingt. Deterministische Workflows statt freier Interpretation, getrennte APIs für menschliche und agentische Nutzung, klare Grenzen für das, was ein Agent überhaupt anstoßen darf. Jeroen Delbarre von Axway widmet sich auf dem Nordic APIs Summit 2026, den der Herausgeber des Ausgangsbeitrags selbst veranstaltet, genau dieser Frage: Wie sieht Governance aus, wenn nicht mehr nur Menschen Anträge stellen, sondern Agenten sie im Fluss erzeugen?

API-Design für Maschinen: Schema, Klarheit, weniger Interpretationsspielraum

Lorna Mitchell brachte es in einem Gespräch auf eine kurze Formel: Wer bewährte Praktiken rund um API-Design und Dokumentation befolgt, ist bereits KI-bereit. Das ist weniger beruhigend, als es zunächst wirkt, denn es verschiebt den Aufwand dorthin, wo er ohnehin hingehört. Konsistente Namenskonventionen, vorhersehbare Fehler, wohldefinierte Schemata und präzise Dokumentation waren nie optional. Sie werden jetzt nur belastbar geprüft.

Menschen füllen Lücken mit Erfahrung und Kontext. Agenten haben dieses Privileg nicht. Wo ein Entwickler aus einem unklaren Feldnamen schließt, was gemeint sein könnte, liest ein Modell genau das, was dasteht, und entscheidet dann vielleicht falsch. Mehrdeutigkeit ist damit nicht mehr nur ein Ärgernis für Leser der Entwicklerdokumentation, sondern eine Fehlerquelle mit direkten Folgen.

In der Praxis bedeutet das schlankere Rechtevergabe für Agenten, stärker spezifikationsgetriebene Entwicklung, maschinenlesbare Dokumentation und weniger Grauzonen im Verhalten. Hinzu kommt eine oft übersehene Ebene: Die Infrastruktur um die API muss sich mitverändern, nicht nur die API selbst. Wer heute Schnittstellen plant, plant also nicht nur für einen Konsumenten, sondern für zwei sehr unterschiedliche.

Observability: nicht nur was passierte, sondern wer in wessen Auftrag handelte

Klassisches API-Monitoring beantwortet die Frage, ob etwas langsam war, ausgefallen ist oder Fehler geworfen hat. Bei agentischer Nutzung reicht das nicht. Die entscheidende Information lautet jetzt: Welcher Agent hat die Anfrage gestellt, in wessen Auftrag, und war sie Teil einer Kette von Aufrufen? Ohne diese Einordnung bleibt jedes Logfile eine Liste von Ereignissen ohne Verantwortlichen.

Agenten-Stacks liefern die passenden Daten, wenn man sie abfragt. Erweiterungen von OpenTelemetry greifen diese veränderten Konsummuster auf: Agent-Identifikatoren, Conversation IDs, Angaben zur Token-Nutzung. Im Bild des Straßenverkehrs ist das kein Radargerät, sondern ein Nummernschild samt Fahrtenbuch. Du weißt nicht nur, dass ein Fahrzeug zu schnell war, sondern auch, wer es geschickt hat und wohin die Fahrt ging. Andere Frameworks und Werkzeuge werden mit hoher Wahrscheinlichkeit nachziehen.

Der Aufwand dafür ist real, aber begrenzt. Es geht nicht darum, bestehende Monitoring-Pipelines zu ersetzen, sondern sie um Identitäts- und Auftragskontext zu erweitern. Wer diese Erweiterung früh einplant, spart sich später die mühsame Rekonstruktion von Vorfällen, bei denen niemand sagen kann, welcher Agent eigentlich gehandelt hat.

Was das für bestehende API-Landschaften konkret bedeutet

Die gute Nachricht am Ende des Beitrags wird gern überlesen: Es ist nicht nötig, alles über API-Architektur über Bord zu werfen und neu anzufangen. Die wachsende agentische Nutzung verlangt Anpassungen, nicht Abriss. Zu einer Sammlung, die über Jahre gereift ist, kommen einige neue Regeln. Das ist deutlich weniger dramatisch als das Wort Zeitenwende, aber deutlich mehr als ein Update.

Konkret heißt das für die Praxis: Berechtigungen kürzen und nicht dauerhaft vergeben, Identität für Agenten einführen, statt sie als anonyme Aufrufe zu behandeln, Dokumentation so schreiben, dass sie maschinenlesbar ist, und Beobachtbarkeit um die Frage erweitern, wer in wessen Auftrag gehandelt hat. Wer diese vier Punkte ernst nimmt, deckt den größten Teil der neuen Angriffsfläche ab, ohne seine bestehende Architektur zu verwerfen.

Der Rest ist eine Frage der Reihenfolge. Identität und Autorisierung sind der Engpass, an dem alles andere hängt: Ohne verlässliche Angaben darüber, wer oder was da ruft, hilft auch die beste Governance nicht. Danach folgen Design und Observability, weil beide auf sauberen Schemata und klaren Berechtigungen aufbauen. Wer das in dieser Reihenfolge angeht, baut kein neues Straßennetz – sondern sorgt dafür, dass die vorhandenen Straßen auch von Fahrzeugen benutzt werden können, die keine Schilder lesen, sondern nur Karten.

Quelle: nordicapis.com

Roboter können heute drei Viertel der physischen Arbeitsaufgaben in den USA erledigen, überwiegend aber nur in begrenzten Umgebungen. Mit diesem Befund beginnt eine Untersuchung des KI-Unternehmens Anthropic, die den Einfluss von Robotik auf den Arbeitsmarkt messen will. Der Satz klingt nach Umbruch, und ein Stück weit ist er das auch. Nur sitzt dieser Umbruch nicht dort, wo man ihn auf den ersten Blick vermutet.

Die Analyse bewertet rund 19.000 Arbeitsaufgaben aus etwa 900 Berufen danach, ob ein Roboter sie heute erledigen kann. Als Werkzeug diente Anthropics eigenes Sprachmodell Claude, das für jede Aufgabe per Websuche nach konkreten Maschinen sucht und zu jeder Einstufung einen Beleg nennt. Die Bewertungen stammen also von einem Modell des Herausgebers, nicht von unabhängigen Gutachtern. Herausgekommen ist ein Roboter-Expositionsindex: keine Prognose, sondern eine Bestandsaufnahme dessen, was bereits läuft.

Wie der Roboter-Expositionsindex Arbeit messbar macht

Die Datengrundlage bildet ONET, eine öffentlich gepflegte Sammlung von Berufsbeschreibungen, die hier in rund 19.000 einzelne Arbeitsaufgaben zerlegt wird. Nicht jede davon ist körperliche Arbeit. Wer am Bildschirm Summen auf einem Formular prüft, benutzt zwar die Hände, verrichtet aber keine physische Tätigkeit im Sinne der Studie. Übrig bleiben etwa 7.600 Aufgaben, bei denen tatsächlich etwas in der Welt bewegt, gehalten, geformt oder transportiert wird.

Für jede dieser Aufgaben stellt der Index dieselbe Frage: Kann ein Roboter sie heute erledigen, und wenn ja, unter welchen Bedingungen? Als Roboter gelten dabei autonome physische Maschinen, die ihre Umgebung wahrnehmen und auf sie einwirken. Eine vollständig vom Chirurgen gesteuerte Operationsmaschine fällt nicht darunter, eine Waschanlage, die Fahrzeuge scannt und die Düsen nachjustiert, schon. Die Definition ist streng. Deshalb fallen die Ergebnisse nüchterner aus als die Schlagzeile.

Die Studie geht vorsichtig mit Unsicherheit um. Ein Roboter zählt nur dann als fähig, wenn sich Einsatz, Verkauf oder eine belastbare Demonstration belegen lässt. Weil kurze Aufgabenbeschreibungen viel verbergen, erzeugt die Methode zu jeder Tätigkeit konkrete Beispiele und gewichtet sie nach Häufigkeit. Erst danach fällt die Einstufung, nach Mehrheitsregel. Der Aufwand ist groß. Er verhindert den üblichen Fehler, aus einer einzelnen gelungenen Vorführung gleich einen ganzen Beruf abzuleiten.

Vier Stufen: Warum die Umgebung über den Einsatz entscheidet

Der Kern der Untersuchung liegt nicht in der Frage, ob ein Roboter etwas kann, sondern wo er es kann. Ein Roboter ist kein Universalhandwerker, sondern ein Spezialist, der eine präparierte Bühne braucht: feste Positionen, wiederkehrende Abläufe, berechenbares Licht. Diese Bühne ist der Maßstab. Daraus entstehen vier Stufen.

E0 heißt: Kein heutiger Roboter schafft die Aufgabe. E1 bedeutet, dass sie in einer eigens gebauten Roboterumgebung gelingt, etwa an einem Fließband. Auf Stufe E2 arbeitet die Maschine in einer strukturierten menschlichen Arbeitsstätte wie einem Logistikzentrum oder einem Klinikflur. E3 schließlich steht für die unstrukturierte Welt, für Stadtstraßen, Baustellen und alles, was sich nicht vorher planen lässt.

Die Staffelung erklärt, warum spektakuläre Roboterdemos so wenig über den Arbeitsalltag verraten: Die Vorführung findet fast immer auf einer Bühne statt, die eigens für sie errichtet wurde. Je ungeordneter die Umgebung, desto schlechter schneiden die Maschinen ab. Und gemessen daran sind die meisten Arbeitsplätze erstaunlich ungeordnet.

Welche Arbeit Roboter heute erledigen können – und welche nicht

Das Ergebnis der Bewertung: Roboter können heute 74 Prozent der physischen Arbeit in den USA erledigen, zumindest unter bestimmten Bedingungen. Gewichtet ist dabei durchgehend nach Arbeitszeit und Zahl der Beschäftigten. Bezogen auf alle Arbeit, also einschließlich kognitiver und zwischenmenschlicher Tätigkeiten, entspricht das 34 Prozent der Arbeitsstunden. Die beiden Zahlen widersprechen sich nicht: Physische Aufgaben machen nur 46 Prozent der gesamten Arbeitszeit aus.

Etwa ein Viertel der physischen Arbeitszeit fällt in die Kategorie E0, ist also für heutige Roboter unerreichbar. Dazu gehört feinmotorische Arbeit wie das Färben oder Tönen von Haaren mit dem Pinsel, aber auch der Aufbau von Gerüsten, der Kraft, Gleichgewicht und Beweglichkeit verlangt. Rund die Hälfte der physischen Arbeitszeit liegt auf Stufe E1: in der eigens gebauten Umgebung machbar, darüber hinaus nicht. Weitere 22 Prozent erreichen E2, also strukturierte menschliche Arbeitsstätten; dort liefern Roboter in Kliniken Medikamente aus. Nur zwei Prozent entfallen auf E3, und das sind überwiegend Fahrtätigkeiten.

Das Muster dahinter: Fahren und Kommissionieren im Lager sind stark exponiert, weil sich diese Umgebungen kontrollieren lassen. Pflege und allgemeine Reparatur sind es kaum, weil dort ständig Unerwartetes passiert. Nicht der Beruf entscheidet über die Betroffenheit, sondern die Frage, wie vorhersagbar der Arbeitstag verläuft.

Roboter und LLMs im Beruf: zwei Techniken, zwei Arten von Arbeit

Setzt man Roboter und Sprachmodelle nebeneinander, decken sie zusammen etwa 80 Prozent der Arbeitsaufgaben ab, wiederum nach Arbeitszeit gerechnet. Das ist mehr, als jede der beiden Technologien allein erreicht. Sie ergänzen sich, statt zu konkurrieren: Roboter übernehmen die körperliche Seite, Sprachmodelle die sprachliche und kognitive.

Was übrig bleibt: Aufgaben, die stark zwischenmenschlich geprägt sind oder physische Fähigkeiten verlangen, über die heutige Maschinen nicht verfügen. Ein Gespräch mit einer verängstigten Patientin, ein Feingefühl in den Fingern beim Lösen verhedderter Kabel. Dafür gibt es derzeit keinen ernsthaften Ersatz.

Auch die Verteilung der Betroffenheit ist nicht neutral. Wer beruflich stärker Robotern ausgesetzt ist, ist statistisch häufiger männlich, geringer qualifiziert und schlechter bezahlt. Automatisierung trifft also nicht zufällig, sondern entlang bekannter Linien. Das ist kein Argument gegen die Technik, aber ein Hinweis darauf, wo Begleitung nötig wäre.

Kosten von Robotern gegenüber menschlicher Arbeit

Technische Machbarkeit ist das eine, Wirtschaftlichkeit das andere. Die Studie vergleicht, ob ein Roboter dieselbe Aufgabe billiger erledigt als ein Mensch. Das Ergebnis: Kostengünstig ist er heute für 0,3 Prozent der Arbeitsaufgaben. Machbar ist viel, bezahlbar ist wenig.

Hinzu kommt die Zeitachse. Wenn die Roboterpreise weiter so sinken wie in der Vergangenheit, dauert es vierzig Jahre, bis dieser Anteil zehn Prozent erreicht. Vierzig Jahre sind keine ferne Zukunft, aber auch kein nächster Montag. Wer heute Entscheidungen trifft, sollte diese Größenordnung im Kopf behalten.

Neben dem Preis bremsen zwei weitere Faktoren. Der erste ist die Fähigkeit selbst: Für viele Aufgaben fehlt schlicht die Geschicklichkeit. Der zweite sind Vorlieben und Regeln: Menschen wollen in manchen Bereichen nicht von Maschinen betreut werden, und Vorschriften setzen zusätzliche Grenzen. Arbeitsplatzautomation ist deshalb nie nur ein technisches Projekt.

Auswirkungen auf Löhne und Beschäftigung – und was daraus folgt

Die Autoren prüfen ihre Methode an der Vergangenheit. Über fünfzig Jahre hinweg, von 1977 bis heute, verzeichnen Berufe mit höherer Roboter-Exposition stärkere Rückgänge bei Löhnen und Beschäftigung als andere. Beweisen lässt sich damit kein Ursache-Wirkung-Zusammenhang. Das Muster ist trotzdem sichtbar. Zudem wächst die Exposition beständig: Jedes Jahr kommen rund zwei Prozent der physischen Arbeit hinzu, die Roboter zuvor nicht erledigen konnten.

Wenn die Vergangenheit ein Maßstab ist, dann trifft der Wandel Taxifahrer und Lagerpacker früher als Krankenschwestern und Mechaniker. Nicht, weil diese Berufe wichtiger oder unwichtiger wären, sondern weil sich ihre Arbeitsumgebung leichter kontrollieren lässt. Der Roboter am Arbeitsplatz ist damit weniger ein plötzlicher Einbruch als eine Verschiebung, die bereits im Gang ist.

Wer wissen will, wo die eigene Tätigkeit steht, kann sich eine einfache Frage stellen: Findet meine Arbeit in einer Halle oder auf einer Straße statt? Läuft sie nach einem Plan ab, oder muss ich mich ständig auf Unerwartetes einstellen? Je planbarer der Tag, desto näher ist die Maschine.

Quelle: anthropic.com

„Amazon hat Muse blockiert. Shopify tat das Gegenteil und eröffnete einen eigenen Zahlungskanal für Muse.“ Der Satz stammt von Jesse Zhang, CEO des Kundenservice-KI-Anbieters Decagon, aus einem Beitrag auf X, den das koreanische Portal DigitalToday aufgegriffen hat. Er beschreibt eine Verschiebung, die mehr ist als eine Designfrage: Sie betrifft die Grundlage, auf der Kunden mit Unternehmen in Kontakt kommen. Wer das verstehen will, muss sich einen Kunden ansehen, der das Schaufenster gar nicht mehr betrachtet. Er liest nur noch das Preisschild.

Ein Schaufenster funktioniert nur, solange jemand davor stehen bleibt und sich verführen lässt. Werbung, Reihenfolge, Farben, Dringlichkeit – all das zielt auf einen Blick, der verweilen kann. Ist die Gegenseite Software, fällt diese Ebene weg. Übrig bleibt eine Liste von Bedingungen. Darum geht es hier: nicht um ein neues Menü oder eine schönere Checkout-Seite, sondern um die Frage, was passiert, wenn der Kunde nicht mehr schaut, sondern verhandelt.

Warum der Bildschirm als Verkaufsfläche an Bedeutung verliert

Zhang bringt sein Argument auf einen Satz: „Wenn der Kunde ein Agent ist, ist die bestehende UX nur noch Ballast.“ Die Begründung ist nüchtern und kaum zu widerlegen. Agenten überspringen alles – Produktdarstellung, kaufauslösende Abläufe, Rabattlogiken, Kündigungen, die drei Bildschirme tief versteckt sind. Sie sehen sich keine Screens an, lesen keine Hinweistexte, klicken nicht auf „Nur heute“. Was jahrelang über Oberflächen durchgesetzt wurde, muss nun auf anderem Weg durchgesetzt werden.

Hier verstehen viele Unternehmen ihre eigene Architektur falsch. Ein großer Teil der heutigen User Experience ist keine Freundlichkeit gegenüber dem Kunden, sondern ein Ringen um Aufmerksamkeit. Zeitdruck, Voreinstellungen, komplizierte Kündigungswege – all das funktioniert nur gegen Menschen. Die Geschäftsregeln dahinter bleiben aber bestehen: Wer bekommt welchen Preis, wer darf umbuchen, wer darf stornieren. Mit dem Bildschirm verschwindet der Ort, an dem diese Regeln bisher umgesetzt wurden. Deshalb wird UX für KI-Agenten zu einer Disziplin, die viel mit Schnittstellen, Berechtigungen und klaren Datenmodellen zu tun hat – und wenig mit Layout.

Für dich heißt das: Die Frage ist nicht, ob deine Seite schön aussieht, wenn ein Agent sie aufruft. Die Frage ist, ob deine Regeln maschinenlesbar vorliegen. Steht eine Bedingung nur im Fließtext einer Hilfeseite, existiert sie für einen Agenten praktisch nicht.

Ein Roboter mit Geldbeutel als neues Kundensegment

Zhang beobachtet, dass persönliche Agenten wie Metas Muse – den Amazon vom Einkaufen aussperrt – oder Instinct stark zulegen, und nennt einen einfachen Grund: Sie erledigen tatsächlich Aufgaben. Bei Meta soll Muse Einkäufe direkt mit dem Geld der Nutzer abwickeln, abgesichert durch einen Käuferschutz von bis zu 1.000 Dollar pro Transaktion. Damit ist der Agent keine Empfehlungsmaschine mehr, sondern eine handelnde Partei mit Zahlungszugang. Zhangs Bild dafür: „Jeder Konsumartikel-Hersteller wird mit einem Kundensegment konfrontiert, das er nie eingeplant hat. Es ist ein Roboter mit einem Geldbeutel.“

Er vergleicht die Tragweite mit dem Wechsel von offline zu online und dann zu mobilen Apps. Man muss diesen Vergleich nicht feiern, um ihn ernst zu nehmen. Jeder dieser Sprünge schuf nicht nur neue Kanäle, sondern verschob die Regeln, nach denen gehandelt wird. Wer die mobile Bestellstrecke damals als kleines Extra behandelt hat, hat später teuer nachgerüstet. In dieser Situation stehen Unternehmen wieder – nur ist die Gegenseite diesmal kein Gerät, sondern ein Akteur mit eigenen Interessen.

Identität, Berechtigung und Verhandlungsgrenzen

Der interessanteste Teil von Zhangs Beitrag beginnt da, wo er von Technik zu Verantwortung wechselt. Die Zusammenarbeit mit Agenten, hält er fest, endet nicht mit einer API und einer Seite Dokumentation. Er nennt fünf Bereiche; der erste ist Identität und Vollmacht. Ein Unternehmen muss prüfen, ob ein Agent wirklich für den Kunden handelt, und den Umfang seiner Vollmacht definieren. Stöbern und Kaufen sind zwei verschiedene Dinge, und eine Nachbestellung für 40 Dollar unterscheidet sich deutlich von einer Buchung für 4.000 Dollar.

Der zweite Bereich sind Regeln und Verfahren. Ob eine Flugumbuchung, eine Neuausstellung der Karte oder ein Tarifwechsel zulässig ist, hängt vom Kundentyp ab, von gesetzlichen Vorgaben und internen Richtlinien. Solche Unterschiede lassen sich nicht in einer allgemeinen Antwort verstecken. Der dritte Bereich sind Verhandlungsgrenzen, und hier wird Zhang deutlich: „Wenn Sie nicht entscheiden können, wer wann einen Rabatt bekommt und wann Sie auf Prinzipien beharren, sichern Agenten jedes Mal die für das Unternehmen ungünstigsten Bedingungen.“ Die Begründung ist einfach und unbequem: Agenten werden nicht müde und nicht verlegen, und sie vergleichen Wettbewerbsangebote in Echtzeit.

Das Argument reicht über die Technik hinaus. Ein menschlicher Kunde akzeptiert einen Preis, weil der Vergleich zu aufwendig ist oder die Situation unangenehm wird. Ein Agent kennt diese Ermüdung nicht. Damit wird die Frage, welche Spielräume ein Unternehmen offenlässt, zur strategischen Entscheidung – nicht zum Verhandlungsgeschick einzelner Mitarbeiter.

Ausnahmen und Betrug im Maschinentempo

Als vierten Punkt nennt Zhang den Umgang mit Ausnahmen. Trifft eine Anfrage nach der Rückgabefrist ein, sollte ein Kunde seit sechs Jahren anders behandelt werden als jemand, der gestern dazugekommen ist. Solche Entscheidungen brauchen Urteilsvermögen und lassen sich nicht vollständig in Regeln pressen. Zhang folgert daraus, dass auch diese Arbeit Agenten übernehmen sollten – allerdings solche, die urteilen, statt nur Regeln abzuarbeiten.

Der fünfte Punkt ist der unbequemste und hat nichts mit Nutzerfreundlichkeit zu tun. Zhang weist darauf hin, dass Betrug im Maschinentempo stattfindet. Während ein legitimer Agent in 0,2 Sekunden Waren kauft, sucht ein bösartiger Agent zehntausend Mal pro Stunde nach Lücken in den Richtlinien. Eine Begrenzung der Anfragefrequenz allein hält das nach seiner Einschätzung nicht auf. Daran sieht man, wie eng KI-Agenten im Customer Experience mit Sicherheit, Missbrauchserkennung und Identitätsprüfung verwoben sind.

Der Endzustand: Maschine handelt mit Maschine

Am Ende steht ein Bild, das Zhang selbst zeichnet. Menschen legen fest, was sie wollen – etwa „kaufe zum niedrigsten Preis“ –, Unternehmen geben die Richtung vor: „schütze die Marge und halte treue Kunden“. Dazwischen handeln Systeme die Transaktion aus. Das Gespräch zwischen Konsument und Unternehmen führen dann nicht mehr auf beiden Seiten Menschen, sondern Software, die im Auftrag handelt. Die UX, wie wir sie kennen, wird in diesem Modell nicht besser oder schlechter. Für einen großen Teil der Vorgänge wird sie schlicht nicht mehr benutzt.

Daraus leitet Zhang eine Erwartung ab: Ein Unternehmen, das mit Kunden zu tun hat, muss künftig mit Menschen und mit KI-Assistenten umgehen können. Wer sich nicht anpasst, bleibt zurück, so seine Formulierung. Dazu eine Beobachtung, die oft übersehen wird: Fällt der Aufwand für ein einzelnes Gespräch gegen null, steigt die Zahl der Gespräche stark an. Daraus entsteht wirtschaftliches Potenzial, das bisher ungenutzt blieb, weil der Aufwand pro Kontakt zu hoch war.

Was das für Unternehmen konkret bedeutet

Man kann diese Prognose teilen oder für übertrieben halten. Die Beobachtungen dahinter sind jedenfalls nicht exotisch: Agenten mit Zahlungszugang existieren, ihre Zahl wächst, und die Frage, wer haftet, wenn ein Agent falsch handelt, ist in vielen Fällen offen. Der Käuferschutz von bis zu 1.000 Dollar pro Transaktion ist ein Signal, aber keine Antwort auf Haftungsfragen. In dieser Lücke liegt derzeit das größte Risiko für Unternehmen, die früh aufspringen, ohne ihre Regeln zu klären.

Praktisch heißt das: Fang mit drei Dingen an, die nichts kosten und viel Ordnung schaffen. Erstens: Prüfe, welche deiner Geschäftsregeln nur in Textform oder in der Oberfläche existieren, und schreibe sie so auf, dass ein System sie auswerten kann. Zweitens: Definiere getrennte Berechtigungsstufen für Suchen, Kaufen und Umbuchen, statt einen einzigen Zugang zu vergeben. Drittens: Lege fest, wo dein Unternehmen bewusst Grenzen zieht – damit nicht ein Agent die Bedingungen bestimmt, weil niemand sie vorher entschieden hat.

Der Bildschirm verschwindet nicht, aber er verliert seine Rolle als Ort, an dem Regeln durchgesetzt werden. Wer heute eine Website baut, plant für einen Menschen, der verweilen kann. Wer morgen plant, plant für einen Kunden, der in Millisekunden entscheidet und dabei nichts sieht. Zwischen diesen beiden Welten liegt keine Designfrage, sondern eine Frage der Ordnung im eigenen Haus.

Quelle: digitaltoday.co.kr