Vereinfachung ist kein Kontrollabbau

Die politische Einigung vom 7. Mai 2026 über Änderungen am europäischen KI-Regelwerk wird vielerorts als Entlastung gelesen. Das ist verständlich, aber zu kurz. Der Digital Omnibus soll Fristen besser mit verfügbaren Standards und Hilfsmitteln verbinden, Vereinfachungen für kleinere Unternehmen ausweiten und Zuständigkeiten neu ordnen. ^[1] Parallel prüft die Kommission im „Digital Fitness Check“, wie Datenschutz-, Daten-, Cyber- und KI-Regeln zusammenspielen. ^[2]

Für Unternehmen lautet die entscheidende Frage nicht: Welche Pflicht verschwindet? Sie lautet: Welche Betriebsfähigkeit bleibt unabhängig von der endgültigen Formulierung notwendig? Wer nur Paragraphen zuordnet, baut bei jeder Änderung ein neues Projekt. Wer Kontrollobjekte, Ereignisse und Evidenz sauber organisiert, kann veränderte Regeln schneller aufnehmen.

Das eigentliche Problem ist institutionelle Fragmentierung

In vielen Konzernen existieren mindestens vier parallele Welten. Datenschutz führt Verzeichnisse und Folgenabschätzungen. Informationssicherheit pflegt Assets, Risiken und Vorfälle. Datenorganisationen dokumentieren Zugriffsrechte und Datenprodukte. KI-Governance baut zusätzlich Use-Case-Register, Modellkarten und Freigaben auf.

Jede Welt besitzt berechtigte fachliche Unterschiede. Problematisch wird es, wenn dieselbe Anwendung viermal beschrieben, derselbe Lieferant viermal bewertet und derselbe Vorfall viermal eskaliert wird. Dann entsteht keine zusätzliche Sicherheit, sondern widersprüchliche Wahrheit.

Die Kommission schlägt unter anderem einen gemeinsamen Eingang für Cybervorfälle und Datenschutzverletzungen vor und will Regelungsüberschneidungen reduzieren. ^[3] Das politische Signal ist richtig: Der Meldeweg darf nicht länger die Organisationsstruktur spiegeln. Ein Ereignis entsteht einmal, kann aber mehrere rechtliche Folgen haben.

Vier Ebenen eines gemeinsamen Kontrollkerns

Ein integriertes Modell muss Unterschiede erhalten, ohne Grundlagen zu vervielfachen.

1. Gemeinsame Objekte

Anwendungen, Modelle, Datenprodukte, Lieferanten, Geschäftsprozesse und kritische Dienste erhalten eindeutige Identitäten. Ein KI-System ist dann nicht nur ein Eintrag im KI-Register, sondern mit dem Dienst, den verwendeten Daten, dem Vertrag und dem verantwortlichen Produktteam verbunden.

2. Gemeinsame Ereignisse

Ein Fehler, eine Schwachstelle oder eine unzulässige Datenverwendung wird zunächst als Geschäftsereignis erfasst. Erst danach bestimmen Fachprofile, ob AI Act, NIS2, CRA, DORA, DSGVO oder mehrere Regelwerke relevant sind.

3. Gemeinsame Evidenz

Testprotokolle, Freigaben, Logs, Lieferantennachweise und Risikobeschlüsse werden nicht für ein einzelnes Audit erzeugt. Sie werden als versionierte Evidenzobjekte geführt und von mehreren Kontrollen referenziert.

4. Spezifische Rechtsprofile

Fristen, Behörden, Schwellenwerte und besondere Dokumentationspflichten bleiben fachlich getrennt. Integration bedeutet nicht, jede Norm gleich zu behandeln. Sie bedeutet, dieselbe Realität nicht mehrfach und widersprüchlich abzubilden.

Was dafür spricht – und was dagegen

Für die Zusammenführung spricht zunächst Geschwindigkeit. Ein Vorfallteam muss nicht herausfinden, welche Abteilung das „richtige“ Register besitzt. Es arbeitet auf einem gemeinsamen Lagebild. Auch die Nachweiskosten sinken: Ein belastbarer Lieferantencheck kann für Sicherheit, Datenschutz und KI-Governance wiederverwendet werden.

Dagegen spricht die Gefahr einer zu groben Zentralisierung. Ein universeller Kontrollkatalog kann Fachlogik verdecken. Datenschutzrisiken lassen sich nicht vollständig auf Cyberrisiken reduzieren; Modellverhalten ist mehr als Softwarequalität. Außerdem kann ein zentrales Tool eine falsche Sicherheit erzeugen, wenn Prozesse nur formal verbunden sind.

Die Lösung ist föderiert: gemeinsame Datenstruktur, gemeinsame Ereignisführung und gemeinsame Evidenz – aber fachlich verantwortete Bewertungsprofile. So bleibt Expertise dezentral, während die Organisation ein konsistentes Bild behält.

