Lebenszyklus-Kontrollen | STOP.LI

STOP.LI · AI Security · Technik und Betrieb

LebenszyklusKontrollen von der Planung bis zur Stilllegung.

Ein KI-System ändert sich auch dann, wenn niemand eine Zeile Code anfasst. Der Katalog ordnet Kontrollen und Nachweise den Phasen von Planung bis Ausserbetriebnahme zu und zeigt, wann eine Modelländerung eine Neufreigabe braucht, was unter Konfigurationsmanagement fällt und wie Notfalländerungen ohne Neutraining ablaufen.

Rechtsstand: 12. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar.

ISMS-Prozess: 14 Entwicklung · 15 Konfiguration · 17 Änderungen · 18 Patchsteuerung
Phasenmodell

Fünf Phasen,
drei Quellen.

Die Quellen schneiden den Lebenszyklus unterschiedlich. Das NIST AI RMF übernimmt vom OECD-Rahmen Lebenszyklusphasen und ordnet ihnen KI-Akteure zu; Risikomanagement beginnt idealerweise bei «Plan and Design» und läuft durch alle Phasen. Die NCSC/CISA-Leitlinien kennen vier Bereiche, ETSI EN 304 223 fünf Phasen. Diese Seite verwendet fünf Phasen und weist jeder die Entsprechung der Quellen zu.

Grundsatz

Jede Kontrolle braucht einen Nachweis, den eine dritte Person prüfen kann: ein Ticket, ein Protokoll, ein Testbericht oder eine Freigabe. Ohne Nachweis gilt die Kontrolle bei Audits als nicht umgesetzt.

Phase NIST AI RMF / OECD NCSC/CISA ETSI EN 304 223
1 Planung und Entwurf Plan and Design Secure design Secure Design (Prinzipien 1 bis 4)
2 Entwicklung und Beschaffung Daten sammeln, Modell bauen, prüfen Secure development Secure Development (Prinzipien 5 bis 9)
3 Inbetriebnahme Deploy and Use Secure deployment Secure Deployment (Prinzip 10)
4 Betrieb und Änderung Operate and Monitor Secure operation and maintenance Secure Maintenance (Prinzipien 11, 12)
5 Ausserbetriebnahme GOVERN 1.7, MANAGE 2.4 nicht eigenständig Secure End of Life (Prinzip 13)

Dieselben Phasen gelten für selbst entwickelte Modelle und für zugekaufte Dienste. Bei zugekauften Diensten verschiebt sich ein Teil der Nachweise zum Anbieter, siehe Lieferanten und Modelle.

Kontrollkatalog

Kontrolle, Nachweis,
je Phase.

Phase Kontrolle Nachweis
1 Planung Use Case im Inventar erfasst und klassifiziert, Risikobeurteilung durchgeführt, Abschaltkriterien und Verantwortliche vor dem Start festgelegt Inventareintrag, Risikobeurteilung, Freigabe der Leitung (Inventar, Risiko)
2 Entwicklung Herkunft von Daten, Modellen und Bibliotheken dokumentiert, Modelldateien mit Hash geprüft und gescannt, Code- und Abhängigkeitsprüfung, Daten, Modelle und Prompts versioniert AI-BOM, Scan-Bericht, Hash-Protokoll, Repository-Historie
2 Entwicklung Sicherheitstests vor Freigabe, möglichst durch unabhängige Prüfer; Ergebnisse vom Entwickler an den Betreiber weitergegeben Testbericht mit Befunden und Massnahmen (Methoden: Testing und Red Teaming)
3 Inbetriebnahme Freigabe durch AI-Owner und Security, bekannte Grenzen und Fehlerbilder an Nutzende kommuniziert, Protokollierung und Monitoring vor dem Start aktiv, Rollback getestet Freigabeprotokoll, Nutzerinformation, Rollback-Test
4 Betrieb Verhalten und Eingaben überwacht, Drift gemessen, Updates und Patches nach Plan eingespielt, Änderungen über Change Management Monitoring-Berichte, Change-Tickets, Patchstand (Monitoring und Incident Response)
5 Ausserbetriebnahme Stilllegungsplan, Zugriffe und Schlüssel entzogen, Daten und Konfiguration sicher gelöscht, Inventar aktualisiert Löschprotokoll, Abnahme durch AI-Owner und Datenverantwortliche

