Digitalisierung & KI

Vom Prototyp zum produktiven KI-System: Das Sieben-Stufen-Reifegradmodell

Kurz gesagt

Ein funktionierender Prototyp beweist nur eine technische Möglichkeit – kein belastbares Produkt. Ein Arbeitsmodell mit sieben Reifestufen von der Idee über Experiment, Prototyp, Proof of Value und Pilot bis zu Produktion und kritischem Dienst macht sichtbar, was auf jeder Stufe bereits belegt ist und was noch fehlt. Ein System springt erst dann eine Stufe weiter, wenn die jeweiligen Übergangskriterien wie Baseline, Monitoring, Restoretest oder On-Call tatsächlich erfüllt sind – nicht, weil es "eigentlich schon funktioniert".

Warum diese Unterscheidung überhaupt nötig ist

Ein häufiger Denkfehler in KI-Projekten: Weil ein Prototyp beeindruckend funktioniert, wird er sprachlich schnell zum "fertigen Produkt" erklärt – ohne dass Nutzennachweis, kontrollierte Nutzung im größeren Rahmen und tatsächliche Betriebsfähigkeit belegt sind. Das Reifegradmodell ist kein formeller Industriestandard, sondern ein Arbeitsmodell, das genau das verhindert: Es macht sichtbar, welche Fragen ein System auf welcher Stufe schon beantwortet hat – und welche eben noch offen sind.

Die sieben Stufen im Überblick

  • Idee: Problem, Nutzer und erwarteter Nutzen sind lediglich beschrieben, noch ohne jeden technischen Nachweis.
  • Experiment: Ein einzelner technischer Mechanismus lässt sich unter kontrollierten Bedingungen zeigen. Es fehlt noch jede End-to-End-Zuverlässigkeit und jeder echte Betrieb.
  • Prototyp: Ein zusammenhängender Nutzerpfad funktioniert mit Testdaten. Sicherheit, Skalierung, Wiederherstellung und Wartung sind meist noch unvollständig.
  • Proof of Value: Der Ansatz liefert unter realistischen Aufgaben messbaren fachlichen Nutzen – allerdings nur bei einem begrenzten Nutzerkreis und unter kontrollierten Randbedingungen.
  • Pilot: Echte Nutzer und echte Daten arbeiten mit dem System, aber mit kontrollierter Reichweite. Eine allgemeine Betriebsfreigabe besteht noch nicht.
  • Produktion: Ein definierter Nutzerkreis erhält einen überwachten, supportfähigen Dienst. Laufende Wartung und Kapazitätsanpassung bleiben notwendig.
  • Kritischer Dienst: Das System erfüllt erhöhte Anforderungen an Verfügbarkeit, Sicherheit und Nachweisführung. Absolute Fehlerfreiheit gibt es dennoch nicht – Resilienz und ein Notbetriebskonzept bleiben zentral.

Die konkreten Übergangskriterien zwischen den Stufen

Der Wechsel von einer Stufe zur nächsten ist an klare, prüfbare Kriterien gebunden, nicht an ein Bauchgefühl:

  • Experiment zu Prototyp: ein reproduzierbarer Mechanismus, dokumentierte Eingaben und bekannte Grenzen.
  • Prototyp zu Proof of Value: realistische Testaufgaben, eine Baseline zum Vergleich, messbarer Nutzen und eine Fehlertaxonomie.
  • Proof of Value zu Pilot: echte Nutzer, begrenzte Daten- und Aktionsrechte, Monitoring, Support und ein durchdachter Ausstiegsweg.
  • Pilot zu Produktion: akzeptierte Restrisiken, definierte Servicelevel, ein Bereitschaftsdienst, ein erfolgreich getesteter Restore sowie kontrollierte Releases und laufende Wartung.
  • Produktion zu kritischem Dienst: stärkere Redundanz, regelmäßige Übungen, unabhängige Prüfung sowie Kontrollen für Lieferkette und Notbetrieb.

Die fünf Evidenzklassen, die Produktionsreife eigentlich ausmachen

