Autorisierung endet an der falschen Grenze

Über Agenten-Identität, Retrieval und die Frage, die niemand stellt.

Die Enterprise-Identity-Branche ist in der ersten Hälfte des Jahres 2026 zu einem echten Konsens gelangt, und es lohnt sich anzuerkennen, wie schnell das geschehen ist. Auf der European Identity Conference in Berlin beschrieb der Vorsitzende der OpenID Foundation KI-Agenten als digitales Personal, das plant, Werkzeuge aufruft und handelt – und argumentierte, dass dies die bestehenden Annahmen über delegierte Autorität, Registrierung und Rechenschaftspflicht bricht, auf denen Enterprise Identity aufgebaut wurde. Anbieter auf derselben Veranstaltung einigten sich auf die Position, dass die fehlende Schicht eine Laufzeit-Autorisierung ist, die jede Aktion bewertet, statt Anmeldeinformationen einmalig an der Tür zu prüfen. Die Cloud Security Alliance veröffentlichte im Mai 2026 ein Whitepaper mit dem Titel „The Non-Human Identity Governance Vacuum" und stellte darin fest, dass Nutzer einer großen Agenten-Plattform gemeinsam mehr als eine Million Agenten erstellt hatten, dass nichtmenschliche Identitäten die menschlichen inzwischen um einen großen und schlecht gemessenen Faktor übersteigen und dass die Identitätsinfrastruktur, die zur Governance dieser Population erforderlich wäre, in den meisten Organisationen nicht existiert, während Angreifer bereits begonnen haben, Attacken gegen diese Lücke zu operationalisieren. Die architektonische Antwort ist inzwischen nahezu Doktrin: Ein Agent muss eine erstklassige Identität eigenen Rechts sein – kryptografisch attestiert, kurzlebig, zur Laufzeit ausgestellt, mit dem ursprünglichen Menschen, der über Token Exchange als delegierendes Subjekt erhalten bleibt – denn ein Agent, der auf einer geliehenen menschlichen Anmeldeinformation läuft, macht jede Aktion forensisch zur Aktion dieser Person, erbt sämtliche Zugriffsrechte, die diese Person im Laufe einer Karriere angesammelt hat, und lässt sich nur abschalten, indem man die Person abschaltet. All das ist richtig. All das betrifft die Frage, was ein Agent tun darf. Und in einem System, in dem die Ausgabe des Agenten in abgerufenen Unternehmensdokumenten verankert ist, ist die Frage, die tatsächlich darüber entscheidet, ob etwas abfließt, eine andere – eine, die in dieser Diskussion fast niemand stellt: Was darf ein Agent wissen?

Dies ist der siebzehnte Beitrag in einer Reihe, die ich für neuland.ai schreibe. [¹] Ein früherer Beitrag argumentierte, dass Containment in agentischen Systemen in beide Richtungen funktionieren muss – dass die eigenen Agenten nicht hinausgelangen und die anderer nicht hereinkommen dürfen. [²] Der jüngste argumentierte, dass zu dem, was verteidigbar bleibt, wenn Standortsouveränität zur Commodity wird, das Autorisierungsmodell gehört, und behauptete nebenbei, dass eine ernstzunehmende Plattform den Retrieval-Raum auf die Rechte der anfragenden Identität reduziert, bevor das Modell überhaupt schlussfolgert, statt nachträglich zu filtern. [³] Diese Behauptung verdient es, belegt statt nur aufgestellt zu werden, denn sie ist die folgenreichste einzelne Designentscheidung in einem berechtigungsbewussten KI-System – und die Branche baut derzeit in die andere Richtung.

Die Konvergenz, und wo sie endet

Der Konsens über Agenten-Identität ist stichhaltig, und ich möchte ihn nicht kleinreden. Die Dreiteilung, die sich in der Praktikerliteratur herausgebildet hat, ist wirklich nützlich: der Requester, der die Arbeit angestoßen hat, der Agent, der für ihre Planung und Koordination verantwortlich ist, und der Executor – das Werkzeug, Modell oder Sub-Agent, der eine bestimmte Operation ausführt. Diese müssen verbunden bleiben, ohne verschmolzen zu werden, denn ein gemeinsam genutztes nachgelagertes Konto verschleiert, welcher Agent gehandelt hat und unter wessen Autorität. [⁴]

