Kategorie: Erklärer

„Instead of relying on a separate, often larger, teacher, we leverage their self-critiques as privileged information.“ Dieser Satz steht im Abstract von UniEvo-VL, einem Paper, das Fang Wu mit 18 Mitautoren vorgelegt hat, unter anderem von der Stanford University und der Johns Hopkins University. Dahinter steckt eine Verschiebung: Nicht das größere Modell soll den Ton angeben, sondern die Kritik, die ein System an seiner eigenen Arbeit formuliert. Der Gedanke ist einfach – wenn ein Modell Bilder erzeugen und Bilder verstehen kann, kann es auch beurteilen, ob sein eigenes Ergebnis zur Aufgabe passt.

Hier setzt die Arbeit an. Moderne multimodale Modelle bringen Generierung und Verständnis in einem einzigen System zusammen, und nur deshalb können sie aus ihrem eigenen Feedback lernen. Viele Verfahren lernen aus korrigierten Zielbildern oder aus einer einzelnen Belohnungszahl. Das Team geht einen anderen Weg und nutzt die Selbstkritik als privilegierte Information, also als etwas, das dem Modell zur Trainingszeit zur Verfügung steht, zur Laufzeit aber nicht mehr gebraucht wird.

Ein Modell in zwei Rollen: Lehrer und Schüler mit unterschiedlichem Kontext

UniEvo-VL beschreibt ein selbstverbesserndes Framework, in dem dasselbe multimodale Modell zwei Aufgaben übernimmt. Der Schüler sieht nur die schlichte Frage, die sogenannte Vanilla-Frage, ohne jeden Zusatz. Der Lehrer sieht dieselbe Frage plus die Kritik am ersten Versuch. Beide sind derselbe Bildgenerator, der Lehrer ist eine langsam nachgeführte Kopie des Schülers (ein exponentieller gleitender Mittelwert der Gewichte). Allein der Kontext unterscheidet sie. Der Kern: Es braucht kein separat trainiertes, größeres Lehrermodell. Die Kritik selbst schreibt im Experiment allerdings ein eigenes Verständnismodell aus derselben Familie, Qwen-VL; trainiert wird nur der Generator, und zwar über schlanke LoRA-Parameter.

Man kann sich das wie eine Werkstatt mit zwei Räumen vorstellen. Im ersten Raum liegt das fertige Stück auf dem Tisch, ohne Kommentar. Im zweiten Raum liegt dasselbe Stück, daneben ein Korrekturzettel mit den Stellen, die nicht stimmen. In beiden Räumen steht dieselbe Person. Die Frage ist nicht, ob sie es besser kann – mit dem Zettel kann sie es offensichtlich besser. Die Frage ist, ob sie diese Fähigkeit auch ohne Zettel abruft. Genau das ist die Aufgabe des Trainings: die Kompetenz aus dem zweiten Raum in den ersten hinüberzuziehen, ohne dass der Zettel je wieder auftaucht.

Deshalb heißt die Information privilegiert. Im Training ist sie reichlich vorhanden, im Betrieb nicht. Wer Selbstkritik als privilegierte Information nutzt, verlagert Wissen, nicht Daten. Das ist etwas anderes als eine Datenbank mit guten Beispielen, denn das Modell lernt hier aus der Differenz zwischen seinem ersten und seinem korrigierten Versuch.

On-Policy Self-Distillation: gelernt wird auf den eigenen Spuren

Der Trainingsmechanismus heißt On-Policy Self-Distillation, und beide Wörter verdienen Aufmerksamkeit. On-Policy bedeutet, dass der Schüler seine eigenen Spuren erzeugt, statt Beispiele aus einem fremden Datensatz nachzuahmen. Bei der Bildgenerierung sind diese Spuren die Denoising-Pfade: die Kette von Zwischenschritten, die vom reinen Rauschen zum fertigen Bild führt. Das Modell läuft durch seinen eigenen Entstehungsprozess, Schritt für Schritt, und genau dort wird gelernt.

