KI-Lebenszyklus: Phasen, Pflichten und Phasentore

Ein KI-System wird nicht erst gesteuert, wenn es läuft, sondern von der ersten Idee bis zu seiner Abschaltung. Genau das meint der KI-Lebenszyklus als Governance-Aufgabe: Jede Phase hat Verantwortliche, Entscheidungen und Nachweise, und die KI-Verordnung knüpft an fast jede dieser Phasen eigene Pflichten. Dieser Beitrag ordnet die Phasen anhand der gängigen Referenzmodelle, zeigt die Pflichten je Phase, beschreibt die Phasentore, die Änderungssteuerung und die Außerbetriebnahme und sagt, welche Belege eine Behörde sehen will.

Auf einen Blick

• Der KI-Lebenszyklus ist eine Governance-Disziplin: Er legt fest, wer ein System in die nächste Phase bringen darf, auf welcher Beweisgrundlage und was aufbewahrt wird. MLOps automatisiert die Pipeline, entscheidet aber nichts.
• Die KI-Verordnung nennt den Lebenszyklus selten, knüpft aber fast jede Hochrisiko-Pflicht an eine bestimmte Phase.
• Vier Referenzmodelle beschreiben ähnliche Phasen. Wählen Sie eines als Arbeitsmodell und bilden Sie die anderen darauf ab.
• Bei Änderungen wird der Lebenszyklus zu Recht: Eine wesentliche Veränderung löst eine neue Konformitätsbewertung aus und zieht seit dem Digital-Omnibus auch Altsysteme in den Anwendungsbereich.
• Die letzte Phase im KI-Lebenszyklus, die Außerbetriebnahme, plant kaum jemand, obwohl dort Rücknahme, Datenbankstatus, zehn Jahre Aufbewahrung und Löschung zusammenkommen.

Was der KI-Lebenszyklus bedeutet und was MLOps auslässt

Unter dem Management des KI-Lebenszyklus verstehen wir die Steuerung eines KI-Systems durch alle seine Phasen: wer es verantwortet, wer an jedem Übergang entscheidet, welche Nachweise dafür vorliegen müssen, wie Änderungen behandelt werden und wie das System geordnet endet. Die Seiten, die für diesen Begriff heute oben stehen, beschreiben fast ausschließlich eine Engineering-Pipeline: Problemdefinition, Daten, Training, Evaluierung, Deployment, Monitoring. Auch der KI-Leitfaden der US-Behörde GSA folgt dieser Logik vom Geschäftsproblem zur technischen Lösung. Das ist nicht falsch, aber es ist nur die Hälfte. In unserer Auswertung der zehn lesbaren Top-Seiten zitiert keine ISO/IEC 42001, ISO/IEC 5338, ISO/IEC 22989 oder die OECD, keine erwähnt die Meldung schwerwiegender Vorfälle, eine einzige nennt einen Artikel der KI-Verordnung und nur zwei sprechen über die Außerbetriebnahme.

MLOps und Lebenszyklus-Governance ergänzen sich, ersetzen sich aber nicht. MLOps automatisiert Training, Tests, Auslieferung und Überwachung und beantwortet die Frage, wie ein Modell schnell und reproduzierbar in Produktion kommt. Die Governance des KI-Lebenszyklus beantwortet eine andere Frage: ob es dorthin darf. Eine Pipeline kann einen Freigabeschritt erzwingen, aber sie kann nicht beurteilen, ob die Zweckbestimmung noch stimmt, ob eine Folgenabschätzung fällig ist oder ob ein Update die Rolle als Anbieter verschiebt.

