Am 27. Juli 2026 trat der sogenannte AI-Omnibus in Kraft, eine EU-Verordnung, die die Hochrisiko-Fristen des EU AI Act um bis zu 16 Monate verschob. Für ein statisches Compliance-Modell ist das ein Problem: Jede Anforderung, die an ein festes Datum gekoppelt ist, muss von Hand nachgepflegt werden, bei Hunderten Anforderungen über mehrere Frameworks hinweg ein Verfahren, das nicht skaliert.
BAM Core, das offene Datenmodell hinter Executable Compliance, beantwortete bisher zwei Fragen: Was gilt? und Sind wir compliant? Mit BAM Core 2.0 kommt eine dritte hinzu: Was hat sich geändert, und wen betrifft das wirklich?
Neu in 2.0
Ein eigener Regulatory-Change-Layer, getrennt von den aktiven BAM-Objekten. Laufende Gesetzesänderungen werden als eigenständige, nachvollziehbare Einträge geführt, mit einer klaren Regel: Solange ein Verfahren nicht final entschieden ist, entstehen keine spekulativen Anforderungsobjekte.
Wie das konkret funktioniert
Jeder Änderungseintrag durchläuft einen Lebenszyklus, von proposal über negotiation bis effective (oder withdrawn, repealed, superseded). Erst im Status effective wird ein Eintrag mit vollständigen BAM-Objekten verknüpft. Für jedes betroffene Objekt hält ein Delta-Eintrag zusätzlich fest, welche Art von Änderung vorliegt, nur eine Frist, oder auch eine inhaltliche Anpassung an Control oder Nachweis:
| Feld | Bedeutung |
|---|---|
| change_type | Art der Änderung (z. B. deadline, scope, definition) |
| requirement_impact | Wirkt sich das inhaltlich auf die Anforderung aus? |
| control_impact | Muss das bestehende Control angepasst werden? |
| evidence_impact | Reicht der bisherige Nachweis noch aus? |
Vier API-Endpunkte machen das direkt abrufbar, darunter eine Impact-Analyse, die nicht nur die direkt verknüpften Objekte liefert, sondern zusätzlich indirekt betroffene Objekte über die bestehenden Cross-Referenzen im Datenmodell findet. Neue Objekte mit passendem Cross-Ref tauchen dabei automatisch auf, ohne dass jemand eine Liste von Hand pflegen muss.
Stresstest · 20 Minuten
Wo steht Ihr Unternehmen bei NIS-2, DORA, CRA & Co.?
Kostenloser Compliance-Stresstest, unabhängig vom eigenen BAM-Core-Einsatz.
Stresstest starten →Der AI-Omnibus als erstes reales Beispiel
Der eingangs erwähnte AI-Omnibus (VO (EU) 2026/1744) ist in BAM Core 2.0 bereits vollständig abgebildet, als erster, tatsächlich entschiedener Eintrag im Regulatory-Change-Layer. Zwei bestehende BAM-Objekte (Risikoklassifizierung, Betreiberpflichten) sind als betroffen verknüpft, ein drittes, neues Objekt hält die Fristverschiebung selbst fest: Hochrisiko-Systeme nach Anhang III erhalten bis 2. Dezember 2027 Zeit, eingebettete Systeme nach Anhang I bis 2. August 2028.
Für alle drei Objekte gilt: Requirement-, Control- und Evidence-Impact sind jeweils "keine", nur der Zeitplan ändert sich. Bemerkenswert dabei: Die betroffenen Objekte mussten inhaltlich gar nicht angefasst werden, weil sie von Anfang an mit relativen Dringlichkeitsstufen statt festen Kalenderdaten gearbeitet hatten.
Was bewusst nicht passiert
Der breitere Digital Omnibus (DSGVO-Neudefinition, ePrivacy, Anpassungen an NIS-2/DORA/CER) befindet sich weiterhin im Trilog-Verfahren. BAM Core 2.0 verfolgt das im Change-Layer, aber legt bewusst keine eigenen Anforderungsobjekte dafür an, solange das Verfahren offen ist.
Für wen das relevant ist
Wer BAM Core bereits einsetzt, kann direkt mit der neuen Version starten, die Struktur ist rückwärtskompatibel. Wer noch nicht damit arbeitet: Der Regulatory-Change-Layer zeigt exemplarisch, warum ein offenes, versioniertes Datenmodell mehr leistet als eine statische Checkliste, die bei jeder Gesetzesnovelle von Hand überarbeitet werden muss.