Anschließend minimiert das Training die Divergenz zwischen den Denoising-Verteilungen von Lehrer und Schüler, und zwar an jedem einzelnen Zustand entlang dieser Pfade. Nicht das Endergebnis wird mit einer Note bewertet, sondern die Wahrscheinlichkeitsverteilung an jedem Zwischenschritt wird zur Deckung gebracht. Es ist der Unterschied zwischen „das Bild ist gut“ und „an dieser Stelle hättest du anders abbiegen müssen“. Der Lernreiz liegt in der dichten Rückmeldung, nicht in einer einzelnen Zahl am Ende.

Das erklärt auch, warum der Ansatz überhaupt funktionieren kann. Ein skalares Belohnungssignal sagt dem Modell, dass etwas besser war, aber nicht wo. Eine Verteilungsangleichung über den gesamten Pfad sagt ihm sehr genau, an welchen Stellen es abweicht. Die Verbesserung der Bildgenerierung durch Selbst-Distillation kommt also nicht aus mehr Rechenzeit allein, sondern aus der Auflösung des Signals.

Die Zahlen: GenEval und Soft-TIFA im Vergleich

Die Experimente bauen auf dem offenen Modell Qwen-Image-2512 auf, das mit Qwen-Image 3.0 verwandt ist. Mit dem hauseigenen Kritiker Qwen-VL steigt der Wert auf GenEval von 0,747 auf 0,808. Die zweite Zahl aus dem Abstract, ein Anstieg von 32,97 auf 35,53 bei GenEval2 Soft-TIFA, stammt dagegen aus dem Lauf mit einem externen Kritiker, GPT-5.6-Luna. Mit dem eigenen Kritiker sinkt GenEval2 im Volltext leicht, von 32,58 auf 32,37; erst wenn die überarbeiteten Prompts zusätzlich geprüft werden, steigt der Wert auf 35,07. Beide Benchmarks prüfen im Kern, wie zuverlässig ein erzeugtes Bild zur Textvorgabe passt – ob Objekte, Farben, Anzahlen und Anordnungen stimmen.

Bemerkenswert ist, dass die Verbesserung ohne korrigierte Zielbilder und ohne Belohnungssignal entsteht. Zusätzlich berichtet das Team, dass die Empfindlichkeit des Modells für zusätzliche Reflexionsinformation erhalten bleibt: Auch das trainierte Modell profitiert noch von einem weiteren Korrekturdurchgang. Es verliert also nicht die Fähigkeit, auf Kritik zu reagieren, während es lernt, ohne sie auszukommen.

Wer selbst mit Bildmodellen arbeitet, sollte die Zahlen dennoch nüchtern lesen. Die Gewinne konzentrieren sich auf Prompts, an denen das Basismodell anfangs scheitert. Bei Prompts, die es schon vorher gut löste, sinken die Werte um 1 bis 4 Punkte auf einer Skala bis 100. Teuer ist das Verfahren auch: Nur 10 bis 21 Prozent der Versuche liefern ein brauchbares Trainingspaar, also fünf bis zehn Anläufe pro Paar, trainiert wurde auf vier H200-GPUs.

Warum ein starker Kritiker die Obergrenze hebt

Ein Ergebnis des Papers verdient besondere Beachtung. Das Team hat zusätzlich mit einem leistungsfähigeren externen Kritiker trainiert, GPT-5.6-Luna. Damit erreicht das Modell auf GenEval 0,882 statt 0,808 und auf GenEval2 den Bestwert von 35,53. Die Autoren folgern, dass Modelle mit starken Beurteilungsfähigkeiten eine höhere Obergrenze der Selbstverbesserung erwarten können. Die Qualität der Kritik bestimmt also, wie weit das Verfahren trägt.