Werkzeugklassen: Code Security, SBOM und VEX (für die AI-BOM), Configuration Management, Change und Remediation Workflow. Die Klasse AI-SPM und Modell-Lieferkette prüft auch Modelldateien vor dem Einsatz.

Modell-Change

Wann eine Änderung
neu freigegeben wird.

Die NCSC/CISA-Leitlinien empfehlen, grosse Updates wie neue Versionen zu behandeln, weil Änderungen an Daten, Modellen oder Prompts das Verhalten ändern können. ETSI EN 304 223 sieht dasselbe vor (Provision 5.4.1-2) und rät Entwicklern, Betreibern die Bewertung von Modelländerungen zu erleichtern, etwa über Vorschauzugang und versionierte Schnittstellen (5.4.1-3). Im Betrieb heisst das: Jede Änderung wird genau einer von vier Klassen zugeordnet. Die Klasse bestimmt den Aufwand und den Nachweis.

Klasse Woran Sie sie erkennen Verfahren und Nachweis
Wesentlich Das Verhalten des Systems kann sich breit oder unvorhersehbar ändern, oder seine Reichweite wächst: anderes Modell oder andere Modellversion, Feinabstimmung, Neutraining, neue Datenquelle oder neuer Index, neues Tool oder neue Berechtigung für einen Agenten. Volle Neufreigabe wie bei der Inbetriebnahme: Regressions- und Sicherheitstest, Vergleich mit der Basislinie, Rollback-Version bereit, Freigabe durch AI-Owner und Security. Nachweis: Freigabeprotokoll und Testbericht.
Geringfügig Das Verhalten ändert sich gezielt und begrenzt, und es gibt kein vorab genehmigtes Muster dafür: Änderung des Systemprompts oder der Guardrail-Regeln, neue Filterregel, neue Vorlage. Normaler Change mit Test (Angriffs- und Qualitätsfälle) und Vier-Augen-Freigabe. Nachweis: Change-Ticket, Testergebnis, Name der freigebenden Person.
Vorab genehmigt Die Änderung entspricht einem Muster, das die Change-Verantwortlichen vorab freigegeben haben, ist wiederholbar und hat ein bekanntes, kleines Risiko: Anpassung von Parametern innerhalb festgelegter Bandbreiten, Patch der Laufzeitumgebung. Standardänderung ohne neue Freigabe. Nachweis im Ticket: Verweis auf das Muster, Zeitpunkt, Ausführende, Ergebnis der Prüfung. Das Muster selbst wird regelmässig überprüft.
Notfall Eine laufende Störung oder ein Angriff verlangt sofortiges Handeln, das reguläre Verfahren dauert zu lange. Eigenes Verfahren, siehe Abschnitt «Notfalländerung» unten.

Im Zweifel gilt die höhere Klasse. Eine Änderung, die sich keinem vorab genehmigten Muster zuordnen lässt, ist mindestens geringfügig. Ein neues Tool oder eine neue Datenquelle ist nie vorab genehmigt: Prüfung nach Agenten und MCP beziehungsweise Herkunfts- und Qualitätsprüfung der Daten.

Wirkt der Anbieter eines zugekauften Modells im Hintergrund eine neue Version ein, fehlt Ihnen die Kontrolle. Vereinbaren Sie festgelegte Modellversionen, Vorankündigung und Rückfalloption im Vertrag.

Rechtlicher Rahmen

«Wesentlich»
im AI Act.