Die Verordnung (EU) 2024/1689 verwendet den Begriff sparsam. In der englischen Fassung des Amtsblatts zählen wir elf Fundstellen von „lifecycle“: sieben in den Erwägungsgründen, vier im verfügenden Teil, nämlich Art. 9 Abs. 2, Art. 15 Abs. 1, Art. 40 Abs. 2 und Anhang IV Nummer 6. Der zentrale Satz steht beim Risikomanagement, das sich als „kontinuierlicher iterativer Prozess“ versteht, „der während des gesamten Lebenszyklus eines Hochrisiko-KI-Systems geplant und durchgeführt wird und eine regelmäßige systematische Überprüfung und Aktualisierung erfordert“ (Art. 9). Art. 15 Abs. 1 verlangt, dass Genauigkeit und Cybersicherheit über den gesamten Lebenszyklus beständig bleiben. Anhang IV Nummer 6 fordert eine Beschreibung der relevanten Änderungen, die der Anbieter im Laufe des Lebenszyklus vornimmt. Hinzu kommen Pflichten über die gesamte Lebensdauer: die Protokollierung nach Art. 12 Abs. 1 und die Datenerhebung zur Beobachtung nach dem Inverkehrbringen nach Art. 72 Abs. 2. Das Wort ist selten, die Sache allgegenwärtig. Wer seine Systeme bereits in einem KI-Register mit Phase und Verantwortlichen führt, hat die Grundlage für alles Weitere.

Die Phasen des KI-Lebenszyklus: vier Referenzmodelle im Vergleich

Wer den KI-Lebenszyklus steuern will, braucht zuerst eine gemeinsame Sprache für die Phasen. Vier Modelle prägen die Praxis: die Begriffsnorm ISO/IEC 22989, auf die sich auch der Europäische Datenschutzbeauftragte (EDSB) stützt, das NIST AI RMF, die OECD-Grundsätze und die Kontrollen in Anhang A.6.2 von ISO/IEC 42001. Die folgende Tabelle legt sie neben unser Arbeitsmodell mit acht Phasen.

Phase (unser Arbeitsmodell)	ISO/IEC 22989 / EDSB	NIST AI RMF	OECD	ISO/IEC 42001 Anhang A.6.2
Konzeption und Zweckbestimmung	Konzeption und Analyse	Plan and Design	Design, Daten und Modelle	Anforderungen und Spezifikation (A.6.2.2)
Datenbeschaffung und Datenaufbereitung	Datenbeschaffung und Datenaufbereitung	Collect and Process Data	Design, Daten und Modelle	(Datenkontrollen in A.7)
Design und Entwicklung	Entwicklung	Build and Use Model	Design, Daten und Modelle	Dokumentation von Design und Entwicklung (A.6.2.3)
Verifizierung und Validierung	Verifizierung und Validierung	Verify and Validate	Verifizierung und Validierung	Verifizierung und Validierung (A.6.2.4)
Bereitstellung	Bereitstellung	Deploy and Use	Bereitstellung	Bereitstellung (A.6.2.5)
Betrieb und Überwachung	Betrieb und Überwachung; kontinuierliche Validierung	Operate and Monitor	Betrieb und Überwachung	Betrieb und Überwachung (A.6.2.6); Ereignisprotokolle (A.6.2.8)
Neubewertung und Änderung	Neubewertung	(TEVV über den gesamten Zyklus)	(iterativ, nicht sequenziell)	Technische Dokumentation aktuell halten (A.6.2.7)
Außerbetriebnahme	Außerbetriebnahme	(keine eigene Phase)	Entscheidung fällt in Betrieb und Überwachung	(keine eigene Kontrolle)

Die Unterschiede sind weniger inhaltlich als strukturell. Die Abbildung der Phasen im NIST AI 100-1 vom Januar 2023 ist laut NIST aus dem Klassifikationsrahmen der OECD adaptiert. NIST behandelt Test, Evaluierung, Verifizierung und Validierung als Daueraufgabe statt als Station, die OECD betont, dass die Phasen oft iterativ durchlaufen werden. ISO/IEC 42001 lässt die Organisation selbst festlegen, in welchen Phasen Ereignisprotokolle aktiviert werden. Einen Schritt weiter geht ISO/IEC 5338:2023, im Dezember 2023 vom Normungsgremium JTC 1/SC 42 veröffentlicht: Die Norm macht aus den Phasen Prozesse, baut auf ISO/IEC/IEEE 15288 und 12207 auf, ergänzt KI-spezifische Prozesse aus ISO/IEC 22989 und ISO/IEC 23053 und gilt gleichermaßen für selbst entwickelte und zugekaufte Systeme. Unsere Empfehlung: Wählen Sie ein Arbeitsmodell, bilden Sie die anderen darauf ab und betreiben Sie nie drei parallel. Wie das mit den Kontrollen der Norm zusammenpasst, zeigt unser Baukasten aus ISO 42001 und KI-Verordnung.

