2026 EU AI Act: Modell-Upgrade auf Markierung testen

Ein Testbericht ist bereits freigegeben, doch im Bericht steht noch der alte Modell-Hash, während die Produktion auf einer neuen quantisierten Version läuft.

Die schnellste Lösung: Ein Modell-Upgrade verlangt nicht automatisch eine vollständige Neuabnahme, aber der alte Bericht darf die neue Version nicht ungeprüft abdecken. Prüfen Sie vor der Veröffentlichung, ob sich Ausgabeform, Markierungsschicht, Erkennbarkeit oder ein Ausgabe-Bypass verändert haben. Falls ja, testen Sie erneut und binden Sie den Nachweis eindeutig an die neue Version.

Zeitplan für diese Woche: Am heutigen 10.08.2026 sollten Sie die Änderungsliste einfrieren, bis 11.08.2026 die Verantwortungs- und Übergangsfrage mit der Rechtsabteilung klären und bis 12.08.2026 eine isolierte Regression gegen die produktive Ausgabekette durchführen. Für ein selbst gehostetes Modell, das nach dem 02.08.2026 wesentlich verändert oder neu in Betrieb genommen wird, darf die Frist 02.12.2026 nicht automatisch als Schutzbehauptung verwendet werden.

Für welche Teams diese Prüfung gedacht ist

Dieser Beitrag richtet sich an MLOps-Teams, die eine maschinenlesbare Markierung bereits eingebaut haben und nun Grundmodelle, Adapter, Quantisierung oder Inferenzkomponenten austauschen.

Er ist außerdem für technische Verantwortliche relevant, deren alter Testbericht noch auf eine frühere Version zeigt, sowie für Produkt- und Compliance-Verantwortliche, die bis zum 02.12.2026 Bestandsumbauten, isolierte Tests und einen belastbaren Rückfallweg organisieren müssen.

Hinweis: Dieser Beitrag ist keine Rechtsberatung. Ob eine Organisation als Provider oder Deployer einzuordnen ist, ob eine Systemänderung rechtlich wesentlich ist und ob eine Übergangsregel weiter gilt, muss die zuständige Rechtsabteilung anhand der konkreten Bereitstellung und der offiziellen Leitlinien beurteilen.

Was sich seit dem 02.08.2026 tatsächlich geändert hat

Article 50 des EU AI Act gilt seit dem 02.08.2026. Für Anbieter generativer KI-Systeme umfasst die Regelung unter anderem die Pflicht, synthetische Audio-, Bild-, Video- oder Textausgaben mit wirksamen, zuverlässigen, robusten und interoperablen maschinenlesbaren Markierungen zu versehen, damit sie als künstlich erzeugt oder manipuliert erkannt werden können. Die Europäische Kommission erläutert diese Pflichten in ihren offiziellen Fragen und Antworten zu Article 50. (digital-strategy.ec.europa.eu)

Für die technische Abnahme ist wichtig, drei Pfade nicht zu vermischen:

1. Interaktionshinweis nach Article 50 Absatz 1: Personen müssen informiert werden, wenn sie direkt mit einem KI-System interagieren.
2. Maschinenlesbare Markierung nach Article 50 Absatz 2: Generierte oder manipulierte Inhalte müssen technisch markiert und erkennbar sein.
3. Sichtbare Offenlegung nach Article 50 Absatz 4: Bestimmte veröffentlichte, KI-generierte Texte zu Angelegenheiten von öffentlichem Interesse müssen klar gekennzeichnet werden, sofern die jeweiligen Voraussetzungen erfüllt sind.

Ein Modell-Upgrade kann alle drei Pfade berühren, auch wenn das Team nur den Gewichtsdatei-Austausch geplant hat. Eine neue Dekodierung kann die Ausgabeform ändern; ein neues Inferenz-Framework kann Streaming oder Batch-Pfade umleiten; ein Gateway kann Metadaten entfernen; ein neuer Agenten-Client kann den Interaktionshinweis an einer anderen Stelle anzeigen.

Die Kommission nennt für Systeme, die vor dem 02.08.2026 auf den Markt gebracht wurden, eine begrenzte Übergangsregel bis zum 02.12.2026. Diese betrifft die Markierungs- und Erkennungspflicht nach Article 50 Absatz 2, nicht pauschal sämtliche Transparenzpflichten. Die offiziellen Informationen stützen deshalb nicht die Annahme, dass jedes spätere Upgrade automatisch dieselbe Übergangsbehandlung erbt. (digital-strategy.ec.europa.eu)

