Der Wendepunkt bei Agent-Frameworks: Was tatsächlich machbar ist, was auf uns zukommt und wie man sich darauf einstellt

Ehrliche Fakten darüber, wo KI-Agenten funktionieren, wo sie versagen und warum technische Disziplin wichtiger ist als die Leistungsfähigkeit des Modells.

18 Min. Lesezeit | KI-Strategie & Technik

---

Jede Woche schickt mir jemand einen Artikel über Unternehmen im Bereich autonomer KI. Jede Woche schaue ich mir die Daten an und stelle etwas anderes fest.

Die Schlagzeilen werden immer spektakulärer. Ein KI-gesteuertes Unternehmen, das 177.000 Dollar erwirtschaftet hat. Ein Agent-Framework, das in sechzig Tagen 247.000 GitHub-Stars erreicht hat. Ein Start-up, das behauptet, sein Programmieragent löse 67 % der realen technischen Aufgaben. Wenn man diese Geschichten für bare Münze nimmt, könnte man meinen, wir stünden zwölf Monate davor, die Hälfte der technischen Belegschaft überflüssig zu machen.

Das glaube ich nicht. Nicht, weil ich KI-Agenten skeptisch gegenüberstehe – ich nutze sie täglich, baue Systeme um sie herum auf und berate Unternehmen bei deren Einsatz. Aber gerade weil ich an dieser Schnittstelle arbeite, sehe ich die Kluft zwischen dem, was die Benchmarks versprechen, und dem, was die Produktion tatsächlich liefert. In dieser Kluft stehen die meisten Unternehmen kurz davor, viel Geld und Zeit zu verlieren.

Dieser Beitrag ist meine ehrliche Einschätzung der Agenten-Landschaft Anfang 2026. Wo die Zahlen stimmen, wo nicht und welches Muster hinter jedem Einsatz steckt, der tatsächlich funktioniert.

Akt 1: Die unbequemen Zahlen

Die Explosion der Tools

Beginnen wir mit dem, was unbestreitbar real ist: Die Tooling-Ebene für KI-Agenten ist explodiert. Paperclip überschritt innerhalb weniger Wochen nach dem Start die Marke von 30.000 Sternen auf GitHub. OpenClaw erreichte in nur sechzig Tagen 247.000 Sterne und ist damit eines der am schnellsten wachsenden Open-Source-Projekte aller Zeiten. Anthropic veröffentlichte das Claude Agent SDK. CrewAI gab bekannt, dass sie über 2 Milliarden Workflows ausgeführt haben. Die Infrastruktur zum Erstellen, Orchestrieren und Bereitstellen von Agenten ist mittlerweile so ausgereift, dass die Eintrittsbarriere praktisch weggefallen ist.

Ich nutze Paperclip für meine eigenen Geschäftsabläufe. Die ehrliche Wahrheit: Es funktioniert bei begrenzten, wiederholbaren Workflows, bei denen ich durch wochenlange Beobachtung Vertrauen in das System gewonnen habe. In dem Moment, als ich versuchte, ihm etwas zu übertragen, das Urteilsvermögen erfordert – die Priorisierung mehrdeutiger Kundenanfragen, das Verfassen von Angeboten, bei denen der Ton zählt, Entscheidungen über den Umfang –, tat es selbstbewusst das Falsche. Nicht manchmal. Zuverlässig.

Diese Selbstsicherheit ohne Kalibrierung ist meiner Meinung nach das zentrale Risiko dieser ganzen Welle.

Die Wahrnehmungslücke

Die wichtigste in diesem Jahr veröffentlichte Studie zu Agenten ist kein Benchmark. Es ist eine randomisierte kontrollierte Studie.

METR führte eine RCT mit erfahrenen Entwicklern durch, die KI-Codierungstools bei realen Aufgaben aus ihren eigenen Repositorys einsetzten. Das Ergebnis, das an jeder CTO-Wand hängen sollte: Entwickler, die KI-Tools nutzten, waren im Durchschnitt 19 % langsamer. Aber hier kommt der Teil, der es wirklich gefährlich macht – dieselben Entwickler glaubten, sie seien 24 % schneller. Die Wahrnehmungslücke war nicht gering. Die Entwickler haben die Verlangsamung nicht nur übersehen; sie waren vom Gegenteil überzeugt.

Überleg mal, was das auf Unternehmensebene bedeutet. Wenn dein Team glaubt, einen Produktivitätsschub von 24 % zu erzielen, aber tatsächlich 19 % langsamer ist, ist jede Planungsentscheidung, die auf dieser Annahme basiert, falsch. Deine Sprint-Schätzungen sind falsch. Deine Personalprognosen sind falsch. Deine Zeit-bis-zur-Markteinführung-Ziele sind falsch. Und alle fühlen sich großartig dabei – bis zur Deadline.