Das ist einleuchtend und ein wenig unbequem. Wenn das Modell nur so weit kommt, wie es sich selbst durchschaut, dann ist Selbstverbesserung zunächst einmal durch die eigene Urteilskraft begrenzt. Ein besseres Urteilsvermögen verschiebt diese Grenze nach oben. Damit ist der Anspruch „ohne externen Lehrer“ an dieser Stelle qualifiziert: ohne externen Lehrer im Training ja, aber nicht ohne gutes Urteilen. Die Formulierung im Abstract spricht davon, dass ein höheres Niveau zu erwarten sei – nicht, dass es bewiesen wäre.

Für die Praxis heißt das: Wer dieses Verfahren nutzen will, sollte zuerst in die Kritikfähigkeit investieren. Der Kritiker ist der eigentliche Engpass, nicht der Generator.

Text-Rendering: wo die Verbesserung nicht gleichmäßig greift

Das Team berichtet außerdem von gemischten Ergebnissen beim Rendern von Text im Bild. Nur die Variante mit geprüften Prompts verbessert sich hier, von 0,771 auf 0,790. Mit dem ungeprüften eigenen Kritiker fällt der Wert unter das Ausgangsniveau, mit GPT-5.6-Luna steigt er nur leicht. Die Selbstverbesserung ist also nicht über alle Aufgaben hinweg gleich verteilt.

Ein Modell erbt die blinden Flecken seines Kritikers. Wenn die Kritik beim Text-Rendering nicht sauber unterscheidet, ob Buchstaben korrekt gesetzt oder nur plausibel aussehen, dann kann die Verteilungsangleichung diese Unterscheidung auch nicht herstellen. Die Selbstverbesserung verstärkt, was die Kritik schon erkennt – und eben auch, was sie übersieht.

Statt eine gleichmäßige Kurve nach oben zu behaupten, benennt das Paper diese Ungleichverteilung. Wer solche Verfahren einsetzt, sollte deshalb nicht von einer pauschalen Qualitätssteigerung ausgehen, sondern von einer aufgabenspezifischen.

Was das konkret bedeutet

UniEvo-VL ist kein Durchbruch, der die Bildgenerierung neu ordnet, sondern ein Rezept mit einer klaren Idee: Selbstkritik wird zur privilegierten Information, und ein einziges Modell spielt Lehrer und Schüler in unterschiedlichen Kontexten. Der Bezug zu Test-Time Compute ist dabei der interessanteste Punkt. Die Kritik entsteht beim Erzeugen, kostet dort Rechenzeit und wird anschließend in dauerhaftes Können übersetzt. Der Aufwand fällt im Training an, danach erzeugt das Modell bessere Bilder ohne zusätzlichen Korrekturdurchgang.

Für die Praxis ergeben sich zwei Konsequenzen. Erstens: Der Engpass verschiebt sich vom Generator zum Kritiker – wer in Beurteilungsfähigkeit investiert, gewinnt mehr als jemand, der nur größere Generatoren baut. Zweitens: Erwartungen gehören aufgabenspezifisch formuliert. Prompt-Treue lässt sich so verbessern, Text-Rendering nicht automatisch mit, und leichte Aufgaben können sogar leicht schlechter werden. Und die Verbesserung ist, wie das Paper selbst schreibt, nicht zwingend gleichmäßig.

Offen bleibt, wie weit das Verfahren skaliert, ob die Selbstkritik mit steigender Modellqualität informativ bleibt oder sich selbst bestätigt, und wo genau die Obergrenze liegt, wenn kein stärkerer externer Kritiker mehr zur Verfügung steht. Wer heute multimodale Modelle einsetzt, muss darauf nicht warten. Die relevante Frage ist ohnehin nicht, ob es einen größeren Lehrer gibt, sondern ob im eigenen System ein verlässlicher Kritiker arbeitet. Die Details stehen im vollständigen Paper, nicht im Abstract.

Quelle: arxiv.org

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