Pflichten im KI-Lebenszyklus: was die KI-Verordnung je Phase verlangt

Für Hochrisiko-KI-Systeme lässt sich fast jede Pflicht einer Phase zuordnen. Die Tabelle nennt für jede Phase, was verlangt wird, wo es steht und welcher Beleg bei einer Prüfung durch Marktüberwachung oder notifizierte Stelle auf dem Tisch liegen sollte.

Phase	Was die KI-Verordnung verlangt	Artikel	Aufzubewahrende Nachweise
Konzeption und Zweckbestimmung	Zweckbestimmung festlegen, System einstufen, Risikomanagementsystem aufsetzen	Art. 3 Nr. 12, Art. 6, Art. 9 Abs. 1 und 2	Beschreibung der Zweckbestimmung, Einstufungsvermerk, eröffnetes Risikoregister
Datenbeschaffung und Datenaufbereitung	Daten-Governance für Trainings-, Validierungs- und Testdaten	Art. 10; Anhang IV Nr. 2 Buchst. d	Datenblätter, Herkunftsnachweise, Dokumentation der Bias-Prüfung
Design und Entwicklung	Technische Dokumentation vor dem Inverkehrbringen; Transparenz und Betriebsanleitung; menschliche Aufsicht bereits im Design; Genauigkeit, Zuverlässigkeit und Cybersicherheit	Art. 11, 13, 14, 15; Art. 17 Abs. 1 Buchst. b und c	Dossier nach Anhang IV, Betriebsanleitung, Aufsichtskonzept
Verifizierung und Validierung	Tests vor dem Inverkehrbringen anhand vorab festgelegter Metriken; Konformitätsbewertung, Konformitätserklärung, CE-Kennzeichnung	Art. 9 Abs. 6 bis 8; Art. 17 Abs. 1 Buchst. d; Art. 43, 47, 48	Testberichte, Konformitätsakte, EU-Konformitätserklärung
Bereitstellung	Registrierung in der EU-Datenbank vor dem Inverkehrbringen (Systeme nach Anhang III); Betreiberpflichten; Grundrechte-Folgenabschätzung für bestimmte Betreiber	Art. 49, 26, 27	Registrierungsnachweis, Checkliste zur Inbetriebnahme, Folgenabschätzung, wo fällig
Betrieb und Überwachung	Protokolle über die Lebensdauer; Beobachtung nach dem Inverkehrbringen; Überwachung und Aussetzung durch Betreiber; Meldung schwerwiegender Vorfälle	Art. 12, 19, 26 Abs. 5 und 6, 72, 73	Nachweis der Log-Aufbewahrung, Beobachtungsplan und Berichte, Vorfallregister
Änderung	Wesentliche Veränderung löst neue Konformitätsbewertung aus; in Anhang IV Nr. 2 Buchst. f vorab festgelegte Änderungen nicht; ein Betreiber, der wesentlich verändert, wird Anbieter	Art. 3 Nr. 23, Art. 43 Abs. 4, Art. 25 Abs. 1; Anhang IV Nr. 6	Änderungsprotokoll mit Triage-Entscheidung, aktualisierte Dokumentation
Außerbetriebnahme	Korrekturmaßnahmen, Rücknahme, Deaktivierung oder Rückruf; Dokumentation zehn Jahre aufbewahren; Status in der Datenbank aktualisieren	Art. 20, 18; Anhang VIII Abschnitt A Nr. 7	Stilllegungsprotokoll, Aufbewahrungsplan, Löschnachweise

Zum Zeitplan: Mit dem Digital-Omnibus zur KI, der Verordnung (EU) 2026/1744, am 24. Juli 2026 im Amtsblatt veröffentlicht und seit dem 27. Juli 2026 in Kraft, gelten die Hochrisiko-Pflichten für Systeme nach Anhang III ab dem 2. Dezember 2027 und für Produkte nach Anhang I ab dem 2. August 2028. Der Omnibus hat zudem den Plan zur Beobachtung nach dem Inverkehrbringen zum Bestandteil der technischen Dokumentation nach Anhang IV gemacht und die Kommission beauftragt, bis zum 2. September 2027 Leitlinien samt Vorlage anzunehmen (neuer Art. 72 Abs. 3). Das Qualitätsmanagementsystem ist nach dem neu gefassten Art. 17 Abs. 2 an die Größe von KMU, einschließlich Start-ups, und kleinen Midcap-Unternehmen anzupassen. Die Pflichten bleiben dieselben, der Zeitpuffer ist eine Gelegenheit, den KI-Lebenszyklus sauber aufzusetzen, keine Einladung zum Abwarten. Eine Übersicht aller Fristen bietet unser operativer Leitfaden zur EU-KI-Verordnung.

