OpenClaw hat die Debatte über KI verschoben. Weg vom Chatfenster, hin zu Systemen, die selbst handeln. Das ist die richtige Richtung. Und ein Problem. Denn die KI-Strategie der meisten Unternehmen besteht bisher aus kaum mehr als einem Chatbot. Für agentische Features, die Daten schreiben, Workflows auslösen und Entscheidungen treffen, fehlt das Fundament. Ich nenne es AI Systems Architecture.
Die Reaktion auf OpenClaw war entsprechend gespalten: Die einen wollen sofort loslegen. Die anderen sehen nur das Risiko. Beide haben einen Punkt. Und beide liegen falsch. Die eigentliche Frage lautet: Wie baut man agentische AI-Features so, dass man ihnen vertrauen kann?
Der Hebel ist da. Ein AI-Feature, das aus einer wirren Kunden-E-Mail erkennt, welche Abteilung zuständig ist, das Anliegen kategorisiert und eine Ersteinschätzung mitliefert, bevor ein Mensch es überhaupt sieht. Ein Agent, der Schadensmeldungen nicht nur entgegennimmt, sondern klassifiziert, priorisiert und der zuständigen Stelle die relevanten Daten aufbereitet zuschiebt. In vielen Unternehmen liegen diese Informationen in Tickets, Wikis, E-Mail-Postfächern und Freitextfeldern. Bisher nie systematisch nutzbar, weil die manuelle Pflege zu aufwendig war.
Aber dafür reicht kein Prompt.
Es reicht nicht, wenn es im Chat funktioniert
Die AI-Fails der letzten Jahre kennt mittlerweile jeder. Der Chevrolet-Chatbot, der einem Kunden ein Auto für einen Dollar “verkauft” hat1. Der Air-Canada-Bot, der Trauertarif-Regeln erfunden hat, für die die Airline dann haften musste2. Der New Yorker Stadtchatbot, der Unternehmen geraten hat, gegen Arbeitsrecht zu verstoßen3. Peinlich, teuer, viral.
Aber das waren Chatbots. Die Konsequenzen waren überschaubar: ein PR-Desaster, ein Gerichtsurteil über 812 Dollar, ein deaktiviertes Feature.
Was seit 2025 passiert, ist eine andere Größenordnung. Bei Replit hat ein AI-Agent im Juli 2025 eine Live-Produktionsdatenbank mit Unternehmens- und Kontaktdaten gelöscht. Danach hat er viertausend Fake-Einträge fabriziert, um die Löschung zu vertuschen4. Ein expliziter Code Freeze in Großbuchstaben wurde ignoriert. Im März 2026 hat bei DataTalks.club ein Claude-Code-Agent die Produktionsinfrastruktur samt Datenbank zerstört. Allein in der Tabelle courses_answer lagen 1.943.200 Zeilen5. Ein alter Terraform-State traf beim destroy die echte Produktionsumgebung.
Die Kontexte sind verschieden: Kundenchats, Coding Agents, Ops-Workflows. Das Muster ist dasselbe. Sobald Modelle nicht nur antworten, sondern handeln, steigt das Schadenspotenzial massiv. Wer einem AI-Feature erlaubt, Daten zu schreiben, Workflows auszulösen oder Entscheidungen vorzubereiten, muss wissen, wie man so ein System baut, betreibt und überwacht. Sonst verschiebt sich das Muster: von “der Chatbot hat etwas Dummes gesagt” zu “der Agent hat etwas Irreversibles getan”.
Die Branche schaut in die falsche Richtung
Die Debatte dreht sich fast ausschließlich um Agentic Software Engineering. Coding Agents, Spec-Driven Development, Context Engineering. Alles wichtig. Aber es beantwortet eine andere Frage als die, die gerade dringend wird.
Agentic Software Engineering fragt: Wie baue ich Software mit Hilfe von AI? AI Systems Architecture fragt: Wie baue ich Software, die AI als Feature enthält und in Produktion zuverlässig funktioniert?
Der entscheidende Unterschied: Beim agentischen Entwickeln bin ich der Mensch im Loop. Ich sehe jede Antwort, ich entscheide, ob der Code passt. Bei einem AI-Feature in Produktion sieht der Nutzer die Antwort. Oder schlimmer: Ein nachgelagertes System verarbeitet sie automatisch weiter. Da steht niemand mehr daneben. Und selbst wo ein Mensch am Ende prüft - wenn das System ihm plausibel klingenden Unsinn liefert, fängt er ihn nicht auf.
Teams nehmen die Geschwindigkeit aus dem Prototyping mit in die Feature-Entwicklung und überspringen alles, was ein AI-Feature produktionsreif macht.
Was AI Systems Architecture ausmacht
Ein Sprachmodell ist kein deterministischer Service. Es ist eine probabilistische Komponente. Leistungsfähig, aber unzuverlässig. Wer es in Produktlogik einbindet, braucht die gleiche Disziplin wie bei jeder anderen fehleranfälligen Abhängigkeit: Verträge, Tests, Monitoring.
AI Systems Architecture ist genau das. Was Softwarearchitektur für die Softwareentwicklung ist, ist AI Systems Architecture für AI Engineering: die Disziplin für die Entscheidungen, die später teuer zu ändern sind. Welches Schema definiert den Contract zwischen Modell und Fachlogik? Wie wird Qualität gemessen? Was darf das System autonom, was braucht menschliche Freigabe? Diese Entscheidungen fallen am Anfang. Oder sie fallen einem später auf die Füße.
Ruben Vitt hat dafür drei Prinzipien formuliert: Contract-first statt Prompt-first, Evaluation statt Bauchgefühl, Observability statt Blindflug. Ich ergänze ein viertes: Action Safety. Was das konkret bedeutet, lässt sich an einem Beispiel durchspielen.
NOTE
Beispiel: Schadensmeldung bei einer Versicherung
Eine Versicherung bekommt Schadensmeldungen per E-Mail. Ein Kunde meldet einen Wasserschaden. Drei Absätze, emotional, unstrukturiert, die Hälfte der Informationen fehlt. Dazu vier Handyfotos vom Keller. Heute landet das in einem Postfach. Ein Sachbearbeiter liest, tippt alles in ein Formular, ordnet zu, priorisiert, leitet weiter. Etwa dreißig Minuten pro Fall.
Bisher war das nicht anders lösbar. Unstrukturierter Text, Bilder, fehlende Angaben - kein regelbasiertes System konnte das zuverlässig verarbeiten. Mit Sprachmodellen ändert sich das. Zum ersten Mal lässt sich dieser Prozess maschinell unterstützen. Aber nur, wenn man ihn als System denkt.
Contract-first statt Prompt-first. Bevor ein Prompt geschrieben wird, steht der Vertrag. Das Modell liefert ein definiertes Schema: Schadenskategorie (Enum: Wasser, Feuer, Einbruch, Sturm, Unklar), Priorität (1-3), betroffene Vertragsnummer, geschätzte Schadenshöhe, fehlende Unterlagen, dazu ein Feld needs_human_review für Fälle, in denen das Modell unsicher ist. Kein Freitext. Das Schema begrenzt die Form der Ausgabe, schützt aber nicht vor fachlich falschen Werten in validen Feldern. Dafür braucht es Validierung und Evals.
Evaluation statt Bauchgefühl. Einige hundert historische Schadensmeldungen, manuell gelabelt. Wird ein Wasserschaden als Einbruch klassifiziert? Erfindet das Modell Vertragsnummern? Diese Tests laufen bei jedem Modellwechsel, jedem Prompt-Update, jedem Deployment, automatisiert in der CI-Pipeline. “Sieht im Chat gut aus” ist kein Test. Wer ohne Evals ausliefert, verschiebt das Testen an echte Nutzer.
Observability statt Blindflug. Jede Klassifikation wird geloggt: Modellversion, Schema-Fehlerrate, Anteil menschlicher Korrekturen, Fehlerquote je Falltyp. Wenn die Trefferquote bei Wasserschäden über Wochen sinkt, schlägt das Monitoring an. Bei DPD hat ein System-Update das Verhalten des Bots unkontrolliert verändert6. Ohne Monitoring fiel das erst auf, als es viral ging.
Action Safety statt Vollzugriff. Das System darf klassifizieren und Vorschläge strukturieren, aber nicht eigenständig Kunden benachrichtigen, Fälle routen oder Zahlungen auslösen. Lese- und Schreibrechte sind getrennt. Neue Modellversionen laufen erst im Sandbox-Modus gegen historische Fälle. Beim Replit-Vorfall hatte der Agent vollen Schreibzugriff ohne jede Einschränkung4. Gelöschte Produktionsdatenbank, viertausend fabrizierte Fake-Einträge.
Ergebnis: Der Sachbearbeiter sieht nicht mehr die Roh-E-Mail, sondern einen vorklassifizierten, strukturierten Fall, abgesichert durch Contract, Evaluation, Monitoring und klare Berechtigungsgrenzen. Er prüft, korrigiert wenn nötig, gibt frei. Erst dann wird geroutet, der Kunde benachrichtigt, Unterlagen angefordert. Aus etwa dreißig Minuten manueller Triage werden wenige Minuten qualifizierte Prüfung.
Warum die meisten das unterschätzen
Ein Prototyp sieht schnell nach Produkt aus. Ein paar gute Prompts, ein Coding Agent, etwas Hartnäckigkeit, und es steht eine beeindruckende Demo im Browser. Dabei fängt die eigentliche Arbeit erst an.
Was passiert, wenn der Modellanbieter still ein Update ausrollt und die Qualität kippt? Wenn ein Edge Case auftaucht, den niemand getestet hat? Wenn das Feature technisch valide Ergebnisse produziert, die fachlich Unsinn sind, und niemand es merkt, weil kein Monitoring existiert?
Schlechte Chatbots fallen auf. Leistungsfähige AI-Systeme mit Systemzugriff scheitern leise.
Die Antworten klingen plausibel. Die Aktionen sind technisch korrekt. Erst wenn jemand genau hinsieht, wird klar, dass das System seit Wochen falsche Entscheidungen getroffen hat.
Eine eigenständige Disziplin
Agentic Software Engineering hat sich als Disziplin etabliert, mit Methoden, Frameworks und Best Practices. Für AI-Features in Produktion fehlt ein vergleichbarer Rahmen. Dabei sind die Entscheidungen hier mindestens genauso weitreichend.
Contract-Design, Evaluationsstrategie, Observability, Berechtigungsmodelle, Action Safety: das sind keine Implementierungsdetails. Das sind Architektur-Entscheidungen, die vor der ersten Zeile Code fallen müssen. Und wie bei jeder Architektur geht es dabei um Trade-offs, die man bewusst abwägen muss. Nicht um eine Lösung, die für alle passt.
Die Technik dafür existiert. Was fehlt, ist die Disziplin, AI-Features als System zu denken. Bevor Teams anfangen zu bauen, nicht als Checkbox vor dem Go-Live. Welche konkreten Entscheidungen das sind und welche Trade-offs dahinterstecken, ist Thema eines Folgeartikels.
Weiterlesen: Ruben Vitt zeigt in AI Systems Architecture beginnt dort, wo Modelloutput Teil der Produktlogik wird und Evals in der CI, wie Contracts mit Zod, Eval-Frameworks und Observability konkret aussehen.
Footnotes
-
VentureBeat: A Chevy for $1? Car dealer chatbots show perils of AI for customer service (Dezember 2023) ↩
-
CBC News: Air Canada found liable for chatbot’s bad advice on bereavement discounts (Februar 2024) ↩
-
The Markup: NYC’s AI Chatbot Tells Businesses to Break the Law (März 2024) ↩
-
Fortune: AI coding tool Replit wiped a production database in what its CEO called a ‘catastrophic failure’ (Juli 2025) ↩ ↩2
-
Alexey Grigorev: How I Dropped Our Production Database and Now Pay 10% More for AWS (März 2026) ↩
-
TIME: AI Chatbot Curses at Customer and Criticizes Company After DPD Update (Januar 2024) ↩