Vom KI-Prototyp zur Produktion: die acht Schichten, die ich ergänze, in dieser Reihenfolge
App-Builder wie Lovable, Bolt oder v0 liefern in wenigen Tagen ein funktionierendes Produkt. Dann kommen echte Kunden, Zahlungen und Personendaten, und der Prototyp fühlt sich plötzlich zerbrechlich an: Eine kleine Änderung legt den Checkout lahm, niemand weiss, ob die Backups funktionieren, und die KI, die alles gebaut hat, schreibt munter weiter um. Der übliche Rat lautet: neu schreiben. Ich habe zwei solche Prototypen ohne Neuschreiben in Produktion gebracht. Das sind die Schichten, die ich ergänze, in dieser Reihenfolge, und warum die Reihenfolge zählt.
Aktualisiert 11 Min. Lesezeit
1. An einem Nachmittag Bilanz ziehen
Den Code nach GitHub exportieren, falls er noch nicht dort liegt, und aufschreiben, was die App tatsächlich tut: Registrierung und Login, Zahlungen, E-Mails, Datei-Uploads, Admin-Ansichten, geplante Jobs, KI-Aufrufe. Alles markieren, was Geld oder Personendaten berührt. Diese Liste ist Ihre Risikokarte, und sie ist meist kürzer und klarer, als man befürchtet.
Dann prüfen, wo die Secrets liegen. In generierten Apps landen sie oft im Frontend-Code, in einer geteilten .env-Datei oder im Chatverlauf mit dem KI-Builder. Auch die Datenbank ansehen: Welche Tabellen gibt es, welche haben keine Zugriffsregeln, welche Spalten enthalten Personendaten? Der Readiness-Check unten macht aus diesem Nachmittag eine Punktzahl, damit Sie auf einen Blick sehen, wo es losgeht, und später Fortschritt zeigen können.
Tipp aus der Praxis
Das gebaute JavaScript-Bundle nach dem Service-Role-Key oder dem Zahlungs-Secret durchsuchen. Steht es dort, heute rotieren, vor allem anderen auf dieser Liste.
Interaktiv
Ist Ihre KI-gebaute App bereit für Produktion?
Haken Sie ab, was schon stimmt. Was übrig bleibt, ist Ihre To-do-Liste, in Reihenfolge.
Ihre nächsten drei Schritte
- Code liegt in Git, Änderungen laufen über Pull Requests
- Keine geheimen Keys im Frontend, Server-Keys nur auf dem Server
- Row-Level-Security (oder Gleichwertiges) auf jeder Tabelle
2. Staging und Produktion trennen
Zwei Umgebungen mit eigener Datenbank, eigenen Keys und eigenen Drittanbieter-Konten im Testmodus. Jede Änderung geht zuerst über Staging, Datenbankmigrationen eingeschlossen, und nichts erreicht die Produktion, was dort nicht gelaufen ist. Mit Supabase liefert ein zweites Projekt oder Branching eine Staging-Datenbank; auf Vercel bekommt jeder Pull Request über Preview-Deployments eine eigene URL zum Durchklicken.
Dieser eine Schritt beseitigt die meisten 'auf der Live-Seite kaputt'-Momente, denn der KI-Builder und die Entwickler haben jetzt einen Ort, an dem sie gefahrlos falsch liegen dürfen. Staging nah an der Produktion halten: gleiche Konfiguration, gleiche Erweiterungen, realistische, aber anonymisierte Daten. Ein Staging, das auseinanderdriftet, wird zu einem Ort, an dem alles funktioniert und nichts etwas beweist. Die Produktions-Checkliste von Supabase ist dabei eine gute Begleiterin: Sie geht die Einstellungen durch, die ein Hobbyprojekt von einem Live-System unterscheiden, von Netzwerkbeschränkungen bis zum E-Mail-Anbieter.
3. Festlegen, wer was lesen darf
Generierter Code vertraut oft dem Browser: Das Frontend versteckt einen Button und hält das für Sicherheit. In Produktion muss die Datenbank das durchsetzen, denn jeder kann Ihre API auch ohne Ihr Frontend aufrufen. Row-Level-Security auf jeder Tabelle einschalten, Policies pro Rolle schreiben und die kritischen Prüfungen in serverseitigen Funktionen wiederholen. Fehlerhafte Zugriffskontrolle steht seit Jahren ganz oben in den OWASP Top 10, und KI-gebaute Apps sind keine Ausnahme.
Dann pro Rolle einen Test schreiben, der Daten zu lesen und zu schreiben versucht, die ihn nichts angehen: die Rechnungen einer anderen Organisation, eine Admin-Einstellung, die Daten eines gelöschten Nutzers. Diese Tests sind billig geschrieben und unbezahlbar, wenn die KI eine Policy ändert, ohne Bescheid zu sagen. Auf einer Plattform hiess das Policies auf jeder Tabelle und eine Testsuite mit über tausend Dateien, und genau diese Suite lässt das Team weiter schnell ausliefern.
-- Members only see invoices of their own organisation
alter table invoices enable row level security;
create policy "members read own org invoices"
on invoices for select
using (
org_id in (
select org_id from memberships
where user_id = auth.uid()
)
);Tipp aus der Praxis
Eine ungetestete Policy ist eine Vermutung. In der Testsuite als jede Rolle einloggen und versuchen, Daten einer anderen Organisation zu lesen; der Test besteht nur, wenn die Datenbank Nein sagt.
4. Backups, die schon zurückgespielt wurden
Die Backups des Hosting-Anbieters sind ein Anfang, kein Plan. Wird das Konto gesperrt, fällt die Region aus oder löscht jemand das Projekt, verschwinden diese Backups mit. Zusätzlich verschlüsselte Dumps nach Zeitplan bei einem anderen Anbieter ablegen und jede Nacht einen davon in ein separates Projekt zurückspielen, mit einer Prüfung, ob die Zeilenzahlen stimmen. Hochgeladene Dateien brauchen dasselbe: auf einen zweiten Object Store spiegeln.
Die Zuverlässigkeitssäulen der Well-Architected Frameworks von Azure und AWS stellen beide dieselbe unbequeme Frage: Wann haben Sie zuletzt eine Wiederherstellung getestet? Auf den Produktionsplattformen, die ich betreibe, läuft der Restore-Test jede Nacht, und nur deshalb kann ich sagen, dass die Backups funktionieren. Ein nie zurückgespieltes Backup ist eine Hoffnung, kein Plan, und das will man nicht mitten in einem Vorfall herausfinden.
# Nightly: dump, encrypt, ship to another provider, prove it restores
pg_dump "$PROD_DB_URL" --format=custom --file=prod.dump
age -r "$BACKUP_PUBKEY" -o prod.dump.age prod.dump
aws s3 cp prod.dump.age "s3://backups-offsite/$(date +%F)/" \
--endpoint-url "$OFFSITE_S3_ENDPOINT"
pg_restore --clean --if-exists --no-owner -d "$RESTORE_TEST_DB_URL" prod.dump
psql "$RESTORE_TEST_DB_URL" -c "select count(*) from public.bookings;"5. Eine Release-Pipeline, die Nein sagen kann
Nur Pull Requests, keine direkten Pushes auf main, auch nicht für die KI. Die CI prüft Typen, lintet mit einer Baseline, die nur besser werden darf, führt Unit-Tests aus und spielt Datenbankmigrationen probeweise gegen Staging durch, bevor etwas gemergt wird. Eine Migration, die um 15 Uhr auf Staging scheitert, ist eine Lektion; dieselbe Migration um 3 Uhr nachts in Produktion ist ein Vorfall.
Nach dem Merge nur ausliefern, was sich geändert hat, und einen Smoke-Test gegen die Live-Seite laufen lassen: Kann sich jemand registrieren, einloggen und bis zum Checkout kommen? Wenn nicht, automatisch oder per Klick zurückrollen. Kleine, umkehrbare Schritte summieren sich schneller als grosse, vorsichtige: Eine Plattform hat so in zehn Monaten 3'025 Pull Requests gemergt, und die Pipeline hat dieses Tempo sicher gemacht.
# .github/workflows/ci.yml (excerpt)
on: pull_request
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22 }
- uses: supabase/setup-cli@v1
- run: npm ci
- run: npm run typecheck && npm run lint && npm test
- name: Migration dry run against staging
run: supabase db push --dry-run --db-url "$STAGING_DB_URL"
env:
STAGING_DB_URL: ${{ secrets.STAGING_DB_URL }}6. Überwachen, was Kunden wirklich tun
CPU-Grafiken verraten nicht, dass seit Mittag niemand buchen konnte. Das Google-SRE-Buch sagt es schlicht: Symptome überwachen, die Nutzer spüren, nicht nur Ursachen. Outside-in-Checks auf die Abläufe legen, die zählen, Registrierung, Checkout und Buchung, alle paar Minuten von ausserhalb des Hostings, damit Sie von einem kaputten Ablauf hören, bevor ein Kunde schreibt.
Dann Geschäftszustände beobachten, nicht nur technische. 'Zahlung erfolgreich, aber keine Buchung angelegt' und 'seit sechs Stunden an einem Werktag keine Buchung' sind die Alerts, die die teuren Fehler fangen. Auf einer Plattform hiess das stündliche Probes auf die Buchungsstrecke, eine tägliche synthetische Zahlung und ein Alarm bei Buchungsflaute. Nur bei Zustandswechseln alarmieren, ausgelöst und behoben, damit die Leute die Alerts weiter lesen, statt den Kanal stummzuschalten.
Tipp aus der Praxis
Jeden Tag eine synthetische Zahlung im Testmodus durch den echten Checkout schicken. Sie fängt kaputte Webhooks lange bevor es ein Kunde tut.
7. Secrets und Zugriff ohne langlebige Keys
Secrets aus dem Code, aus Chatverläufen und von den Laptops der Leute holen. Jede Umgebung bekommt eigene Secrets im Secret Store der Plattform. Die CI meldet sich per OpenID Connect statt mit gespeicherten Keys bei der Cloud an, damit in GitHub kein langlebiger Zugang liegt, der leaken könnte. Service-Role-Keys bleiben auf dem Server und erreichen nie den Browser.
Zugriff für Menschen folgt derselben Idee. Jeder bekommt ein eigenes Konto mit den minimal nötigen Rechten, Admins nutzen Multi-Faktor-Authentifizierung, und Zugriffe werden am Tag des Austritts entfernt. Das in einer einseitigen Zugriffsmatrix festhalten: Wer darf deployen, wer darf Produktionsdaten lesen, wer darf die Abrechnung ändern? Das dauert eine Stunde und beantwortet die ersten Fragen jedes Security-Fragebogens, den Kunden Ihnen je schicken. Jedes Quartal überprüfen; Zugriffe, auf die niemand schaut, wachsen nur.
8. Leitplanken für die KI, die weiterbaut
Der Coding-Agent, der den Prototyp gebaut hat, wird ihn weiter ändern, also bekommt er Regeln, so wie man einen neuen Entwickler einarbeitet. Eine schriftliche Anweisungsdatei im Repository sagt, was er anfassen darf und was nicht, welche Befehle er vor einem Pull Request ausführen muss und welche Bereiche immer einen Menschen brauchen: Login, Zahlungen, Löschen von Daten, Zugriffs-Policies.
Seine Pull Requests klein halten und ihn seine Arbeit belegen lassen. Ein Check der wichtigsten Abläufe in einem echten Browser vor jedem Release, ein Screenshot oder Testergebnis in jedem Pull Request, der einen Nutzerablauf ändert, und eine menschliche Freigabe für die sensiblen Bereiche. Der Agent behält sein Tempo; Pipeline, Tests und Review halten die Produktion sicher. Genau darum geht es: das Tempo eines KI-gebauten Produkts mit der Zuverlässigkeit, die Kunden von einem echten erwarten.
Tipp aus der Praxis
Den Agenten beweisen lassen: Kein Pull Request, der einen Nutzerablauf berührt, wird ohne Browser-Testergebnis oder Screenshot gemergt.
Fazit
Das Tempo des Prototyps behalten und die Sicherheit der Produktion schichtweise ergänzen. Sie brauchen kein Neuschreiben, sondern diese acht Schritte, in dieser Reihenfolge.
Echte Projekte dazu
Selbst ausprobieren
Quellen und offizielle Leitfäden
Weitere Artikel
- 3'025 Pull Requests in zehn Monaten: ein KI-gestützter Delivery-Prozess von innen
- Der EU AI Act für den Mittelstand: was für Sie gilt, und ab wann
- FinOps für KI-Kosten: Tokens, Caching, Routing und Budgets, die halten
- Ein Restaurant-Netzwerk in KI-Antworten sichtbar machen: ein GEO-Projekt Schritt für Schritt
- Wie diese Website gebaut ist: statisch, wo es geht, streamend, wo es muss
- Kubernetes-Kosten auf EKS und GKE: dasselbe Playbook, andere Hebel
- Eine Landing Zone für den Mittelstand, in Terraform oder Bicep: die Teile, die zählen
- Das Playbook für Legacy-Migrationen: Wellen, Parallelbetrieb und identische Zeilenzahlen und Prüfsummen
- MCP-Sicherheit im Detail: KI-Assistenten ins Produkt lassen, ohne die Türen zu öffnen
- Monitoring auf Geschäftsergebnisse: grüne Dashboards, leere Kasse
- KI-Agenten am Telefon: die Architektur, und die Stolperfallen, die keine Demo zeigt
- Restore-Tests: Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hoffnung
- KI-Antworten auf Azure Static Web Apps streamen: der eine Header, der alles zurückhielt
- Einen KI-Assistenten für WhatsApp bauen, von Anfang bis Ende: was es über die Demo hinaus braucht
- Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben
- Produktive KI auf AWS: Amazon Bedrock und AgentCore in einem privaten Setup
- Produktive KI auf Microsoft Foundry: ein privates Referenz-Setup für Agenten
- /goal, /loop oder Routines: Hören Sie auf, Ihren Coding-Agenten zu babysitten
- Claudes neue Pläne: Max, Ultra und was sie für Teams bedeuten
- OpenAI Codex Ende 2026: Goal Mode, Dots und wie man es absichert
- GitHub Copilot, Claude Code oder Codex? So würde ich für ein Unternehmen entscheiden
- GEO-Grundlagen: So erscheinen Sie in KI-Antworten
- Produktive KI auf Google Cloud: von Vertex AI zur Gemini Enterprise Agent Platform
- Lokale LLMs im Air-Gap-Netz: KI für Ihre sensibelsten Daten
- Ich will ein lokales LLM betreiben: Welchen Server soll ich kaufen?
- MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?
- Prompt-Research im grossen Stil mit einem offenen Modell
- SEO und GEO zusammen: ein praktisches Audit in 6 Schritten
- Kubernetes richtig dimensionieren: das Playbook, mit dem ein Cluster von 7 auf 4 Nodes kam
- Private KI für sensible Daten: ein lokales LLM-Setup, das durch die Sicherheitsprüfung kommt