Phasentore im KI-Lebenszyklus: wer auf welcher Grundlage entscheidet

Phasen beschreiben, was passiert. Phasentore legen fest, wer den Übergang freigibt und auf welcher Beweisgrundlage. Sechs Tore reichen in der Praxis aus:

1. <b>Aufnahme.</b> Das System kommt mit einer namentlich verantwortlichen Person und einer schriftlichen Zweckbestimmung ins Inventar. Ohne diesen Eintrag gibt es weder Zugang zu Produktivdaten noch einen Vertrag mit dem Lieferanten.
2. <b>Designfreigabe.</b> Einstufung, Folgenabschätzung und Risikoregister liegen vor, das Governance-Gremium entscheidet über Go oder No-Go. Bei Hochrisiko-Systemen steht hier auch fest, welches Konformitätsbewertungsverfahren gilt.
3. <b>Freigabe zum Betrieb.</b> Die Validierung hat die vorab festgelegten Metriken bestanden, die Dokumentation ist vollständig, und die menschliche Aufsicht ist konkreten Personen zugewiesen. Bei Hochrisiko-Systemen sind Konformitätsbewertung und Registrierung abgeschlossen, bevor das System produktiv geht.
4. <b>Änderungs-Triage.</b> Jede Änderung an Modell, Daten oder Zweck wird protokolliert und eingestuft: Routine, vorab festgelegt oder wesentlich. Nur die dritte Kategorie öffnet erneut den Weg zur Konformitätsbewertung, aber alle drei hinterlassen eine Spur.
5. <b>Periodische Neubewertung.</b> Mindestens jährlich und nach jedem Vorfall werden die Ergebnisse im Betrieb mit den ursprünglich identifizierten Risiken abgeglichen. Weicht die Wirklichkeit ab, geht das System zurück in die Triage oder vor das Gremium.
6. <b>Außerbetriebnahme.</b> Entscheidung, Benachrichtigung, Archivierung und Löschung werden als ein Vorgang dokumentiert. Das Tor schließt erst, wenn Inventar und gegebenenfalls EU-Datenbank den neuen Status zeigen.

Die Rollen sollten vor dem ersten Tor feststehen. Der Fachbereich als Business Owner verantwortet Zweck und Nutzen. Das KI-Governance-Gremium entscheidet an den Toren 2, 3 und 6. Recht und Datenschutzbeauftragte prüfen Einstufung, Rechtsgrundlagen und Folgenabschätzungen. Die Modellvalidierung als zweite Verteidigungslinie, wie sie aus dem Modellrisikomanagement der Banken bekannt ist, bestätigt Metriken und Tests. Die IT-Sicherheit verantwortet Zugänge, Protokolle und Schwachstellen. Für Zweck und Struktur des KI-Lebenszyklus genügt eine Seite Text, für die Nachweise braucht es ein System. In AI Sigil werden Prozesse als Abfolge von Phasen abgebildet, mit Formularen und Freigaben je Phase.

Änderungssteuerung: wann ein Update zur wesentlichen Veränderung wird

Nach Art. 3 Nr. 23 ist eine wesentliche Veränderung eine Änderung nach dem Inverkehrbringen oder der Inbetriebnahme, die in der ursprünglichen Konformitätsbewertung nicht vorgesehen oder geplant war und entweder die Erfüllung der Anforderungen aus Kapitel III Abschnitt 2 berührt oder die Zweckbestimmung verändert. Die Rechtsfolge steht in Art. 43 Abs. 4: eine neue Konformitätsbewertung, gleichgültig, ob das veränderte System weitervertrieben oder vom bisherigen Betreiber weitergenutzt wird. Für Systeme, die nach dem Inverkehrbringen weiterlernen, gilt eine Ausnahme: Änderungen, die der Anbieter bei der ersten Bewertung vorab festgelegt und in Anhang IV Nummer 2 Buchstabe f beschrieben hat, sind keine wesentliche Veränderung. Ein sauber geschriebener Änderungsplan verschafft also Spielraum.