Die dahinterliegende Einsicht ist noch schärfer. Ein klassisches Servicekonto hat eine feststehende Identität und einen feststehenden Geltungsbereich; es existiert für einen definierten Zweck. Ein Agent hat einen pro Aufgabe variablen Geltungsbereich – derselbe Agent handelt zu unterschiedlichen Zeitpunkten für unterschiedliche Personen, mit unterschiedlichen Berechtigungen, innerhalb unterschiedlicher Delegationsketten. [⁵] Ein einmaliger Login kann daher nicht belegen, dass der Agent über die Dauer eines Workflows innerhalb seines genehmigten Zwecks geblieben ist – weshalb Autorisierung fortlaufend bewertet und nicht einmalig erteilt werden muss. Und die Folgerung, die regulierte Institute zweimal lesen sollten: Die Erlaubnis, einen Kundendatensatz einzusehen, impliziert nicht die Erlaubnis, ihn zu exportieren, zu ändern, an ein anderes System weiterzuleiten oder den Zugriff darauf zu delegieren. [⁶]

All das betrifft Aktionen. Werkzeugaufrufe, Schreibvorgänge, Versand, Eskalationen, Delegationen. Der Policy Enforcement Point sitzt zwischen der Absicht des Agenten und der Wirkung, die er in der Welt entfalten will, und fragt: Darf diese Identität genau jetzt diese Operation ausführen?

Das ist eine notwendige Frage. Sie ist nicht hinreichend, und der Grund dafür liegt spezifisch darin, wie diese Systeme tatsächlich Antworten erzeugen.

Die Frage, die das Aktions-Autorisierungsmodell nicht stellen kann

Man betrachte, was passiert, wenn ein Mitarbeiter einem Assistenten eine Frage über seine eigene Organisation stellt. Das System bettet die Anfrage ein, durchsucht einen Korpus, der Dateifreigaben, E-Mail, ein Dokumentenmanagementsystem und mehrere Fachanwendungen umspannt, ruft die semantisch nächstliegenden Passagen ab und übergibt sie dem Modell als Kontext. Das Modell schlussfolgert über diesen Kontext und erzeugt eine Antwort mit Quellenangaben.

Nehmen wir nun an, der Korpus enthält ein Dokument, das dieser bestimmte Mitarbeiter nicht sehen darf – eine Personalakte, einen Entwurf eines Restrukturierungsplans, ein Rechtsgutachten zu einem laufenden Streitfall, die kommerziellen Konditionen eines von einer anderen Division verhandelten Lieferantenvertrags.

Das Aktions-Autorisierungsmodell hat dazu nichts zu sagen. Es hat keine verbotene Operation stattgefunden. Der Agent führte ein Retrieval aus, zu dem er berechtigt war, auf einem Korpus, den er abfragen durfte, unter einer Identität, die ordnungsgemäß ausgestellt und korrekt delegiert war. Jede Laufzeitprüfung besteht. Und das vertrauliche Dokument befindet sich nun im Kontextfenster des Modells.

Die gängige Antwort besteht darin, die Ausgabe zu filtern: Berechtigungen gegen das prüfen, was das Modell erzeugt hat, und alles schwärzen oder unterdrücken, was der Nutzer nicht erhalten sollte. Hier stehen derzeit sehr viele Enterprise-KI-Implementierungen, und es scheitert aus fünf separaten Gründen, die sich verstärken.

Das unbefugte Material ist in den Kontext gelangt, was bedeutet, dass es die erzeugten Tokens beeinflusst hat, ob es nun zitiert wurde oder nicht. Es hat die Schlussfolgerung geprägt – eine Antwort, die Kenntnis eines vertraulichen Restrukturierungsplans widerspiegelt, ist eine Offenlegung, auch wenn sie nichts beim Namen nennt. Es steht in den Logs, denn ein System mit einem ordentlichen Audit-Trail protokolliert, was abgerufen wurde, und der Audit-Trail ist damit selbst zu einem Vertraulichkeitsproblem geworden. Es ist indirekt erreichbar, denn ein Filter, der Zitate abfängt, fängt keine Inferenz ab, und ein hinreichend geduldiger Nutzer braucht das Dokument nicht zitiert. Und am gravierendsten: Man kann das Negative nicht beweisen. Auf die Frage eines Prüfers, ob ein Mitarbeiter Informationen aus einem Dokument hätte erlangen können, für das er nicht freigegeben war, lautet die ehrliche Antwort aus einer Post-Filtering-Architektur, dass das Dokument abgerufen und verarbeitet wurde und dass man annimmt, der Filter habe funktioniert.