Auch die mögliche Sanktion ist kein Grund für eine pauschale technische Überreaktion, aber ein Grund für saubere Nachweise: Verstöße gegen die Transparenzpflichten nach Article 50 können mit bis zu 15.000.000 € oder 3 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres sanktioniert werden, je nachdem, welcher Betrag höher ist. Die konkrete Durchsetzung und Verhältnismäßigkeit hängen vom Einzelfall und den zuständigen Behörden ab. (eur-lex.europa.eu)

Vor dem Upgrade entscheidet die technische Änderungsanalyse

Die zentrale Frage lautet nicht: „Hat sich die Versionsnummer geändert?“ Entscheidend ist: Kann die Änderung beeinflussen, was erzeugt wird, wo markiert wird, ob die Markierung erkennbar bleibt oder ob eine Ausgabe die Markierungsschicht umgehen kann?

Erstellen Sie deshalb vor jedem Release eine Änderungsakte mit mindestens diesen Komponenten:

• Grundmodell und Modell-Hash
• LoRA oder anderer Adapter
• Quantisierungsverfahren und verwendete Gewichte
• Tokenizer und Chat-Template
• Dekodierungsparameter und Stop-Logik
• Inferenz-Framework und Container-Image
• Hardware-Backend und Laufzeitbibliotheken
• Systeminstruktionen und Agentenwerkzeuge
• Markierungsbibliothek oder Markierungsdienst
• Detektions- und Prüfwerkzeuge
• API-Gateway, Streaming-Schicht und Batch-Pipeline
• Dateiformate, Transkodierung und Nachbearbeitung
• Clients, Kanäle und sichtbare Veröffentlichungspfade

Danach ordnen Sie die Änderung einer von drei Klassen zu.

Klasse A: Vollständige Neuabnahme

Diese Klasse ist angebracht, wenn mehrere Schichten verändert wurden oder wenn die Änderung die technische Identität der bereitgestellten Anwendung erkennbar verschiebt. Typische Auslöser sind:

• Wechsel des Grundmodells
• neuer Tokenizer oder neues Chat-Template
• Änderung der Dekodierungs- oder Streaming-Logik
• neues Inferenz-Framework
• Austausch der Markierungskomponente
• neuer Transkodierer oder Medien-Postprozessor
• zusätzlicher direkter Ausgabepfad
• neue Modalität, etwa Text zu Bild oder Audio
• Änderung des Agentenablaufs mit externem Tool- oder Dateiausgang

Hier muss die Testbasis aus Modell, Markierung, Detektor, Container, Ausgabeformat und realem Veröffentlichungsweg als zusammengehöriges System geprüft werden.

Klasse B: Gezielte Regression

Eine Teilprüfung kann genügen, wenn die Änderung klar begrenzt ist und die betroffenen Pfade isoliert werden können. Das gilt beispielsweise für eine Quantisierung, bei der Markierungsdienst, Ausgabeformat und Gateway unverändert bleiben. Es gilt auch für eine Adapteränderung, wenn der Adapter lediglich Antwortinhalte beeinflusst, aber keine neue Ausgabeart oder Bypass-Möglichkeit einführt.

Die alte Abnahme bleibt dann nicht „gültig, weil die Architektur gleich aussieht“. Sie wird als unveränderter Teilnachweis übernommen. Zusätzlich dokumentiert das Team, welche Annahmen geprüft wurden und welche konkreten Regressionen die neue Version abdecken.

Klasse C: Nur Dokumentation aktualisieren

Diese Einstufung ist nur bei Änderungen vertretbar, die nachweisbar außerhalb der Ausgabe- und Markierungskette liegen. Beispiele können interne Eigentümerwechsel, reine Dokumentationskorrekturen oder eine Konfigurationsänderung ohne Einfluss auf Build, Laufzeit, Ausgabe, Markierung, Detektion und Veröffentlichung sein.

Eine solche Entscheidung braucht eine schriftliche Impact-Analyse. Ohne diese Begründung wird „keine technische Änderung“ schnell zu einer unbelegten Behauptung.

Der Veröffentlichungsstand muss als unveränderliche Testbasis eingefroren werden

Vor dem Test sollten Sie einen eindeutigen Release-Kandidaten erstellen. Der Testbericht muss nicht nur auf einen Modellnamen verweisen, sondern auf die Kombination, die tatsächlich veröffentlicht werden soll:

1. Modell- und Adapter-Hash erfassen.
2. Container-Image und Inferenzbibliotheken festhalten.
3. Tokenizer, Prompt-Vorlagen und Dekodierungsparameter speichern.
4. Markierungs- und Detektionskomponenten versionieren.
5. Ausgabeformate und Konvertierungsschritte definieren.
6. API-, Streaming- und Batch-Endpunkte dokumentieren.
7. Testprotokoll mit demselben Build erzeugen.
8. Freigabe nur erteilen, wenn Bericht und Produktionsartefakt denselben Versionsbezug haben.

Ein häufiger Fehler entsteht, wenn ein Modellbericht am Montag mit der alten Gewichtsdatei erzeugt wird, am Dienstag aber eine optimierte oder quantisierte Variante in das Produktions-Image gelangt. Die Markierungsbibliothek kann unverändert sein und trotzdem liegt kein sauberer Nachweis für die veröffentlichte Systemkombination vor.

Die Leitlinien der Europäischen Kommission zu den Transparenzpflichten betonen den praktischen Anwendungsbereich für Provider und Deployer. Für die technische Dokumentation bedeutet das: Die Organisation sollte nicht nur einen erfolgreichen Markierungsschreibvorgang protokollieren, sondern die relevante Ausgabe und ihren Veröffentlichungsweg nachvollziehbar zuordnen. (digital-strategy.ec.europa.eu)

Die Regression muss die reale Ausgabe statt nur den Schreibvorgang prüfen

Führen Sie die Prüfung in einer isolierten Umgebung mit derselben Markierungskomponente und möglichst demselben Release-Image durch. Eine belastbare Reihenfolge ist:

1. Textausgaben prüfen: kurze Antworten, lange Antworten, strukturierte Daten, Fehlermeldungen und Ausgaben mit Sonderzeichen.
2. Streaming und Batch getrennt ausführen: Prüfen Sie, ob Teilantworten, gepufferte Antworten und Sammelverarbeitung denselben Markierungspfad verwenden.
3. Dateierzeugung testen: Wenn das System Dateien erstellt, muss die Markierung nach Speicherung, Konvertierung und Download noch vorhanden beziehungsweise erkennbar sein.
4. Adapter- und Quantisierungsvarianten vergleichen: Ermitteln Sie, ob sich Ausgabeform, Länge, Zeichensatz oder Fehlerverhalten verändert.
5. Gateway und Nachbearbeitung einbeziehen: Prüfen Sie Kompression, Transkodierung, Caching, Inhaltsfilter, Signatur- oder Metadatenoperationen.
6. Clientpfade simulieren: Kontrollieren Sie Weboberfläche, API, Desktop-Client und Agentenkanal getrennt, sofern diese unterschiedliche Ausgaben erzeugen.
7. Fehler- und Ausweichpfade erzwingen: Ein Timeout, ein Detektorfehler oder eine nicht unterstützte Ausgabe darf nicht unbemerkt zu einer unmarkierten Veröffentlichung führen.
8. Nachweis sichern: Speichern Sie Input, Versionen, Output, Detektionsergebnis, Logauszug, Prüfer und Entscheidung in einem Release-Paket.

Vermeiden Sie dabei erfundene Erfolgsquoten oder starre Testmengen. Die angemessene Abdeckung hängt von den unterstützten Modalitäten, der Markierungstechnik, dem gewählten Standard beziehungsweise Code of Practice und der eigenen Ausgabearchitektur ab. Der offizielle Code of Practice für Transparenz bei KI-generierten Inhalten ist ein freiwilliges Compliance-Instrument; die gesetzlichen Pflichten aus Article 50 bleiben davon unabhängig verbindlich. (digital-strategy.ec.europa.eu)

FAQ: Die häufigsten Upgrade-Entscheidungen im Betrieb

LoRA, Quantisierung und Inferenz-Framework

Eine LoRA-Anpassung muss nicht automatisch eine komplette Neuabnahme auslösen. Sie sollte jedoch mindestens eine gezielte Regression erhalten, wenn sich dadurch Antwortstruktur, Ausgabeart, Tool-Nutzung oder die nachgelagerte Verarbeitung ändern.

Bei einer Quantisierung kann der alte Bericht als Architektur- und Referenznachweis weiterleben. Er ersetzt aber nicht den Nachweis, dass die neue Gewichtsrepräsentation unter realer Last dieselben markierbaren und detektierbaren Ausgaben erzeugt.