Das ist kein Argument gegen KI-Codierungstools. Es ist ein Argument gegen deren Einsatz ohne Messung. Die Entwickler in der METR-Studie, die am meisten profitierten, waren diejenigen, die wussten, wann sie das Tool nicht mehr nutzen und die Arbeit selbst erledigen mussten. Das ist eine Fähigkeit, und die meisten Unternehmen schulen ihre Mitarbeiter nicht darin.

Devin und die Realität der Benchmarks

Sprechen wir über Devin, denn es ist zum Lackmustest dafür geworden, wie man über die Fähigkeiten von Agenten denkt.

Der Leistungsbericht von Cognition für 2025 besagt, dass 67 % von Devins Pull-Anfragen von menschlichen Prüfern zusammengeführt werden – ein Maß für die Akzeptanz der Ergebnisse, nicht für die autonome Erledigung von Aufgaben. Unabhängige Tests – bei denen echte Unternehmen Devin reale technische Aufgaben ohne kuratierte Setups übergaben – ergaben End-to-End-Erfüllungsraten von eher 14–30 %, je nach Komplexität der Aufgabe. Diese Kluft zwischen einer vom Anbieter ausgewählten Erfolgskennzahl und der tatsächlichen Erfüllungsrate in der Praxis ist an sich schon die Geschichte.

Um es klar zu sagen: 30 % bei wirklich frei definierbaren technischen Aufgaben sind immer noch beeindruckend. Und echte Unternehmen ziehen daraus Nutzen. Goldman Sachs nutzt Devin. Nubank nutzt Devin. Aber schau dir an, wofür sie es tatsächlich einsetzen: Sicherheitspatches, Erweiterung der Testabdeckung, Aktualisierung von Abhängigkeiten, Standardcode für Migrationen. Begrenzte Aufgaben mit objektiven Erfolgskriterien und geringer Mehrdeutigkeit. Niemand setzt Devin einfach auf eine komplett neue Architektur an und überlässt ihm dann die Arbeit.

Das Muster ist bereits erkennbar: Die Kluft zwischen Benchmarks und Produktion vergrößert sich in direktem Verhältnis dazu, wie viel Urteilsvermögen die Aufgabe erfordert.

Technische Schulden in Maschinen-Geschwindigkeit

GitClears Analyse der Trends in der Codequalität seit dem Mainstream-Durchbruch von KI-Codierungstools erzählt eine Geschichte, die jeden beunruhigen sollte, der über langfristige Codebasen nachdenkt. Die Code-Duplizierung hat sich etwa verachtfacht. Der Anteil des Entwicklungsaufwands, der für Refactoring aufgewendet wird – also die Arbeit, die Codebasen über Jahre hinweg wartbar hält – ist von rund 25 % auf unter 10 % gesunken.

Wir bauen technische Schulden in Maschinen-Geschwindigkeit auf. KI-Tools machen es kinderleicht, neuen Code zu generieren, und es ist äußerst verlockend, die mühsame Arbeit zu überspringen, ihn sauber in bestehende Systeme zu integrieren. Wenn dein Agent innerhalb von Sekunden eine funktionierende Funktion erstellen kann, sinkt der Anreiz, den umgebenden Code entsprechend anzupassen, auf nahezu null. Multiplizier das mit einem Team und über Monate hinweg, und du hast eine Codebasis, die schnell wächst und noch schneller verfällt.

46 % des auf GitHub eingecheckten Codes wird mittlerweile von KI generiert. In der W25-Runde von YC gaben 25 % der Startups an, dass ihre Codebasen zu 95 % oder mehr KI-generiert sind. Die Entwicklerumfrage 2025 von Stack Overflow ergab, dass nur 3 % der Entwickler KI-generierten Output „sehr vertrauen“, und 66 % beschrieben ihn als Lösungen, die „fast richtig“ sind. „Fast richtig“ ist in großem Maßstab eine ganz besondere Art von Katastrophe.

Die 90-prozentige Ausfallrate

Mehrere Branchenanalysen, darunter Untersuchungen des MIT und von Gartner, beziffern die Ausfallrate von Agent-Implementierungen der ersten Generation auf 70–95 %, wobei die meisten innerhalb weniger Wochen scheitern. Diese Zahl klingt dramatisch, bis man sich ansieht, was diese Implementierungen gemeinsam haben: vage Ziele, keine Erfolgskennzahlen, kein Rollback-Plan, keine menschlichen Überprüfungsinstanzen und Teams, die „einen Agenten implementieren“ als Strategie und nicht als technisches Projekt betrachteten.

