Fünf EU-Regelwerke, die heute Systemarchitektur bestimmen

Regulierung wird meist als Liste zu dokumentierender Pflichten gelesen. Die fünf Rechtsakte in diesem Artikel liest man besser als Liste von Eigenschaften, die ein System vorzeigen können muss: wo eine Grenze verläuft, was ein Build erzeugt, wer von wo auf ein Repository zugreifen kann, wohin Daten gelangen können müssen und wer antwortet, wenn etwas schiefgeht. Jeder von ihnen hat zwischen September 2025 und September 2026 seinen Status geändert, und jeder wurde am 17. September 2026 an seiner Primärquelle gelesen. Die Daten stammen aus den Rechtsakten selbst, nicht aus Sekundärberichten.

Dies ist eine Landkarte, keine Beratung. Ob einer dieser Texte auf ein bestimmtes System anwendbar ist, ist eine rechtliche Feststellung, die von Produkt, Sektor und Rolle der Organisation abhängt, und nichts im Folgenden ersetzt sie. Der Artikel übersetzt jeden Rechtsakt in die Architekturfrage, die er erzwingt, denn diese Frage muss im Entwurf beantwortet werden, bevor eine Anwältin gefragt wird.

Die Verordnung (EU) 2024/1689, die KI-Verordnung, gilt nicht für KI-Systeme, soweit sie ausschließlich für militärische Zwecke, Verteidigungszwecke oder Zwecke der nationalen Sicherheit in Verkehr gebracht, in Betrieb genommen oder verwendet werden, mit oder ohne Änderung (Artikel 2 Absatz 3). Das entscheidende Wort ist ausschließlich. Ein System, das für eine zivile und eine Verteidigungsnutzung gebaut wurde, ist nicht ausschließlich militärisch; seine zivile Nutzung fällt also vollständig unter die Verordnung, was auch immer seine Verteidigungsnutzung ist.

Der Zeitplan hat sich in diesem Sommer verschoben. Die Verordnung (EU) 2026/1744, der Digital Omnibus, ist am 27. Juli 2026 in Kraft getreten und hat das Hochrisiko-Regime neu terminiert: Die eigenständigen Kategorien des Anhangs III, etwa Beschäftigungsentscheidungen und der Zugang zu wesentlichen Diensten, gelten ab dem 2. Dezember 2027, die in regulierte Produkte eingebetteten Systeme des Anhangs I ab dem 2. August 2028. Die Transparenzpflichten des Artikels 50 wurden nicht verschoben und gelten seit dem 2. August 2026, mit einem Übergang bis zum 2. Dezember 2026 nur für die Kennzeichnungspflicht generativer Systeme, die bereits auf dem Markt waren. Die Verbote des Artikels 5 gelten seit dem 2. Februar 2025.

Für die Architektur ist Artikel 2 Absatz 3 eine Grenze, die im System existieren muss, nicht nur in einem Vertrag. Wird ein mit zivilen Daten trainiertes Modell in einem Verteidigungskontext wiederverwendet oder eine Verteidigungskomponente in einem zivilen Produkt, müssen die beiden Nutzungen auf Verlangen trennbar sein: getrennte Deployments, Pipelines, die Trainingsdaten oder Gewichte nicht versehentlich teilen, und Provenienz für jedes Artefakt, die sagt, auf welche Seite es gehört und woraus es gebaut wurde. Das ist die Logik eines digitalen Produktpasses, angewandt auf Modelle, Datensätze und Prompts. Ein Artefakt, das seine Herkunft nicht angeben kann, lässt sich auf keine Seite der Linie stellen.

Die Verordnung (EU) 2024/2847, der Cyber Resilience Act, gilt vollständig ab dem 11. Dezember 2027, ihre Meldepflicht kam jedoch zuerst. Seit dem 11. September 2026 verlangt Artikel 14 von einem Hersteller, der von einer aktiv ausgenutzten Schwachstelle in einem Produkt mit digitalen Elementen oder von einem schwerwiegenden Sicherheitsvorfall erfährt, die Meldung über die von der ENISA betriebene zentrale Meldeplattform: eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und einen Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme, bei einem Vorfall einen Monat. Betroffene Nutzer sind unverzüglich zu informieren, zusammen mit den Maßnahmen, die sie ergreifen können (Artikel 14 Absatz 8). Kapitel IV über die Stellen, die Produkte künftig prüfen, gilt seit dem 11. Juni 2026.