Der AI Act kennt den Begriff «wesentliche Veränderung» (Art. 3 Nr. 23): eine Veränderung nach Inverkehrbringen oder Inbetriebnahme, die in der ursprünglichen Konformitätsbewertung nicht vorgesehen war und entweder die Konformität mit den Anforderungen an Hochrisiko-Systeme beeinträchtigt oder die Zweckbestimmung ändert. Hochrisiko-Systeme müssen nach einer solchen Änderung ein neues Konformitätsbewertungsverfahren durchlaufen (Art. 43 Abs. 4). Bei lernenden Systemen gelten vorab festgelegte und in der technischen Dokumentation beschriebene Änderungen nicht als wesentlich.

Auch Betreiber betroffen

Wer ein Hochrisiko-System wesentlich verändert, so dass es Hochrisiko bleibt, wird selbst zum Anbieter (Art. 25 Abs. 1 Bst. b). Das Qualitätsmanagementsystem des Anbieters muss ein Konzept für das Management von Änderungen enthalten (Art. 17 Abs. 1 Bst. a). Die interne Klasse «Wesentlich» ist nicht der Rechtsbegriff: Eine intern wesentliche Änderung kann eine wesentliche Veränderung im Sinne des AI Act sein, muss es aber nicht. Rechtsfolgen, namentlich das neue Konformitätsverfahren nach Art. 43 Abs. 4, hat nur die rechtlich wesentliche Veränderung eines Hochrisiko-Systems. Ob sie vorliegt, prüft die Rechtsabteilung oder der Anbieter anhand von Art. 3 Nr. 23 und der technischen Dokumentation, nicht die interne Klasse. Die interne Einteilung ist bewusst strenger als das Gesetz: Sie prüft jede Änderung, nicht nur rechtlich wesentliche.

Konfiguration

Was versioniert
werden muss.

Bei KI-Systemen bestimmt nicht nur der Code das Verhalten. ETSI EN 304 223 sieht ein Prüfprotokoll für Änderungen an Systemprompts und anderer Modellkonfiguration vor (Provision 5.2.4-3) und sieht vor, dass Entwickler Hashes der weitergegebenen Modellkomponenten veröffentlichen (5.2.4-1.2).

  • Modellversion: exakt festgelegt, nie «latest».
  • Systemprompt und Vorlagen: im Repository, mit Freigabe und Änderungshistorie.
  • Guardrails und Filterregeln: als Code mit Version.
  • Parameter: Temperatur, Token-Limits, Rate Limits.
  • Tool- und Berechtigungsliste der Agenten.
  • Index und Embedding-Modell der Wissensbasis.
  • Abweichungserkennung: laufende Konfiguration wird täglich mit dem freigegebenen Stand verglichen.
Notfalländerung

Schnell handeln,
ohne Neutraining.

Ein Modell lässt sich nicht in Stunden neu trainieren. Wirksame Notmassnahmen greifen deshalb ausserhalb des Modells. ETSI sieht Mechanismen und Notfallpläne vor, wenn Updates nicht möglich sind (Provision 5.4.1-1.1).

Massnahme Wirkung Grenze
Eingabefilter oder Blockregel für ein Angriffsmuster Stoppt bekannte Injection-Varianten Variationen umgehen starre Regeln
Ausgabefilter für Personendaten, Geheimnisse, Formate Begrenzt Abfluss sofort Entfernt keine Daten aus Modell oder Index
Funktion oder Tool per Schalter deaktivieren Unterbricht den Pfad, die Anwendung läuft weiter Schalter muss vorher gebaut und geübt sein
Rollback auf letzte geprüfte Modell-, Prompt- und Indexversion Stellt bekannten Zustand her Setzt versionierte Konfiguration voraus
Rate Limits senken, Schlüssel sperren Bremst Extraktion und Kostenmissbrauch Trifft auch legitime Nutzung