Die Erzählung vom „autonomen Unternehmen“ ist hier aufschlussreich. Nat Eliasons Felix, das auf OpenClaw läuft und über Paperclip orchestriert wird, hat 177.000 Dollar erwirtschaftet. Das ist eine reale Zahl. Aber Felix ist ein eng gefasstes Kreativunternehmen mit vorlagenbasierten Aufgaben und einem geringen Schadensradius. Content-Erstellung, E-Mail-Sequenzen, Social-Media-Planung – Workflows, bei denen ein schlechtes Ergebnis zwar ärgerlich, aber nicht katastrophal ist. Der Umsatz ist real. Die Übertragbarkeit auf Unternehmen, die folgenreiche Entscheidungen treffen, ist es nicht.

Sicherheit: Die übersehene Krise

Die Geschwindigkeit der explosionsartigen Zunahme von Agenten hat die Sicherheit überholt. Die Entwicklung von OpenClaw ist bezeichnend: 247.000 Sterne, massive Verbreitung und dann CVE-2026-25253 – eine Schwachstelle zur Remote-Codeausführung mit einem Klick. Über vierzigtausend öffentlich exponierte Instanzen. Zwanzig Prozent der Pakete im ClawHub-Register enthalten nachweislich bösartigen Code. Prompt-Injection-Angriffe über Nachrichtenvorschauen ermöglichen die Ausführung von beliebigem Code.

Das ist keine Hypothese. Es handelt sich um Agenten mit Zugriff auf Codebasen, Bereitstellungspipelines und Produktionssysteme. Die Angriffsfläche eines Agenten ist nicht nur das Modell – es sind alle Tools, die der Agent aufrufen kann, jedes System, auf das er zugreifen kann, und jede nicht vertrauenswürdige Eingabe, die er verarbeitet. Die meisten Unternehmen, die Agenten einsetzen, haben noch nicht einmal begonnen, über diese Angriffsfläche nachzudenken.

Akt 2: Was tatsächlich funktioniert

Nachdem ich im letzten Abschnitt dargelegt habe, dass der Hype der Realität voraus ist, möchte ich ebenso ehrlich über die andere Seite sein: Einige Agenteneinsätze funktionieren. Und zwar gut. Und sie weisen ein Muster auf, das es wert ist, verstanden zu werden.

Das Muster hinter jedem Erfolg

Jeder erfolgreiche Agenteneinsatz, den ich gesehen oder untersucht habe, weist dieselbe DNA auf:

• Enger Anwendungsbereich. Der Agent erledigt eine Aufgabe oder eine kleine Gruppe verwandter Aufgaben.
• Objektive Erfolgskriterien. Man kann ohne subjektive Beurteilung messen, ob der Agent erfolgreich war.
• Begrenzter Schadensradius. Wenn der Agent versagt – und das wird er –, sind die Kosten des Versagens überschaubar.
• Menschliche Kontrollinstanzen bei irreversiblen Aktionen. Alles, was nicht rückgängig gemacht werden kann, durchläuft einen Schritt der menschlichen Überprüfung.
• Schrittweise Ausweitung des Vertrauens. Der Agent beginnt mit minimalen Befugnissen und verdient sich im Laufe der Zeit mehr.

Dieses Rahmenkonzept habe ich nicht erfunden. Es ist ein Muster, das ich aus der Beobachtung erfolgreicher Vorgehensweisen abgeleitet habe. Unternehmen, die sich daran halten, sind in der Regel erfolgreich. Unternehmen, die Schritte überspringen – insbesondere den letzten –, gehören meist zu den 90 %.

Beschleunigung der Forschung: Der Bereich mit der größten Glaubwürdigkeit

Wenn es einen Bereich gibt, in dem KI-Agenten eindeutig Ergebnisse liefern, dann ist es die automatisierte Forschung und das Experimentieren.

Andrej Karpathys Autoresearch-Setup führte in zwei Tagen 700 Experimente durch und entdeckte in 17 Stunden eigenständig Techniken wie RMSNorm und gebundene Einbettungen wieder – Erkenntnisse, für deren Entwicklung die Forschungsgemeinschaft Jahre gebraucht hatte. Tobi Lutke, CEO von Shopify, ließ es über Nacht laufen: 37 Experimente, 19 % Leistungssteigerung bei seiner Zielkennzahl. Das sind keine handverlesenen Demos. Das sind systematische Optimierungsläufe mit messbaren Ergebnissen.

