Definition
Begriff aus der EU-Maschinenverordnung Anhang I: Verhalten einer Maschine, das sich während des Betriebs durch maschinelles Lernen oder adaptive Algorithmen verändert. Sicherheitsfunktionen mit selbstevolvierendem Verhalten gelten automatisch als Hochrisiko (Teil A) und erfordern zwingend eine Konformitätsbewertung durch eine benannte Stelle. Auch statisch trainierte, aber selbstlernende Komponenten sind erfasst. Risikobeurteilung muss die Lernphase abbilden.
In der Praxis
Selbstevolvierendes Verhalten ist der MVO-Begriff für Maschinen, die nach dem Inverkehrbringen ihr Verhalten selbst ändern — lernende Systeme, im Kern KI an der Maschine. Die regulatorische Konsequenz ist scharf: Sicherheitsbauteile mit selbstevolvierendem Verhalten stehen in Anhang I Teil A der Hochrisiko-Liste, und damit kann die Benannte Stelle ins Verfahren kommen. In der Praxis erlebe ich zwei Fehleinschätzungen. Die erste: „Unsere KI optimiert nur die Zykluszeit, das ist keine Sicherheit." Sobald das lernende System eine Funktion berührt, die eine Gefährdung beherrscht, ist es Sicherheitsthema — und die Trennung zwischen Optimierung und Sicherheit muss architektonisch belegbar sein, nicht behauptet. Die zweite: klassische Validierungslogik. Einmal validieren und freigeben funktioniert bei einem System nicht, das sich weiterentwickelt — die Lernphase muss begrenzt, überwacht und von Gefährdungen entkoppelt werden, wie es Anhang III verlangt. Beachten Sie die Doppelbelastung: Bei KI-Sicherheitsbauteilen kann zusätzlich die Hochrisiko-Logik des EU AI Act greifen.
Verwandte Begriffe
Häufige Fragen zu Selbstevolvierendes Verhalten
Was unterscheidet selbstevolvierendes Verhalten von normaler KI in der Maschine?
Die Trennlinie ist der Zeitpunkt der Verhaltensänderung. Ein eingefrorenes Modell — trainiert, abgenommen und dann unverändert im Einsatz — verhält sich funktional wie komplexe Software: Sein Verhalten ist zum Zeitpunkt der Konformitätsbewertung vollständig prüfbar, die klassische Validierung trägt. Selbstevolvierend bedeutet: Das System lernt im Betrieb weiter und ändert sein Verhalten nach dem Inverkehrbringen — die Validierung zum Auslieferungszeitpunkt deckt dann nur den Startzustand ab, nicht das, was die Maschine in zwei Jahren tut. Genau dafür braucht es die MVO-Anforderungen: Lernziele und -grenzen müssen spezifiziert sein, unkontrollierte Änderungen, die zu Gefährdungen führen könnten, sind zu verhindern — auch während der Lernphase. Praktisch heißt das: Wer KI einsetzt, muss architektonisch entscheiden, ob das System einfriert oder weiterlernt — und die Entscheidung in der technischen Dokumentation begründen (Verordnung (EU) 2023/1230, Anhang III).
Welche regulatorischen Folgen hat ein Sicherheitsbauteil mit selbstevolvierendem Verhalten?
Zwei Ebenen greifen. Erstens die MVO: Sicherheitsbauteile mit selbstevolvierendem Verhalten sind in Anhang I Teil A der Hochrisiko-Liste aufgeführt — für solche Produkte kommt je nach gewähltem Konformitätsbewertungsverfahren und je nachdem, ob harmonisierte Normen angewendet werden, eine Benannte Stelle ins Spiel. Das ist ein erheblicher Unterschied zur Selbsterklärung, die bei Standardmaschinen der Normalfall ist. Zweitens der EU AI Act: KI-Systeme, die als Sicherheitsbauteile in Produkten stecken, die selbst Hochrisiko-Regelungen unterliegen, fallen in dessen Hochrisiko-Logik — mit eigenen Pflichten zu Risikomanagement, Datenqualität und menschlicher Aufsicht. Beide Regelwerke laufen parallel; die MVO ist ab dem 20. Januar 2027 anwendbar, die AI-Act-Fristen staffeln sich ebenfalls in diese Jahre. Planen Sie KI-Sicherheitsfunktionen also immer als Doppel-Compliance-Projekt (Verordnung (EU) 2023/1230, Anhang I Teil A; Verordnung (EU) 2024/1689).
Wie setzen wir lernende Systeme in der Maschine sicher und konform ein?
Vier Architektur-Regeln haben sich bewährt. Erstens: Entkoppeln Sie die Sicherheit von der Lernlogik — Sicherheitsfunktionen bleiben deterministisch und nach ISO 13849-1 oder IEC 62061 ausgelegt; die lernende Komponente darf sie niemals überstimmen. Ein lernender Optimierer, der die Sicherheitsgrenze verschieben kann, ist ein Konstruktionsfehler, kein Feature. Zweitens: Spezifizieren Sie Lernziele, Lernraum und Grenzen explizit — was darf das System verändern, in welchem Korridor, mit welchen harten Stopps. Drittens: Trennen Sie Lernphase und Normalbetrieb, und protokollieren Sie Verhaltensänderungen — ohne Änderungshistorie ist im Schadensfall nichts rekonstruierbar. Viertens: Bauen Sie einen Freigabeprozess für Verhaltensänderungen, analog zum Änderungsmanagement in der Konstruktion — jede wesentliche Verhaltensänderung durch Lernen muss bewertet werden, ob sie eine neue Konformitätsfrage auslöst. Dokumentieren Sie das Gesamtkonzept in der Risikobeurteilung nach ISO 12100 und der technischen Dokumentation.