Die zweite Folge betrifft die Rolle. Nach Art. 25 Abs. 1 Buchstaben b und c wird zum Anbieter, wer ein Hochrisiko-System wesentlich verändert oder die Zweckbestimmung eines Systems so ändert, dass es hochriskant wird. Die dritte Folge kam mit dem Omnibus: Nach dem neu gefassten Art. 111 Abs. 2 fällt ein Hochrisiko-System, das vor dem Geltungsbeginn von Kapitel III bereits in Verkehr war, nur dann unter die Verordnung, wenn sein Design ab diesem Datum erheblich geändert wird; Systeme von Behörden müssen bis zum 2. August 2030 konform sein. Laut Erwägungsgrund entspricht die „erhebliche Änderung“ inhaltlich der wesentlichen Veränderung. Im KI-Lebenszyklus ist die Änderungssteuerung damit der Auslöser, der Bestandssysteme in den Anwendungsbereich zieht.

Verbindliche Auslegungshilfen fehlen noch. Die Kommission hat am 19. Mai 2026 den Entwurf der Leitlinien zur Hochrisiko-Einstufung veröffentlicht, die Konsultation bis zum 23. Juli 2026 verlängert und will die endgültige Fassung bis Ende 2026 annehmen. Leitlinien zur wesentlichen Veränderung stehen auf der Liste der Dokumente, die das AI Office noch vorbereitet. Das Issue Paper von CERRE vom Juni 2026 argumentiert, routinemäßige Änderungen im Lebenszyklus sollten in der Regel außerhalb dieses Regimes bleiben, im Einklang mit der Ausnahme in Art. 43 Abs. 4. Als Grenzfall nennt es einen Lieferanten, der das zugrunde liegende KI-Modell mit allgemeinem Verwendungszweck gegen eine neuere Version tauscht. Eine brauchbare Vorlage für den Plan nach Anhang IV Nummer 2 Buchstabe f liefert die US-Arzneimittelbehörde FDA: Ihre finale Leitlinie zu Predetermined Change Control Plans vom 4. Dezember 2024 gliedert ihn in Beschreibung der Änderungen, Änderungsprotokoll und Folgenabschätzung.

Prüffragen für die Triage

• Verändert die Anpassung die Zweckbestimmung?
• Berührt sie eine Anforderung aus Kapitel III, etwa Genauigkeit, Zuverlässigkeit, Aufsicht oder Daten?
• War sie in der technischen Dokumentation vorab festgelegt?
• Wer hat sie vorgenommen: Anbieter, Betreiber oder Lieferant des Basismodells?
• Betrifft sie ein Altsystem nach dem Geltungsbeginn von Kapitel III?

Betrieb und Überwachung: Protokolle, Drift und Vorfälle

Der Betrieb ist die längste Phase im KI-Lebenszyklus und die, in der Disziplin am schnellsten nachlässt. Der Anbieter richtet nach Art. 72 ein System zur Beobachtung nach dem Inverkehrbringen ein, das Daten zur Leistung über die gesamte Lebensdauer aktiv und systematisch erhebt, dokumentiert und auswertet, um die fortlaufende Konformität zu bewerten. Der Betreiber überwacht den Betrieb anhand der Betriebsanleitung, informiert den Anbieter und setzt die Nutzung aus, sobald er ein Risiko erkennt (Art. 26 Abs. 5). Die automatisch erzeugten Protokolle bewahren beide mindestens sechs Monate auf, der Anbieter nach Art. 19 Abs. 1, der Betreiber nach Art. 26 Abs. 6, soweit anderes Unionsrecht oder nationales Recht nichts anderes vorsieht. Wirksam wird diese Kontrolle nur, wenn die menschliche Aufsicht weiß, welche Signale sie auswerten soll.