Sakana AI veröffentlichte einen Artikel über von KI verfasste wissenschaftliche Forschung, der bei der ICLR-Peer-Review besser abschnitt als 55 % der von Menschen verfassten Artikel. In der Arzneimittelforschung durchlief Rentosertib von Insilico Medicine den Weg von der KI-gesteuerten Zielidentifizierung über die präklinische Entwicklung bis hin zu klinischen Ergebnissen der Phase IIa, die in Nature Medicine veröffentlicht wurden. Echte Patienten, echte klinische Ergebnisse, echte Peer-Review.

Ich nutze Loops im Autoresearch-Stil für die ML-Optimierung in meinen eigenen Projekten. Der Produktivitätsgewinn ist real – aber nur, weil ich den Suchraum definiere, die Einschränkungen festlege und die Ergebnisse überprüfe. Der Agent führt 100-mal mehr Experimente durch, als ich es könnte. Ich entscheide immer noch, welche Experimente es wert sind, durchgeführt zu werden.

Dieser Unterschied ist entscheidend. Es handelt sich um automatisierte Optimierung innerhalb bekannter Designräume, nicht um eine offene Entdeckung. Autoresearch kann nur Experimente durchführen, die in Python innerhalb der von dir definierten Parameter ausdrückbar sind. Es ist ein leistungsstarkes Werkzeug, kein Forscher. Die Unternehmen und Labore, die davon profitieren, verstehen das. Diejenigen, die das nicht tun, werden 700 Experimente durchführen und nichts Nützliches lernen.

Der Fall der Arzneimittelforschung ist es wert, näher betrachtet zu werden, da er die Grenzen der aktuellen Fähigkeiten des Agenten verdeutlicht. Insilico Medicine hat einem Agenten kein leeres Blatt Papier gegeben und gesagt: „Finde ein Krebsmedikament.“ Sie nutzten KI, um ein spezifisches Zielmolekül zu identifizieren, dann nutzten sie KI, um für dieses Zielmolekül optimierte Molekülkandidaten zu generieren, und führten diese Kandidaten anschließend durch die standardmäßige klinische Pipeline. Die KI beschleunigte jede Phase. Sie hat keine Phase übersprungen. Der Zulassungsprozess, die klinischen Studien, die Begutachtung durch Fachkollegen – alles menschlich. Der Agent trug zu Geschwindigkeit und Reichweite innerhalb eines klar definierten wissenschaftlichen und regulatorischen Rahmens bei. Das ist das Modell.

Kundensupport: Der deutlichste Produktionserfolg

Im Kundensupport weisen Agenten die stärkste Erfolgsbilanz in der Produktion auf, und der Grund dafür ist struktureller Natur: Supportanfragen haben klare Lösungskriterien, einen begrenzten Umfang und natürliche Eskalationswege, wenn der Agent versagt.

Intercoms Fin löst 51 % der Supportanfragen ohne menschliches Eingreifen. Das ist keine Pilotzahl – es ist Produktion in großem Maßstab über den gesamten Kundenstamm hinweg. Die Erfolgsgeschichten einzelner Unternehmen sind sogar noch eindrucksvoller: Synthesia meldete eine Selbstbedienungsquote von 98,3 % bei einem Volumenanstieg von 690 %. Esusu erreichte eine E-Mail-Automatisierung von 64 % mit einer Verbesserung der Kundenzufriedenheitswerte um 10 Punkte.

Das Muster bleibt bestehen: enger Anwendungsbereich (Beantwortung von Fragen zu unserem Produkt), objektive Erfolgskriterien (wurde das Problem des Kunden gelöst?), begrenzter Schadensradius (im schlimmsten Fall wird der Kunde an einen Menschen weitergeleitet) und menschliche Kontrollpunkte (komplexe oder sensible Fälle werden automatisch an Agenten weitergeleitet).

Programmierende Agenten: Die nuancierte Realität

Ich arbeite jeden Tag mit Claude Code. Es ist das Tool, mit dem ich die direkteste Erfahrung habe, daher möchte ich konkret darauf eingehen, was funktioniert und was nicht.

Mein Produktivitätsgewinn resultiert nicht aus dem Code, den es schreibt, sondern aus den Leitplanken, die ich darum herum aufgebaut habe. Hooks, die Schreibvorgänge in die main-Datei blockieren. Pre-Commit-Prüfungen, die Stilverstöße und Typfehler abfangen. Subagent-Reviews, die nach Sicherheitsproblemen suchen. Deploy-Check-Pipelines, die alles validieren, bevor es ausgeliefert wird. Je mehr Schutzmechanismen ich hinzufüge, desto mehr kann ich dem Tool vertrauen. Das ist keine Einschränkung – das ist das Designmuster.