Produktionsreife lässt sich in fünf Nachweisarten zerlegen. Fehlt eine davon, entsteht ein konkretes, benennbares Risiko:

  • Fachliche Evidenz (Baseline, Abnahmekriterien, Nutzerfeedback, Fehlertaxonomie): Fehlt sie, läuft ein technisch aktives System ohne belegten Nutzen.
  • Technische Evidenz (Build, Tests, Verträge, Last- und Migrationstests): Fehlt sie, entstehen nicht reproduzierbare oder unentdeckte Defekte.
  • Sicherheitsevidenz (Bedrohungsmodell, Rechteprüfungen, Lieferketten- und Sicherheitstests): Fehlt sie, drohen unkontrollierter Zugriff und schwer nachweisbare Herkunft von Änderungen.
  • Betriebsevidenz (Servicelevel-Ziele, Dashboards, Alarmierung, Runbooks, Bereitschaftsdienst): Fehlt sie, werden Störungen zu spät erkannt oder nur improvisiert behandelt.
  • Recovery- und Lebenszyklusevidenz (Restoretest, Rollback, Wartungs- und Ausstiegsplan): Fehlt sie, kann ein System zwar gestartet, aber nicht sicher verändert oder beendet werden.

Die praktische Entscheidungsregel dahinter: Je irreversibler, schwerer erkennbar und folgenreicher eine fehlerhafte Wirkung sein kann, desto mehr unabhängige Evidenz und desto mehr menschliche Freigabe braucht der Start in den echten Betrieb.

Prototyp-Fragen sind nicht dieselben wie Produktions-Fragen

Ein Prototyp beantwortet typischerweise: Kann das Modell diese Aufgabe einmal lösen? Läuft die Anwendung lokal? Antwortet die Programmierschnittstelle? Wurde irgendein Backup aktiviert? Produktionsreife verlangt dagegen andere Antworten: Wie oft, unter welchen Eingaben und mit welchen Fehlertypen löst das Gesamtsystem die Aufgabe zuverlässig? Ist der Aufbau reproduzierbar und unabhängig von einer einzelnen Person? Wurde ein vollständiger Restore innerhalb der Zielvorgabe erfolgreich geprüft? Erkennt das Team eine Nutzerwirkung und einen Qualitätsverlust rechtzeitig, statt sie erst durch Beschwerden zu bemerken?

Wann bewusst auf KI verzichtet werden sollte

Das Modell hält auch fest, wann eine KI-Lösung von vornherein die falsche Wahl ist: wenn eine Entscheidung vollständig durch klare Regeln oder Berechnungen beschrieben werden kann, wenn Fehler nicht tolerierbar, schwer erkennbar und nicht rückgängig zu machen sind, wenn die nötigen Datenrechte oder die Datenqualität fehlen, wenn ein Modellanbieter mit seinen Limits nicht dauerhaft betreibbar in die Anwendung integriert werden kann, oder wenn der Nutzen gegenüber einer klassischen Lösung nicht messbar größer ist als die zusätzliche Betriebs- und Risikolast.

Häufige Fragen

Ist jede Stufe für jedes Projekt zwingend nötig?
Nein, eine interne, risikoarme Hilfsfunktion braucht weniger Nachweis als ein öffentliches, zahlungswirksames oder personenbezogene Daten verarbeitendes System; die nötige Tiefe richtet sich nach dem Schadenspotenzial.
Kann ein Pilotprojekt direkt als fertiges Produkt gelten?
Nein, ein Pilot arbeitet zwar mit echten Nutzern und Daten, hat aber noch keine allgemeine Betriebsfreigabe und meist keine vollständige Wiederherstellungs- und Wartungsstruktur.
Was ist der häufigste Fehler beim Stufenübergang?
Eine Stufe wird sprachlich übersprungen, weil das System "eigentlich schon funktioniert", ohne dass die konkreten Übergangskriterien wie Baseline, Monitoring oder Restoretest tatsächlich erfüllt sind.