Als wir im Juli unseren ersten AI Technology Radar veröffentlicht haben, haben wir ein Versprechen gegeben: Er würde öffentlich altern. Wenn sich eine Empfehlung ändert, sieht man die Änderung und die Begründung dahinter, statt eines stillen internen Memos. Diese zweite Ausgabe ist der erste echte Test dieses Versprechens, und ganz bequem ist er nicht. Zwei der am weitesten verbreiteten Tools auf dem Radar haben sich rückwärts bewegt. 30 Einträge haben ihn ganz verlassen. Der Radar ist kleiner als im Mai.
Genau das ist der Punkt. Dieser Beitrag geht durch, was sich bewegt hat, wie die Beleglage aussah und warum wir die Regeln des Radars selbst geändert haben, damit er schrumpfen darf.
Die Form dieser Ausgabe
Die Ausgabe September 2026 kam in zwei Releases. Das erste am 4. September berührte 42 von 153 Einträgen. Ein zweiter Durchgang am 6. September, gegen das Ergebnis des ersten gerechnet, berührte 27 weitere. Zusammen lassen sie den Radar bei 136 Einträgen zurück:
- 30 gestrichen. Einträge, zu denen der Radar keine Meinung mehr braucht.
- 7 Ringwechsel. Vier Aufstiege nach Adopt, einer nach Trial und zwei Herabstufungen.
- 19 aktualisiert. Auf Basis neuer Belege neu geschrieben, ohne den Ring zu wechseln.
- 13 hinzugefügt. Zwölf in Assess und einer in Hold.
Nach beiden Releases verteilen sich die Einträge auf 26 Adopt (19%), 38 Trial (28%), 58 Assess (43%) und 14 Hold (10%). Assess bleibt der größte Ring, und das sollte er auch. Dieses Feld produziert weiterhin mehr Kandidaten als erprobte Praxis. Neu ist, dass der Radar jetzt eine Möglichkeit hat, Kandidaten loszulassen, aus denen nie etwas geworden ist.
Zwei Herabstufungen aufgrund von Sicherheitsbelegen
Die sichtbarste Änderung: LangChain und MLflow 3, seit unserer ersten Ausgabe beide in Adopt, sind nach Trial gewandert. Keines von beiden ist eine Empfehlung, den Einsatz zu beenden. Beides ist eine Änderung dessen, was der Einsatz voraussetzen muss.
LangChain. Im März dokumentierte Cyeras koordinierte Offenlegung
"LangDrained" drei hoch beziehungsweise kritisch eingestufte Schwachstellen
in LangChain und LangGraph: eine Serialisierungs-Injection mit CVSS 9.3, ein
Path Traversal und eine SQL-Injection im SQLite-Checkpointer. Jede davon
legte eine andere Klasse von Unternehmensdaten frei, von Dateisysteminhalten
über API-Zugangsdaten bis zu gespeicherten
Gesprächsverläufen[1]. Die
Patches kamen. Dann folgte im Mai ein weiterer als hoch eingestufter Hinweis
zu unsicherer Deserialisierung über zu breit gefasste load()-Allowlists,
der sowohl die 0.3- als auch die 1.x-Linie
betraf[2]. Dieselbe
Fehlerklasse war wieder da. Trial heißt: Man baut weiter darauf, aber nur
innerhalb klarer Leitplanken für Versionen, Document Loader, Serialisierung
und Checkpoint-Stores, und nur dann, wenn das Team die Kapazität hat,
Sicherheitshinweise zu verfolgen und Patches schnell auszurollen.
MLflow 3. CVE-2026-64849 ist eine kritische, nicht authentifizierte Server-Side Request Forgery im Webhook-Test-Endpunkt von MLflow. Betroffen ist jede Version vor 3.15.0. Weil der Endpunkt die Upstream-Antwort an den Aufrufer zurückspiegelt, kann ein Angreifer per DNS-Rebinding Cloud-Instanz-Credentials direkt aus dem Server auslesen. Innerhalb weniger Stunden nach Vergabe der CVE wurde die Lücke gegen exponierte Tracking-Server ausgenutzt, und die CISA hat sie in ihren Katalog der bekannten ausgenutzten Schwachstellen aufgenommen[3]. Und es ist keine Geschichte einer einzelnen CVE. Zehn Hinweise zwischen April und August beschrieben fehlende oder falsch angewandte Autorisierungsprüfungen an MLflow-Endpunkten. Trial bedeutet hier: Patch auf 3.15.0 oder neuer, Netzwerkisolation und niemals ein exponierter Tracking-Server, und zwar als hartes Gate statt als Punkt im Härtungs-Backlog.
Beide Einträge beschreiben weiterhin Tools mit enormer Produktionsverbreitung und intaktem Nutzenversprechen. Was ihnen im Mai Adopt eingebracht hat, war Reife. Was sie im September bewegt, ist, dass ein sicherer Betrieb inzwischen eine echte operative Verpflichtung ist. Und dieses Sternchen sollte Adopt nicht stillschweigend mittragen.
Was Adopt erreicht hat
Vier Einträge sind über die beiden Releases hinweg auf Basis wiederholter Produktionsbelege nach Adopt aufgestiegen. Einer davon ist eine Kontrolle, keine Fähigkeit.
Das NIST AI Risk Management Framework ist von Trial nach Adopt gewandert. Im Mai war es ein angesehenes Dokument. Seitdem hat NIST Anwendungsfälle und Profile veröffentlicht, und Organisationen wie Workday haben dokumentiert, wie sie ihre Kontrollrahmen daran ausgerichtet haben[4]. Das ist der Unterschied zwischen einem Framework, das zitiert wird, und einem, das tatsächlich betrieben wird.
LLMOps-Plattformen sind als Kategorie nach Adopt gewandert, gestützt auf Produktionsfallstudien von ZenML und benannte LangSmith-Einsätze bei Schneider Electric, Rippling und Toyota. Dagster ist nach Adopt aufgestiegen, mit dokumentiertem Produktionseinsatz bei US Foods, easyJet Holidays und PostHog[5].
Das zweite Release hat den vierten hinzugefügt. CrewAI ist von Trial nach Adopt gewandert, gestützt auf benannte Unternehmenseinsätze bei PwC, IBM und Gelato sowie bei AWS, wo es Bedrock-Agenten trägt[6]. Die weiter unten beschriebenen Framework-Risiken sind real, und der Eintrag sagt das auch. Sie gehören in Produktionskontrollen, nicht in eine Sperre.
AI Platform Engineering hat es mit Pilotprojekten von Nirmata, Pulumi Neo und Itential FlowAI in Trial geschafft.
Dreizehn Neuzugänge, zwölf davon in Assess
Das erste Release hat sechs Einträge hinzugefügt, alle in Assess, und bei fünf von sechs geht es darum, Agenten zu steuern, nicht sie zu bauen:
- Microsofts Agent Governance Toolkit, quelloffene Laufzeit-Sicherheitskontrollen für autonome Agenten[7]
- asago, Red Hats Open-Source-Projekt, das Governance-Richtlinien in ausgerollte, durchsetzbare Kontrollen übersetzt[8]
- Die OWASP MCP Top 10, jetzt ein eigenständiger Eintrag, weil das Model Context Protocol inzwischen eine eigene Risikooberfläche hat[9]
- Agent Evaluation Harnesses und Agent Trajectory Evaluation, ein Feld, das gerade zusammenwächst und die Zuverlässigkeit von Agenten als Ingenieursdisziplin misst statt als Benchmark-Score
Der sechste, Rerun, ist der Ausreißer. Es ist eine Datenschicht für multimodale Zeitreihen mit unterschiedlichen Taktraten in Robotik und Physical AI, also eine Lücke, die unsere textzentrierten MLOps-Einträge bislang nicht abgedeckt hatten.
Das zweite Release hat sieben weitere hinzugefügt. Sechs starten in Assess: Agent Memory Layers, Agentic Data Control Planes, Agentic Test Automation, Agentic Vulnerability Research for Code, AI Control Protocol Evaluation und Apache Fluss, die Streaming-Speicherschicht für Lakehouses, die dieses Jahr zum Apache-Top-Level-Projekt aufgestiegen ist und Produktionsfälle bei Rednote und Taobao vorweist[10].
Agent Memory Layers verdient ein Wort, denn am 4. September haben wir den eigenständigen Mem0-Eintrag mangels Signal gestrichen. Zwei Tage später hat der zweite Durchgang die Kategorie gefunden statt des Produkts. Mem0, Zep, Cognee, Letta, TencentDB, Redis und Oracle liefern inzwischen alle persistentes Gedächtnis für Agenten, und Mem0s eigener Bericht zählt 21 integrierte Frameworks und 20 Vektorspeicher[11]. Das ist ein eigenes Anliegen, getrennt von Retrieval, und es hat jetzt einen eigenen Eintrag.
Der siebte ist der einzige Neuzugang, der in Hold startet: Agent Framework Supply Chain Risk. Check Point hat diesen Sommer fast ein Dutzend Schwachstellen in den großen Agent-Frameworks gefunden und argumentiert, dass Prompt Injection nicht der Fehler ist, sondern die Frameworks[12]. Langflow hat die erste Agent-Framework-Schwachstelle auf CISAs Liste der aktiv ausgenutzten Schwachstellen geliefert, und ein vollständig gepatchtes LiteLLM-Gateway ließ sich weiterhin von jedem kapern, der einen Admin-Schlüssel hält[13]. Das Hold richtet sich nicht gegen Agent-Frameworks. Es richtet sich gegen ihren Einsatz ohne Sandboxing, Abhängigkeitskontrolle, minimale Rechte und Laufzeitüberwachung.
Die aktualisierten Einträge folgen demselben roten Faden. Prompt Injection Defenses ist jetzt rund um Berechtigungsbegrenzung und Tool-Call-Monitoring aufgebaut. AI-augmented CI/CD stellt eine dokumentierte Angriffsklasse an den Anfang: Prompt Injection gegen Agenten, die Issues triagieren und Pull Requests prüfen, während sie erhöhte Repository-Rechte halten[14]. Und der AutoGen-Eintrag hält fest, dass AutoGen in den Wartungsmodus übergeht, während Microsoft Agent Framework als Nachfolger mit Version 1.0 allgemein verfügbar ist[15]. Das zweite Release hat zehn weitere Einträge auf dieselbe Weise neu geschrieben. GitHub Copilot bleibt in Adopt, trägt jetzt aber seine dokumentierten Prompt-Injection- und Exfiltrations-Hinweise, pgvector bleibt mit einer CVE beim Indexaufbau in Trial, und Milvus bleibt trotz kritischer Hinweise zur Umgehung der Authentifizierung in Assess. Der Ring hat sich nicht bewegt. Das Bedrohungsmodell schon.
Warum wir 30 Einträge gestrichen haben
Hier ist die unbequeme Erkenntnis aus dieser Ausgabe: Der Radar, wie wir ihn im Mai entworfen hatten, konnte nur wachsen. Jede Aktion, die uns zur Verfügung stand, ob hinzufügen, verschieben oder aktualisieren, hielt einen Eintrag auf dem Radar oder setzte einen neuen darauf. Es gab keine Möglichkeit zu sagen, dass wir zu etwas keine Meinung mehr brauchen. Nach ein paar Quartalen hat man dann einen Radar, auf dem alles Richtung Adopt driftet, der Hold-Ring sich mit Warnungen füllt, die niemand mehr braucht, und die Liste keine Entscheidungshilfe mehr ist, sondern ein Inventar.
Also haben wir zwei Regeln geändert.
Ausmustern ist jetzt eine Aktion. Ein Eintrag kann vom Radar genommen werden, ohne dass seine Historie verloren geht. Sein Text bleibt in dem Release, in dem er veröffentlicht wurde, und eine spätere Ausgabe kann ihn zurückholen. Ausmustern ist kein Urteil, dass eine Technologie schlecht ist. Das sagt Hold, und ein Hold-Eintrag verdient seinen Platz, indem er warnt. Ausmustern heißt nur, dass der Radar diese Meinung nicht mehr mittragen muss.
Jeder Quadrant hat eine Obergrenze von 30. Ein Radar kann nicht alles enthalten. Ist ein Quadrant voll, bedeutet ein Neuzugang eine Streichung, und die Review muss begründen, welche. Zwei unserer vier Quadranten stehen jetzt genau an der Obergrenze, AI & Data Engineering bei 31, und Developer AI & Delivery steht bei 45, runter von 52. Er kommt über die nächsten zwei Ausgaben dort an statt in einem Schnitt. Wir begrenzen Streichungen auf acht pro Quadrant und Release, damit jede einzelne tatsächlich geprüft werden kann.
Die meisten der 30 Streichungen sind Zusammenführungen, keine Ablehnungen. Ein eigenständiger Eintrag zum Agent-to-Agent-Protokoll, typisierte Tool-Schnittstellen, KServe und mehrere IDE-Agenten wurden gestrichen, weil die Entscheidung, die sie unterstützt haben, jetzt von einem breiteren Eintrag abgedeckt wird. Serving liegt inzwischen bei vLLM, NVIDIA Dynamo und Kubernetes for AI Inference. Typisierte Tools gehen in Structured Outputs auf. Einige waren Hold-Warnungen, die ihren Zweck erfüllt hatten: eigenständige AutoML-Plattformen, handgeschriebene ETL-Skripte, homomorphe Verschlüsselung in Produktions-KI und blindes LLM-as-Judge-Scoring. Die Branche ist weitergezogen, und die Warnung braucht den Platz nicht mehr.
Das zweite Release hat nach derselben Regel neun weitere gestrichen: Bloom, Federated Learning, Figma Make, Hadoop HDFS, Monte Carlo, PageIndex, den Pi Coding Agent, Prefect 3 und Seldon Core v1. Jeder war seit Mai unverändert geblieben und kam in einer Recherche mit mehr als 2.400 Signalen nicht vor.
Wie wir entschieden haben und was wir dem Werkzeug nicht überlassen haben
Wir pflegen diesen Radar mit einem Agenten, und in dieser Ausgabe haben wir seine Grenzen gefunden. Wir haben ihn fünfmal gegen dieselbe Mai-Baseline laufen lassen, jedes Mal mit derselben Frage: Was hat sich dieses Quartal geändert? Er hat uns fünf deutlich unterschiedliche Antworten gegeben. Über alle fünf Läufe hinweg kamen 162 verschiedene Vorschläge zusammen, und nur 24 davon tauchten in mehr als einem Lauf auf.
Keinen der Vorschläge, die nur einmal auftauchten, haben wir veröffentlicht. Alles, was sich in dieser Ausgabe bewegt hat oder hinzugekommen ist, wurde von mindestens zwei Läufen unabhängig voneinander vorgeschlagen oder war ein Ringwechsel aus dem Lauf mit der tiefsten Beleglage. Die Streichungen haben wir umgekehrt gefiltert. Alles, was ein Lauf streichen und ein anderer hochstufen wollte, etwa Feast, AI Inference Gateways oder AI-augmented CI/CD, ist auf dem Radar geblieben. Fehlendes Signal in einer einzelnen Recherche ist kein Beleg. Fehlendes Signal über mehrere hinweg schon.
Der zweite Durchgang war dieselbe Disziplin, angewandt auf die Lücken des Werkzeugs selbst. Zwischen den beiden Releases haben wir festgestellt, dass drei seiner neun Suchanbieter seit Monaten stillschweigend tot waren, dass seine Suchanfragen nicht gegen sein Budget gezählt wurden und dass es weniger als die Hälfte dessen las, was es fand. Wir haben das behoben, es drei weitere Male gegen das Ergebnis vom 4. September laufen lassen und wieder nur veröffentlicht, worin sich zwei Läufe einig waren: 29 von 125 verschiedenen Vorschlägen, 27 nach unserer eigenen Prüfung. Außerdem führen wir jetzt eine kurze Liste von Technologien, von denen wir wissen, dass es sie finden sollte. Seine Scouts erreichen drei Viertel dieser Liste. Seine Vorschlagsliste hält ein Drittel. Diese Lücke ist das Nächste, woran wir arbeiten, und die Dezember-Ausgabe wird sagen, ob sie sich geschlossen hat.
Das ist die Disziplin, die dieses Format verlangt. Das Werkzeug findet die Kandidaten. Die Belege entscheiden. Und wenn die Belege sagen, dass zwei Adopt-Einträge ein Sternchen brauchen, dann druckt man das Sternchen.
Sie können jeden Eintrag, Ring und Quadranten im vollständigen RUBINLAKE AI Technology Radar erkunden, einschließlich der kompletten Methodik. Die nächste Ausgabe ist für Dezember geplant.