Ohne diese Schutzmechanismen ist KI-unterstütztes Programmieren ein Risiko. Mit ihnen ist es ein echter Multiplikator. Der Unterschied liegt nicht im Modell. Der Unterschied liegt im Rahmenwerk.

Dies spiegelt sich in den übergeordneten Daten wider. GitHub berichtet, dass mittlerweile 46 % des eingecheckten Codes von KI generiert wird. Die Zahlen von Stack Overflow zeigen jedoch die andere Seite der Medaille: Entwickler wissen, dass die Ergebnisse unzuverlässig sind. Die guten unter ihnen haben sich darauf eingestellt, indem sie Überprüfungen und Validierungen in ihren Arbeitsablauf integriert haben. Diejenigen, die dies nicht getan haben, produzieren in großem Umfang „fast richtigen“ Code, und die Kosten für „fast richtig“ summieren sich schneller, als den meisten Menschen bewusst ist.

Ich stelle mir das wie Elektrowerkzeuge in einer Werkstatt vor. Eine Tischsäge macht einen erfahrenen Tischler dramatisch produktiver. Sie macht einen unerfahrenen Tischler dramatisch gefährlicher. Das Werkzeug verstärkt das, was man selbst einbringt. Dieselbe Claude-Code-Sitzung, die mir bei einer klar definierten Aufgabe drei Stunden spart, kann mich fünf Stunden kosten, wenn ich sie nachlässig nutze – wenn ich Code ohne klare Vorgaben generiere, Vorschläge akzeptiere, ohne sie zu lesen, und den Überprüfungsschritt überspringe, weil die Ausgabe „richtig aussieht“. Das Werkzeug hat sich nicht verändert. Meine Disziplin schon.

Die unangenehme Voraussetzung

Hier ist die Erkenntnis, die alles zusammenführt, und es ist eine, von der die meisten Anbieter von Agenten nicht wollen, dass du sie hörst:

Agenten ersetzen keine technische Disziplin. Sie legen deren Fehlen offen.

Unternehmen, die mit Agenten scheitern, sind in der überwiegenden Mehrheit dieselben Unternehmen, die keine Tests, keine Dokumentation, keine CI/CD-Pipeline, keine Kultur der Codeüberprüfung und keine Bereitstellungsstandards hatten. Agenten haben das Problem nicht verursacht. Sie haben es mit maschineller Geschwindigkeit verstärkt.

Ein Coding-Agent, der in einer Codebasis ohne Tests eingesetzt wird, generiert schneller ungetesteten Code. Ein Agent, der in einem System ohne Logging eingesetzt wird, verursacht schneller nicht beobachtbare Fehler. Ein Agent, der ohne Deployment-Gates Zugriff auf die Produktion erhält, liefert schneller fehlerhaften Code an die Nutzer aus.

Die Voraussetzung für den Einsatz von Agenten ist nicht bessere KI. Es ist technische Reife. Unternehmen, die in die Grundlagen investiert haben – Tests, CI/CD, Observability, Code-Review, Dokumentation – stellen fest, dass sich Agenten nahtlos einfügen. Unternehmen, die nicht in die Grundlagen investiert haben, stellen fest, dass Agenten ihre bestehenden Missstände beschleunigen.

Wenn du aus diesem ganzen Artikel nur eine Sache mitnimmst, dann sollte es diese sein: Bevor du Agenten einsetzt, bring deine technischen Grundlagen in Ordnung. Der Ertrag dieser Investition wird jeden Produktivitätsgewinn, den der Agent verspricht, in den Schatten stellen, und im Gegensatz zur Leistung des Agenten wächst er im Laufe der Zeit zuverlässig an.

Akt 3: Wie man sich anpasst

Das EU-KI-Gesetz als Designbeschränkung

Das Wort „agentic“ kommt in den 113 Artikeln des EU-KI-Gesetzes nicht vor. Die Verordnung wurde nicht für KI-Agenten geschrieben. Aber sie gilt für sie, und mit dem vollständigen Inkrafttreten der Vorschriften für Hochrisikosysteme ab dem 2. August 2026 – schließt sich das Zeitfenster, um Compliance als ein Problem der Zukunft zu betrachten.