Für ein beaufsichtigtes Institut ist das keine Antwort. Unter den Audit- und Nachvollziehbarkeitspflichten, die mit dem EU AI Act am 2. August 2026 breit anwendbar wurden, ist „man nimmt an, der Filter habe funktioniert" keine Kontrolle. [⁷]

Stattdessen das Retrieval autorisieren

Die Alternative besteht darin, die Prüfung nach vorne zu verlagern, sodass die Berechtigung auf den Suchraum angewendet wird statt auf die Ausgabe.

Die anfragende Identität kommt mit der Anfrage. Bevor irgendein Retrieval ausgeführt wird, wird der durchsuchbare Raum genau auf das Material reduziert, das diese Identität sehen darf. Die Vektorsuche, die lexikalische Suche und das Reranking arbeiten dann alle auf diesem reduzierten Raum. Die Konsequenz verdient eine präzise Formulierung: Für diese Anfrage existiert das unbefugte Dokument nicht. Es wird nicht abgerufen, gelangt also nicht in den Kontext, kann also die Schlussfolgerung nicht beeinflussen, erscheint also nicht im Audit-Trail, ist also nicht indirekt erreichbar – und die Antwort auf die Frage des Prüfers wird strukturell statt probabilistisch. Das Dokument wurde nicht herausgefiltert. Es war nie im Geltungsbereich.

Die Garantie ist ein einziger Satz, und sie muss in vier Fällen identisch gelten: bei einem Menschen, der direkt fragt, bei einer langlaufenden Sitzung, bei einem autonomen Agenten, der im Auftrag dieses Menschen handelt, und bei einem Agenten, der unter einer delegierten Identität von einer anderen Plattform kommt. Was die anfragende Identität nicht sehen darf, kann das System nicht ausgeben – weil es nie abgerufen wurde.

Drei Dinge sind nötig, damit das zutrifft, und keines davon ist umsonst.

Ein maßgeblicher Berechtigungsdatensatz, getrennt von der Bedeutungsschicht. Das ist der Teil, den die meisten Architekturen falsch machen, und der Grund ist nachvollziehbar. Ein Vektorindex, der für approximative Ähnlichkeitssuche in großem Maßstab optimiert ist, ist der falsche Ort für die maßgebliche Antwort darauf, wer was sehen darf. „Approximativ" ist genau die falsche Eigenschaft für eine Zugriffsentscheidung. Der Berechtigungsdatensatz gehört daher in einen bewusst unspektakulären transaktionalen Speicher – einen, den ein Prüfer lesen, abfragen und verstehen kann, ohne irgendeine probabilistische Komponente darin – strukturell getrennt von der Schicht, die die semantischen Repräsentationen hält. Die eine Ebene ist das System of Record für Berechtigungen. Die andere ist das System of Meaning. Keine sollte versuchen, die Aufgabe der anderen zu übernehmen.

Beziehungen statt Rollen. Rollenbasierte Zugriffskontrolle beantwortet: Wer bist du? Retrieval-Autorisierung muss beantworten: Darfst du dieses spezifische Objekt sehen, genau jetzt, in diesem Kontext – und das ist eine Frage nach der Beziehung zwischen einer Identität und einem Objekt, die pro Anfrage bewertet wird. Sie muss außerdem den Fall abdecken, den rollenbasierte Modelle strukturell nicht abdecken können: einen mitten in der Aufgabe erzeugten Sub-Agenten, dessen Identität beim Start des übergeordneten Workflows noch nicht existierte und der daher nicht im Voraus bereitgestellt werden konnte. Ein beziehungsbasiertes Modell drückt das nativ aus, denn die Delegationskette ist selbst eine Menge von Beziehungen, und die Berechtigung eines zur Laufzeit erzeugten Sub-Agenten ist aus der Kette ableitbar, die ihn erzeugt hat.

