Warum ein Prototyp nicht automatisch produktionsreif ist
Ein Prototyp ist bewusst darauf optimiert, eine Idee schnell greifbar zu machen – nicht darauf, jede Abhängigkeit zu verifizieren oder jede Codezeile auf Sicherheitslücken zu prüfen. Genau diese bewusst übersprungenen Schritte sind aber keine Kleinigkeiten, sobald echte Nutzende und echte Daten im Spiel sind: Sie entsprechen genau den Risiken aus den drei vorigen Modulen dieses Kurses.
Die vier Fragen vor dem Go-Live
Erstens: Wurde ein Dependency-Audit durchgeführt, das jeden von der KI vorgeschlagenen Paketnamen gegen die offizielle Registry verifiziert – als Schutz gegen Slopsquatting? Zweitens: Wurde der Code gezielt auf die sechs häufigsten Schwachstellenklassen geprüft (hardcodierte Credentials, fehlende Autorisierung, SSRF, unvalidierte Eingaben, fehlende Security-Header, halluzinierte Dependencies)? Drittens: Wurde der im Governance-Modul beschriebene Review-Schwellenwert tatsächlich angewendet, statt den hohen KI-Anteil im Prototyp-Tempo zu übergehen? Viertens: Wurde geprüft, welche Daten während der Entwicklung an das KI-Coding-Tool geflossen sind – und ob echte Produktionsdaten darunter waren?
Der häufigste Fehler: Prototyp-Tempo einfach beibehalten
Der häufigste Fehler beim Übergang ist nicht technischer, sondern organisatorischer Natur: Das Tempo, das den Prototyp so schnell gemacht hat, wird unreflektiert beibehalten, während die vier oben genannten Prüfungen stillschweigend übersprungen werden – meist unter dem Druck, eine funktionierende Demo schnell live zu bringen.
Praxis-Teil: eine Checkliste statt eines Bauchgefühls
Die praktische Konsequenz: eine kurze, verbindliche Checkliste mit genau diesen vier Punkten, die vor jedem Prototyp-zu-Produktion-Übergang abgehakt werden muss – unabhängig davon, wie überzeugend die Demo bereits funktioniert. Das kostet einen Bruchteil der Zeit, die der ursprüngliche Prototyp gespart hat, verhindert aber genau die Risiken, die in den drei vorigen Modulen im Detail beschrieben wurden.