Eine 24-Stunden-Uhr lässt sich nicht mit einem Prozess einhalten, der damit beginnt, dass jemand eine Tabelle öffnet. Sie setzt voraus, dass der Hersteller bereits weiß, was in jeder ausgelieferten Version steckt, was eine Software-Stückliste erfordert, die der Build erzeugt und die nicht nachträglich geschrieben wird; dass er von der Ausnutzung aus dem Feld erfährt, was Telemetrie aus dem eingesetzten Produkt und einen Kanal für Schwachstellenmeldungen erfordert; und dass er binnen Tagen ein korrigierendes Release ausliefern kann, was eine Auslieferungspipeline erfordert, die routinemäßig genutzt wird und nicht nur im Notfall. In Deutschland beschreibt die Technische Richtlinie TR-03183 des Bundesamts für Sicherheit in der Informationstechnik den Mindestinhalt einer solchen Stückliste.

Die Verordnung (EU) 2021/821 kontrolliert die Ausfuhr von Gütern mit doppeltem Verwendungszweck, und ihre Definition der Ausfuhr endet nicht bei Waren, die eine Grenze überqueren. Sie umfasst die Übertragung von Software oder Technologie mittels elektronischer Medien sowie das Bereitstellen solcher Software oder Technologie in elektronischer Form für Personen außerhalb des Zollgebiets der Union (Artikel 2 Nummer 2). Wer außerhalb der Union Zugriff auf ein Repository, einen Objektspeicher oder einen Cluster mit kontrollierter Technologie erhält, empfängt nach dieser Definition eine Ausfuhr, und die braucht dieselbe Genehmigung wie eine Lieferung.

Die Kontrollliste, Anhang I, wurde durch die Delegierte Verordnung (EU) 2025/2003 der Kommission aktualisiert, in Kraft seit dem 15. November 2025. Die Aktualisierung nahm Quantencomputer und ihre kryogenen Komponenten auf, Anlagen und Materialien für die Fertigung fortgeschrittener Halbleiter, Hochleistungsrechner, additive Fertigungssysteme für Metalle und die von ihnen verwendeten Pulver sowie weitere fortgeschrittene Werkstoffe. Vieles auf dieser Liste beschreibt, wofür ein industrielles Softwareunternehmen baut oder worauf es läuft.

Architektonisch macht das Identitäts- und Zugriffsmanagement zum Instrument der Exportkontrolle. Eine Zugriffsentscheidung muss auswerten können, wo sich die Person befindet und wohin die Daten gelangen würden, bevor sie etwas gewährt; sind Güter US-amerikanischen Ursprungs beteiligt, fügen die Regeln dieses Landes die Staatsangehörigkeit als Attribut hinzu, was das europäische Recht nicht tut. Beide Attribute sind personenbezogene Daten, ihre Erhebung muss also gegen die Datenminimierung nach Artikel 5 Absatz 1 Buchstabe c DSGVO gerechtfertigt werden, und dieses Spannungsfeld muss entworfen werden, statt entdeckt zu werden. Und weil eine Einstufung zu einem Artefakt gehört und nicht zu einem Team, muss sie mit dem Artefakt durch den Build wandern: Ein Repository, ein Container-Image und ein Modell-Checkpoint tragen jeweils ihre eigene Einstufung, und eine Pipeline, die sie nicht lesen kann, kann sie nicht durchsetzen.

Die Verordnung (EU) 2023/2854, der Data Act, gilt seit dem 12. September 2025. Sie gibt Nutzern vernetzter Produkte und der damit verbundenen Dienste das Recht, auf die von diesen Produkten erzeugten Daten zuzugreifen und sie an einen Dritten ihrer Wahl weitergeben zu lassen (Artikel 4 und 5). Für Produkte, die nach dem 12. September 2026 in Verkehr gebracht werden, muss das Produkt selbst so entworfen sein, dass die Daten standardmäßig, einfach, sicher und in einem umfassenden, strukturierten und maschinenlesbaren Format zugänglich sind (Artikel 3 Absatz 1).

Dieselbe Verordnung erreicht Cloud-Anbieter. Anbieter von Datenverarbeitungsdiensten müssen einem Kunden den Wechsel zu einem anderen Anbieter oder in die eigene Infrastruktur ermöglichen, bei Diensten derselben Art mit funktionaler Gleichwertigkeit. Wechselentgelte sind seit dem 11. Januar 2024 reduziert und dürfen ab dem 12. Januar 2027 gar nicht mehr erhoben werden (Artikel 29).

Für eine Fertigungs- oder Edge-Architektur folgt daraus, dass eine Datenexportschnittstelle ein Produktmerkmal mit rechtlicher Definition ist und dass ein Deployment, das seinen Cloud-Anbieter verlassen kann, eine Anforderung ist und keine Vorliebe. Das Datenmodell einer Maschine und die Formate, in denen Daten die Maschine verlassen, gehören jetzt zu dem, was ein Entwurf vorzeigen muss.