Propagierung, ehrlich verbucht. Hier liegen die Kosten. Wenn sich eine Berechtigung ändert – jemand verlässt ein Projekt, ein Dokument wird neu klassifiziert, eine Aufbewahrungsfrist läuft ab, ein Legal Hold greift –, muss diese Änderung beide Ebenen erreichen. Sie muss beim Ingest von Inhalten angewendet und bei Ausführung einer Anfrage neu bewertet werden, denn zwischen diesen beiden Momenten bewegt sich die Welt. Löschung ist noch schlimmer: Ein aus einem Quellsystem entferntes Dokument muss aus dem Datensatz, aus dem semantischen Index und aus allem daraus Abgeleiteten verschwinden. Das ist echte Ingenieursarbeit mit echten Fehlermodi, sie verbraucht bei jeder Anfrage einen Teil des Latenzbudgets, und jeder Anbieter, der Ihnen erzählt, das sei ein Konfigurationsschalter, hat es nicht gebaut. Die richtige Aussage ist nicht, dass die Kosten gering sind. Sie lautet, dass die Kosten es wert sind, denn die Alternative ist eine Architektur, die die Frage eines Prüfers nicht beantworten kann.

Warum das die schwierigere Hälfte ist

Es gibt einen Grund, warum die Branche zuerst zur Aktions-Autorisierung konvergiert ist, und er heißt nicht Inkompetenz.

Aktions-Autorisierung ist ein gut verstandenes Problem mit ausgereiften Standards. Es gibt eine Anfrage, eine Policy, einen Entscheidungspunkt und ein Ergebnis, das entweder erlaubt oder verweigert wird. Die Identity-Branche baut das seit zwanzig Jahren, und die Anpassung an Agenten – kurzlebige Credentials, Token Exchange, Delegationsketten – ist wirklich schwierig, aber sie ist schwierig in einer vertrauten Richtung. Die Praktikereinschätzung aus Berlin lautete, dass die Diskussion über agentische Identität derzeit ungefähr dort steht, wo Passkeys vor einigen Jahren standen: Das Problem ist klar formuliert, die Standards bilden sich heraus, und produktive Fallstudien sind dünn gesät. [⁸] Das ist eine faire Beschreibung eines Feldes, das echte Fortschritte macht.

Retrieval-Autorisierung ist aus einem strukturellen Grund schwieriger. Sie lässt sich nicht als Schicht ergänzen. Ein Policy Enforcement Point kann vor einen Werkzeugaufruf gesetzt werden, weil der Werkzeugaufruf ein diskretes Ereignis mit einer Grenze ist. Retrieval hat keine entsprechende Grenze – die Berechtigung muss innerhalb der Anfrage liegen und mitbestimmen, welche Kandidaten überhaupt in Betracht gezogen werden, was bedeutet, dass Autorisierungsmodell und Sucharchitektur gemeinsam entworfen werden müssen. Ein System, das gebaut wurde, um zuerst abzurufen und danach zu filtern, lässt sich nicht nachträglich in eines umbauen, das zuerst zuschneidet, denn der Zuschnitt erfordert einen maßgeblichen Berechtigungsdatensatz, der mit Retrieval-Latenz abfragbar ist – und wenn dieser Datensatz nicht in der richtigen Form existiert, muss er von Grund auf gebaut werden.

Das ist das Argument, das diese Reihe seit Februar in der einen oder anderen Form vorträgt: Die Eigenschaften, auf die es in der Enterprise-KI ankommt, sind Eigenschaften der Architektur, keine Features obendrauf. Compliance ist eine Systemeigenschaft. Containment ist eine Systemeigenschaft. Die Autorisierung dessen, was ein System wissen darf, ist eine Systemeigenschaft, und sie wird zur Entwurfszeit entschieden oder gar nicht.

Wo neuland.ai steht

Der neuland.ai HUB setzt Berechtigungen auf dem Suchraum durch, bevor das Modell schlussfolgert. Der maßgebliche Datensatz darüber, wer was sehen darf, liegt in einem transaktionalen Speicher ohne probabilistische Komponente, bewusst getrennt von der Schicht, die die semantischen Repräsentationen hält, und für einen Prüfer ohne Interpretation lesbar. Berechtigungen werden als Beziehungen statt als Rollen ausgedrückt, was es einem zur Laufzeit erzeugten Sub-Agenten erlaubt, einen ableitbaren Geltungsbereich aus seiner Delegationskette zu erben, statt eine im Voraus bereitgestellte Identität zu benötigen. Berechtigungs- und Löschänderungen werden beim Ingest angewendet und zur Anfragezeit neu bewertet. Dieselbe Garantie gilt, unabhängig davon, ob der Anfragende eine Person, eine Sitzung, ein Agent oder ein Agent ist, der unter einer delegierten Identität über eine Plattformgrenze hinweg kommt – und genau das macht Plattform-zu-Plattform-Kopplung möglich, ohne das Zugriffskontrollmodell des Kunden zusammen mit der Anfrage zu exportieren. Jedes Retrieval und jede Entscheidung wird auf einem Append-only-Trail protokolliert, sodass die Frage, was eine bestimmte Identität zu einem bestimmten Zeitpunkt hätte sehen können, eine Antwort hat, die nicht davon abhängt, einem Filter zu vertrauen. [⁹]