Die Entscheidung: warten oder vorbauen?

Die schlechteste Option ist passives Warten. Standards und Detailregeln können sich ändern; fehlende Eigentümerschaft, unverbundene Inventare und unklare Eskalationen werden dadurch nicht verschwinden. Gleichzeitig wäre es unvernünftig, jeden Entwurf sofort in starre Software zu gießen. Gebaut werden sollte die dauerhafte Fähigkeit, nicht das vorläufige Formular.

Ein 90-Tage-Programm ohne neues Großprojekt

In den ersten 30 Tagen werden die wichtigsten Kontrollobjekte verglichen: Wo existieren unterschiedliche Namen, Owner oder Kritikalitäten? Danach wählt das Unternehmen zehn digitale Dienste aus, bei denen mehrere Regulierungswelten sichtbar überlappen.

In den Tagen 31 bis 60 entsteht ein gemeinsames Ereignismodell. Es beantwortet vier Fragen: Was ist passiert? Welcher Dienst ist betroffen? Welche Wirkung besteht? Wer darf welche Entscheidung treffen? Fachabteilungen ergänzen anschließend ihre rechtlichen Klassifikationen.

In den Tagen 61 bis 90 wird nicht weiter modelliert, sondern geübt. Ein Szenario sollte bewusst mehrere Perspektiven verbinden: Ein externes KI-Modell erzeugt falsche Ausgaben, sensible Daten werden verarbeitet, ein Kunde ist betroffen und der Lieferant meldet verspätet. Die Übung zeigt, ob ein gemeinsamer Kern wirklich funktioniert.

Woran der Vorstand Fortschritt erkennt

Ein Vorstand braucht keine Liste erledigter Policies. Er braucht wenige operative Indikatoren:

• Zeit vom ersten Signal bis zur benannten Geschäftsverantwortung,
• Anteil kritischer Dienste mit vollständiger Abhängigkeitskette,
• Anteil zentraler Kontrollen mit wiederverwendbarer Evidenz,
• Zahl widersprüchlicher Kritikalitäts- oder Owner-Zuordnungen,
• Zeit bis zu einer entscheidungsfähigen Vorfallbewertung.

Diese Kennzahlen messen nicht Rechtskonformität im Ganzen. Sie zeigen aber, ob die Organisation überhaupt in der Lage ist, Pflichten konsistent zu erfüllen.

Vereinfachung ist gelungen, wenn weniger institutionelle Reibung entsteht – nicht wenn weniger jemand verantwortlich ist.

Der Digital Omnibus sollte deshalb nicht als Pause verstanden werden. Er ist ein Architekturfenster: Unternehmen können ihre über Jahre gewachsenen Kontrollinseln verbinden, bevor die nächste Technologiewelle erneut neue Register erzeugt.

Vom Kontrollkatalog zum Kontrollprodukt

Die meisten Compliance-Organisationen denken in Anforderungen. Ein Kontrollprodukt denkt zusätzlich in Nutzern, Servicequalität und Lebenszyklus. Seine Nutzer sind Produktteams, Prüfer, Vorstände, Incident Manager und Aufsichtsbehörden. Sie benötigen nicht dieselbe Oberfläche, greifen aber auf dieselben verlässlichen Fakten zurück.

Ein gutes Kontrollprodukt besitzt einen benannten Product Owner. Dieser verantwortet nicht die rechtliche Auslegung aller Normen, sondern die Qualität des gemeinsamen Dienstes. Dazu gehören ein aktuelles Objektmodell, erreichbare Schnittstellen, nachvollziehbare Versionen und eine klare Servicezusage. Fachverantwortliche bleiben Eigentümer ihrer Bewertungslogik.

Das klingt zunächst nach zusätzlicher Organisation. Tatsächlich ersetzt es informelle Koordination. Heute wird dieselbe Information häufig per Tabellenblatt, E-Mail und Präsentation neu zusammengetragen. Ein Kontrollprodukt macht die wiederkehrende Arbeit sichtbar und finanzierbar.

Die Evidenzkette als wirtschaftlicher Vermögenswert

Evidenz wird in vielen Unternehmen erst kurz vor einem Audit gesammelt. Dann beginnt eine teure Suche nach Screenshots, Freigaben und Testprotokollen. Diese Arbeitsweise behandelt Nachweis als Abfallprodukt. Besser ist eine kontinuierliche Evidenzkette.

Jede wesentliche Kontrolle definiert:

• welches Ereignis einen Nachweis erzeugt,
• welches System die Primärquelle ist,
• wer die Aussage verantwortet,
• wie lange sie gültig bleibt,
• welche Änderung eine erneute Prüfung auslöst,
• und welche anderen Kontrollen denselben Nachweis nutzen dürfen.