Hier liegt der Irrtum der meisten Unternehmen in Bezug auf das Gesetz: Sie betrachten es als pauschale Regelung für KI-Technologie. Das ist es nicht. Die Risikoklassifizierung erfolgt auf der Grundlage von Anwendungsfällen. Dieselbe Agentenarchitektur ist bei interner Forschung mit minimalem Risiko verbunden, bei Einstellungsentscheidungen, Bonitätsprüfungen oder sicherheitskritischen Entscheidungen jedoch mit hohem Risiko. Deine Verpflichtungen hängen davon ab, was der Agent tut, nicht davon, wie er funktioniert.

Dies schafft eine praktische Herausforderung, mit der sich die meisten Organisationen noch nicht auseinandergesetzt haben. Ein einzelner Orchestrator-Agent, der Aufgaben an Unteragenten weiterleitet, kann für manche Aufgaben ein minimales Risiko darstellen und für andere ein hohes Risiko, je nachdem, welche nachgelagerten Entscheidungen durch seine Ausgabe beeinflusst werden. Anhang III des Gesetzes listet die Hochrisikokategorien auf, aber die Zuordnung deiner tatsächlichen Agenten-Workflows zu diesen Kategorien erfordert ein Verständnis deines Systems auf einer Ebene, die die meisten Unternehmen nicht dokumentiert haben.

Die Anforderung an die menschliche Aufsicht in Artikel 14 führt zu einer strukturellen Spannung mit autonomen Agenten. Die Verordnung verlangt eine sinnvolle menschliche Überprüfung – nicht nur einen nominellen „Übersteuerungs“-Knopf, den niemand drückt. Für Agentensysteme, die Entscheidungen in Maschinen-Geschwindigkeit treffen, ist die Gestaltung von Überprüfungsschritten, die wirklich sinnvoll (und nicht nur pro forma) sind, ein offenes Designproblem.

Dann gibt es noch die Lücke bei der Rechenschaftspflicht. Wenn ein Orchestrator-Agent Aufgaben an Unteragenten delegiert und ein Schaden entsteht, wer trägt dann die Verantwortung? Der Bereitsteller? Der Anbieter des Orchestrators? Der Anbieter des Unteragenten, der die schädliche Ausgabe erzeugt hat? Die Rechenschaftspflicht bei Multi-Agenten-Systemen ist eine rechtliche Frage, die das Gesetz nicht eindeutig klärt, und es ist eine Frage, mit der sich die Gerichte noch jahrelang beschäftigen werden.

92 Prozent der CISOs in Unternehmen geben an, keinen Überblick über die Identitäten der KI-Agenten in ihren Organisationen zu haben. Die meisten Unternehmen haben noch nicht einmal den ersten Schritt getan, um zu verstehen, welche Agenten sie einsetzen, auf welche Daten diese Agenten zugreifen können und welche Entscheidungen diese Agenten beeinflussen. Das ist eine Lücke in der Governance, die durch die Regulierung schmerzlich offengelegt werden wird.

Wenn ich Start-ups zur Agentenarchitektur berate, nutze ich mittlerweile die Risikoklassifizierung des EU-KI-Gesetzes als Checkliste für das Design – selbst für Unternehmen außerhalb der EU. Die Fragen, zu denen sie einen zwingt (Welche Entscheidungen trifft dieser Agent? Was ist der Worst-Case-Fehlermodus? Wer überprüft die Ausgabe? Wie auditiert man die Entscheidungskette?), sind dieselben Fragen, die gutes Engineering ohnehin erfordert. Die Regulierung hat diese Fragen nicht erfunden. Sie hat sie lediglich verbindlich gemacht.

Ich werde nicht so tun, als sei das Gesetz einfach oder als würde es Multi-Agenten-Systeme elegant behandeln – das tut es nicht, und die Lücke zwischen den statischen Risikokategorien der Verordnung und dem dynamischen Verhalten von Agentensystemen ist real. Aber als treibende Kraft, um die richtigen Fragen zu stellen, ist es nützlicher, als die meisten Ingenieure ihm zutrauen.

Das praktische Anpassungs-Framework

Basierend auf dem von mir beschriebenen Muster – enger Anwendungsbereich, objektive Kriterien, begrenzter Schaden, menschliche Kontrollinstanzen, schrittweises Vertrauen – würde ich Organisationen folgende Vorgehensweise bei der Einführung von Agenten empfehlen:

1. Prüfe deine Anwendungsfälle anhand von Anhang III

Beginn nicht mit der Frage „Nutzen wir KI?”, sondern mit der Frage „Beeinflusst die Ausgabe unseres Agenten direkt Entscheidungen in den Bereichen Personal, Kreditvergabe, Gesundheitswesen, Bildung oder Sicherheit?” Wenn die Antwort für irgendeinen Arbeitsablauf „Ja” lautet, befindest du dich in einem Hochrisikobereich, ob du dir dessen bewusst bist oder nicht.

