Ist Ihre KI-gebaute App produktionsreif? Eine Checkliste mit 20 Punkten

KI-App-Builder wie Lovable, Bolt, Replit, v0 und Cursor bringen Sie in wenigen Tagen von der Idee zu einer funktionierenden Demo. Das ist eine echte Leistung – und genau hier beginnt das Risiko. Eine Demo hat einen Nutzer, Testdaten und keine Folgen. Eine Produktiv-App hat fremde Nutzer, personenbezogene Daten, Zahlungen und einen Ruf, den es zu schützen gilt.

Diese Checkliste umfasst die 20 Punkte, die ein Entwickler prüft, bevor echte Nutzer kommen. Sie richtet sich an Gründer und Product Owner: Zu jedem Punkt erfahren Sie, warum er wichtig ist und wie Sie ihn überprüfen, ohne den gesamten Code zu lesen. Wenn Sie mehr als ein paar dieser Punkte nicht sicher beantworten können, zeigt Ihnen ein technisches Audit Ihrer KI-App, wo Sie stehen, bevor es der Launch-Tag tut.

So nutzen Sie diese Checkliste

Arbeiten Sie die fünf folgenden Gruppen durch und markieren Sie jeden Punkt als verifiziert (Sie oder jemand anderes hat es getestet), angenommen (der Builder hat es wahrscheinlich umgesetzt) oder unbekannt. Behandeln Sie „angenommen“ wie „unbekannt“. KI-Tools erzeugen Code, der vollständig aussieht, und die Lücken liegen meist genau dort, wo niemand getestet hat.

1. Konten und Zugriff

1. Registrierung, E-Mail-Verifizierung und Passwort-Zurücksetzen funktionieren durchgängig. Legen Sie ein ganz neues Konto an, verifizieren Sie es, setzen Sie das Passwort zurück und versuchen Sie dann, den alten Reset-Link erneut zu verwenden. Reset-Links sollten ablaufen und nur einmal funktionieren.
2. Die Autorisierung wird auf dem Server durchgesetzt und nicht nur in der Oberfläche versteckt. Eine Schaltfläche, die normalen Nutzern nicht angezeigt wird, schützt nichts, wenn die zugrunde liegende Anfrage trotzdem funktioniert. Melden Sie sich als einfacher Nutzer an und rufen Sie die Admin-Endpunkte direkt auf. Sie sollten die Anfrage ablehnen.
3. Rollen werden dort gespeichert, wo Nutzer sie nicht ändern können. In manchen Stacks können Nutzer die Metadaten ihres Profils selbst ändern. Liegt „is_admin“ dort, kann sich jeder Nutzer selbst befördern. Rollen gehören in eine geschützte Tabelle oder in serverseitig kontrollierte Claims.
4. Login und andere sensible Endpunkte sind per Rate Limiting begrenzt. Ohne Limits können Angreifer Tausende von Passwörtern oder Einmalcodes durchprobieren, und Bots können Ihr Registrierungsformular fluten.
5. Admin-Bereiche sind geschützt, und Admin-Konten nutzen Multi-Faktor-Authentifizierung. Ein einziges gestohlenes Admin-Passwort sollte nicht ausreichen, um die Daten aller Kunden einzusehen.

2. Daten und Datenschutz

6. Jede Tabelle mit Nutzerdaten hat Zugriffsregeln. Bei Supabase bedeutet das Row Level Security. Eine Tabelle ohne diese Regeln kann von jedem gelesen werden, der Ihren öffentlichen API-Schlüssel besitzt. Lesen Sie dazu unseren Leitfaden zu den sieben RLS-Fehlern in KI-gebauten Apps.
7. Die Mandantentrennung ist mit zwei Testkonten nachgewiesen. Melden Sie sich als Kunde A an, kopieren Sie eine Datensatz-ID und versuchen Sie dann, den Datensatz als Kunde B zu öffnen oder zu bearbeiten. Ändern Sie außerdem IDs in URLs und API-Aufrufen. Das ist der wertvollste einzelne Test für jedes Produkt mit mehreren Nutzern.
8. Datenbankänderungen liegen in versionierten Migrationen. Existiert das Schema nur im Dashboard eines Builders, können Sie es weder neu aufbauen noch prüfen oder zurückrollen. Bedenken Sie, dass manche Änderungen, etwa das Löschen einer Spalte, ohne Backup nicht rückgängig gemacht werden können.
9. Backups sind aktiviert, und eine Wiederherstellung wurde getestet. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung und kein Plan. Messen Sie, wie lange eine Wiederherstellung dauert, und halten Sie es schriftlich fest.
10. Sie wissen, welche personenbezogenen Daten Sie speichern und wie Sie sie löschen. Listen Sie die Felder auf, wo sie liegen (auch in Logs und Drittanbieter-Tools) und was passiert, wenn ein Nutzer um Löschung bittet.