Notfalländerungen folgen einem vorab festgelegten Verfahren, sind aber kein Freibrief: Entscheid durch die Leitung des Incident-Teams, Dokumentation im Ticket, nachträgliche Prüfung innert weniger Arbeitstage, Rücknahme oder reguläre Überführung. Ablauf der Vorfallbehandlung: Monitoring und Incident Response.

Ausserbetriebnahme

Stilllegen,
ohne Altlasten.

Das NIST AI RMF sieht Prozesse vor, um KI-Systeme sicher stillzulegen und auslaufen zu lassen, ohne Risiken zu erhöhen oder Vertrauen zu mindern (GOVERN 1.7). MANAGE 2.4 sieht Mechanismen vor, um Systeme abzulösen, abzuschalten oder zu deaktivieren, deren Ergebnisse nicht zum vorgesehenen Gebrauch passen.

  • Beim Stilllegen eines Modells oder Systems beziehen Entwickler und Betreiber die Datenverantwortlichen ein und löschen Daten und Konfigurationsdetails sicher (ETSI Provision 5.5.1-2).
  • Beim Übertragen von Trainingsdaten oder Modellen an Dritte gilt dasselbe für die abgegebenen Bestände (5.5.1-1).
  • Zugänge, Schlüssel, Dienstkonten, Agenten-Tools und Integrationen widerrufen.
  • Protokolle und Dokumentation nur so lange aufbewahren, wie Pflichten es erfordern. Anbieter von Hochrisiko-Systemen halten Unterlagen zehn Jahre bereit (Art. 18 Abs. 1).
  • Inventar, Lieferantenverträge und Kontinuitätsplanung nachführen.
Post-Market-Monitoring

Beobachtung
nach Inverkehrbringen.

Anbieter von Hochrisiko-KI-Systemen richten ein System zur Beobachtung nach dem Inverkehrbringen ein und dokumentieren es (Art. 72 Abs. 1). Es muss Leistungsdaten über die gesamte Lebensdauer aktiv und systematisch erheben, dokumentieren und analysieren, damit der Anbieter die fortdauernde Einhaltung der Anforderungen bewerten kann (Abs. 2). Es beruht auf einem Plan, der Teil der technischen Dokumentation ist; die Kommission legt bis 2. September 2027 Leitlinien samt Muster vor (Abs. 3). Das System ist Teil des Qualitätsmanagementsystems (Art. 17 Abs. 1 Bst. h). Betreiber informieren den Anbieter gegebenenfalls (Art. 26 Abs. 5).

Die Hochrisiko-Anforderungen gelten nach der Verordnung (EU) 2026/1744 später als ursprünglich vorgesehen; massgebende Daten im Fristenkalender DCH. Für andere KI-Systeme ist der Plan ein sinnvoller Massstab. Signale, Schwellen und Protokolle stehen auf der Seite Monitoring und Incident Response; die Kennzahlen dazu auf Kennzahlen und Reporting.

Zusätzlich für Finanzinstitute

EU: Für Anbieter von Hochrisiko-KI-Systemen, die Finanzinstitute sind, gilt die Pflicht zum Qualitätsmanagementsystem als erfüllt, wenn sie die Vorschriften zur internen Unternehmensführung nach dem Finanzmarktrecht einhalten; ausgenommen sind Art. 17 Abs. 1 Bst. g, h und i, also Risikomanagement, Beobachtung nach dem Inverkehrbringen und Vorfallmeldung (Art. 17 Abs. 4). Für Hochrisiko-Systeme nach Anhang III Nr. 5 dürfen Finanzinstitute den Plan zur Beobachtung in bestehende Systeme integrieren, sofern ein gleichwertiges Schutzniveau erreicht wird (Art. 72 Abs. 4 UAbs. 2).

AI Act Framework für Finanzinstitute

Unterstützung

Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt beim Aufbau von Freigabe, Change-Klassen und Stilllegungsprozess für KI-Systeme. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.