Eine bestandene Regressionstestsuite beantwortet nicht, ob eine KI-Änderung innerhalb der bisher bewerteten Zweckbestimmung und Grenzen bleibt. Fixieren Sie vor der Freigabe ein Vorher-nachher-Dossier, identifizieren Sie betroffene Kontrollen und übergeben Sie offene Fragen zu Zweckbestimmung, Verantwortung oder Konformität an eine zuständige prüfende Person. Automatisieren Sie Nachweisprüfungen und die Weiterleitung – nicht das rechtliche Urteil, ob eine Veränderung wesentlich ist.
Dieser Beitrag beschreibt eine technische Übergabe für Plattformteams und KI-Verantwortliche. Er ist weder Rechtsberatung noch Konformitätsbewertung. Qualifizierte Rechtsberatung muss Geltungsbereich, Rollen, Anwendungszeitpunkte, Ausnahmen und die rechtliche Bedeutung einer konkreten Änderung klären. Ein Prompt-, Modell- oder Retrieval-Update ist nicht automatisch eine wesentliche Veränderung. Umgekehrt belegt ein unverändertes Modell keine unveränderte Zweckbestimmung des Systems.
Trennen Sie drei Fragen vor der Änderung Ihres Freigabeprozesses
Die erste Frage ist technisch: Erfüllt der Kandidat die freigegebenen Qualitäts-, Sicherheits- und Betriebstests? Die zweite ist sachlich: Was ändert sich gegenüber dem bewerteten System und seiner Zweckbestimmung? Die dritte ist rechtlich: Erfordern diese Tatsachen eine andere Verantwortungszuordnung oder ein anderes Konformitätsverfahren? Diese Fragen nutzen gemeinsame Nachweise, haben aber unterschiedliche Entscheidungsverantwortliche.
Artikel 3 Nummer 23 definiert die wesentliche Veränderung anhand einer Änderung nach dem Inverkehrbringen oder der Inbetriebnahme, die in der ursprünglichen Konformitätsbewertung des Anbieters nicht vorgesehen oder geplant war und die Einhaltung der Anforderungen aus Kapitel III Abschnitt 2 beeinflusst oder die bewertete Zweckbestimmung verändert. Die Artikel-3-Referenz der Kommission bietet Kontext. Wegen ihres Änderungshinweises ist sie jedoch zusammen mit dem aktuellen Text zu lesen, nicht als vollständig aktualisiertes Regelwerk.
Artikel 25 Absatz 1 unterscheidet unter anderem zwischen der wesentlichen Veränderung eines bereits bestehenden Hochrisiko-KI-Systems, das weiterhin ein Hochrisiko-KI-System bleibt, und einer Zweckänderung, durch die ein zuvor nicht als hochriskant eingestuftes System zu einem Hochrisiko-KI-System wird. Auch das Anbringen eines eigenen Namens oder einer eigenen Marke ist ein genannter Fall. Artikel 43 Absatz 4 behandelt eine neue Konformitätsbewertung nach wesentlicher Veränderung eines bereits bewerteten Hochrisiko-KI-Systems, auch bei weiterer Nutzung durch denselben Betreiber. Fassen Sie Rollenprüfung und Konformitätsprüfung nicht in einem einzigen Kontrollkästchen zusammen.
Die Regelung desselben Absatzes für weiterlernende Systeme betrifft Änderungen und Leistung, die der Anbieter bei der ursprünglichen Konformitätsbewertung vorab festgelegt und nach Anhang IV Nummer 2 Buchstabe f dokumentiert hat. Ein späterer Roadmap-Eintrag „Wir wollten das Modell verbessern“ belegt diesen ursprünglich dokumentierten Umfang nicht. Die Regelung ist auch keine pauschale Ausnahme für sämtliche Updates.
Die Quellenprüfung am 21. September 2026 nutzte die aktuelle EUR-Lex-Konsolidierung und den ändernden Rechtsakt im Amtsblatt. Vollständige nummerierte Bestimmungen wurden mit einer aufbewahrten PDF-Fassung derselben Konsolidierung abgeglichen, weil die frisch abgerufene HTML-Extraktion einzelne Absätze ausließ. Die Konsolidierung ist eine Dokumentationshilfe; maßgeblich sind die authentischen Rechtsakte im Amtsblatt. Anwendungsbestimmungen unterscheiden sich je nach Fall und wurden geändert. Die folgende Freigabesperre ist ein technischer Gestaltungsvorschlag, keine Aussage, dass jede zitierte Pflicht heute für jedes Deployment gilt.
Erstellen Sie ein Änderungsdossier statt eines weiteren Inventars
Beginnen Sie mit einer stabilen System-ID und zwei unveränderlichen Release-Referenzen: der bewerteten Baseline und dem Kandidaten. Vergleichen Sie nicht ausschließlich das letzte Deployment mit dem neuen. Mehrere kleine Releases können sich insgesamt vom bewerteten Ausgangszustand entfernen, obwohl jede einzelne Differenz gering erscheint. Bewahren Sie die Zwischenstände als ergänzende Nachweise auf.
Das LLM-Release-Bundle liefert reproduzierbare Komponentenidentität und Rollback. Das Dossier ergänzt eine andere Zuordnung: Welche bewertete Zweckbestimmung, dokumentierten Grenzen und Verantwortungsentscheidung haben diese Komponenten unterstützt? Eine Bundle-Prüfsumme belegt die Integrität der Bytes, nicht den regulatorischen Umfang.
Nutzen Sie die folgende vorgeschlagene Dossiervorlage. Die Beispiele sind hypothetische Feldinhalte, keine Anbieteraussagen und kein vorgeschriebenes Rechtsformular. Jede inhaltliche Aussage benötigt eine Nachweisreferenz und eine verantwortliche Person. Unbekannt ist ein zulässiger Zustand, aber keine Freigabe.
| Dossierfeld | Bewertete Baseline | Vorgeschlagener Kandidat | Nachweis und Verantwortung |
|---|---|---|---|
| System und Release | System-ID; Digest des bewerteten Bundles | Gleiche Identität oder vorgeschlagene Identitätsänderung; Kandidaten-Digest | Deployment-Register; Release-Verantwortung |
| Zweck und betroffene Nutzer | Zitierte Zweckbestimmung; Dokumentrevision; zulässiger Ablauf | Explizite Zweckänderung; Nutzer; Entscheidungsbefugnis | Anleitung und Prozessentwurf; Produktverantwortung |
| Vorab festgelegter Änderungsumfang | Ursprüngliche Bewertungsreferenz; genaue dokumentierte Grenzen | Behauptete Übereinstimmung, Widerspruch oder unbekannt | Ursprüngliche technische Dokumentation; Anbieterbetreuung |
| Komponenten und Abhängigkeiten | Revisionen von Modell, Prompt, Retrieval, Werkzeugen und Oberfläche | Hinzugefügte, entfernte und geänderte Revisionen | Manifestvergleich; Plattformverantwortung |
| Kontrollen und Tests | Bewertete Aufsicht, Protokollierung und Eingabegrenzen | Auswirkungszuordnung; neue Tests; offene Fehler | Testartefakte; Kontrollverantwortliche |
| Verantwortung und Übergabe | Rechtsträger, Rollenentscheidung und geprüfter Verfahrensweg | Möglicher Rollenwechsel; fehlende Anbieternachweise | Rechtlich verantwortete Entscheidung; Recht und Compliance |
Speichern Sie Nachweise mit Zugriffskontrolle. Das Release-Manifest sollte Referenzen, Revisionen und Digests enthalten, keine ungeschützten Personalakten oder Lieferantendokumente. Halten Sie fest, wer die zugrunde liegenden Nachweise einsehen darf und was bei einem Entzug des Zugriffs geschieht. Eine erreichbare URL genügt nicht, wenn die zuständige prüfende Person den Inhalt nicht lesen kann.
Entscheidungstabelle: Tatsachen zuordnen, keinen Rechtsstatus verkünden
Verwenden Sie zwei unabhängige Achsen: Komponentenänderung und Änderung von Zweck oder Kontext. Ein Codevergleich kann eine neue Werkzeugberechtigung erkennen. Er kann nicht entscheiden, ob ein neuer Ablauf wesentlich verändert, wer betroffen ist oder wie Ergebnisse verwendet werden. Lassen Sie diese Tatsachen ausdrücklich von der Prozessverantwortung bestätigen.
| Beobachtete Änderung | Erforderliche Nachweise | Technische Behandlung | Frage für die zuständige Prüfung |
|---|---|---|---|
| Neues Modell oder neuer Prompt; Zweck angeblich unverändert | Baseline-/Kandidatentests; ursprünglicher Änderungsumfang; Kontrollauswirkungen | Bei ungeklärtem Umfang oder Einfluss Freigabe halten | Deckt die dokumentierte Bewertung diese Tatsachen ab? |
| Gleiches Modell; Empfehlung löst jetzt eine Entscheidung aus | Alter/neuer Prozess; betroffene Personen; Befugnis und Aufsicht | Geänderte Entscheidungsfunktion zurückhalten | Ändern sich Zweckbestimmung oder Rollenverantwortung? |
| Retrieval-Korpus erhält eine neue Dokumentklasse | Eingabegrenzen; Herkunft; Tests unzulässiger Eingaben und Ausgaben | Betroffenen Pfad vor Freigabe prüfen | Sind bewertete Grenzen oder Kontrollen betroffen? |
| Lernupdate angeblich innerhalb vorab festgelegter Grenzen | Ursprüngliche Bewertung; Referenz auf Anhang IV 2(f); gemessene Grenzen | Nachweise prüfen, dann gemäß freigegebener Richtlinie weiterleiten | Ist die behauptete Grundlage tatsächlich anwendbar? |
| Neue Marke, neuer Rechtsträger oder neue Lieferantengrenze | Verträge; Kennzeichnung; Systemidentität; Informations- und Zugriffslücken | Verantwortungsprüfung eröffnen | Welche Fälle und Ausnahmen aus Artikel 25 sind relevant? |
| Keine relevante Umfangsänderung; Nachweise vollständig | Bestätigter Tatsachenvergleich; aktuelle begrenzte Entscheidung; bestandene Tests | Für eine autorisierte Freigabeentscheidung vorbereiten | Gilt die vorhandene Freigabe für diesen Kandidaten weiter? |
„Zurückhalten“ bedeutet hier: Die Übernahme des Kandidaten wird nach der vorgeschlagenen internen Richtlinie gesperrt. Es ist keine pauschale Aufforderung, ein laufendes industrielles System anzuhalten. Betriebssicherheit, Vorfallmeldungen und rechtlich erforderliche Aussetzungen benötigen eigene freigegebene Verfahren. Eine Release-Ausnahme darf diese nicht außer Kraft setzen.
Ein Entscheidungsbaum, der bei einer prüfenden Person endet
Lesen Sie das Diagramm als Nachweiszuordnung. Fehlen Baseline-Zweck, Bewertungsreferenz oder Kandidatenidentität, lautet der Zustand nachweis-unvollständig; die fehlende Information erhält eine verantwortliche Person. Sind die Referenzen vorhanden, vergleichen Sie Zweck, betroffene Nutzer, Ergebnisbefugnis und Kontrollen. Eine geänderte oder unbekannte Antwort eröffnet die Umfangsprüfung. Bleiben diese Tatsachen unverändert, prüfen Sie den behaupteten dokumentierten Änderungsumfang und betroffene Testergebnisse. Ungeklärter Umfang führt ebenfalls zur Prüfung, fehlgeschlagene Tests zur technischen Nacharbeit.
Der letzte automatisierte Zustand lautet prüfbereit – nicht konform, nicht unwesentlich und nicht freigegeben. Ein autorisierter Entscheidungsdatensatz benennt die geprüfte Dossierrevision, den Kandidaten-Digest, den erlaubten Umfang, Bedingungen, Entscheidungsbefugnis und gegebenenfalls Ablauf- oder Wiedereröffnungskriterien. Ein separater Release-Controller prüft diese Entscheidung zusammen mit der technischen Abnahme vor der Übernahme.
Invalidieren Sie die Entscheidung, sobald sich die zugeordneten Nachweise ändern. Wird der Kandidat nach der Prüfung angepasst, darf die frühere Freigabe nicht allein wegen derselben Ticketnummer bestehen bleiben. Verwenden Sie an der Freigabegrenze einen Compare-and-Swap auf Dossierrevision oder Digest. Wiederholte Freigabeereignisse müssen idempotent sein und dürfen keinen anderen Kandidaten autorisieren.
Anbieterkooperation gehört zum Nachweispfad
Der geänderte Artikel 25 Absatz 2 konkretisiert die Kooperationsunterlagen: relevante technische Dokumentation, bekannte Grenzen und Fehlermodi sowie gezielter technischer Zugang einschließlich Tests und Validierung. Zugleich bleibt eine ausdrücklich genannte Ausnahme bestehen, wenn der ursprüngliche Anbieter klar festgelegt hat, dass sein System nicht in ein Hochrisiko-KI-System umgewandelt werden darf. Betrachten Sie fehlende Unterlagen nicht als automatisch beschaffbar und unterstellen Sie keinen unbegrenzten Anspruch auf Modellgewichte.
Der geänderte erste Unterabsatz von Artikel 25 Absatz 4 nennt ausdrücklich auch ein KI-Modell bei den Liefergegenständen der schriftlichen Informations- und Unterstützungsvereinbarung. Seine Ausnahme für freie und quelloffene Angebote ist begrenzt und nimmt KI-Modelle mit allgemeinem Verwendungszweck von dieser Ausnahme aus. Die Artikel-25-Seite der Kommission weist weiterhin darauf hin, dass ihr dargestellter Text nicht aktualisiert wurde. Grundlage dieser Details ist die operative Änderung, nicht die Zusammenfassung der Seite.
Verfolgen Sie angeforderte Nachweise, Anbieterantwort, Zugangsbedingungen, ungeklärte Grenzen und die verantwortliche Einkaufs- oder Rechtsfunktion. Eine Ablehnung des Anbieters wird zur sichtbaren Prüfbedingung, nicht zu einer leeren Zeichenfolge, die die Schemavalidierung besteht. Schützen Sie vertrauliche Informationen und Geschäftsgeheimnisse; sinnvolle Zusammenarbeit bedeutet keine uneingeschränkte Offenlegung.
Beispiel: unveränderte Gewichte, geänderte Befugnis
Betrachten Sie einen hypothetischen Assistenten, der interne Wartungsnotizen entwirft. Ein vorgeschlagener Ablauf erzeugt aus demselben Ergebnis nun einen priorisierten Arbeitsauftrag ohne die bisherige Bestätigung durch das Bedienpersonal. Der Modell-Digest bleibt gleich; Werkzeugberechtigungen, Entscheidungsbefugnis und menschliche Aufsicht ändern sich. Dieses Beispiel stuft das System weder als hochriskant ein noch erklärt es die Änderung für wesentlich.
Das Dossier sollte frühere Anleitung und Prozessdarstellung, das neue Schreibrecht, den entfernten Bestätigungsschritt, betroffene Nutzer und Anlagen sowie den Rückfallpfad enthalten. Prüfen Sie, ob eine nicht abgesicherte Empfehlung einen Auftrag erzeugen kann, ob ein Abbruch laufende Schreibvorgänge stoppt und ob das Bedienpersonal den Grund eines vorgeschlagenen Auftrags rekonstruieren kann. Bestandene Sprachqualitätstests allein beantworten diese Fragen nicht.
Die Produktverantwortung bestätigt den beabsichtigten Ablauf. Plattform- und Betriebsverantwortliche weisen die Kontrollen nach. Recht und Compliance prüfen die tatsächliche Änderung sowie den einschlägigen Verantwortungs- und Konformitätsweg. Erst eine begrenzte Entscheidung zusammen mit bestandenen technischen Prüfungen kann den Kandidaten nach diesem Richtlinienvorschlag autorisieren. Begrenzt die Prüfung die Nutzung auf Entwürfe, setzen Sie diese Grenze in Berechtigungen durch statt in einem Warnabsatz.
Eine durch ein Schadenssignal ausgelöste Änderung sollte mit dem Post-Market-Risikofeedback verbunden bleiben. Dringlichkeit beseitigt die bewertete Baseline nicht. Nutzen Sie ein geprüftes Notfalländerungsverfahren mit ausdrücklicher Befugnis, begrenztem Umfang und nachgelagerten Nachweispflichten. Die Bezeichnung „Vorfallkorrektur“ darf keine dauerhafte Umgehung schaffen.
Prüfen Sie die Sperre vor ihrer verpflichtenden Einführung
Fehlende Nachweise: Entfernen Sie das ursprüngliche Zweckdokument. Das Ergebnis muss nachweis-unvollständig sein und darf nicht standardmäßig unverändert lauten.
Kumulative Abweichung: Reichen Sie einen Kandidaten über mehrere einzeln kleine Änderungen ein. Prüfen Sie den Vergleich sowohl mit der bewerteten Baseline als auch mit dem unmittelbar vorherigen Release.
Veraltete Freigabe: Genehmigen Sie eine Dossierrevision, ändern Sie eine Werkzeugberechtigung und spielen Sie die alte Freigabe erneut ein. Die Übernahme muss an der abweichenden Kandidatenbindung scheitern.
Anbieterunsicherheit: Erfassen Sie einen fehlenden Nachweis zum Änderungsumfang oder nicht verfügbaren Testzugang. Das System muss die Lücke einer verantwortlichen Person zuweisen, ohne eine Anbieteraussage zu erfinden.
Getrennte Entscheidungen: Bestandene Regressionstests dürfen keine rechtliche Prüfung schließen. Ein rechtlicher Prüfvermerk darf umgekehrt keinen fehlgeschlagenen Sicherheits- oder Security-Test überschreiben.
Nachgelagerter Abgleich: Wird eine geprüfte Änderung von Zweck, Rechtsträger oder Lebenszyklus genehmigt, stoßen Sie die Übergabe zwischen Registrierung und Deployment-Inventar an, soweit der separat geprüfte Verfahrensweg dies erfordert. Erstellen Sie nicht automatisch für jedes Release einen neuen regulatorischen Eintrag.
Machen Sie den Prüfaufwand sichtbar
Zu viele automatische Eskalationen erzeugen eine Freigabewarteschlange, die Teams umgehen. Zu wenige verbergen Zweckänderungen hinter scheinbar routinemäßiger Modellpflege. Begrenzen Sie wiederkehrende Arbeit mit von Prüfverantwortlichen freigegebenen Tatsachenvorlagen und Auswirkungszuordnungen. Behalten Sie einen ausdrücklichen Unbekannt-Pfad bei. Ein Sprachmodell darf Dokumentdifferenzen vorschlagen; Quellpassagen und verantwortete Bestätigung müssen sichtbar bleiben.
Messen Sie das Alter unvollständiger Nachweise, wiederholt fehlende Felder, wiedereröffnete Entscheidungen und Prüfaufwand. Das sind Prozesskennzahlen, kein Compliance-Score. Prüfen Sie an Freigabe- und relevanten Änderungsgrenzen, statt bei jeder Inferenz Rechtsdokumente abzurufen. Dies reduziert Laufzeitabhängigkeiten, lässt aber eine Beobachtungsaufgabe im Betrieb bestehen: Änderungen von Anbieterbedingungen, Oberflächenverhalten und Umfangsannahmen zwischen den Prüfungen erkennen.
Beginnen Sie mit einer anstehenden Änderung und rekonstruieren Sie Baseline, Kandidat und offene Entscheidungen. Ich unterstütze Plattform- und Compliance-Teams bei Nachweisschema, testbarer Weiterleitung und Release-Bindung; die rechtliche Bewertung liegt bei qualifizierter Rechtsberatung. Das Ergebnis sollte eine nachvollziehbare Änderungsprüfung sein – und eine Deployment-Pipeline, die den geprüften Kandidaten nicht unbemerkt gegen einen anderen austauschen kann.
