Die 6 Säulen produktionsreifer KI-Software

Der Abstand zwischen “funktioniert” und “ist produktionsreif” ist real. Und bei KI-gebauten Codebasen sieht er erstaunlich oft gleich aus. Wir haben ihn in sechs Säulen gefasst: nicht, weil sechs eine magische Zahl ist, sondern weil KI-generierter Code genau in diesen sechs Bereichen regelmäßig schwach ist. Und weil Fehler dort teuer werden.

Dieses Framework nutzen wir in jedem Engagement. So sieht jede Säule in der Praxis aus.

Säule 1: Architektur

Architektur bedeutet Struktur. KI-generierter Code tendiert zu monolithischen Strukturen, in denen alles mit allem gekoppelt ist: Business-Logik gemischt mit Datenzugriff, UI-Logik direkt an der Datenbank, Konfiguration verstreut über mehrere Dateien.

Das ist keine Faulheit der KI. Es ist Effizienz. Der kürzeste Weg zu einem funktionierenden Prototyp ist oft eine flache Struktur. Das Problem entsteht, wenn Sie das System ändern, skalieren oder testen wollen. Eine Änderung bricht drei andere Dinge. Ein neues Feature setzt voraus, dass man die ganze Codebasis versteht. Tests brauchen plötzlich die komplette Anwendung.

So sieht produktionsreife Architektur aus:

Klare Trennung in Schichten: Präsentation, Business-Logik, Datenzugriff. Mit expliziten Schnittstellen dazwischen. Module, die isoliert getestet werden können. Zentralisierte, umgebungsabhängige Konfiguration. Dependency Injection statt fest verdrahteter Abhängigkeiten.

Der Audit-Prozess:

Zeichnen Sie den tatsächlichen Abhängigkeitsgraphen Ihrer Codebasis. Wenn daraus ein Netz statt eine klare Hierarchie wird, haben Sie ein Architekturproblem. Starten Sie damit, Business-Logik in eine Service-Schicht zu ziehen, die weder HTTP noch Datenbanken kennt. Dieser eine Schritt macht den Rest meist deutlich einfacher.

Säule 2: Security

Security ist der Abstand zwischen dem, was der Code tun soll, und dem, wozu ein Angreifer ihn bringen kann. KI-Tools generieren Code für die erwarteten Use Cases. Security kümmert sich um die unerwarteten.

Die OWASP Top 10 sind die Basis. Bei KI-generierten Codebasen sehen wir besonders häufig SQL Injection durch String-Verkettung, fehlende Authentifizierung auf internen Endpunkten, hardcodierte Secrets im Repository, fehlendes Rate Limiting auf öffentlichen Endpunkten und unzureichende Input-Validierung.

So sieht produktionsreife Security aus:

Parametrisierte Queries überall. Secrets in einem echten Secret Manager, zum Beispiel AWS Secrets Manager, HashiCorp Vault oder einer sauberen Environment-Variablen-Schicht. Niemals im Code. Authentifizierung auf jedem nicht öffentlichen Endpunkt, mit explizitem Allowlisting statt Blocklisting. Serverseitige Input-Validierung an jeder Systemgrenze. Rate Limiting auf Login- und öffentlichen Endpunkten.

Der Audit-Prozess:

Führen Sie ein statisches Analyse-Tool gegen die Codebasis aus, zum Beispiel Bandit für Python, Semgrep oder Snyk. Behandeln Sie jeden Fund als echt, bis das Gegenteil bewiesen ist. Danach folgt ein manueller Review von Authentifizierung und Autorisierung. Automatische Tools übersehen Autorisierungsfehler oft, weil dafür Geschäftslogik verstanden werden muss.

Säule 3: Testing

Automatisierte Tests tun zwei Dinge: Sie finden Fehler vor dem Deployment, und sie machen spätere Änderungen sicher. KI-generierten Codebasen fehlt meistens beides.

Keine Tests zu haben ist ein Problem, das mit der Zeit größer wird. Jede Woche ohne Tests macht es schwerer, später Tests einzuführen, weil ungetesteter Code immer mehr Abhängigkeiten sammelt. Je länger man wartet, desto teurer wird es.

So sieht produktionsreifes Testing aus:

Unit-Tests für Business-Logik: reine Funktionen, Entscheidungen und Transformationen. Integrationstests für externe Grenzen: Datenbank, API-Aufrufe, Dateisystem. End-to-End-Tests für kritische Nutzerflüsse. Coverage-Ziele, die sich auf Business-Logik konzentrieren, zum Beispiel 70 Prozent und mehr, statt auf generierten Randcode.

Die Umsetzungsreihenfolge:

Beginnen Sie mit der Business-Logik. Dort entstehen die meisten fachlichen Fehler, und dort ändern Sie am häufigsten etwas. Schreiben Sie Tests für das bestehende Verhalten, selbst wenn Teile davon falsch sind. Sie brauchen zuerst eine Basislinie. Danach kommen Integrationstests für Datenbank und externe APIs. E2E-Tests kommen zuletzt, weil sie am teuersten zu pflegen sind.

Säule 4: Observability

