¶ KI-Systemlebenszyklus und Änderungsmanagement – jede Version kontrolliert beherrschen
Kurz gesagt: KI-Governance endet nicht mit der Erstfreigabe. Zweck, Daten, Modell, Prompt, Wissensbasis, Schnittstellen, Anbieter, Nutzergruppe und Aufsicht können sich verändern. Deshalb besitzt jede KI-Anwendung eine nachvollziehbare Lifecycle-Akte und jede wesentliche Änderung eine eigene Bewertung, Prüfung, Freigabe und Rückfalloption.
Wichtiger Grundsatz: Eine Änderung mit gleicher Produktbezeichnung kann das Risiko wesentlich erhöhen. Umgekehrt ist nicht jedes technische Update automatisch kritisch. Maßgeblich sind Auswirkungen auf Zweck, Daten, Betroffene, Leistung, Sicherheit, Recht, Aufsicht und bestehende Kontrollen.
Musterstatus: Die nachfolgenden Gates, Änderungsklassen und Beispiele sind fiktiv. Sie bestätigen weder Umsetzung, Freigabe noch Wirksamkeit eines realen KI-Systems.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | AIMS-VA-03-03 |
| Dokumentenart | Verfahren für KI-Systemlebenszyklus, Konfigurations- und Änderungsmanagement |
| Wiki.js-Pfad | /ISO-42001/03-KI-Lebenszyklus-und-Kontrollen/KI-Systemlebenszyklus-und-Aenderungsmanagement |
| Prozesseigner | Technischer KI-Owner / AIMS-Verantwortliche/r |
| Operativ verantwortlich | System Owner, Produktverantwortung, Entwicklung oder zuständige IT-Funktion |
| Fachlich beteiligt | Fachlicher Owner, Informationssicherheit, Datenschutz, Recht/Compliance, Qualitätsmanagement, Einkauf, Betrieb und menschliche Aufsicht |
| Freigabe | Entsprechend Änderungsklasse durch technischen und fachlichen Owner, AIMS-Verantwortung oder Geschäftsführung |
| Status | Entwurf – Lifecycle-Gates, CI/CD-Integration, Änderungsklassen und Befugnisse sind organisationsbezogen festzulegen |
| Version | 0.3 |
| Stand | 10.08.2026 |
| Prüfung | Mindestens jährlich sowie bei wesentlicher Änderung, Vorfall, Drift, Anbieterwechsel oder Außerbetriebnahme |
| Schutzklasse | Öffentliches Muster; Systemakten, Architektur, Schwachstellen und Rollback-Daten regelmäßig Intern bis Streng vertraulich |
| Normbezug | ISO/IEC 42001:2023; ergänzend ISO/IEC 5338:2023, ISO/IEC 8183:2023 und ISO/IEC 23894:2023 |
| Schnittstellen | ISO/IEC 27001, ISO 9001, DSGVO, Verordnung (EU) 2024/1689, Vertrags- und Branchenanforderungen |
Jede Lifecycle-Phase besitzt Kriterien, Nachweise und eine Entscheidung; Änderungen führen kontrolliert zurück zur erforderlichen Prüfung. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Was gehört zum KI-System?
Der kontrollierte Gegenstand besteht nicht nur aus einem Modell. Die Systemgrenze umfasst je nach Anwendung:
- fachlichen Prozess, Zweck und Entscheidungswirkung,
- Modelle, Versionen, Parameter und Anbieterfunktionen,
- System- und Entwicklerprompts, Agentenlogik und Werkzeuge,
- Trainings-, Test-, Eingabe-, Wissens- und Protokolldaten,
- Vor- und Nachverarbeitung, Regeln und Schwellenwerte,
- Benutzeroberflächen, Warnhinweise und menschliche Aufsicht,
- Schnittstellen, Identitäten, Berechtigungen und automatisierte Aktionen,
- Cloud-, Hardware-, Netzwerk- und Drittanbieterdienste,
- Monitoring, Alarmierung, Fallback, Sicherung und Exit.
Eine Änderung an einem dieser Elemente kann Leistung oder Wirkung verändern. Deshalb werden Konfiguration und Abhängigkeiten versioniert, soweit sie für Reproduzierbarkeit und Entscheidung relevant sind.
¶ 2. Lifecycle-Phasen und Gates
| Phase | Leitfrage | Gate-Ergebnis |
|---|---|---|
| 1. Bedarf | Welches Problem, welcher Nutzen und welche Alternative bestehen? | Auftrag zur Vorprüfung oder Ablehnung |
| 2. Kontext und Anforderungen | Zweck, Nutzer, Betroffene, Daten, Qualitäts-, Sicherheits- und Rechtsanforderungen klar? | freigegebene Anforderungsbasis |
| 3. Bauen oder beschaffen | Ist Eigenentwicklung, Integration oder Dienstleistung geeigneter? | Make-or-Buy- und Lieferantenentscheidung |
| 4. Entwerfen und konfigurieren | Architektur, Datenflüsse, Aufsicht, Grenzen und Kontrollen definiert? | Designfreigabe |
| 5. Entwickeln/integrieren | Änderungen reproduzierbar, geschützt und geprüft umgesetzt? | Kandidat für Verifikation |
| 6. Testen und bewerten | Funktion, Qualität, Sicherheit, Datenschutz, Folgen und Grenzfälle ausreichend? | Pilotfreigabe, Nacharbeit oder Ablehnung |
| 7. Pilotieren | Funktioniert das Gesamtsystem im begrenzten Realbetrieb? | Produktionsfreigabe mit Scope und Auflagen |
| 8. Betreiben und überwachen | Bleiben Leistung, Daten, Risiken und Kontrollen innerhalb der Schwellen? | Weiterbetrieb, Einschränkung oder Änderung |
| 9. Ändern | Welche Auswirkungen besitzt die Änderung und welche Gates sind zu wiederholen? | Änderungsfreigabe oder Rollback |
| 10. Stilllegen | Sind Daten, Zugänge, Abhängigkeiten, Verträge und Nachweise kontrolliert beendet? | Exit- und Lösch-/Archivnachweis |
Ein Gate ist keine Besprechung ohne Ergebnis. Entscheidung, Befugnis, Bedingungen, offene Punkte, Nachweise und Datum werden dokumentiert.
¶ 3. Make-or-Buy und Lieferantenabhängigkeit
| Option | Zusätzlich zu prüfen |
|---|---|
| Eigenentwicklung | Kompetenzen, Entwicklungsumgebung, Datenrechte, Reproduzierbarkeit, Testtiefe, Wartung und technische Schuld |
| Standard-SaaS | Mandant, Tarif, Datenverwendung, Modellwechsel, Unterauftragnehmer, Protokollierung, Export, Sperrung und Exit |
| API/Modellservice | Versionsbindung, Rate Limits, Filter, Logging, Datenregion, Ausfall, Kosten und Ersatzmodell |
| Open-Source-Modell | Lizenz, Herkunft, Integrität, Sicherheitsprüfung, Betriebsressourcen, Updates und Support |
| eingebettete KI-Funktion | Erkennbarkeit, Abschaltbarkeit, Datenfluss, Herstelleränderungen und Einfluss auf Hauptprodukt |
| kundenspezifische Fremdentwicklung | Verantwortungsgrenzen, Quellcode/Artefakte, Abnahme, Dokumentation, Rechte und Übergabe |
Die Entscheidung berücksichtigt nicht nur Anschaffungskosten. Konzentrationsrisiko, Lock-in, Änderungsrechte, Kompetenzverlust und sichere Beendigung gehören zum Business Case.
¶ 4. Anforderungsbasis vor Entwicklung oder Beschaffung
| Anforderungsgruppe | Mindestinhalt |
|---|---|
| fachlich | Zweck, Prozess, Nutzer, erwartete Ausgabe, Grenzen und Nicht-Ziele |
| Qualität | Sollwerte, Fehlertoleranz, Teilgruppen, Grenzfälle und Messmethode |
| Daten | Quelle, Rechte, Schutz, Qualität, Version, Aufbewahrung und Löschung |
| Risiko und Wirkung | Szenarien, Betroffene, Schutzgüter, Kontrollen und Stop-Kriterien |
| Sicherheit | Identität, Zugriff, Geheimnisse, Schnittstellen, Logging, Schwachstellen und Fallback |
| Datenschutz/Recht | Rolle, Grundlage, Transparenz, Rechte, Verträge und gesetzliche Einstufung |
| menschliche Aufsicht | Information, Kompetenz, Prüfkriterien, Eingriff, Vertretung und Anfechtung |
| Betrieb | Verfügbarkeit, Kapazität, Monitoring, Support, Wiederherstellung und Exit |
| Nachweise | Systembeschreibung, Datenblatt, Tests, Freigaben, Versionen und Änderungsakte |
Widersprüchliche Anforderungen werden vor dem Design entschieden. „Hohe Genauigkeit“ oder „erklärbar“ ohne messbare oder prüfbare Bedeutung sind keine ausreichenden Kriterien.
¶ 5. Lifecycle-Akte und Baseline
Die Baseline beschreibt den freigegebenen Zustand. Sie enthält mindestens:
- KI-ID, Systemname, Zweck und Scope,
- Modell-/Dienstversion und relevante Parameter,
- Prompt-, Agenten-, Regel- und Schwellenwertversion,
- Daten-, Index-, Wissensbasis- und Schema-Version,
- Architektur, Schnittstellen und Berechtigungen,
- Anbieter, Tarif, Region und wesentliche Unterauftragnehmer,
- Testpaket, Ergebnisse und bekannte Grenzen,
- Risiko-/Folgenbewertung, Kontrollen und Restrisiko,
- Freigabe, Auflagen, Aufsicht und Monitoring,
- Build-, Release-, Rollback- und Exitinformationen.
Nicht jede technische Datei muss im Wiki liegen. Die Seite verweist auf kontrollierte Repositories, Tickets, Register und geschützte Nachweise.
¶ 6. Entwicklung und Integration
| Kontrollbereich | Praktische Umsetzung |
|---|---|
| getrennte Umgebungen | Entwicklung, Test und Produktion mit eigenen Daten- und Zugriffsregeln |
| Versionskontrolle | Code, Prompts, Konfiguration, Datenpipeline und Infrastruktur nachvollziehbar ändern |
| Peer Review | sicherheits-, qualitäts- oder wirkungsrelevante Änderungen unabhängig prüfen |
| Geheimnisschutz | API-Schlüssel und Zugangsdaten nicht in Prompts, Code oder öffentlichen Repositories |
| Abhängigkeiten | Bibliotheken, Modelle, Container und Dienste inventarisieren und prüfen |
| reproduzierbarer Build | Abhängigkeiten, Parameter und Artefakte soweit erforderlich festhalten |
| Testautomatisierung | Regression, Sicherheit und definierte Qualitätskriterien wiederholbar prüfen |
| Protokollierung | Änderung, Build, Test, Freigabe und Deployment mit Verantwortlichkeit verknüpfen |
KI-spezifische Artefakte werden in die bestehende sichere Entwicklung integriert, ohne klassische Software-, Infrastruktur- und Lieferantenkontrollen zu ersetzen.
¶ 7. Testpaket vor Pilot und Produktion
| Testart | Ziel | Beispielnachweis |
|---|---|---|
| Funktionstest | Anforderungen und Prozessschritte funktionieren | erwartete und tatsächliche Ergebnisse |
| Qualitäts-/Leistungstest | messbare Sollwerte und Teilgruppen erreichen | Metriken, Konfidenz, Fehlertypen und Stichprobe |
| Robustheit/Grenzfall | ungewöhnliche, fehlerhafte oder manipulative Eingaben beherrschen | dokumentierte Negativtests |
| Sicherheitsprüfung | Missbrauch, Prompt Injection, Datenabfluss und Berechtigungen prüfen | Testbericht und Maßnahmen |
| Datenschutz-/Rechtstest | Transparenz, Löschung, Auskunft, Datenfluss und Nutzungsgrenzen funktionieren | Fachabnahme und Konfiguration |
| Human-Oversight-Test | Menschen erkennen Fehler und können eingreifen | Übung, Übersteuerungs- und Stop-Nachweis |
| Regressionstest | vorherige Kernfunktion nach Änderung erhalten | Vergleich zur freigegebenen Baseline |
| Last-/Ausfalltest | Kapazität, Zeitverhalten, Fallback und Wiederherstellung genügen | Lastprofil, RTO/RPO und Rückfalltest |
| Abnahmetest | Gesamtsystem ist im Prozess geeignet | datierte fachliche Abnahme |
Testergebnisse werden nicht nur als „bestanden“ gespeichert. Version, Testdaten, Umgebung, Sollwert, Ergebnis, Abweichung und Entscheidung müssen rekonstruierbar sein.
¶ 8. Änderungsklassen
| Klasse | Beispiele | Mindestverfahren |
|---|---|---|
| Klasse 0 – redaktionell | Dokumentation ohne Einfluss auf System oder Nutzung | Vier-Augen-Prüfung und Dokumentenlenkung |
| Klasse 1 – gering | UI-Text, nicht wirkungsrelevante Konfiguration | technische Prüfung, Kurzregression, Owner-Freigabe |
| Klasse 2 – wesentlich | Promptlogik, Wissensquelle, Modellversion, Schwellenwert, Nutzergruppe | Auswirkungsanalyse, Risiko-/Datenschutzprüfung, Regression und Freigabe |
| Klasse 3 – kritisch | neuer Zweck, automatisierte Aktion, sensible Daten, Betroffenengruppe, Hochrisikoindikation | vollständige Neubewertung, vertiefte Tests, Managementfreigabe oder Ablehnung |
| Notfalländerung | akute Schwachstelle, Vorfall, gefährliche Ausgabe oder Dienststörung | sofort begrenzen, befugt freigeben, dokumentieren und nachträglich vollständig prüfen |
Die Einstufung wird begründet. Mehrere kleine Änderungen werden gemeinsam betrachtet, weil ihre kumulierte Wirkung wesentlich sein kann.
¶ 9. Auswirkungsanalyse einer Änderung
Vor Umsetzung beantwortet der Änderungsantrag:
- Welche Baseline und welche Anwendungen sind betroffen?
- Ändern sich Zweck, Rolle, Nutzer, Betroffene oder Entscheidungswirkung?
- Ändern sich Daten, Modell, Prompt, Regeln, Schnittstellen oder Anbieter?
- Welche Risiken, Folgen, Rechts- und Schutzanforderungen verändern sich?
- Welche Tests und Freigaben müssen wiederholt werden?
- Wie wird die Änderung überwacht und wann gilt sie als erfolgreich?
- Wie wird bei Fehlern sicher zurückgerollt?
- Welche Nutzer, Kunden oder Betroffenen müssen informiert werden?
Ein Lieferantenupdate ohne vollständige Versionsinformation wird als Unsicherheit dokumentiert. Bei kritischer Nutzung kann dies eine Einschränkung oder Aussetzung erfordern.
¶ 10. Entscheidungsablauf für Änderungen
flowchart TD
A[Änderung melden] --> B[Betroffene Baseline bestimmen]
B --> C{Zweck Daten Betroffene oder Wirkung wesentlich geändert?}
C -->|Ja| D[Klasse 3: vollständige Neubewertung]
C -->|Nein| E{Kontrollen oder Leistung relevant betroffen?}
E -->|Ja| F[Klasse 2: Auswirkungsanalyse und Regression]
E -->|Nein| G[Klasse 1 oder 0: vereinfachtes Verfahren]
D --> H[Test und befugte Freigabe]
F --> H
G --> H
H --> I[Gestuft ausrollen und überwachen]
I --> J{Schwelle verletzt?}
J -->|Ja| K[Stop Rollback Vorfallbewertung]
J -->|Nein| L[Neue Baseline bestätigen]
¶ 11. Rollout und Rollback
Eine sichere Einführung nutzt je nach Kritikalität:
- isolierte Testumgebung und synthetische Daten,
- internen Pilot mit benannten Nutzern,
- Shadow Mode ohne entscheidende Wirkung,
- prozentuale oder organisatorische Staffelung,
- Parallelbetrieb mit alter Lösung,
- Feature Flag oder schneller Sperrmechanismus,
- definierte Beobachtungszeit und Erfolgs-/Abbruchschwellen.
Der Rollback ist vor dem Deployment geplant und getestet. Er umfasst nicht nur Software, sondern auch Datenversion, Index, Prompt, Regeln, Schnittstellen, Berechtigungen und gegebenenfalls die Information betroffener Nutzer.
¶ 12. Notfalländerungen
Notfall bedeutet verkürzte Vorlaufzeit, nicht fehlende Kontrolle. Mindestanforderungen sind:
- dokumentierter Anlass und unmittelbare Gefahr,
- befugte Entscheidung und Vier-Augen-Prinzip soweit möglich,
- kleinstmöglicher Scope und zeitliche Befristung,
- Sicherung der vorherigen Baseline,
- Kernprüfung von Sicherheit, Funktion und Rückfall,
- erhöhte Überwachung nach Umsetzung,
- vollständige Nachprüfung innerhalb einer festgelegten Frist.
Kann eine sichere Änderung nicht rechtzeitig umgesetzt werden, ist Aussetzen oder manueller Fallback häufig die bessere Maßnahme.
¶ 13. Betrieb, Monitoring und Drift
| Signal | Mögliche Ursache | Lifecycle-Reaktion |
|---|---|---|
| Qualitätswert sinkt | Daten- oder Konzeptdrift, Modelländerung | Analyse, Scope begrenzen, Nachtraining oder Rollback |
| Gruppenunterschied steigt | veränderte Population oder Verzerrung | Folgenbewertung und vertiefte Tests |
| Kosten/Latenz steigen | Anbieter-, Last- oder Architekturänderung | Kapazität, Vertrag und Alternative prüfen |
| Sicherheitswarnung | Schwachstelle, Missbrauch oder neue Angriffstechnik | Notfalländerung, Sperre oder Patch |
| Beschwerden häufen sich | ungeeigneter Prozess, Transparenz- oder Qualitätsproblem | Anwendung und Aufsicht neu bewerten |
| Anbieter kündigt Modell ab | externe Lebenszyklusentscheidung | Ersatzmodell testen, Migration oder Exit |
| Aufsicht übersteuert häufig | Modell oder Workflow ungeeignet | Ursachenanalyse und Designänderung |
Monitoring besitzt Schwellen, Owner, Reaktionszeit und Nachweis. Ohne definierte Reaktion ist eine Kennzahl nur Beobachtung.
¶ 14. Stilllegung und Exit
| Aufgabe | Prüffrage |
|---|---|
| Nutzung stoppen | Sind UI, API, Agenten und Automationen deaktiviert? |
| Zugänge entziehen | Sind Konten, Schlüssel, Rollen und Serviceverbindungen entfernt? |
| Daten behandeln | Werden Eingaben, Logs, Indizes, Trainingsartefakte und Backups aufbewahrt oder gelöscht? |
| Vertrag beenden | Sind Kündigung, Datenrückgabe, Löschbestätigung und Restpflichten geklärt? |
| Abhängigkeiten entfernen | Nutzen andere Prozesse unbemerkt den Dienst oder seine Ausgaben? |
| Nachweise erhalten | Bleiben Entscheidungen, Vorfälle und erforderliche Belege verfügbar? |
| Betroffene informieren | Müssen Nutzer, Kunden oder Betroffene über das Ende oder eine Alternative informiert werden? |
| Register schließen | Sind Status, Enddatum, Grund, Nachfolger und letzte Freigabe dokumentiert? |
Außer Betrieb bedeutet nicht gelöscht. Aufbewahrung und Löschung werden getrennt anhand gesetzlicher, vertraglicher und Beweisanforderungen entschieden.
¶ 15. Dummy-Lifecycle-Akte
| Feld | Beispiel KI-ANW-0002 |
|---|---|
| System | Cloud-Protokollassistent, Modell Beispiel-Text-4.2 |
| Baseline | BL-2026-08-01, EU-Mandant, Training deaktiviert, Prompt 1.7, Löschfrist 30 Tage |
| Scope | zehn Nutzer, interne Regeltermine, keine Personal- oder vertraulichen Kundengespräche |
| Daten | Audio und Transkript; Schutzklasse Intern; Datenblatt KI-DAT-0015 |
| Freigabe | Pilot bis 31.10.2026 mit manueller Protokollfreigabe |
| Tests | Sprecherzuordnung, wesentliche Inhaltsfehler, Löschung, Zugriff und manueller Stop |
| Änderung | Anbieter kündigt Modell 4.3 mit verbesserter Zusammenfassung an |
| Einstufung | Klasse 2, da Modellverhalten und Fehlermuster betroffen |
| Wiederholung | Qualitäts-, Datenschutz-, Sicherheits- und Regressionstest mit Pilotstichprobe |
| Rollback | Modell 4.2 für 30 Tage verfügbar; Feature Flag je Nutzergruppe |
| Entscheidung | 4.3 zunächst für zwei Testnutzer; Ausweitung nur bei erfüllten Schwellen |
| Nachweis | Änderungsantrag, Testbericht, Risikonachtrag, Freigabe und Monitoringprotokoll |
¶ 16. Qualitätsampel des Lifecycle-Prozesses
| Prüffeld | 🔴 Rot | 🟡 Gelb | 🟢 Grün |
|---|---|---|---|
| Systemgrenze | nur Produktname bekannt | Kernkomponenten erfasst | Modell, Daten, Prompts, Schnittstellen, Aufsicht und Betrieb vollständig |
| Baseline | produktiver Zustand unbekannt | Versionen teilweise | freigegebener Zustand reproduzierbar und verknüpft |
| Gates | faktische Entscheidungen | Checklisten ohne Befugnis | Kriterien, Nachweise, Entscheider und Ergebnis dokumentiert |
| Tests | Demo oder Einzeltest | Funktion und Qualität teilweise | Risiko-, Gruppen-, Sicherheits-, Aufsichts- und Regressionstests |
| Änderung | Anbieterupdate automatisch übernommen | Änderung erfasst, Wirkung offen | Klasse, Analyse, Test, Freigabe und Rollback vorhanden |
| Rollback | technisch unmöglich | ungeprüfter Plan | getesteter Rückfall einschließlich Daten und Konfiguration |
| Monitoring | nur Ausfall | Kennzahlen ohne Schwelle | Qualität, Drift, Wirkung, Sicherheit und Reaktion definiert |
| Exit | Vertragsende ohne Plan | manueller Einzelfall | Deaktivierung, Daten, Zugänge, Nachweise und Abhängigkeiten geprüft |
¶ 17. Nachweise und Kennzahlen
¶ Mindestnachweise
- Systembeschreibung und freigegebene Anforderungsbasis,
- Architektur-, Datenfluss- und Abhängigkeitsdarstellung,
- Make-or-Buy- und Lieferantenentscheidung,
- versionierte Baseline und Konfigurationsliste,
- Testplan, Testdaten, Ergebnisse und Abweichungen,
- Gate-, Pilot- und Produktionsfreigaben,
- Änderungsanträge, Klassen, Auswirkungsanalysen und Reviews,
- Deployment-, Rollback-, Monitoring- und Vorfallnachweise,
- Stilllegungs-, Daten-, Zugangs- und Exitprotokolle.
| Kennzahl | Aussage |
|---|---|
| Systeme ohne bestätigte Baseline | Betrieb nicht rekonstruierbar |
| Änderungen ohne Klasse oder Analyse | unkontrolliertes Änderungsrisiko |
| fehlgeschlagene Regressionstests | Qualitäts- oder Integrationsproblem |
| Notfalländerungen und Nachprüfungsfrist | Reife und technische Schuld |
| Rollback-Erfolgsquote und -dauer | tatsächliche Wiederherstellbarkeit |
| Anbieteränderungen ohne Vorankündigung | Lieferketten- und Vertragsrisiko |
| Drift-Alarme bis Entscheidung | Reaktionsfähigkeit des Betriebs |
| stillgelegte Systeme mit offenen Zugängen | kritische Exit-Abweichung |
¶ 18. Interne Verknüpfungen
- ISO/IEC 42001 – KI-Managementsystem
- KI-Anwendungsregister
- KI-Risiko- und Folgenbewertung
- KI-Freigabe und menschliche Aufsicht
- Datenmanagement und Datenqualität
- KI-Transparenz, Kennzeichnung und Kommunikation
- KI-Lieferanten und Drittanbietersteuerung
- Sichere Entwicklung
- IT-Betrieb und Änderungen
- Lieferanten und Dienstleister
- Incident Response
¶ 19. Offizielle Quellen und Abgrenzung
- ISO: ISO/IEC 42001:2023 – AI management systems
- ISO: ISO/IEC 5338:2023 – AI system life cycle processes
- ISO: ISO/IEC 8183:2023 – Data life cycle framework
- ISO: ISO/IEC 23894:2023 – Guidance on risk management
- EUR-Lex: Verordnung (EU) 2024/1689
Diese Seite beschreibt eine eigene organisatorische Methode und ersetzt weder lizenzierte Normtexte noch eine Rechtsberatung. Lifecycle-Gates, Änderungsklassen und Nachweise werden an System, Rolle, Risiko, Vertrag und geltendes Recht angepasst.
¶ 20. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Erstfassung mit Lifecycle-Phasen, Gates, Make-or-Buy, Baseline, Entwicklung, Tests, Änderungsklassen, Rollout, Rollback, Notfalländerung, Monitoring, Exit und Dummy-Systemakte | Musterredaktion | Ausstehend | – |
| 0.2 | 10.08.2026 | Transparenz-, Kennzeichnungs- und Kommunikationsverfahren als Lifecycle-Gate und Änderungsschnittstelle verknüpft | Musterredaktion | Ausstehend | – |
| 0.3 | 10.08.2026 | KI-Lieferanten- und Drittanbietersteuerung als Make-or-Buy-, Änderungs-, Vorfall- und Exit-Schnittstelle verknüpft | Musterredaktion | Ausstehend | – |
Seite 1 von 1 · AIMS-VA-03-03 · Version 0.3