Die Richtlinie (EU) 2022/2555, NIS2, verpflichtete die Mitgliedstaaten, ihre Umsetzungsvorschriften ab dem 18. Oktober 2024 anzuwenden. Deutschland war spät: Das Umsetzungsgesetz, das NIS2UmsuCG, ist am 6. Dezember 2025 in Kraft getreten und hat das BSI-Gesetz neu gefasst. Die Schätzung der Bundesregierung zum Gesetzentwurf bezifferte die Zahl der neu erfassten Einrichtungen auf rund 29.500 in achtzehn Sektoren, mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) als Aufsichtsbehörde.

Zwei Vorschriften tragen das architektonische Gewicht. Die Meldepflicht für Vorfälle hat dieselbe Form wie im Cyber Resilience Act: eine Frühwarnung binnen 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls, eine Meldung binnen 72 Stunden und ein Abschlussbericht binnen eines Monats (Artikel 23 der Richtlinie). Und § 38 des neuen BSI-Gesetzes macht die Mitglieder der Geschäftsleitung einer Einrichtung persönlich dafür verantwortlich, die Risikomanagementmaßnahmen zu billigen, ihre Umsetzung zu überwachen und an Schulungen teilzunehmen, und lässt einen Verzicht auf diese Verantwortung nicht zu.

Sobald eine Geschäftsleitung persönlich verantwortlich ist, hört Sicherheit auf, eine Hilfsfunktion zu sein, und wird zu einer Eigenschaft, die die Architektur nachweisen muss: ein Inventar dessen, was läuft, ein Vorfallspfad, der eine 24-Stunden-Frist einhalten kann, Widerstandsfähigkeit während eines Angriffs und nicht erst danach, und Nachweise, dass die gebilligten Maßnahmen tatsächlich vorhanden sind. Eine Maßnahme, die in einem Richtliniendokument existiert und nirgends im System, ist genau das, wonach eine Aufsicht fragen wird.

Nebeneinandergestellt verlangen die fünf Rechtsakte fünf architektonische Eigenschaften. Die KI-Verordnung fragt, wo die Grenze zwischen ziviler und Verteidigungsnutzung verläuft, und nach dem Nachweis, auf welcher Seite ein Artefakt steht. Der Cyber Resilience Act fragt, was ein Build erzeugt und wie schnell eine Korrektur ausgeliefert werden kann. Die Exportkontrolle fragt, wer von wo auf ein Repository zugreifen darf. Der Data Act fragt, wohin Daten gelangen können müssen und in welcher Form. NIS2 fragt, wer das Risiko gebilligt hat und wie sich zeigen lässt, dass das Gebilligte auch das ist, was läuft.

Was die fünf teilen, ist die Forderung nach Provenienz und Nachweisen auf der Ebene des einzelnen Artefakts: ein Modell, ein Build, ein Container-Image, ein Datensatz, der Datenstrom einer Maschine, jedes mit seiner Herkunft, seiner Einstufung und den Prüfungen, die es bestanden hat. Das ist die Eigenschaft, die ein digitaler Produktpass einem physischen Produkt gibt, und es ist die Eigenschaft, die diese Texte jetzt von Software verlangen. Ein System, das sie trägt, kann alle fünf Fragen aus seinen eigenen Aufzeichnungen beantworten. Ein System, das sie nicht trägt, muss die Antwort jedes Mal rekonstruieren, unter Fristdruck.

Er sagt nicht, dass einer dieser Rechtsakte auf ein bestimmtes System, Produkt oder eine bestimmte Organisation anwendbar ist. Der Anwendungsbereich hängt von Tatsachen ab, die dieser Artikel nicht kennt, und von Begriffen wie Produkt mit digitalen Elementen, besonders wichtige Einrichtung oder Dateninhaber, die jeder Text für sich definiert.

Er sagt nicht, dass die hier beschriebene Architektur ausreicht. Getrennte Deployments, eine Stückliste, attributbasierter Zugriff, eine Exportschnittstelle und ein Vorfallspfad sind das, was die Texte voraussetzen; jeder Rechtsakt verlangt mehr, und manches davon, etwa die Prüfung von Produkten nach dem Cyber Resilience Act oder die Registrierung beim BSI, ist prozedural und nicht technisch.

Und er sagt nicht, dass die Daten endgültig sind. Drei der fünf Rechtsakte haben sich bereits einmal verschoben. Jedes Datum oben nennt den Rechtsakt, aus dem es stammt, damit es sich an dem Tag, an dem es zählt, am Text überprüfen lässt.