Für schwerwiegende Vorfälle gelten die Fristen aus Art. 73: unverzüglich, spätestens 15 Tage nach Kenntnis; zwei Tage bei einem weitverbreiteten Verstoß oder einem schwerwiegenden Vorfall nach Art. 3 Nr. 49 Buchstabe b, also einer schweren und unumkehrbaren Störung kritischer Infrastruktur; zehn Tage beim Tod eines Menschen. Ein zunächst unvollständiger Erstbericht ist zulässig (Art. 73 Abs. 5). Die Kommission hat eine Vorlage für die Meldung schwerwiegender Vorfälle veröffentlicht. Wer den Meldeweg erst im Ernstfall sucht, verliert genau die Tage, die das Gesetz gewährt. Rollen, Schwellen und Meldekette beschreiben wir im Beitrag zur KI-Vorfallmeldung.

Drift ist die stille Variante desselben Problems: Datenverteilungen verschieben sich, die Genauigkeit sinkt, ohne dass ein einzelnes Ereignis auffällt. Schwellenwerte für Modelldrift gehören deshalb in den Beobachtungsplan und nicht in ein Dashboard, das niemand liest. Der EDSB führt für Systeme, die weiterlernen, die kontinuierliche Validierung als eigene Phase. Das ist konsequent: Ein System, das sich im Betrieb verändert, wird im Betrieb erneut validiert. Im KI-Lebenszyklus verbindet diese Phase den Betrieb mit der Änderungs-Triage, denn jeder Drift-Befund, der eine Nachschulung auslöst, ist zugleich ein Änderungsfall mit eigenem Eintrag im Protokoll.

Außerbetriebnahme: die Phase, die niemand plant

Die Außerbetriebnahme ist die blinde Stelle fast aller Modelle. Im Leitfaden des EDSB zum Risikomanagement von KI-Systemen vom 11. November 2025 ordnet die Risiko-Checkliste je Phase in Anhang 3 weder der Bereitstellung noch der Außerbetriebnahme ein einziges Risiko zu. Zur Außerbetriebnahme heißt es lediglich sinngemäß, das System solle verantwortungsvoll und effizient außer Betrieb genommen werden. Die OECD kennt keine eigene Phase, die Entscheidung kann während Betrieb und Überwachung fallen. Und von den zehn Seiten, die wir ausgewertet haben, erwähnen nur zwei das Thema überhaupt. Wer den KI-Lebenszyklus ernst nimmt, plant das Ende mit dem Anfang: Schon bei der Aufnahme sollte feststehen, wer über die Abschaltung entscheidet und welche Daten dann wohin gehen.

Dabei landen am Ende des KI-Lebenszyklus harte Pflichten. Ist ein Hochrisiko-System nicht konform, ergreift der Anbieter nach Art. 20 Korrekturmaßnahmen, nimmt es zurück, deaktiviert es oder ruft es zurück und informiert Händler und Betreiber. Nach Art. 18 hält er technische Dokumentation, Unterlagen zum Qualitätsmanagementsystem und EU-Konformitätserklärung zehn Jahre nach dem Inverkehrbringen bereit; das Ende des Betriebs beendet die Aufbewahrung also nicht. Anhang VIII Abschnitt A Nummer 7 verlangt, den Status in der EU-Datenbank zu pflegen, bis zu dem Vermerk, dass das System nicht mehr in Verkehr oder in Betrieb ist oder zurückgerufen wurde. Hinzu kommen die Aufbewahrungsfristen der Protokolle sowie Speicherbegrenzung und Löschpflichten nach der DSGVO für Trainings- und Inferenzdaten, die wir unter DSGVO-konforme KI behandeln. Eine Checkliste für das sechste Tor:

• Entscheidung und Begründung sind dokumentiert, mit Datum und entscheidender Stelle.
• Betreiber und Nutzer sind mit ausreichendem Vorlauf informiert.
• Zugänge sind entzogen, Modellartefakte archiviert oder gelöscht.
• Personenbezogene Daten sind nach dem Löschkonzept gelöscht oder anonymisiert.
• Die Dokumentation ist für die gesamte Aufbewahrungsfrist archiviert.
• Inventar und Status in der EU-Datenbank sind aktualisiert, ein Nachfolgesystem durchläuft regulär die Aufnahme.