Ein Wechsel des Inferenz-Frameworks ist besonders kritisch, weil er nicht nur Modellberechnung, sondern auch Streaming, Batch-Logik, Fehlerrückgabe und Dateiausgabe verändern kann. Deshalb ist hier eine Prüfung der vollständigen Veröffentlichungskette erforderlich.

Der erste Betriebsabschnitt braucht kontrollierten Verkehr

Nach der Freigabe sollte die neue Version nicht sofort alle Nutzer bedienen. Verwenden Sie stattdessen eine der folgenden Formen:

• Schattenverkehr ohne sichtbare Auslieferung an Endnutzer
• isolierter Mandant mit begrenztem Zugriff
• graue Version neben der bestehenden Produktionsversion
• getrennte API-Route für ausgewählte interne Anwendungen
• kontrollierte Stichprobe mit protokollierter Rückfallmöglichkeit

Für die Freigabe sollten mindestens vier Bedingungen gleichzeitig erfüllt sein:

• Die Markierung ist in den vorgesehenen Ausgaben vorhanden und detektierbar.
• Direkte oder indirekte Ausgabe-Bypässe sind kontrolliert.
• Bericht, Modell, Markierung, Gateway und Produktionsartefakt sind korrekt miteinander verbunden.
• Die vorherige Version kann ohne erneuten Neuaufbau wieder aktiviert werden.

Wenn eine Markierung fehlschlägt, sollte das Team die Kombination aus Modell und betroffener Ausgabekette zurückrollen. Ein sichtbarer Hinweis im Frontend oder das Abschalten einer Warnung löst den technischen Fehler nicht. Die Anleitung zum parallelen Modellbetrieb und schnellen Rückfall kann bei der Planung einer solchen Doppelspur als technische Ergänzung dienen.

Für die ersten Betriebsstunden sind besonders diese Signale relevant:

• Ausgaben ohne erwartete Markierung
• Unterschiede zwischen API und Benutzeroberfläche
• Verluste nach Konvertierung oder Download
• Abweichungen zwischen Streaming und vollständiger Antwort
• Detektionsfehler nur bei bestimmten Sprachen oder Längen
• Umgehung über Agentenwerkzeuge, Exportfunktionen oder alternative Clients

In der ersten Woche werden Ausnahmen zu belastbaren Belegen

Ein Durchschnittswert verschleiert die Fälle, die später eine Untersuchung auslösen. Sammeln Sie deshalb im ersten Betriebsabschnitt einzelne, reproduzierbare Beispiele aus:

• unterschiedlichen Ausgabeformaten
• kurzen und langen Antworten
• den tatsächlich unterstützten Sprachen
• verschiedenen Clients und API-Versionen
• allen veröffentlichten Kanälen
• Cache-, Transkodierungs- und Downloadpfaden
• normalen und fehlerhaften Betriebszuständen

Ordnen Sie jeden Fehler einer Ursache zu. Ein neues Modell kann die Ausgabeform verändert haben. Ein Gateway kann Metadaten entfernt haben. Ein Client kann nur einen sichtbaren Hinweis ausblenden. Ein Drittanbieterkanal kann Dateien neu kodiert haben. Diese Ursachen dürfen nicht in einer einzigen „Markierung fehlgeschlagen“-Metrik verschwinden.

Dokumentieren Sie außerdem externe Fehlermeldungen, Korrekturen, betroffene Versionen und die Wiederholungsprüfung. Sobald eine neue Ausgabefähigkeit oder ein neuer sichtbarer Veröffentlichungspfad hinzukommt, beginnt die Eignungs- und Verantwortungsprüfung erneut.

Eine Trigger-Matrix ersetzt die monatliche Grundsatzdebatte

Legen Sie für jede Änderung eine feste Entscheidung fest. Die folgende Liste ist als operative Bedingung gedacht:

• Wenn Grundmodell, Tokenizer, Chat-Template, Markierungskomponente oder Ausgabeformat wechseln, dann vollständige Neuabnahme.
• Wenn Adapter, Quantisierung oder Dekodierung wechseln, aber Markierungs- und Gateway-Schichten unverändert bleiben, dann gezielte Regression mit schriftlicher Übernahme der unveränderten Nachweise.
• Wenn nur interne Dokumentation oder eine nachweislich wirkungslose Konfiguration geändert wird, dann Impact-Analyse und Dokumentationsaktualisierung.
• Wenn Streaming, Batch, Datei-Export, Transkodierung oder Clientpfade verändert werden, dann Regression über den realen Veröffentlichungsweg.
• Wenn eine neue Modalität, ein neuer Agentenkanal oder eine neue Nutzergruppe hinzukommt, dann Scope- und Rollenprüfung vor der technischen Freigabe.
• Wenn unklar ist, ob die Änderung die Systemidentität oder den Marktbereitstellungsstatus verändert, dann keine automatische Nutzung der Übergangsfrist, sondern Rechtsprüfung.