Der Forschungsaufwand dahinter ist Systems- und Infrastrukturarbeit statt Modellforschung, und die ehrliche Einordnung lautet, dass der schwierige Teil nie das Konzept war. Einen Suchraum auf eine Berechtigungsmenge zuzuschneiden ist keine neuartige Idee. Die Schwierigkeit besteht darin, es mit Retrieval-Latenz zu tun, über einen Korpus, der groß genug ist, um relevant zu sein, über Quellsysteme hinweg, deren eigene Berechtigungsmodelle einander widersprechen, und dabei zwei Ebenen unter kontinuierlicher Veränderung konsistent zu halten – und es dann einem Prüfer nachzuweisen. Das ist unglamouröses Engineering, und es ist der größte Teil der Arbeit.

Persönliche Einschätzung

Die Identity-Branche wird Agenten-Authentifizierung und Aktions-Autorisierung lösen, vermutlich innerhalb von etwa zwei Jahren, und das wird eine echte Leistung sein. Standards bilden sich heraus, die Anbieter meinen es ernst, und die Richtung stimmt.

Was mich beunruhigt, ist, dass sehr viele Unternehmen diesen Fortschritt als Vollendung lesen werden. Sie werden ordentliche Agenten-Identitäten ausstellen, Laufzeit-Autorisierung für Werkzeugaufrufe implementieren, eine beeindruckende Policy-Architektur hervorbringen – und dennoch ein Retrieval betreiben, das den gesamten Korpus erreicht und die Ausgabe filtert, weil ihnen nichts in der Diskussion über Agenten-Identität gesagt hat, dass das ein Problem ist. Sie werden ein Security Review bestehen und weiterhin außerstande sein, die einzige Frage zu beantworten, die ein Regulator tatsächlich stellen wird – nämlich nicht, was Ihr System getan hat, sondern was diese Person hätte erfahren können.

Die Unterscheidung ist leicht auszusprechen und teuer nachzurüsten. Ein Agent, der ordentlich identifiziert, korrekt eingegrenzt, fortlaufend autorisiert und vollständig auditiert ist, kann einem Nutzer immer noch etwas mitteilen, das dieser nie wissen durfte, wenn das Retrieval, das seine Antwort verankert hat, nicht selbst durch die Rechte dieses Nutzers eingeschränkt war. Identität legt fest, wer handelt. Aktions-Autorisierung legt fest, was er tun darf. Keines von beidem legt fest, was er wissen darf – und in einem retrieval-verankerten System wohnt genau dort die Vertraulichkeit.

Eine kurze Anmerkung zum regulatorischen Hintergrund, da er sich weiterentwickelt. Der EU AI Act wurde am 2. August 2026 breit anwendbar, mit ab diesem Datum bindenden GPAI-Durchsetzungsbefugnissen nach Kapitel V; die Digital-Omnibus-Einigung vom 7. Mai 2026 verschob die Hochrisiko-Pflichten nach Anhang III auf den 2. Dezember 2027 und die Pflichten nach Anhang I auf den 2. August 2028. [¹⁰] Audit- und Nachvollziehbarkeitserwartungen an KI-initiierte Aktivitäten haben sich von guter Praxis in Richtung gesetzlicher Anforderung verschoben, und eine Architektur, die nur nachweisen kann, dass ein Filter angewendet wurde, steht auf der falschen Seite dieser Verschiebung.

Autorisierung endet an der falschen Grenze. Sie nach vorne zu verlagern ist die Arbeit, die vor uns liegt – und es ist die Arbeit, die wir seit Längerem tun.

¹ Artikel der Reihe auf http://neuland.ai : Zentrale Plattform für Enterprise-KI.

² Siehe den früheren Beitrag dieser Reihe über Containment als bidirektionale Systemeigenschaft.

³ Siehe den vorherigen Beitrag dieser Reihe über die Commoditisierung der Standortsouveränität und die vier Eigenschaften, die verteidigbar bleiben.