Gekauft statt gebaut: der KI-Lebenszyklus beim Betreiber

Die meisten Organisationen entwickeln KI nicht, sie kaufen sie. Auch dafür liefert der EDSB ein Muster: einen Beschaffungszyklus für EU-Institutionen nach der Haushaltsordnung, Verordnung (EU, Euratom) 2024/2509, mit vier Schritten, nämlich Veröffentlichung und Transparenz, Ausschreibung, Auswahl und Zuschlag sowie Ausführung. In der Ausführung wiederholen sich Verifizierung und Validierung, Bereitstellung, Betrieb und Überwachung, kontinuierliche Validierung, Neubewertung und Außerbetriebnahme. Für den Betreiber endet der KI-Lebenszyklus also nicht mit dem Vertragsschluss, er beginnt dort erst richtig. Ein zugekauftes System durchläuft im KI-Lebenszyklus des Betreibers dieselben sechs Tore wie ein selbst entwickeltes, nur stammen viele Belege vom Lieferanten.

Steuerbar wird er über den Vertrag. Fünf Klauseln entscheiden: Ankündigung von Modell- oder Versionswechseln mit Vorlauf, Zugang zu den Protokollen, Mitwirkung bei Vorfällen, Dokumentation und Betriebsanleitung sowie Regeln für das Vertragsende mit Rückgabe oder Löschung der Daten. Unsere Hinweise zur Lieferanten-Due-Diligence gehen diese Punkte im Detail durch. Vorsicht mit Art. 25: Wer ein zugekauftes Hochrisiko-System unter eigenem Namen oder eigener Marke anbietet oder es wesentlich verändert, wird selbst Anbieter, mit allen Pflichten aus der Tabelle oben.

In Deutschland ist seit dem 29. Juli 2026 das KI-MIG in Kraft; die Bundesnetzagentur ist Marktüberwachungsbehörde, das BSI bleibt für die Informationssicherheit maßgeblich. Für Betreiber ist die Mitbestimmung oft der eigentliche Engpass: Kann ein KI-System Verhalten oder Leistung von Beschäftigten überwachen, hat der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitzubestimmen, bei der Einführung und erneut bei jeder erheblichen Änderung. Planen Sie die Betriebsvereinbarung deshalb als Teil der Änderungssteuerung, nicht als einmalige Hürde. In Frankreich decken die Empfehlungen der CNIL zur Entwicklung von KI-Systemen vor allem die Design- und Datenphasen ab. In Italien hat das Gesetz 132/2025 AgID und ACN als nationale Behörden benannt.

Häufige Fragen

<b>Was ist das Management des KI-Lebenszyklus?</b>

Es ist die Steuerung eines KI-Systems von der ersten Idee bis zur Abschaltung. Dazu gehören eine verantwortliche Person, definierte Phasen, Tore mit klaren Entscheidern, Nachweise für jede Freigabe, eine Änderungssteuerung und eine geordnete Außerbetriebnahme. Im Unterschied zu einem reinen Entwicklungsprozess umfasst es auch zugekaufte Systeme und alle Entscheidungen, die nicht im Code stehen: Zweckbestimmung, Einstufung, Folgenabschätzung, Vertragsklauseln. Das Ziel ist, jederzeit belegen zu können, wer was auf welcher Grundlage entschieden hat, gegenüber Revision, Aufsicht oder einem KI-Audit.

<b>Welche Phasen hat der KI-Lebenszyklus?</b>

Unser Arbeitsmodell kennt acht Phasen: Konzeption und Zweckbestimmung, Datenbeschaffung und Datenaufbereitung, Design und Entwicklung, Verifizierung und Validierung, Bereitstellung, Betrieb und Überwachung, Neubewertung und Änderung, Außerbetriebnahme. Es lässt sich auf ISO/IEC 22989, das NIST AI RMF, die OECD und ISO/IEC 42001 abbilden. Der EDSB unterscheidet neun Phasen, weil er die kontinuierliche Validierung für weiterlernende Systeme gesondert führt. Entscheidend ist weniger die genaue Zahl als die Festlegung auf ein Modell, an dem sich Inventar, Tore und Nachweise ausrichten.

<b>Verlangt die KI-Verordnung ein Management des KI-Lebenszyklus?</b>