Ordne jeden von Agenten berührten Arbeitsablauf den Risikokategorien des Gesetzes zu. Diese Übung ist auch dann wertvoll, wenn du niemals an einen EU-Kunden verkaufst, denn sie zwingt dich dazu, zu formulieren, was deine Agenten tatsächlich tun und welche Folgen sich daraus ergeben. Die meisten Teams können diese Frage nicht präzise beantworten, und das ist ein Problem, das unabhängig von der Regulierung besteht.

2. Bau auf eine begrenzte Ausweitung des Vertrauens

Lass Agenten mit Aufgaben beginnen, bei denen wenig auf dem Spiel steht und die rückgängig gemacht werden können. Überwache ihre Leistung streng. Gewinn Vertrauen durch Daten. Erweitere den Umfang nur, wenn die Daten dies rechtfertigen.

Das klingt selbstverständlich, und doch ist das häufigste Muster, das ich beobachte, das Gegenteil: Unternehmen geben Agenten vom ersten Tag an weitreichende Befugnisse, erleben einen Fehlschlag und geben den Einsatz entweder ganz auf oder überkorrigieren mit einem so aufwendigen Überprüfungsprozess, dass der Agent keinen Produktivitätsgewinn mehr bringt.

Der schrittweise Ansatz ist anfangs langsamer, langfristig aber schneller. Er schafft ein Verständnis innerhalb der Organisation dafür, wo Agenten einen Mehrwert schaffen und wo nicht. Er liefert die Überwachungsdaten, die du benötigst, um fundierte Entscheidungen über die Erweiterung des Anwendungsbereichs zu treffen. Und, was entscheidend ist: Er ermöglicht es dir, während des Lernprozesses kostengünstig zu scheitern.

In meiner eigenen Arbeit sieht das so aus, dass ich Paperclip zunächst in einem einzigen Workflow starte – der Planung von Social-Media-Beiträgen aus vorab genehmigten Inhalten – und ihn zwei Wochen lang mit vollständiger Protokollierung laufen lasse, bevor ich auf die Erstellung von E-Mail-Entwürfen ausweite. Dann lasse ich das einen Monat lang laufen, bevor ich irgendetwas in Betracht ziehe, das den Kunden betrifft. Jede Erweiterung wurde durch Daten aus der vorherigen Phase gestützt. Jede Phase hatte einen Rollback-Plan. Die Gesamtzeit vom ersten Einsatz bis zum sinnvollen Anwendungsbereich betrug etwa drei Monate. Die Gesamtkosten für Agent-Ausfälle während dieses Zeitraums lagen nahe Null, da jeder Ausfall in einem risikoarmen Kontext mit Überwachung stattfand.

3. Compliance in einen Wettbewerbsvorteil verwandeln

Dies gilt speziell für B2B-Unternehmen in regulierten Branchen, stellt jedoch eine echte strategische Chance dar. Unternehmenskunden aus den Bereichen Finanzen, Gesundheitswesen und kritische Infrastruktur bevorzugen zunehmend Anbieter, die ihre Compliance-Fläche reduzieren, anstatt sie zu vergrößern. Wenn dein Agentensystem EU-AI-Act-konform ist – mit dokumentierten Risikobewertungen, Prüfpfaden, Mechanismen zur menschlichen Aufsicht und Verfahren zur Reaktion auf Vorfälle –, ist dies ein Alleinstellungsmerkmal in Verkaufsgesprächen mit Unternehmen.

Die meisten deiner Wettbewerber denken noch nicht darüber nach. Diejenigen, die Compliance als lästige Pflicht betrachten, werden unvorbereitet sein, wenn ihre Unternehmenskunden dies verlangen. Diejenigen, die dies von Anfang an einbauen, verfügen bereits über die Dokumentation, die Architektur und die Betriebshistorie.

4. Investiere zuerst in technische Grundlagen

Wenn du keine Tests, CI/CD, Code-Reviews und Protokollierung hast, solltest du das vor der Bereitstellung von Agenten nachholen. Ich wiederhole es noch einmal, denn dies ist die wichtigste Empfehlung in diesem Artikel: Agenten auf einer schwachen technischen Grundlage führen schnell zu kostspieligen Ausfällen.

Konkret:

