Jedes Team, das aktuell mit KI arbeitet, führt unbewusst dasselbe Experiment durch: Dutzende Tools werden in Slack-Threads bewertet, eine Handvoll wird übernommen, weil jemand Erfahrenes sie ausprobiert hat, ein paar werden nach einem schlechten Produktionsvorfall still wieder verworfen, ohne dass jemand aufschreibt, warum. Das ist keine Technologiestrategie. Das ist institutionelles Gedächtnis ohne Institution dahinter.
Deshalb veröffentlichen wir den RUBINLAKE AI Technology Radar: eine vierteljährliche, evidenzbasierte Übersicht der KI-, Daten-, MLOps-, Governance- und Developer-AI-Tools und -Praktiken, die wir tatsächlich bewerten, testen und empfehlen. Dieser Beitrag erklärt, warum wir ihn gebaut haben, was ein Radar leistet, das eine Tabelle nicht kann, und was unsere erste Ausgabe mit 153 Einträgen in vier Quadranten bereits darüber aussagt, wohin KI-Investitionen 2026 gehen sollten und wohin nicht.
Die Lücke, die der Radar schließen soll
Die Zahlen zur KI-Adoption im Mittelstand sind eindeutig. Eine Netrio-Umfrage aus 2026 ergab, dass 82% der IT-Verantwortlichen im Mittelstand KI bereits produktiv einsetzen, aber nur 26% sagen, dass KI unternehmensweit gesteuert und geregelt ist[1]. Eine Salesforce-Studie fand außerdem, dass 55% der Mitarbeitenden zugeben, KI-Tools zu nutzen, die ihr Unternehmen nie freigegeben hat[2], und laut IBM verfügen nur 37% der Organisationen überhaupt über eine Richtlinie, um solche Schatten-KI zu erkennen[3].
Klar gesagt: Die Adoption läuft der Governance fast überall davon. Teams bringen KI-Funktionen und Agenten-Workflows schneller in Produktion, als irgendjemand nachverfolgt, welche Tools vertrauenswürdig sind, welche Experimente sind und welche man aktiv meiden sollte. Genau in dieser Lücke entstehen teure Fehler. Die meisten Unternehmen entdecken sie erst nach einem Vorfall, nicht davor.
Gartners eigene Prognose für 2026 unterstreicht den Ernst der Lage: mehr als 40% der agentischen KI-Projekte werden bis Ende 2027 eingestellt, getrieben von steigenden Kosten, unklarem Geschäftsnutzen und, entscheidend, unzureichenden Risikokontrollen[4]. Ein Technology Radar rettet keinen schlechten Business Case. Aber er zwingt dazu, das Gespräch über Risikokontrollen vor Projektstart zu führen, nicht erst in der Manöverkritik danach.
Was ein Technology Radar tatsächlich leistet
Das Format selbst ist nicht neu. Thoughtworks veröffentlicht seinen Technology Radar seit über einem Jahrzehnt zweimal jährlich[5], und einige Unternehmen wie Zalando und Digitec Galaxus pflegen eigene, öffentliche Radare[6][7]. Was das Format nützlich macht, ist die spezifische Unterscheidung, die eine Feature-Vergleichstabelle nicht leisten kann: der Unterschied zwischen "das nutzen wir", "das sollten wir ausprobieren", "das beobachten wir" und "das haben wir versucht, und es hat Probleme verursacht".
Wir ordnen jeden Eintrag, jeden Blip, entlang zweier Dimensionen ein:
Vier Ringe, nach Vertrauensgrad:
| Ring | Bedeutung |
|---|---|
| Adopt | Ausgereift und wertvoll genug, dass Teams einen klaren Grund brauchen, es nicht zu nutzen. |
| Trial | Wert, in einem echten Projekt mit klaren Erfolgskriterien und einer verantwortlichen Person getestet zu werden. |
| Assess | Vielversprechend oder strategisch wichtig, aber noch nicht ausreichend belegt für den Produktionseinsatz. |
| Hold | Für neue Arbeit meiden, außer es gibt eine dokumentierte, bewusste Ausnahme. |
Vier Quadranten, nach Thema: KI & Data Engineering, Data Platforms & MLOps, AI Security & Governance und Developer AI & Delivery.
Entscheidend: Die Position im Ring ist wichtiger als der Quadrant. Zwei Tools im selben Quadranten können gegensätzliche Empfehlungen tragen. Genau das ist der Sinn: Der Radar macht eine implizite Entscheidung explizit und sichtbar für das ganze Unternehmen, sodass sie hinterfragt werden kann.
Was unsere erste Ausgabe zeigt
Unsere Ausgabe von Mai 2026 umfasst 153 Einträge. Allein die Verteilung ist aufschlussreich:
- 24 Einträge in Adopt (16%)
- 49 Einträge in Trial (32%)
- 60 Einträge in Assess (39%)
- 20 Einträge in Hold (13%)
Weniger als jeder sechste Eintrag hat unsere stärkste Empfehlung verdient. Das ist keine Vorsicht als Selbstzweck. Es spiegelt wider, wie jung der Großteil dieses Stacks noch ist. Vieles, worüber Teams gerade begeistert sind, gehört zu Recht in Trial oder Assess, nicht in ein Standardisierungsmandat.
Was tatsächlich "Adopt" erreicht hat
Der Adopt-Ring neigt zu Tools mit mehrjähriger Produktionshistorie und Coding-Agenten, die längst von der Neuheit zum täglichen Werkzeug geworden sind: Claude Code, GitHub Copilot und Cursor auf der Entwicklerseite; dbt Core und Cloud und Databricks Lakehouse auf der Datenplattform-Seite; und, bemerkenswert, Zero Trust Architecture für AI Agents, Prompt-Injection-Defenses und KI-Risiko-Governance-Frameworks im Bereich Security und Governance.
Diese letzte Gruppe zählt mehr, als es auf den ersten Blick scheint. Die Hälfte unserer Adopt-Einträge im Governance-Bereich sind Kontrollen, keine Fähigkeiten. Wir sagen nicht "mehr KI einsetzen". Wir sagen, dass ein bestimmter Satz an Kontrollen von Best Practice zur Grundvoraussetzung geworden ist, sobald KI produktiv läuft.
Wovon wir aktiv abraten
Zwanzig Einträge liegen in Hold, und sie sind ebenso aufschlussreich wie die Adopt-Liste. Prompt-Only AI Governance, also einen System-Prompt zu schreiben, der dem Modell sagt, sich zu benehmen, und das als Sicherheitsstrategie zu bezeichnen, liegt in Hold. Ebenso MCP by Default, das Verdrahten von Model-Context-Protocol-Servern ohne Bedrohungsmodell für das, was ein Agent damit erreichen kann. Ebenso Vollautonome SDLC-Agenten, also einen Agenten planen, coden, testen und ausliefern zu lassen, ohne irgendwo im Ablauf einen menschlichen Kontrollpunkt.
Keiner dieser Fälle ist hypothetisch. Es sind die konkreten Formen, in denen wir "KI-beschleunigte Schatten-IT" und vermeidbare Produktionsvorfälle in der Praxis gesehen haben, verallgemeinert zu einem Muster, damit ein Team es erkennt, bevor es gebaut wird, nicht danach.
Was wir beobachten
Der Assess-Ring ist aus gutem Grund der größte: Dort findet gerade das echte Experimentieren statt. Context Engineering liegt noch in Trial, tendiert Richtung Adopt, je mehr Teams Produktionsergebnisse berichten, während Structured Outputs von LLMs in dieser Ausgabe bereits nach Adopt gewechselt ist. Multi-Agenten-Frameworks, Agent-zu-Agent-Protokolle und mehrere Coding-Agent-Plattformen sammeln noch Evidenz in Assess und Trial. Wir haben sogar unsere eigene Kategorie von Agenten-Tooling zur Bewertung eingeordnet. Hermes Agent liegt in Assess, genau dort, wo ein neues Muster liegen sollte, bevor jemand Produktionslast darauf verlagert.
Warum wir das veröffentlichen, statt es nur intern zu nutzen
Wir hätten das als internes Dokument behalten können. Wir veröffentlichen es aus demselben Grund, aus dem wir KI- und Datenberatung überhaupt anbieten: Die Mittelstandsunternehmen, mit denen wir arbeiten, treffen dieselben Adopt-oder-Hold-Entscheidungen mit deutlich weniger Evidenz, als ein dediziertes Research-Team sammeln kann, und mit deutlich weniger Zeit, sie selbst zu sammeln.
Ein öffentlicher Radar leistet drei Dinge, die ein privater nicht kann:
- Er zwingt uns, unsere Begründung aufzuschreiben, nicht nur unser Fazit. Jeder Eintrag nennt Adoptionssignale, Risiken und eine Empfehlung, sodass das "Warum" überlebt, auch wenn die Person, die die Entscheidung getroffen hat, das Projekt wechselt.
- Er gibt unseren Kunden und Lesern eine zweite Meinung, die sie gegen ihre eigenen Anbietergespräche prüfen können, bevor sie einen Vertrag unterschreiben.
- Er altert öffentlich. Wenn wir im nächsten Quartal etwas von Trial nach Hold verschieben, ist das eine sichtbare, nachvollziehbare Korrektur, kein stilles internes Memo, das außerhalb des Teams niemand sieht.
Wie man einen solchen Radar nutzt
Wer prüft, ob das eigene Team so etwas braucht: Die praktische Regel ist einfach: fangen Sie bei Adopt und Hold an. Adopt-Einträge sind Ihr Standard; Sie brauchen einen Grund, davon abzuweichen. Hold-Einträge sind Ihre Stoppschilder; Sie brauchen eine dokumentierte, bewusste Ausnahme, um sie in neuer Arbeit einzusetzen. Alles in Trial und Assess ist der Ort für begrenzte Experimente: eine verantwortliche Person, eine Kennzahl, eine Exit-Entscheidung, regelmäßig überprüft statt endlos laufen gelassen.
Diese Disziplin, die Empfehlung aufzuschreiben, Evidenz anzuhängen und jedes Quartal erneut zu prüfen, ist der ganze Wert des Formats. Sie macht Ihr agentisches KI-Projekt nicht von allein erfolgreich. Aber sie macht den Unterschied zwischen einem Team, das genau sagen kann, warum es ein Tool gewählt hat, und einem Team, das das erst sechs Monate später in einer Vorfallsanalyse herausfindet.
Den vollständigen RUBINLAKE AI Technology Radar mit allen Einträgen, Ringen und Quadranten können Sie selbst erkunden, inklusive der vollständigen Methodik, nach der wir jedes Quartal Einträge platzieren und verschieben.
