Das Feature lief im Sprint-Review. Alle waren begeistert, der Prompt lieferte saubere Antworten, das Management nickte. Drei Wochen nach dem Go-live häufen sich die Tickets: falsche Ausgaben, niemand merkt es rechtzeitig, die Kosten explodieren, und keiner kann erklären, warum. Die Frage ist nicht, ob dein Modell gut genug ist. Die Frage ist, was zwischen Demo und Produktion eigentlich passieren muss.
Das Modell ist nie das Problem — seine Einbettung schon
Eine KI-Demo beweist genau eine Sache: dass der Prompt unter kontrollierten Bedingungen ein plausibles Ergebnis liefert. Mehr nicht. Sie sagt nichts darüber, ob das Feature trägt, wenn echte Daten, echte Last und echte Nutzer:innen darauf treffen.
Der Grund, warum so viele KI-Features den Sprung nicht schaffen, liegt selten am Modell. Er liegt an den Fragen, die in der Demo niemand stellt: Wer definiert, welche Daten das Modell strukturiert liefern muss, damit der Rest des Systems damit arbeiten kann? Wer merkt es, wenn die Qualität langsam abrutscht? Wer darf welche Aktion auslösen — und wer muss freigeben? Was kostet das Ganze pro Anfrage, und wie sehen wir das überhaupt?
Das sind keine Modell-Fragen. Das sind Architektur-Fragen. Und solange sie unbeantwortet bleiben, ist jedes KI-Feature ein Prototyp im Produktiv-Kostüm — nichtdeterministisch, undurchsichtig und im Zweifel teuer.
Wer KI als reine Prompt-Disziplin behandelt, behandelt das Symptom. Das eigentliche Thema ist die Systemschicht darunter.
Behandle das KI-Feature als Architektur, nicht als Prompt
Der entscheidende Perspektivwechsel ist unbequem, weil er die Verantwortung verschiebt: weg von „besseren Prompts“, hin zu besserer Struktur. Ein KI-Feature ist kein Stück Text, das man optimiert, bis es passt. Es ist ein nichtdeterministischer Baustein in einem deterministischen System — und genau diese Grenze muss man bewusst gestalten.
Ob ein KI-Feature in Produktion trägt, entscheidet nicht der Prompt — sondern die Architektur um ihn herum.
Sobald du das Feature als Architektur denkst, ändern sich die Werkzeuge. Du fängst mit einem Vertrag an, nicht mit einem Prompt. Du baust Qualitätssicherung als Quality Gate, nicht als Bauchgefühl. Du machst Kosten, Latenz und Qualität sichtbar, bevor du skalierst. Und du klärst Governance, bevor ein autonomer Agent auf deine Daten losgelassen wird — nicht danach.
Sechs Ebenen zwischen Demo und Produktion
Die vier Schichten eines tragfähigen KI-Features
Die Frage „Demo oder Produktion?“ lässt sich auf vier Architekturebenen herunterbrechen. Contract-first Design legt fest, welche strukturierten Daten das Modell liefern muss, bevor überhaupt ein Prompt entsteht. Evaluations werden als Quality Gate in die Pipeline integriert, statt am Nutzer zu testen. Control regelt über Tool-Security, Policy-Gates und Human-in-the-Loop, wer was auslösen darf. Observability macht Latenz, Kosten, Token-Verbrauch und Qualität eines nichtdeterministischen Systems überhaupt erst sichtbar. Du nimmst eine Landkarte mit, an der du jedes KI-Feature entlang prüfen kannst.
→ AI Systems Architecture beim Software Architecture Summit mit Ruben Vitt und Michael Seel
RAG, MCP und MLOps an echten Szenarien
Viele KI-Trainings bleiben abstrakt — und genau daran scheitert der Transfer in Produktion. Dieses zweitägige Bootcamp setzt auf den Lebenszyklus eines KI-Projekts: Tag eins baut Retrieval-Augmented-Generation-Anwendungen und setzt das Model Context Protocol praktisch ein. Tag zwei bringt diese Modelle mit MLOps-Methoden zuverlässig und überwacht in Produktion. Du gehst mit einer eigenen RAG-Anwendung und einer Pipeline-Erfahrung heraus, die du auf dein nächstes Projekt überträgst.
→ AI Engineering Bootcamp beim Software Architecture Summit mit Alessandro Buttignon
MCP als Architekturschicht verstehen
Sobald KI-Systeme sich von einzelnen Modellen zu verteilten Ökosystemen entwickeln, brauchst du eine Schicht, die regelt, wie Modelle, Tools und Umgebungen kommunizieren. Das Model Context Protocol ist diese Schicht. Dieser demo-lastige Workshop betrachtet MCP nicht aus Endnutzer-, sondern aus Architektursicht: wie das Protokoll modulares Systemdesign prägt, den Datenfluss zwischen Agenten und externen Diensten steuert und über SDKs, APIs und Authentifizierung sichere, skalierbare Erweiterbarkeit ermöglicht. Du verstehst MCP als Rückgrat komponierbarer KI-Architekturen auf Enterprise-Ebene.
KI für Architekturdokumentation — produktiv und ohne Fallstricke
Dokumentation ist unbeliebt und textlastig — kein Wunder, dass GenAI hier als naheliegende Abkürzung erscheint. Entlang der arc42-Struktur erarbeitest du in Live-Demos und Übungen, wo KI bei ADRs, Sichten und Diagrammen wirklich hilft und wo sie gefährlich wird: Scheingenauigkeit, Kostenfallen durch permanente Aktualisierung, Governance-Fragen. Betrachtet werden bestehende wie neu entstehende Systeme. Du nimmst einen klaren Blick mit, wann KI-gestützte Dokumentation produktiv ist — und wann sie sich verbietet.
Architektur-Wissen sicher auf KI-Systeme übertragen
Erfahrene Architekt:innen müssen ihr Wissen nicht über Bord werfen — sie müssen es übersetzen. Dieses zweitägige Bootcamp zeigt, welche bestehenden Architektur-Skills sich auf KI-Systeme übertragen lassen und wo die Fallstricke gegenüber klassischer IT liegen. Themen sind Grundlagen und neue Konzepte aus Architektensicht, regulatorische Anforderungen wie der EU AI Act, die Dokumentation von KI-Architekturen und die Auswirkungen auf die Enterprise Architecture. Du gewinnst architektonische Orientierung in der KI-Welt, ohne dein Fundament aufzugeben.
→ KI-Architektur meistern beim Software Architecture Summit mit Bernd Fondermann
Agentic AI braucht Data Governance, nicht nur Autonomie
Der nächste Schritt sind autonome Agenten, die eigenständig Ziele verfolgen und Werkzeuge nutzen. Doch ein Agent ist nur so gut wie die Daten, auf denen er handelt. Fehlen klare Vorgaben zu Datenqualität, Zugriffssteuerung und Compliance, wird aus dem intelligenten Helfer schnell ein unkontrollierbares Risiko. Diese Keynote ordnet praxisnah ein, welche Agentic-AI-Versprechen in der Architekturarbeit heute schon tragen, wo die Grenzen liegen — und was du an Data Governance heute schaffen musst, damit der produktive Einsatz morgen gelingt.
Drei Schritte vor dem nächsten KI-Feature
- Schreib den Vertrag vor dem Prompt. Bevor du an Formulierungen feilst, definiere, welche strukturierten Daten das Modell liefern muss, damit der Rest deiner Anwendung sie verarbeiten kann. Der Prompt folgt dem Contract, nicht umgekehrt.
- Bau eine minimale Eval-Suite als Quality Gate. Schon eine kleine Sammlung erwarteter Ein- und Ausgaben verhindert, dass du Qualität am Nutzer testest. Lass sie in der Pipeline laufen, bevor das Feature live geht.
- Mach Kosten, Latenz und Qualität sichtbar. Logge Token-Verbrauch und Antwortzeiten ab Tag eins. Ein nichtdeterministisches System, das du nicht beobachten kannst, ist in Produktion ein blinder Fleck.
Produktion ist eine Strukturentscheidung
Die Begeisterung über eine funktionierende Demo ist berechtigt — aber sie verführt dazu, das Schwierige für erledigt zu halten. Tatsächlich beginnt die eigentliche Arbeit erst danach: Verträge, Quality Gates, Kontrolle, Sichtbarkeit und Governance sind keine Features, die man nachrüstet. Sie sind Eigenschaften der Struktur, die man von Anfang an wählt — oder eben nicht.
Die Lücke zwischen Demo und Produktion ist keine Modell-Lücke. Sie ist eine Architektur-Lücke.
Wer diese Schichten hands-on durcharbeiten will, statt sie im nächsten Produktionsvorfall zu lernen, findet beim Software Architecture Summit in Berlin (12.–16. Oktober 2026) genau die sechs Sessions, die das Thema von Contract-first Design bis Data Governance abdecken. → Zum Programm des Software Architecture Summit
Key Takeaways
- Eine Demo beweist, dass der Prompt funktioniert — nicht, dass das System trägt. Die Produktionsreife entscheidet die Architektur darum herum.
- Vier Schichten machen KI-Features tragfähig: Contract-first Design, Evaluations als Quality Gate, Control und Observability.
- Verteilte KI-Systeme brauchen eine Protokollschicht — das Model Context Protocol regelt Kommunikation, Datenfluss und Erweiterbarkeit.
- GenAI in der Dokumentation hilft entlang von arc42, birgt aber Scheingenauigkeit, Kostenfallen und Governance-Risiken.
- Agentic AI ohne Data Governance ist ein unkontrollierbares Risiko — Datenqualität und Zugriffssteuerung sind Voraussetzung, nicht Kür.
🔍 FAQ
1. Warum funktionieren KI-Features in der Demo, aber nicht in Produktion?
Weil eine Demo nur beweist, dass der Prompt unter kontrollierten Bedingungen ein plausibles Ergebnis liefert. In Produktion treffen echte Daten, echte Last und echte Nutzer auf das Feature. Ohne klare Verträge zwischen Modell und System, ohne Qualitätskontrolle und ohne Sichtbarkeit von Kosten und Qualität bricht das Feature zusammen. Das Problem liegt fast nie am Modell, sondern an seiner Einbettung ins System.
2. Was ist Contract-first Design bei KI-Features?
Contract-first Design bedeutet, zuerst festzulegen, welche strukturierten Daten das Modell liefern muss, damit der Rest der Anwendung damit arbeiten kann — und erst danach den Prompt zu bauen. Der Vertrag steht am Anfang, nicht die Formulierung. So wird die Schnittstelle zwischen KI-Feature und System verlässlich, statt von der Tagesform des Modells abzuhängen.
3. Brauche ich für ein einzelnes KI-Feature wirklich MLOps?
Auch für ein einzelnes Feature gilt: Sobald es in Produktion läuft, brauchst du einen Weg, Qualität, Kosten und Verhalten über die Zeit zu überwachen und Modelle kontrolliert zu aktualisieren. MLOps muss nicht groß starten, aber ganz ohne Lebenszyklus-Disziplin wird jedes KI-Feature in Produktion zum Blindflug.
4. Was ist der Unterschied zwischen Prompt Engineering und AI Systems Architecture?
Prompt Engineering optimiert die Anweisung an das Modell. AI Systems Architecture gestaltet das System um das Modell herum: Verträge, Qualitäts-Gates, Kontrollmechanismen und Observability. Prompt Engineering allein reicht für eine Demo. Für Produktion entscheidet die Architektur.
5. Welche Rolle spielt Data Governance bei KI in Produktion?
Eine zentrale. Ein KI-System — und besonders ein autonomer Agent — ist nur so gut wie die Daten, auf denen es handelt. Ohne klare Vorgaben zu Datenqualität, Zugriffssteuerung und Compliance wird aus einem hilfreichen Feature schnell ein unkontrollierbares Risiko. Data Governance ist deshalb Voraussetzung für produktiven KI-Einsatz, nicht nachgelagerte Pflicht.