⁴ Die Unterscheidung Requester / Agent / Executor und die Anforderung, dass die drei verbunden bleiben, ohne verschmolzen zu werden, wie sie in den im Laufe des Jahres 2026 veröffentlichten Leitlinien zur Enterprise-Agenten-Identität dargelegt ist. Der beschriebene Fehlermodus – ein gemeinsam genutztes nachgelagertes Konto, das verschleiert, welcher Agent unter wessen Autorität gehandelt hat – ist in dieser Literatur breit dokumentiert.

⁵ Zur Unterscheidung zwischen einem klassischen Servicekonto (feststehende Identität, feststehender Geltungsbereich, definierter Zweck) und einem Agenten (pro Aufgabe variabler Geltungsbereich, Handeln für unterschiedliche Prinzipale zu unterschiedlichen Zeitpunkten innerhalb unterschiedlicher Delegationsketten) siehe die Mitte 2026 veröffentlichten Referenzen zur agentischen Authentifizierung im Unternehmen.

⁶ Die Feststellung, dass die Erlaubnis, einen Datensatz einzusehen, nicht die Erlaubnis impliziert, ihn zu exportieren, zu ändern, weiterzuleiten oder Zugriff darauf zu delegieren, findet sich durchgängig in den Leitlinien zur Agenten-Identität aus 2026 und ist der in der Umsetzung am häufigsten verlorene Punkt.

⁷ EU AI Act breit anwendbar ab dem 2. August 2026. Im Juni 2026 veröffentlichte Praktikerkommentare wiesen darauf hin, dass die Auditfähigkeit für KI-initiierte Aktivitäten mit Näherrücken dieses Datums von Best Practice in Richtung gesetzlicher Anforderung wanderte.

⁸ Praktikereinschätzung von der European Identity Conference, Berlin, Mitte 2026: Die Diskussion über agentische Identität wurde so charakterisiert, dass sie ungefähr dort stehe, wo Passkeys einige Jahre zuvor standen – Problem klar formuliert, Standards in Entstehung, produktive Fallstudien noch nicht verfügbar. Ebenfalls von dieser Veranstaltung: die Einordnung des Vorsitzenden der OpenID Foundation, Agenten seien digitales Personal, das plant, Werkzeuge aufruft und handelt, und breche damit bestehende Annahmen über delegierte Autorität, Registrierung und Rechenschaftspflicht; sowie das Argument, die fehlende Schicht sei eine Laufzeit-Autorisierung, die jede Aktion bewertet, statt einmalig geprüfter Credentials. Cloud Security Alliance, „The Non-Human Identity Governance Vacuum", 20. Mai 2026, zum Ausmaß der Agentenerstellung auf großen Plattformen, zum Verhältnis nichtmenschlicher zu menschlichen Identitäten und zum Fehlen einer angemessenen Governance-Infrastruktur.

⁹ Autorisierungsarchitektur des neuland.ai HUB: Berechtigungsdurchsetzung auf dem Retrieval-Raum vor der Schlussfolgerung; maßgeblicher Berechtigungsdatensatz in einem transaktionalen Speicher getrennt von der semantischen Schicht; beziehungsbasiertes Berechtigungsmodell, das zur Laufzeit erzeugte Sub-Agenten-Identitäten mit aus der Delegationskette ableitbarem Geltungsbereich unterstützt; Berechtigungs- und Löschänderungen beim Ingest angewendet und zur Anfragezeit neu bewertet; identische Garantie über menschliche, sitzungsbezogene, agentische und plattformübergreifend delegierte Anfragen hinweg; Append-only-Audit-Trail für Retrieval- und Zugriffsentscheidungen. Die neuland.ai AG behält die Verantwortung für Inhaltsqualität und saubere Ergebnislieferung über alle Kundenengagements hinweg.

¹⁰ Vorläufige politische Einigung von Rat der EU und Europäischem Parlament zum Digital Omnibus zur KI, 7. Mai 2026: Hochrisiko-Pflichten nach Anhang III verschoben auf den 2. Dezember 2027; Pflichten nach Anhang I verschoben auf den 2. August 2028; Watermarking-Pflichten nach Artikel 50(2) verschoben auf den 2. Dezember 2026. GPAI-Durchsetzungsbefugnisse nach Kapitel V bindend ab dem 2. August 2026.

Bild generiert mit dem neuland.ai HUB.