So kann beispielsweise eine dokumentierte Lieferantenänderung gleichzeitig Sicherheits-, Datenschutz- und KI-Risiken aktualisieren. Die fachliche Bewertung bleibt unterschiedlich, aber die Information über den geänderten Unterauftragnehmer wird nicht dreimal recherchiert.

Der wirtschaftliche Nutzen zeigt sich in kürzeren Prüfungen, weniger Rückfragen und schnelleren Produktentscheidungen. Noch wichtiger ist die Qualität: Wenn Evidenz im Arbeitsprozess entsteht, ist sie näher am tatsächlichen Ereignis und weniger von nachträglicher Erinnerung abhängig.

Drei typische Fehlarchitekturen

Die erste Fehlarchitektur ist das zentrale Megaregister. Es soll alles abbilden, wird dadurch komplex und verliert Akzeptanz. Teams pflegen Daten nur vor Audits. Die Lösung ist kein noch größeres Formular, sondern eine föderierte Datenarchitektur mit wenigen verpflichtenden Kernfeldern.

Die zweite Fehlarchitektur ist das Ticket als Wahrheit. Ein Ticket dokumentiert Kommunikation, aber nicht automatisch den Zustand eines Systems. Kritische Fakten sollten aus Quellsystemen kommen; das Ticket referenziert sie und hält Entscheidungen fest.

Die dritte Fehlarchitektur ist die vollständig juristische Prozessführung. Juristische Expertise ist unverzichtbar, aber ein Vorfall muss zunächst technisch und geschäftlich beherrscht werden. Wenn jede Aktion auf eine vollständige Rechtsklassifikation wartet, verliert die Organisation wertvolle Zeit.

Szenario: Ein Assistent verändert seine Datenverarbeitung

Ein Anbieter aktualisiert ein generatives Modell. Danach werden Eingaben länger gespeichert und für eine neue Qualitätsfunktion verarbeitet. Gleichzeitig ändern sich Ausgabeverhalten und Unterauftragnehmer. In einer fragmentierten Organisation entstehen vier getrennte Prüfungen.

Das gemeinsame Modell erkennt dagegen ein Änderungsereignis. Es verknüpft betroffene Dienste, Datenkategorien, Nutzergruppen und Verträge. Datenschutz bewertet Zweck und Rechtsgrundlage. Sicherheit prüft Speicherung und Zugriff. KI-Governance bewertet Modelländerung, Transparenz und Leistung. Einkauf klärt Vertragsrechte. Das Produktteam erhält eine gemeinsame Entscheidung mit fachlich getrennten Bedingungen.

Der Unterschied liegt nicht in weniger Prüfung. Er liegt in einer gemeinsamen Faktenbasis und einer abgestimmten Entscheidung.

Wer darf Ausnahmen genehmigen?

Vereinfachung scheitert häufig an Ausnahmen. Standardpfade sind klar, aber dringende Produktziele erzeugen Sonderentscheidungen. Ohne Regeln werden Ausnahmen informell, dauerhaft und unsichtbar.

Ein professioneller Ausnahmeprozess verlangt:

1. eine konkret benannte Abweichung,
2. Geschäftsnutzen und betroffene Risiken,
3. kompensierende Maßnahmen,
4. eine zeitliche Befristung,
5. einen verantwortlichen Entscheider,
6. und einen automatischen Neubewertungstermin.

Die Zahl offener Ausnahmen ist weniger aussagekräftig als ihr Alter und ihre Konzentration. Zehn kurzfristige, kontrollierte Ausnahmen können gesünder sein als zwei seit Jahren tolerierte strukturelle Lücken.

Das Gegenargument der Fachbereiche

Fachbereiche befürchten zu Recht, dass ein gemeinsamer Kern ihre Besonderheiten ignoriert. Ein Medizinprodukt, eine HR-Anwendung und eine Marketingautomation besitzen verschiedene Risikobilder. Zentralisierung kann lokale Verantwortung schwächen.

Das Gegenargument ändert jedoch nicht die Notwendigkeit gemeinsamer Objekte. Gerade weil Bewertungen unterschiedlich sind, müssen alle Beteiligten wissen, dass sie über dasselbe System, dieselbe Version und denselben Dienst sprechen. Föderation ist deshalb kein Kompromiss aus Unentschlossenheit. Sie ist das bewusste Design: zentrale Identität, dezentrale Bewertung, gemeinsame Entscheidung.

Das Gegenargument der Effizienz

Manche Organisationen argumentieren, der Aufbau einer Evidenzplattform sei teurer als die heutigen Tabellen. Diese Rechnung unterschätzt Wiederholung. Ein einzelnes Tabellenblatt ist günstig. Hunderte lokale Register, manuelle Abgleiche und wiederkehrende Auditkampagnen sind es nicht.