Nicht unter diesem Namen. Die Verordnung verlangt aber ein Risikomanagement über den gesamten Lebenszyklus, beständige Genauigkeit und Cybersicherheit, Protokolle über die Lebensdauer, eine Beobachtung nach dem Inverkehrbringen, eine dokumentierte Änderungshistorie, Meldungen schwerwiegender Vorfälle und eine zehnjährige Aufbewahrung. Wer diese Pflichten erfüllen will, braucht faktisch ein Management des KI-Lebenszyklus mit Phasen, Toren und Nachweisen. Die meisten Pflichten treffen Anbieter von Hochrisiko-Systemen, Betreiber haben eigene Überwachungs-, Protokoll- und Meldepflichten.

<b>Was unterscheidet das Management des KI-Lebenszyklus von MLOps?</b>

MLOps automatisiert die technische Pipeline: Training, Tests, Auslieferung, Monitoring und Rollback. Das Management des KI-Lebenszyklus entscheidet, ob ein System in die nächste Phase darf, auf welcher Beweisgrundlage und wer dafür einsteht. MLOps liefert viele der Belege, etwa Testergebnisse, Versionsstände und Protokolle, aber es bewertet weder die Zweckbestimmung noch die Rolle als Anbieter oder Betreiber. Gute Organisationen verbinden beides, indem die Pipeline an den Phasentoren auf eine dokumentierte Freigabe wartet, statt sie zu ersetzen.

<b>Wann gilt eine Änderung als wesentliche Veränderung?</b>

Nach Art. 3 Nr. 23 KI-VO dann, wenn sie nach dem Inverkehrbringen oder der Inbetriebnahme erfolgt, in der ursprünglichen Konformitätsbewertung nicht vorgesehen war und entweder die Erfüllung der Anforderungen aus Kapitel III Abschnitt 2 berührt oder die Zweckbestimmung ändert. Bei weiterlernenden Systemen sind Änderungen, die vorab festgelegt und in Anhang IV Nummer 2 Buchstabe f beschrieben wurden, ausgenommen. Folge ist eine neue Konformitätsbewertung; wer die Änderung als Betreiber vornimmt, wird Anbieter. Leitlinien der Kommission zur wesentlichen Veränderung sind angekündigt, aber noch nicht veröffentlicht.

<b>Was passiert, wenn ein KI-System außer Betrieb genommen wird?</b>

Die Entscheidung wird mit Begründung dokumentiert, Betreiber und Nutzer werden informiert, Zugänge entzogen und Modellartefakte archiviert oder gelöscht. Bei Hochrisiko-Systemen wird der Status in der EU-Datenbank aktualisiert, und die Dokumentation bleibt zehn Jahre nach dem Inverkehrbringen verfügbar (Art. 18). Ist das System nicht konform, greifen zusätzlich Korrekturmaßnahmen, Rücknahme oder Rückruf nach Art. 20. Personenbezogene Trainings- und Inferenzdaten werden nach dem Löschkonzept gelöscht oder anonymisiert. Ein Nachfolgesystem beginnt seinen eigenen KI-Lebenszyklus regulär beim ersten Tor.

Fazit

Der KI-Lebenszyklus ist kein Diagramm aus der Entwicklungsabteilung, sondern die Ordnung, nach der eine Organisation über ihre KI-Systeme entscheidet. Die KI-Verordnung spricht selten vom Lebenszyklus, aber sie hängt ihre Pflichten an seine Phasen, und sie macht die Änderung zum Moment, in dem Rollen wechseln, Bewertungen neu beginnen und Altsysteme in den Anwendungsbereich rücken. Am Ende steht eine Phase, die kaum jemand plant und in der Aufbewahrung, Datenbankstatus und Löschung zusammenkommen. Unser Rat: Legen Sie ein Arbeitsmodell fest, definieren Sie die sechs Tore mit Entscheidern und Belegen, schreiben Sie den Änderungsplan, bevor das erste Update kommt, und behandeln Sie die Außerbetriebnahme als vollwertige Phase. Beginnen Sie mit dem Inventar und einem Werkzeug, das Risikomanagement und Nachweise für jede Phase im KI-Lebenszyklus an einem Ort hält.