KI wird Ihr Engineering-Team nicht ersetzen. Schlechte Architektur schon.
KI ist ein Multiplikator, keine Lösung: Auf einer sauberen, beobachtbaren Architektur vervielfacht sie den Output Ihres Teams, auf einer verworrenen vervielfacht sie das Durcheinander. Ob eine KI-Funktion den Produktivbetrieb übersteht, entscheidet die Architektur darunter, lange bevor der erste Prompt geschrieben ist.
Jede Woche sprechen wir mit Gründern, die KI-Funktionen an Codebasen geschraubt haben, die dafür nie gebaut wurden: Vektordatenbanken, notdürftig an einen Monolithen geklebt, LLM-Aufrufe mitten in synchrone Request-Zyklen gepresst, Prompt-Logik über 15 Microservices verstreut, ohne Observability, ohne Caching, ohne Fallback. Das Ergebnis ist ein Produkt, das in der Demo glänzt und beim ersten echten Traffic zusammenbricht.
Hier ist die unbequeme Wahrheit, die kaum jemand laut aussprechen will:
KI behebt keine technischen Altlasten. Sie vervielfacht sie.
Wenn das Fundament wackelt, macht jede neue KI-Funktion das System schwerer zu debuggen, schwerer zu skalieren und teurer im Betrieb. Die Token-Kosten laufen weit über alles hinaus, was Ihre Stückkostenrechnung vorgesehen hat. Die P99-Latenz wird unbegrenzt, weil niemand geplant hat, was passiert, wenn die Modell-API schwächelt. Ihr Team verbringt mehr Zeit mit Feuerwehreinsätzen als mit Ausliefern.
Die Startups, die gerade mit KI gewinnen, sind nicht die mit den ausgefallensten Modellen. Es sind die, deren Systeme von Anfang an darauf ausgelegt waren, sich weiterzuentwickeln.
Wie scheitert KI im Produktivbetrieb? Die drei Muster, die wir jede Woche sehen
1. Synchrone LLM-Aufrufe im Request-Zyklus
Ein Nutzer klickt auf einen Button. Ihr API-Handler wartet auf einen LLM-Aufruf, der 4 bis 12 Sekunden dauert. Der HTTP-Timeout greift. Der Request wird wiederholt. Derselbe Prompt läuft dreimal. Der Nutzer lädt die Seite neu. Jetzt viermal. Vierfache Token-Kosten. 12 Sekunden Latenz. Die Nutzererfahrung ist kaputt.
Dieses Muster steckt in etwa der Hälfte der KI-Produkte, die wir prüfen. Die Lösung ist strukturell: Modellaufrufe laufen über eine Queue mit Idempotenzschlüsseln, die API antwortet sofort mit einer Job-ID, und das Frontend fragt das Ergebnis ab oder abonniert einen Ergebnis-Stream. Auf einer sauberen Codebasis ist das ein Refactoring von einer Woche, auf einer verworrenen eines von sechs Wochen.
2. Keine Observability auf der Modellebene
Wenn die KI-Funktion im Produktivbetrieb kaputt ist, sollte die Frage „Welcher Prompt hat mit welchen Eingaben was zurückgegeben, wie schnell und zu welchen Kosten?“ in 30 Sekunden beantwortet sein. Stattdessen wird daraus eine halbtägige Untersuchung über Logs, Support-Tickets und Reproduktionsversuche hinweg.
KI-Systeme im Produktivbetrieb brauchen mindestens: strukturiertes Logging pro Aufruf mit Prompt-Vorlage, Modell, Eingaben, Ausgaben, Tokens, Latenz, Kosten sowie Nutzer- und Mandantenkontext. Ohne das können Sie keine Regressionen debuggen, keine Stückkosten modellieren und ganz sicher keine Compliance-Prüfung bestehen.
3. Kein Fallback, wenn das Modell ausfällt
Modell-APIs fallen aus oder werden langsam. Anthropic, OpenAI und jede selbst gehostete Alternative hatten in den letzten 12 Monaten mehrstündige Störungen. Wenn Ihr Produkt unbenutzbar ist, sobald das Modell nicht verfügbar ist, dann ist die Verfügbarkeit Ihres Produkts die des Modells, und Ihre SLA-Gespräche mit Enterprise-Kunden werden hart.
Die Lösung ist architektonisch: ein vorab geplantes Verhalten im eingeschränkten Betrieb. Eine zwischengespeicherte Antwort auf eine ähnliche Anfrage. Eine einfachere, heuristikbasierte Antwort. Ein klarer Zustand in der Oberfläche wie „KI ist derzeit nicht verfügbar“. Was auch immer zum Produkt passt, entscheidend ist, dass die Frage vor der Störung beantwortet wurde, nicht währenddessen.
Wie sieht eine „KI-taugliche“ Architektur tatsächlich aus?
Die Form, die wir empfehlen und die jedes KI-Produkt nutzt, das wir in den letzten zwei Jahren ausgeliefert haben:
- Async-first. Modellaufrufe laufen über eine Queue. Der Pfad, den der Nutzer sieht, blockiert nicht. Worker übernehmen den Modellaufruf, speichern das Ergebnis und benachrichtigen das Frontend.
- Eine Abstraktionsschicht für Modelle. Alle Modellaufrufe laufen über eine einzige interne Schnittstelle. Der Wechsel von einem Anbieter zum anderen oder ein A/B-Test zweier Modelle gegeneinander ist eine Konfigurationsänderung, kein Refactoring.
- Observability pro Aufruf. Jeder Modellaufruf wird mit vollem Kontext geloggt: Mandant, Nutzer, Version der Prompt-Vorlage, Modell, Eingaben, Ausgaben, Tokens, Kosten, Latenz und Ergebnis.
- Kostenleitplanken. Budgets pro Mandant, Rate Limits pro Funktion, automatische Abschaltungen. Token-Kosten sind die neuen Infrastrukturkosten und brauchen dieselbe operative Reife.
- Evaluations-Pipelines. Änderungen an Prompts und Modellen durchlaufen eine automatisierte Testreihe, bevor sie in den Produktivbetrieb gehen. „Wir haben es an ein paar Beispielen getestet“ ist kein Release-Prozess.
- Saubere Datenpipelines. Funktionen mit Retrieval-Augmentation hängen von der Qualität der Daten ab, aus denen sie abrufen. Die meisten KI-Bugs im Produktivbetrieb sind in Wahrheit verkleidete Datenbugs.
Nichts davon ist exotisch. Alles davon ist Betrieb. Und alles davon ist früh günstig einzubauen und spät schmerzhaft nachzurüsten.
Sollten Sie KI in Ihr bestehendes Produkt einbauen?
Wenn Sie CTO oder Gründer mit einem funktionierenden Produkt sind und Ihr Board drängt, „KI hinzuzufügen“, empfehlen wir diese Reihenfolge:
- Prüfen Sie die bestehende Architektur, bevor Sie die KI-Funktion planen. Wenn das Fundament die oben beschriebenen Fehlerbilder hat, beheben Sie diese zuerst. KI auf einem kaputten System verliert immer. (Siehe: 5 Architekturentscheidungen, die bestimmen, ob Ihr Startup das Wachstum übersteht.)
- Definieren Sie die Erfolgskennzahl in geschäftlichen Begriffen, nicht in Modellbegriffen. „Verkürzt die Antwortzeit im Support von 12 Stunden auf 2“ ist eine Kennzahl. „Nutzt GPT-4o“ ist keine.
- Wählen Sie eine klar abgegrenzte Funktion. KI-Funktionen scheitern meist, weil ihr Umfang zu breit war, um ihn zu bewerten. Beginnen Sie mit einem Prompt, einem Modell, einem Nutzerablauf.
- Bauen Sie die Observability vor der Funktion. Logging, Evaluierungen, Kostenerfassung. Spätestens in Woche zwei im Produktivbetrieb brauchen Sie sie, ob Sie sie gebaut haben oder nicht.
- Planen Sie den Fallback vor dem Launch. Was macht die Funktion, wenn die Modell-API ausfällt? Legen Sie es fest, bevor Sie es herausfinden müssen.
Wenn diese fünf Schritte so aussehen, als würden sie den Auftrag „KI noch in diesem Quartal ausliefern“ ausbremsen: Genau darum geht es. Sechs Wochen architektonische Disziplin schlagen sechs Monate Feuerwehreinsätze nach dem Launch, jedes einzelne Mal.
Zuerst das Fundament richtig legen
Wir haben KI-Produkte für Kundensupport, Dokumentenverarbeitung, Finanzanalyse und dialogbasierte Oberflächen ausgeliefert, Beispiele finden Sie in unseren Projekten. Das Muster ist jedes Mal dasselbe: Die Architektur entscheidet mehr über das Ergebnis als das Modell.
Wenn Sie KI in ein bestehendes Produkt einbauen und eine erfahrene technische Einschätzung wollen, ob Ihre Architektur dafür bereit ist, oder wenn Sie neu starten und es vom Fundament an richtig machen wollen, buchen Sie ein 30-minütiges Strategiegespräch. Wir sagen Ihnen in 30 Minuten, ob Ihr Stack für das bereit ist, was Sie als Nächstes bauen.
Über den Autor: Konstantinos Tsolakidis ist Gründer von WeAreFabbrik und arbeitet als Fractional CTO mit finanzierten Startups und Scale-ups, die in Europa KI-Produkte entwickeln. WeAreFabbrik ist ein Senior-Engineering-Team mit Sitz in Athen und Tallinn.