Sie können nicht verbessern, was Sie nicht messen. Und Sie können nicht reparieren, was Sie nicht sehen. Observability ist die Instrumentierung, die zeigt, was Ihr System in Produktion wirklich tut.

Die drei Bausteine sind Logs, Metriken und Traces. Die meisten KI-generierten Systeme haben davon nichts in brauchbarer Form. Vielleicht gibt es print()-Statements oder unstrukturierte Log-Zeilen. Aber nichts, womit man systematisch debuggen oder alarmieren kann.

So sieht produktionsreife Observability aus:

Strukturierte Logs mit konsistenten Feldern: Zeitstempel, Request-ID, User-ID, Aktion, Dauer, Ergebnis. Jede Anfrage bekommt eine Korrelations-ID, die durch alle Log-Zeilen und Service-Aufrufe wandert. Metriken für die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung. Alerts auf Fehlerraten und Latenz-Perzentile, nicht nur auf Uptime. Distributed Tracing für Systeme mit mehreren Services.

Die Umsetzungsreihenfolge:

Führen Sie eine Logging-Bibliothek ein, zum Beispiel structlog für Python oder pino für Node.js, und ersetzen Sie print() sowie unstrukturierte Logs durch strukturierte Events. Danach kommt Request-ID-Middleware. Danach Error-Rate-Tracking. Metriken und Tracing kommen, sobald die Logs zuverlässig sind.

Säule 5: CI/CD

Continuous Integration und Continuous Deployment sind die Automatisierungsschicht zwischen Code schreiben und Code in Produktion betreiben. Sie sind der Unterschied zwischen “ich deploye manuell, wenn es sich fertig anfühlt” und “jeder Push wird automatisch geprüft und deployed, wenn er besteht”.

Manuelle Deployments sind ein Zuverlässigkeitsproblem. Wenn der Prozess manuell ist, variiert er bei jedem Deployment. Wissen lebt in Köpfen statt im Code. Rollbacks sind langsam und ebenfalls manuell.

So sieht produktionsreifes CI/CD aus:

Eine Pipeline läuft bei jedem Push und führt Linting, Typecheck, Unit-Tests, Integrationstests, Security-Scan und Build aus. Eine bestandene Pipeline ist Voraussetzung für den Merge in den Hauptbranch. Staging wird nach dem Merge automatisch deployed. Produktion braucht entweder eine manuelle Freigabe oder läuft automatisch nach erfolgreicher Staging-Validierung. Rollback ist automatisiert oder ein einzelner Befehl.

Die Umsetzungsreihenfolge:

Starten Sie mit einer einfachen Pipeline, die bei jedem Push Tests ausführt. Danach kommt Deployment nach Staging. Danach Production Deployment. Versuchen Sie nicht, alles auf einmal zu automatisieren. Eine einfache Pipeline, die zuverlässig läuft, ist mehr wert als eine komplexe Pipeline, die ständig bricht.

Säule 6: Infrastruktur

Infrastruktur ist die Laufzeitumgebung Ihrer Anwendung. KI-generierte Prototypen laufen oft auf einem einzelnen Server, mit manuell provisionierter Datenbank, ohne Backup-Strategie und mit Konfiguration direkt im Anwendungscode.

Das funktioniert, bis der Server ausfällt. Bis Sie skalieren müssen. Bis Sie mehrere Umgebungen brauchen. Oder bis Sie Ihre Infrastruktur für Disaster Recovery reproduzieren müssen.

So sieht produktionsreife Infrastruktur aus:

Stateless Application Server, die horizontal skalieren können. Managed Databases mit automatisierten Backups, Point-in-Time-Recovery und bei Bedarf Read Replicas. Klare Trennung von Development, Staging und Production mit eigenen Credentials und eigener Konfiguration. Infrastructure as Code mit Terraform, Pulumi oder CDK, damit alles reproduzierbar und versioniert ist. Secret Management außerhalb der Anwendung.

Die Umsetzungsreihenfolge:

Trennen Sie zuerst Anwendung und Konfiguration. Alles, was zwischen Umgebungen variiert, gehört in Environment Variablen oder eine saubere Konfigurationsschicht. Danach ziehen Sie die Datenbank in einen Managed Service, falls sie dort noch nicht liegt. Danach definieren Sie Infrastruktur als Code. Containerisierung und Orchestrierung kommen nach den Grundlagen.

Warum die Reihenfolge zählt

Die Säulen sind grob nach Risiko und Abhängigkeiten sortiert. Security-Probleme können sofort und irreversibel schaden. Architekturprobleme werden mit der Zeit teurer, verursachen aber nicht zwingend sofort Ausfälle. Infrastrukturprobleme sind schwer nachzurüsten, können aber oft parallel bearbeitet werden.

In der Praxis startet jedes Engagement mit einem Production-Readiness-Scorecard: mehr als 50 Checks, bei denen jeder Fund einer Säule und einem Risikoniveau zugeordnet wird. Die höchsten Risiken werden zuerst gelöst, unabhängig von der Säule. Das Framework liefert die Sprache und Kategorien. Die Scorecard liefert die Priorisierung.

Das Ziel sind keine perfekten Werte in allen Säulen. Das Ziel ist systematische Risikoreduktion, beginnend mit den Risiken, die am meisten Schaden anrichten können.