Viele Unternehmen haben den AI Omnibus vor allem als Terminmeldung gelesen. Das ist verständlich – und operativ gefährlich. Denn eine geänderte Frist beantwortet nicht die Frage, welche KI-Systeme im Unternehmen tatsächlich eingesetzt werden, wer für sie entscheidet und welche Nachweise schon heute belastbar sind.
Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.
Der AI Omnibus ist am 27. Juli 2026 in Kraft getreten. Er enthält gezielte Vereinfachungen, neue beziehungsweise erweiterte Unterstützungsangebote und geänderte Anwendungszeitpunkte. Rechtsgenau gelten Kapitel III Abschnitte 1 bis 3 des AI Act – mit Ausnahme von Artikel 6 Absatz 5 – für nach Artikel 6 Absatz 2 in Verbindung mit Anhang III als hochriskant eingestufte Systeme ab dem 2. Dezember 2027. Für nach Artikel 6 Absatz 1 in Verbindung mit Anhang I als hochriskant eingestufte Systeme gelten diese Abschnitte ab dem 2. August 2028. Andere Teile des AI-Act-Regimes folgen eigenen Zeitlinien. Eine pauschale Aussage wie „der AI Act wurde verschoben“ ist deshalb falsch.
Der 2. August 2026 bleibt zugleich ein allgemeiner Umsetzungs-, Aufsichts- und Durchsetzungsmeilenstein: Ab diesem Datum tragen das AI Office und die Behörden der Mitgliedstaaten Verantwortung für Umsetzung, Aufsicht und Durchsetzung; die Transparenzregeln gelten ab August 2026. Der durch den Omnibus ergänzte neunte Verbotsfall für KI-Systeme, die nicht-einvernehmliche sexuell explizite oder intime Inhalte beziehungsweise Darstellungen sexuellen Missbrauchs von Kindern erzeugen, greift dagegen ab Dezember 2026. Unternehmen müssen deshalb nicht einen einzigen Endtermin verwalten, sondern eine fallbezogene Zeitachse aus bereits geltenden, 2026 hinzukommenden und später anwendbaren Pflichten.
In Deutschland ist zusätzlich das KI-Marktüberwachungs- und -Innovationsförderungsgesetz (KI-MIG) seit dem 29. Juli 2026 in Kraft. Die Bundesnetzagentur ist grundsätzlich Marktüberwachungsbehörde, soweit das Gesetz keine Fach- oder Landesbehörde bestimmt; sie ist deshalb nicht die alleinige KI-Aufsicht. Bei ihr werden zugleich ein Koordinierungs- und Kompetenzzentrum sowie die zentrale Anlaufstelle und zentrale Beschwerdestelle eingerichtet. Für ein Governance-Inventar folgt daraus: Neben dem EU-Rechtsstand müssen zuständige Behörde, Aufsichtskanal und gegebenenfalls Fachregime je Anwendungsfall identifizierbar sein.
Für das Management zählt deshalb nicht der vermeintliche Gewinn an Monaten, sondern die aktuelle Entscheidungsfähigkeit: Das Unternehmen muss erklären können, welche Systeme es steuert, warum es sie wie einstuft und wer eine Abweichung akzeptieren darf.
Der eigentliche Schmerz: KI ist schneller gewachsen als ihre Verantwortungsstruktur
In vielen Organisationen existieren gleichzeitig zentrale KI-Projekte, eingekaufte SaaS-Funktionen, eingebettete Copilots, lokale Experimente und Funktionen, die nach einem Produktupdate plötzlich „mit KI“ arbeiten. Einkauf, Datenschutz, Informationssicherheit, Legal, Fachbereich und IT führen jeweils Ausschnitte. Niemand besitzt das belastbare Gesamtbild.
Das Problem zeigt sich spätestens bei einer Freigabe. Dann müssen die zulässige Nutzung von Beschäftigtendaten, die Rolle des Unternehmens in der Wertschöpfungskette, die bewertete Modellversion und die praktisch vorgesehene menschliche Aufsicht geklärt sein. Ein Tabellenblatt mit dem Produktnamen hilft nur begrenzt, wenn diese Beziehungen fehlen.
Ein KI-Inventar ohne Verantwortliche ist wie ein Organigramm ohne Namen – formal sehr ordentlich und im Störungsfall erstaunlich still. Der Mechanismus dahinter ist trocken, aber wichtig: Ohne eindeutig zugewiesene Entscheidungsrechte werden Risiken weitergereicht, bis Zeitdruck die Entscheidung ersetzt.
Eine hypothetische Betriebsszene macht die Lücke greifbar. Ein internationaler Mittelständler schaltet im Recruiting eine neue Zusammenfassungsfunktion frei. Der Einkauf kennt den SaaS-Vertrag, HR kennt den Zweck, Datenschutz kennt die Datenkategorien und IT die Anmeldung. Trotzdem kann am Freigabetermin niemand verbindlich sagen, ob die Funktion nur Texte verdichtet oder bereits die Vorauswahl beeinflusst. Die Produktbezeichnung hilft nicht weiter; entscheidend ist der tatsächliche Einsatz im Prozess.
Das Team muss deshalb nicht zuerst über eine abstrakte Risikofarbe streiten. Es muss den Ablauf rekonstruieren: die Eingabe des Systems, das erzeugte Ergebnis, dessen Empfänger und die nachfolgende Entscheidung. Danach lassen sich Rolle, Betroffenheit, Aufsicht und Kontrollen sinnvoll bewerten. Bleibt die Zweckbeschreibung offen, ist auch die Einstufung nur scheinbar präzise. In diesem hypothetischen Fall könnte das Management die Nutzung auf reine Zusammenfassungen begrenzen, eine dokumentierte menschliche Prüfung verlangen und jede Erweiterung des Zwecks als Neubewertungssignal behandeln. Aus einer unklaren Toolfrage wird damit eine konkrete Betriebsentscheidung.
Damit ist der Fall noch nicht abgeschlossen. HR muss die Begrenzung in Arbeitsanweisung und Prozessdesign übersetzen, IT die freigeschalteten Funktionen und Berechtigungen auf den beschlossenen Umfang ausrichten, Einkauf Änderungen des Anbieters sichtbar machen und Datenschutz sowie Informationssicherheit ihre jeweiligen Prüfungen auf dieselbe Zweckbeschreibung beziehen. Wenn jede Funktion eine eigene Kurzfassung des Anwendungsfalls führt, entstehen trotz guter Einzelarbeit vier Wahrheiten. Das Inventar dient deshalb als gemeinsames Entscheidungsobjekt: Es hält nicht alle Fachdokumente doppelt vor, sondern verbindet deren gültige Versionen, Verantwortliche und offene Punkte.
Eine typische Fehlsteuerung wäre, das Recruiting-Tool nach einer einmaligen Freigabe als statisches Objekt zu behandeln. Drei Monate später aktiviert der Anbieter eine neue Ranking-Option, HR testet sie mit realen Vorgängen, und IT bewertet das Update als normale Produktpflege. Ohne Änderungssignal erreicht die Information die freigabeberechtigte Rolle nicht. Das Risiko entsteht dann nicht primär durch fehlendes Fachwissen, sondern durch eine unterbrochene Übergabe. Ein belastbares Inventar ordnet deshalb auch dem Produktupdate einen Meldeweg zu. Bis zur Neubewertung bleibt die neue Funktion gesperrt oder auf eine kontrollierte Testumgebung begrenzt.
Für das Management werden damit drei unterschiedliche Entscheidungen sichtbar. Es kann die bestehende, eng begrenzte Nutzung fortführen, einen befristeten Pilot für die Erweiterung genehmigen oder die Änderung bis zum Vorliegen bestimmter Nachweise stoppen. Jede Option hat einen Owner, einen Review-Termin und ein Abbruchkriterium. Diese Form der Entscheidung ist unspektakulär, aber belastbar. Sie verhindert, dass ein technischer Standardwert stillschweigend zur Geschäftsentscheidung wird.
Was ein Governance-Inventar anders macht als eine Toolliste
Ein Governance-Inventar dokumentiert nicht nur Technik. Es verbindet jeden relevanten Anwendungsfall mit einer steuerbaren Entscheidungskette. Dafür braucht es mindestens sechs Perspektiven.
1. Anwendungsfall und Wirkung
Erfasst wird, welche Entscheidung oder Tätigkeit das System unterstützt, welche Personengruppen betroffen sind und welche Folgen ein Fehler haben kann. „Chatbot“ ist keine ausreichende Beschreibung. „Unterstützt den Kundendienst bei Antwortvorschlägen; keine automatische Ablehnung oder Vertragsentscheidung“ ist steuerbar.
2. Rolle und Lieferkette
Die Organisation muss festhalten, in welcher Rolle sie handelt und welche externen Parteien beteiligt sind. Vertrag, Produktbeschreibung und tatsächliche Nutzung müssen zusammenpassen. Eine Anbieterbeschreibung ersetzt keine eigene Rollenentscheidung.
3. Einstufung mit Begründung
Die Einstufung darf nicht nur als Farbe oder Dropdown gespeichert werden. Sie braucht Datum, Verantwortlichen, herangezogene Fakten, offene Annahmen und einen Auslöser für die Neubewertung. Die Begründung ist der Nachweis, nicht das grüne Feld.
4. Kontrollen und Evidenz
Zu jedem Risiko gehören konkrete Kontrollen: Freigabegrenzen, Protokollierung, Zugriffsrechte, Tests, menschliche Aufsicht, Eskalation, Lieferantennachweise oder Schulung. Ebenso wichtig sind Speicherort, Eigentümer, Aktualität und nächster Prüftermin der Evidenz.
Evidenz ist dabei nicht bloß ein Anhang zum Register. Sie verbindet Behauptung und Betrieb. Wenn „menschliche Aufsicht“ als Kontrolle eingetragen ist, muss erkennbar sein, wer tatsächlich prüft, welche Fälle eskaliert werden und anhand welcher Aufzeichnungen sich die Prüfung später nachvollziehen lässt. Eine Schulungsfolie belegt, dass es eine Folie gibt. Über das Verhalten im Prozess ist sie deutlich zurückhaltender.
5. Lebenszyklus und Änderungssignale
Modellwechsel, neue Datenquellen, veränderte Zwecke, Produktupdates oder neue Nutzergruppen können eine frühere Bewertung entwerten. Das Inventar braucht deshalb definierte Änderungssignale und einen Prozess, der Neubewertungen auslöst.
6. Managemententscheidung
Nicht jedes offene Risiko muss sofort technisch beseitigt werden. Es muss aber sichtbar, befristet und von einer autorisierten Rolle entschieden sein. Das macht Informationssicherheit und AI Governance managementfähig: nicht risikofrei, sondern entscheidbar und prüfbar.
Die Beziehungen im Inventar bestimmen seine Steuerungsqualität
Die sechs Perspektiven entfalten ihren Wert erst als verknüpftes Modell. Ein Anwendungsfall verweist auf die aktuelle Zweckbeschreibung, die betroffenen Dienste und Personengruppen. Die Einstufung verweist auf die Tatsachen und Annahmen, auf denen sie beruht. Kontrollen verweisen auf ausführende Rollen und Evidenz. Änderungssignale verweisen auf die Bewertungen, die sie erneut öffnen. Ausnahmen verweisen auf eine konkrete Managemententscheidung. Fehlt eine dieser Beziehungen, bleibt das Inventar zwar durchsuchbar, aber nicht verlässlich steuerbar.
Diese Verknüpfung verändert auch die Zusammenarbeit der Kontrollfunktionen. Legal bewertet nicht isoliert einen Produktnamen, sondern eine dokumentierte Rolle und Nutzung. Datenschutz sieht, welche Daten- und Zweckänderung eine erneute Prüfung auslöst. Informationssicherheit kann technische Kontrollen auf den tatsächlich freigegebenen Prozess beziehen. Einkauf macht vertragliche und produktseitige Änderungen zum Eingangssignal für Governance. Der Fachbereich bleibt Eigentümer des Geschäftszwecks und kann die Verantwortung nicht an eine zentrale Registerpflege delegieren.
Gerade an diesen Übergängen entsteht häufig falsche Sicherheit. Ein Anbieterfragebogen kann vollständig sein, während die lokale Konfiguration vom beschriebenen Standard abweicht. Ein Test kann erfolgreich sein, aber eine frühere Modellversion betreffen. Eine dokumentierte Aufsicht kann bestehen, obwohl die prüfende Person im Tagesgeschäft weder Zeit noch Eskalationsrecht hat. Das Inventar sollte solche Unterschiede nicht in einem Sammelstatus glätten. Es führt Behauptung, Geltungsbereich, Evidenzdatum und Restabweichung getrennt. Das ergibt gelegentlich weniger Grün in der Präsentation, aber deutlich mehr Führung.
Auch Kennzahlen brauchen diese Logik. Die Zahl erfasster Systeme misst Abdeckung, nicht Beherrschung. Der Anteil begründeter Einstufungen zeigt formale Reife, aber noch keine wirksame Kontrolle. Für Managemententscheidungen aussagekräftiger sind überfällige Neubewertungen, offene Hochwirkungsfälle ohne Entscheider, Kontrollen ohne aktuelle Evidenz und Ausnahmen nahe ihrem Ablaufdatum. Jede Kennzahl sollte eine vorher festgelegte Reaktion auslösen. Sonst ist das Dashboard lediglich ein sehr ordentlich beleuchtetes Archiv.
Der AI Omnibus ändert Prioritäten – nicht die Notwendigkeit der Steuerung
Die Änderungen betreffen unterschiedliche Themen: Zeitlinien für bestimmte Hochrisiko-Kategorien, Erleichterungen für kleinere und bestimmte mittelgroße Unternehmen, Sandboxes, einzelne administrative Pflichten, AI Literacy sowie Aufsicht und Verfahrensklarheit. Die bisherige AI-Literacy-Anforderung für Unternehmen wurde vereinfacht; Kommission und Mitgliedstaaten erhalten eine stärkere Förderrolle. Das ist kein belastbarer Grund, interne Kompetenzmaßnahmen pauschal zu löschen: Die Organisation muss weiterhin entscheiden können, welche Kenntnisse ihre Rollen für Freigabe, Nutzung, Aufsicht und Eskalation tatsächlich benötigen.
Auch die Aufsicht wird konkreter. Das AI Office erhält erweiterte Zuständigkeiten für bestimmte KI-Systeme, darunter Systeme auf Basis von GPAI-Modellen, die in sehr großen Online-Plattformen und Suchmaschinen eingebettet sind. Für GPAI-Modelle kann es technische Dokumentation anfordern, Modelle evaluieren, Korrekturmaßnahmen verlangen und bei Verstößen Geldbußen verhängen. Für das Governance-Inventar folgt daraus ein praktischer Anspruch: Modellbezug, Anbieterrolle, technische Dokumentation, Prüfkontakte und offene Korrekturmaßnahmen müssen auffindbar und versioniert sein. Welche Omnibus-Änderung für ein Unternehmen relevant ist, hängt weiterhin vom konkreten System, der Rolle und dem Nutzungskontext ab.
Deshalb sollte die Organisation keine globale „Omnibus-Ausnahme“ in ihre Roadmap schreiben. Sinnvoller ist ein Delta-Verfahren: Für jeden betroffenen Anwendungsfall wird dokumentiert, welche bisherige Annahme sich durch den finalen Rechtstext ändert, welche nicht, und welche interne Maßnahme deshalb verschoben, angepasst oder bewusst fortgeführt wird.
Eine verschobene Frist ist kein geschlossenes Risiko – sie ist ein Risiko mit mehr Kalender. Der Mechanismus: Wenn Teams Fristgewinn mit Aufgabenwegfall verwechseln, verschwinden Abhängigkeiten aus der Planung und kehren kurz vor dem nächsten Stichtag als Eskalation zurück.
Auch hier hilft eine hypothetische Betriebsszene. Ein Produktteam plant, eine bereits bewertete KI-Funktion um eine neue Datenquelle und eine automatische Priorisierung zu erweitern. Wegen der Omnibus-Änderungen möchte es die Governance-Prüfung um mehrere Quartale verschieben. Das Delta-Verfahren trennt jedoch Rechtszeitlinie und Betriebsänderung: Die neue Datenquelle verändert die Tatsachengrundlage, die Priorisierung verändert den möglichen Effekt, und beides entwertet Teile der früheren Bewertung unabhängig vom nächsten gesetzlichen Stichtag.
Die Entscheidungsfolge ist nüchtern. Zuerst wird dokumentiert, welche Annahmen unverändert bleiben. Danach werden die betroffenen Kontrollen und Nachweise identifiziert. Schließlich entscheidet die autorisierte Rolle, ob die Erweiterung freigegeben, begrenzt erprobt oder bis zur Klärung gestoppt wird. So verhindert das Inventar, dass eine allgemeine Rechtsnachricht als pauschale Produktfreigabe missverstanden wird. Der Rechtstext setzt den Rahmen; die betrieblichen Akzeptanzkriterien muss die Organisation selbst festlegen.
Ein konkreter 30-Tage-Start
In der ersten Woche werden vorhandene Listen aus Einkauf, Datenschutz, Informationssicherheit, IT-Architektur und Fachbereichen zusammengeführt. Ziel ist keine Vollständigkeitsbehauptung, sondern eine nachvollziehbare Ausgangsbasis mit Suchlücken.
In Woche zwei werden die wichtigsten Anwendungsfälle nach Wirkung, Betroffenheit und Unsicherheit priorisiert. Für die obersten Fälle werden Rolle, Zweck, Daten, Anbieter, Modellbezug und Entscheidungsverantwortung geklärt.
In Woche drei werden Einstufungsentscheidungen und Kontrollen mit vorhandener Evidenz verknüpft. Fehlende Nachweise werden nicht als „in Arbeit“ versteckt, sondern mit Eigentümer, Zieltermin und Übergangsentscheidung geführt.
In Woche vier erhält das Management ein kleines Steuerungsbild: Anzahl priorisierter Fälle, ungeklärte Rollen, überfällige Bewertungen, kritische Evidenzlücken und anstehende Änderungssignale. Keine Ampel ohne Begründung; kein KPI ohne Entscheidung, die er auslösen soll.
Nach diesen 30 Tagen ist das Inventar nicht „fertig“. Es ist erstmals betriebsfähig. Der Qualitätsmaßstab lautet, ob ein Verantwortlicher eine Änderung erkennt, die betroffene Bewertung findet und eine Entscheidung mit den zugehörigen Nachweisen auslösen kann. Vollständigkeit wächst dann kontrolliert weiter. Eine große Liste ohne diesen Rückkopplungsweg verliert dagegen schnell den Bezug zum laufenden Betrieb.
Zum Regelbetrieb gehört außerdem eine saubere Übergabe zwischen Fachbereich und zentraler Governance. Der Fachbereich erkennt Zweckänderungen meist zuerst, während zentrale Funktionen Rollenfragen, Rechtsänderungen und wiederkehrende Kontrollmuster über mehrere Anwendungsfälle hinweg sehen. Das Inventar muss beide Sichtweisen verbinden. Nur zentral gepflegt wird es schnell sachlich fern; nur dezentral gepflegt entstehen verschiedene Definitionen für denselben Status. Ein sinnvoller Ablauf lässt den Fachbereich Änderungen und Evidenz aktualisieren, während eine unabhängige zweite Rolle Einstufung, Ausnahmen und übergreifende Abhängigkeiten prüft.
Für das Management folgt daraus eine klare Entscheidungslogik. Es muss nicht jede technische Einzelheit abzeichnen. Es muss erkennen können, wo ein Geschäftszweck auf ungeklärte Rolle, fehlende Evidenz oder unzureichende Aufsicht trifft und welche Handlungsoptionen bestehen. Eine befristete Pilotfreigabe kann dabei vertretbarer sein als eine scheinbar endgültige Freigabe auf dünner Tatsachengrundlage. Entscheidend ist, dass Begrenzung, Review-Zeitpunkt und Abbruchkriterium dokumentiert sind. Governance beweist ihren Wert nicht durch die Zahl der Felder, sondern durch bessere Entscheidungen an den Übergängen.
Eine kurze Managementprüfung sichert den nächsten Schritt
- Zentrale, dezentrale und eingebettete KI-Nutzung ist in einer gemeinsamen Sicht verbunden.
- Jeder priorisierte Anwendungsfall hat eine verantwortliche Fachrolle und einen freigabeberechtigten Entscheider.
- Einstufungen sind begründet, datiert, versioniert und mit aktuellen Nachweisen verknüpft.
- Modell-, Zweck-, Daten-, Lieferanten- und Rechtsänderungen lösen eine fallbezogene Neubewertung aus.
- Ausnahmen sind sichtbar, befristet und können vom Management akzeptiert oder eskaliert werden.
Fazit: der A-R-C-Impuls
Der AI Omnibus schafft gezielte Änderungen, aber keine governancefreie Zwischenzeit. Wer jetzt nur Termine aktualisiert, verschiebt Unklarheit. Wer Systeme, Rollen, Entscheidungen und Evidenz verbindet, schafft dagegen eine belastbare Grundlage für die nächste Rechtsänderung, Prüfung oder Managemententscheidung.
Der A-R-C-Impuls lautet: Wählen Sie die zehn KI-Anwendungsfälle mit der größten Wirkung oder Unsicherheit. Prüfen Sie bei jedem Fall drei Dinge: verantwortliche Rolle, begründete Einstufung, auffindbarer Nachweis. Jede Lücke erhält einen Eigentümer und ein Entscheidungsdatum. So wird AI Governance steuerbar, prüfbar und managementfähig.
Abgrenzung
Dieser Beitrag ist eine fachliche Governance-Einordnung und keine Rechtsberatung. Er ersetzt weder die Prüfung des konkreten Anwendungsfalls und des finalen Rechtstextes noch eine behördliche, anwaltliche oder zertifizierende Bewertung. Eine bestimmte Compliance- oder Prüfungserfüllung wird nicht garantiert.
Quellen
- Europäische Kommission, „AI Omnibus enters into force“, veröffentlicht am 27.07.2026, geprüft am 02.08.2026: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
- Europäische Union, AI-Omnibus-Verordnung, Amtsblatt L 2026/1744, geprüft am 02.08.2026: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
- Europäische Kommission, „AI Act – Regulatory framework“, Übersichts- und Zeitlinienseite, geprüft am 02.08.2026: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Bundesrepublik Deutschland, KI-Marktüberwachungs- und -Innovationsförderungsgesetz (KI-MIG), BGBl. 2026 I Nr. 223, verkündet am 28.07.2026, geprüft am 02.08.2026: https://www.recht.bund.de/bgbl/1/2026/223/regelungstext.pdf?__blob=publicationFile&v=1
Über den Autor
Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.