3. Zahlungen und Abonnements

11. Zahlungs-Webhooks sind signaturgeprüft und idempotent. Andernfalls kann jeder eine Nachricht „Zahlung erfolgreich“ fälschen, und doppelte Zustellungen können doppelte Datensätze erzeugen. Details finden Sie in unserem Leitfaden zu Stripe-Webhooks und Abonnements.
12. Bezahlter Zugriff ergibt sich aus Abonnement-Ereignissen, nicht aus der Danke-Seite. Die Erfolgsseite ist nur eine Weiterleitung im Browser. Nutzer schließen Tabs, und jeder kann die URL einfach eintippen.
13. Testmodus und Live-Modus sind vollständig getrennt, und Fehlerfälle werden behandelt. Getrennte Schlüssel, Produkte und Webhook-Endpunkte. Prüfen Sie, was bei einer fehlgeschlagenen Verlängerung, einer Kündigung, einer Erstattung und einem Tarifwechsel passiert.

4. Secrets und Integrationen

14. Keine Secrets im Frontend-Bundle oder in der Git-Historie. Alles, was an den Browser ausgeliefert wird, ist öffentlich. Durchsuchen Sie Ihr gebautes JavaScript und Ihr Repository nach Service-Schlüsseln und API-Tokens. Rotieren Sie alles, was jemals offengelegt wurde, denn das Löschen der Datei löscht nicht die Historie.
15. Schlüssel von Drittanbietern folgen dem Prinzip der minimalen Rechte und haben Ausgabenlimits. Das ist bei KI-Funktionen besonders wichtig. Ein unbeschränkter API-Schlüssel für ein Sprachmodell in einer öffentlichen App kann binnen Stunden hohe Kosten verursachen. Legen Sie Nutzungsobergrenzen und Limits pro Nutzer fest.
16. Datei-Uploads und Storage-Buckets sind abgesichert. Prüfen Sie, wer jeden Bucket lesen und wer hochladen darf und ob Dateityp und -größe begrenzt sind. Öffentliche Buckets sind für öffentliche Bilder in Ordnung, für Rechnungen oder Ausweise jedoch gefährlich.

5. Deployment und Betrieb

17. Staging und Produktion sind getrennt. Unterschiedliche Datenbanken, unterschiedliche Schlüssel, unterschiedliche Domains. Wer gegen Produktionsdaten testet, sorgt dafür, dass Kunden Test-E-Mails erhalten.
18. Fehlerüberwachung und Verfügbarkeitsalarme erreichen eine Person, die handelt. Wenn Sie von einem Ausfall zuerst durch eine Kundennachricht erfahren, fehlt das Monitoring.
19. Domain, HTTPS und E-Mail-Zustellbarkeit sind sauber eingerichtet. Dazu gehören SPF-, DKIM- und DMARC-Einträge, damit Verifizierungs- und Bestätigungs-E-Mails nicht im Spam landen.
20. Es gibt einen Rollback-Plan und einen benannten Verantwortlichen. Wer darf deployen? Wie kehren Sie zur letzten funktionierenden Version zurück? Wer hat Bereitschaftsdienst? Nach dem Launch muss außerdem jemand Updates einspielen, was die monatliche SaaS-Wartung abdeckt.

Was Sie mit Ihren Ergebnissen tun sollten

• Überwiegend verifiziert, wenige Unbekannte: Testen Sie die unbekannten Punkte noch diese Woche selbst und starten Sie dann mit eingerichtetem Monitoring.
• Mehrere Unbekannte in den Gruppen 1 bis 3: Halten Sie inne. Bei Zugriff, Daten und Zahlungen werden Fehler zu Vorfällen. Eine gezielte Prüfung dieser Bereiche ist günstiger als ein Datenleck oder ein Abrechnungsfehler.
• Bekannte Fehler: Listen Sie sie mit Schritten zur Reproduktion auf. Genau diese Liste braucht ein Entwickler, um eine Behebung einzugrenzen, und sie ist der Ausgangspunkt für unsere Arbeit an Reparatur und Produktiv-Launch von KI-Apps.

Was eine Checkliste Ihnen nicht sagen kann

Eine Checkliste findet bekannte Kategorien von Problemen. Sie kann nicht beurteilen, ob Ihre Architektur mit Wachstum zurechtkommt, ob Ihre Geschäftslogik subtile Fehler enthält oder ob ein Angreifer kleine Schwachstellen miteinander verketten könnte. Wenn Sie eine formale Sicherheitsbewertung benötigen, finden Sie die Unterschiede in unserem Vergleich von technischen Audits, Penetrationstests und Code-Reviews.

Die gute Nachricht: Die meisten Launch-Blocker in KI-gebauten Apps lassen sich ohne Neuentwicklung beheben. Ziel ist es, sie zu finden, solange nur Sie selbst davon betroffen sind.