Die Übergangsregel bis zum 02.12.2026 sollte in dieser Matrix als juristischer Prüfpunkt erscheinen, nicht als technische Standardannahme. Die offizielle FAQ beschreibt ausdrücklich eine begrenzte Regel für Systeme, die vor dem 02.08.2026 auf den Markt gebracht wurden. Sie sagt nicht, dass jede spätere Modelländerung ohne weitere Prüfung darunterfällt. (digital-strategy.ec.europa.eu)

Nach einer Veröffentlichung neuer technischer Standards, einer Überarbeitung des Code of Practice, einer Änderung von Übergangsregeln oder ersten behördlichen Auslegungshinweisen muss die Matrix erneut bewertet werden. Der Code of Practice wurde von der Kommission als geeignetes Hilfsmittel bewertet, stellt laut offizieller Darstellung aber keinen abschließenden Beweis für die Einhaltung dar. (digital-strategy.ec.europa.eu)

Die Entscheidungsstufen im direkten Vergleich

Eine Übersicht der Kosten- und Laufzeitentscheidungen für eine gemietete Mac-Testumgebung kann ergänzend helfen, wenn für den Vergleich alter und neuer Builds eine getrennte Umgebung benötigt wird. Für die technische Freigabe selbst ersetzt eine Testumgebung jedoch keine rechtliche Einordnung.

Was gegenüber einer lokalen Einzelumgebung oft fehlt

Eine rein lokale Testumgebung ist für kleine Änderungen günstig, hat aber bei häufigen Upgrades drei konkrete Schwächen: Die alte Produktionsversion wird oft überschrieben, parallele Tests mit unterschiedlichen Builds sind organisatorisch schwierig, und macOS-Clients oder Agentenpfade werden nicht immer unter realistischen Bedingungen reproduziert.

Auch ein gewöhnlicher Cloud-Server ist nicht automatisch die bessere Lösung. Es können Unterschiede bei Dateisystem, Berechtigungen, Netzwerkzugriff, Medienbibliotheken, Desktop-Clients und Auslieferung entstehen. Für einen belastbaren Vergleich benötigen Sie daher eine isolierte Umgebung, in der alte und neue Version parallel erhalten bleiben und die tatsächliche Mac-Ausgabekette reproduziert werden kann.

Wenn Ihre bestehende Umgebung diese Anforderungen nicht erfüllt, prüfen Sie zunächst die Konfiguration einer isolierten Selbsthosting-Testumgebung für AI Agents und die Möglichkeit einer getrennten Testspur. Falls für kurze Upgrade-Zyklen weder parallele Versionen noch reproduzierbare macOS-Clients verfügbar sind, kann das Mieten einer Mac-Umgebung wirtschaftlich sinnvoller sein als wiederholte manuelle Umbauten. Die passende Dauer und Ausstattung sollten Sie anhand der tatsächlichen Testlast statt anhand einer pauschalen Monatsplanung wählen.

Für eine kurzfristige Validierung vor dem 02.12.2026 ist eine gemietete Umgebung besonders dann interessant, wenn sie drei Bedingungen erfüllt: Sie können das alte Release unverändert behalten, die neue Modell- und Markierungskette isoliert prüfen und nach einem Fehler ohne Datenverlust zurückrollen. Das verbessert nicht automatisch die rechtliche Position, reduziert aber die technischen Lücken, durch die ein Testbericht vom produktiven Artefakt entkoppelt wird. Informationen zu verfügbaren Optionen finden Sie auf der JexMac-Übersicht für Mac-Umgebungen.

Die faire Gegenentscheidung lautet: Für dauerhaft hohe Last, dauerhafte Hardwarebindung oder spezielle physische Schnittstellen ist der Kauf eigener Hardware weiterhin sinnvoller. Für kurze Upgrade-Fenster, Paralleltests, macOS-Client-Reproduktion und kontrollierte Rückfalltests ist eine gemietete Umgebung dagegen oft flexibler. Entscheidend ist, dass die Testumgebung den Release-Nachweis verbessert, statt nur einen weiteren unverbundenen Rechner bereitzustellen.

FAQ