Die Investition sollte dennoch schrittweise erfolgen. Zuerst werden nur kritische Dienste und drei Evidenztypen integriert. Erst wenn Zeit, Qualität oder Risikotransparenz messbar besser werden, folgt die nächste Domäne. So bleibt das Programm ein Produkt mit überprüfbarer Wirkung und wird nicht zum neuen zentralen Großprojekt.

Entscheidungsempfehlung

Der Vorstand sollte einen gemeinsamen Kontrollkern beauftragen, aber seine Grenzen explizit machen. Das Mandat umfasst Identitäten, Abhängigkeiten, Ereignisse, Evidenz und Entscheidungsprotokolle. Es umfasst nicht die Auflösung fachlicher Verantwortung in einer Universalabteilung.

Nach sechs Monaten sollte die Organisation drei Ergebnisse zeigen: ein schnelleres gemeinsames Lagebild, weniger widersprüchliche Stammdaten und nachweislich wiederverwendete Evidenz. Werden diese Ergebnisse nicht erreicht, muss das Design verändert werden. Neue Software allein ist kein Erfolg.

Die zentrale These bleibt: Ein agileres europäisches Regelwerk kann Unternehmen entlasten. Die nachhaltige Entlastung entsteht aber erst, wenn die Organisation ihre eigene regulatorische Komplexität reduziert.

Das Betriebssystem muss vor dem Gesetz stehen

Die wichtigste praktische Konsequenz lautet daher: Unternehmen sollten ihre Compliance-Architektur nicht entlang einzelner Verordnungen organisieren. Sie sollten ein gemeinsames Betriebssystem für digitale Verantwortung schaffen. Dieses Betriebssystem beginnt bei einer einheitlichen Taxonomie für Systeme, Daten, Modelle, Anbieter und Risiken. Es verbindet diese Taxonomie mit klaren Verantwortlichkeiten, dokumentierten Freigaben und überprüfbaren Nachweisen. Erst danach werden einzelne Rechtsakte als zusätzliche Anforderungen auf dieses Grundmodell gelegt.

Das verändert auch die Arbeit des Vorstands. Statt regelmäßig isolierte Projektstände zu Datenschutz, KI, Cyberresilienz und Plattformregulierung entgegenzunehmen, erhält er ein integriertes Lagebild: Welche digitalen Fähigkeiten sind geschäftskritisch? Wo fehlen Nachweise? Welche Abhängigkeiten können nicht kurzfristig ersetzt werden? Und welche Entscheidungen verlangen bewusst akzeptierte Restrisiken? Ein solches Lagebild macht Regulierung steuerbar, weil es technische Fakten mit wirtschaftlichen Konsequenzen verbindet.

Wer dagegen auf die nächste endgültige Fassung wartet, verliert wertvolle Zeit. Der Gesetzgeber kann Fristen verschieben, Begriffe präzisieren oder Berichtspflichten zusammenführen. Er nimmt dem Unternehmen jedoch nicht die Aufgabe ab, seine eigene digitale Wertschöpfung zu verstehen. Die beste Vorbereitung auf Vereinfachung ist deshalb keine Pause, sondern eine Architektur, die Änderungen aufnehmen kann, ohne jedes Mal neue Parallelprozesse zu erzeugen.

Redaktionsurteil

Regulatorische Vereinfachung ist weder ein Freibrief noch ein reines Juristenprojekt. Sie ist ein Test, ob Unternehmen aus Erfahrungen mit überlappenden Digitalregeln lernen. Die richtige Reaktion ist ein Kontrollsystem, das Veränderungen aufnehmen kann, ohne jedes Mal neue organisatorische Inseln zu erzeugen.

Transformation Briefing empfiehlt, bis zum Jahresende drei überprüfbare Ziele zu setzen: einen gemeinsamen Identifikator für kritische digitale Dienste, einen integrierten Eingang für relevante Ereignisse und eine Evidenzbibliothek für die zehn wichtigsten Kontrollen. Diese Ziele sind klein genug, um real umgesetzt zu werden, und groß genug, um strukturelle Wirkung zu erzeugen.

Der Vorstand sollte außerdem verlangen, dass jede neue regulatorische Anforderung zunächst gegen den bestehenden Kontrollkern geprüft wird. Erst wenn kein tragfähiger Anschluss möglich ist, darf ein neues Register oder Sonderverfahren entstehen. Diese Umkehr der Beweislast schützt die Organisation vor der nächsten Welle paralleler Lösungen.

Am Ende entscheidet nicht die Zahl konsolidierter Richtlinien. Entscheidend ist, ob ein Team unter Zeitdruck schneller zu einer richtigen, dokumentierten und verantworteten Entscheidung gelangt. Genau daran sollte die Vereinfachung intern gemessen werden.