• Testen. Agenten generieren Code, der getestet werden muss. Wenn du keine Testinfrastruktur hast, stellst du ungetesteten Code mit Maschinen-Geschwindigkeit bereit.
• CI/CD. Agenten benötigen Deployment-Gates. Wenn dein Code ohne automatisierte Prüfungen vom Commit in die Produktion gelangt, wird ein Agent-Ausfall zu einem Produktionsvorfall.
• Observability. Wenn du nicht sehen kannst, was deine Agenten tun, kannst du keine Fehler beheben, die Leistung verbessern oder Audit-Anforderungen erfüllen.
• Code-Review. Die manuelle Überprüfung von agentengeneriertem Code ist kein Mehraufwand. Es ist der Mechanismus, der die „fast richtigen“ Lösungen auffängt, bevor sie ausgeliefert werden.

Der Ertrag dieser Investitionen besteht unabhängig von Agenten. Aber Agenten steigern den Ertrag jeder einzelnen davon dramatisch.

5. Entwirf Audit-Trails vom ersten Tag an

Artikel 26 des EU-KI-Gesetzes schreibt für risikoreiche Systeme eine sechsmonatige Aufbewahrungspflicht für Protokolle vor. Doch selbst ohne diese gesetzliche Anforderung gilt: Wenn du nicht nachvollziehen kannst, was dein Agent getan hat, welche Eingaben er erhalten hat, welche Entscheidungen er getroffen hat und welche Ausgaben er erzeugt hat, kannst du ihn nicht debuggen, verbessern oder ihm vertrauen.

Entwirf deine Agentensysteme so, dass Protokollierung und Rückverfolgbarkeit von Anfang an im Vordergrund stehen und nicht erst nachträglich berücksichtigt werden. Jede Aktion eines Agenten sollte auf einen Auslöser zurückverfolgt werden können. Jede Entscheidung sollte rekonstruierbar sein. Jede Ausgabe sollte zuordenbar sein. Das ist nicht nur Compliance – es ist technische Sorgfalt, die deine Systeme debuggbar und verbesserungsfähig macht.

Die Unternehmen, die den größten Aufwand in Audit-Trails investieren, werden am meisten von Agenten profitieren, denn sie sind es, die tatsächlich aus dem Verhalten von Agenten in großem Maßstab lernen können.

---

Was das bedeutet

Der Wendepunkt bei der Nutzung von Agenten ist real. Die Tools sind ausgereift. Die Fähigkeiten sind echt. Und der Hype überholt die Realität um ein Maß, das für viele Unternehmen teuer zu stehen kommen wird.

Die Unternehmen, die Erfolg haben werden, sind nicht diejenigen, die Agenten am schnellsten einsetzen. Es sind diejenigen, die Agenten am durchdachtesten einsetzen – mit Leitplanken, die es ihnen ermöglichen, sicher schneller voranzukommen, mit technischer Disziplin, die es Agenten ermöglicht, Kompetenz statt Chaos zu verstärken, und mit einer Compliance-Haltung, die Regulierung in einen Wettbewerbsvorteil verwandelt.

Das Muster ist klar. Eingeschränkter Umfang. Objektive Kriterien. Begrenzter Schaden. Menschliche Kontrollpunkte. Schrittweises Vertrauen. Technische Reife. Jeder erfolgreiche Agenteneinsatz folgt diesem Weg. Jeder Misserfolg überspringt einen dieser Schritte.

Die Frage ist nicht, ob Agenten die Art und Weise verändern werden, wie wir Software entwickeln und Unternehmen führen. Das werden sie. Die Frage ist, ob du diesen Wendepunkt mit der erforderlichen Disziplin nutzt oder ob du unter den technischen Schulden, Sicherheitsrisiken und Compliance-Lücken begraben wirst, die entstehen, wenn man ohne Fundament zu schnell voranschreitet.

Die Daten zeigen, dass die meisten Unternehmen hier Fehler machen werden. Die Chance liegt darin, zu denjenigen zu gehören, die das nicht tun.

Ich möchte dir noch etwas mit auf den Weg geben, das ich in jedem Beratungsauftrag, bei jedem Robotik-Startup und in jedem Gespräch über KI-Systemdesign in den letzten zwei Jahren beobachtet habe: Die Organisationen, die am meisten aus KI-Agenten herausholen, sind niemals diejenigen mit den besten Modellen oder der ausgefeiltesten Orchestrierung. Es sind diejenigen mit dem klarsten Verständnis ihrer eigenen Prozesse, der ehrlichsten Einschätzung, wo Urteilsvermögen gefragt ist, und der Disziplin, schrittweise vorzugehen.

Das ist kein technologisches Problem. Es ist ein Problem der Ingenieurskultur. Und im Gegensatz zur Modellfähigkeit liegt es vollständig in deiner Hand.

• Bewertung agentischer KI
• Entwurf von Agentensystemen
• Einhaltung des EU-KI-Gesetzes
• Fractional CTO