Artikel 50 in 12 Wochen: Was GPAI-Anbieter und -Nutzer bis zum 2. August 2026 umsetzen müssen

Was am 2. August 2026 bindend wird

Die EU-KI-Verordnung — Verordnung (EU) 2024/1689 — hat einen gestaffelten Durchsetzungskalender, den das Digital-Omnibus-Paket vom Mai 2026 neu geordnet hat. Die Verbote in Artikel 5 wurden am 2. Februar 2025 bindend. Die Hochrisiko-System-Pflichten in Anhang III werden nun am 2. Dezember 2027 bindend (verschoben vom 2. August 2026 durch das Omnibus-Paket). In Produkte eingebettete KI nach EU-Sektor-Sicherheitsrecht folgt am 2. August 2028. KI-Systeme, die vor Inkrafttreten der Verordnung bereits am Markt waren, unterliegen rückwirkenden Pflichten ab dem 2. August 2030.

Die Daten, die für die meisten heutigen Nutzer und GPAI-Anbieter planungsrelevant sind, fallen in das Jahr 2026:

2. August 2026. Die GPAI-Anbieter-Pflichten der Artikel 51–56 treten in die formale Durchsetzung ein. Die Pflichten selbst sind seit dem 2. August 2025 anwendbar; dies ist das Datum, an dem die Durchsetzungsbefugnisse des KI-Büros und das Sanktionsregime greifen. Die meisten Transparenzpflichten des Artikels 50 für Anbieter und Nutzer werden ebenfalls anwendbar.

2. Dezember 2026. Die Pflicht zur maschinenlesbaren Kennzeichnung synthetischer Inhalte aus Artikel 50(2) — Audio, Bild, Video, Text, generiert durch KI — wird wirksam. Das Omnibus-Paket hat dieses Datum als Kompromiss zwischen dem Vorschlag der Kommission (Anfang 2027) und der Präferenz des Parlaments (November 2026) ausgehandelt. Es ist der einzige Absatz von Artikel 50, den das Omnibus-Paket verschoben hat.

Zusammengenommen ist die zweite Jahreshälfte 2026 der Zeitpunkt, an dem die EU-KI-Verordnung aufhört, primär ein zukunftsgerichtetes Compliance-Programm zu sein, und beginnt, tatsächliche Durchsetzungsereignisse gegen Unternehmen zu produzieren, deren Geschäftsmodelle von KI abhängen. Die Höchststrafe für Nichteinhaltung beträgt 35 Mio. € oder 7 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist, für verbotene Praktiken nach Artikel 5; 15 Mio. € oder 3 % für Nichteinhaltung der meisten anderen Pflichten, einschließlich Artikel 50; 7,5 Mio. € oder 1 % für informationsbezogene Verstöße.

Dieser Beitrag handelt davon, was vor diesen Daten umgesetzt werden muss. Es ist keine Rechtsberatung. Es ist eine Praktikerlesart dessen, was ein Audit übersteht — geschrieben von Leuten, die signierte Quittungen für KI-Inferenz in Produktion betreiben.

Sind Sie Anbieter, Nutzer oder nachgelagerter Nutzer?

Die erste Frage, die zu klären ist, bevor Sie einen weiteren Absatz der Verordnung lesen: welche der drei Rollen Sie einnehmen. Die Verordnung weist Pflichten unterschiedlich zu.

Ein Anbieter ist die juristische oder natürliche Person, die ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt (Artikel 3 Nr. 3). Bei GPAI-Modellen speziell ist der Anbieter, wer das Modell trainiert und verfügbar macht — OpenAI, Anthropic, Mistral, Google, Meta, die Open-Weights-Labs.

Ein Nutzer ist die juristische oder natürliche Person, die ein KI-System unter ihrer Verantwortung einsetzt, ausgenommen die Nutzung im Rahmen einer persönlichen, nicht-beruflichen Tätigkeit (Artikel 3 Nr. 4). Wer ein Drittanbieter-LLM in ein Produkt, einen internen Workflow oder einen kundennahen Entscheidungsfluss integriert, ist Nutzer dieses LLM. Fast jedes EU-Unternehmen, das KI heute in Produktion einsetzt, ist Nutzer, nicht Anbieter.

Ein nachgelagerter Nutzer ist informelle Sprache, die manchmal verwendet wird, um einen Nutzer zu beschreiben, der mehrere Schritte vom Modell entfernt ist — zum Beispiel ein SaaS-Kunde, der eine Funktion verwendet, die intern ein LLM aufruft. Im Sinne der Verordnung ist dieses Unternehmen weiterhin Nutzer; die Pflicht trifft denjenigen, der das KI-System unter eigener Verantwortung für eigene Zwecke einsetzt.

Die Entscheidungsbaum-Praxisversion:

• Sie trainieren und veröffentlichen Foundation-Modelle → GPAI-Anbieter. Die Artikel 51–55 gelten in vollem Umfang.
• Sie nehmen ein Drittanbieter-LLM und rufen es aus Ihrem Produkt, Ihren internen Tools oder Ihren kundennahen Flows auf → Nutzer. Artikel 50(3) und 50(4) gelten, wenn Ihre Nutzung im Anwendungsbereich liegt. Artikel 50(1) und 50(2) wirken vorgelagert — Ihr Anbieter muss sie erfüllen, aber Ihre vertragliche Position muss vermutlich bestätigen, dass er das tut.
• Sie kaufen ein SaaS-Produkt mit eingebauter KI → trotzdem Nutzer dieses Produkts, auch wenn die KI für Sie unsichtbar ist. Die Verordnung entbindet Sie nicht von Pflichten, weil die KI durch Ihren Anbieter implementiert wird.

Die meisten Leser dieses Beitrags werden Nutzer sein. Die nächsten beiden Abschnitte sind für dieses Publikum geschrieben, mit Anbieter-spezifischen Pflichten dort, wo sie auftauchen.

Was Artikel 50 tatsächlich verlangt

Artikel 50 trägt den Titel „Transparenzpflichten für Anbieter und Nutzer bestimmter KI-Systeme". Er umfasst vier operative Absätze.

Artikel 50(1) — Anbieter stellen sicher, dass KI-Systeme, die für direkte Interaktion mit natürlichen Personen bestimmt sind, so konzipiert und entwickelt werden, dass die betroffenen Personen darüber informiert werden, dass sie mit einem KI-System interagieren — sofern dies nicht aus den Umständen ersichtlich ist. Der Auslöser ist „für direkte Interaktion bestimmt". Ein Kundenservice-Chatbot löst sie aus. Ein Backend-Inferenz-Dienst, der eine Transaktion bewertet, nicht — weil keine direkte Interaktion stattfindet.

Artikel 50(2) — Anbieter von KI-Systemen, einschließlich GPAI-Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen, stellen sicher, dass die Ausgaben in einem maschinenlesbaren Format markiert und als künstlich erzeugt oder manipuliert erkennbar sind. Das ist die Wasserzeichen-Pflicht. Die Verordnung gibt die Wasserzeichen-Technik nicht vor; das wird in technischen Standards (CEN-CENELEC JTC 21, ISO/IEC) und in der erwarteten Anleitung des KI-Büros geklärt.

Artikel 50(3) — Nutzer eines Emotionserkennungs- oder biometrischen Kategorisierungssystems informieren die natürlichen Personen, die dem System ausgesetzt sind. Auslöser ist die Existenz des Systems im Umfeld des Nutzers — nicht, ob die Ausgabe des Systems dem Nutzer angezeigt wird.

Artikel 50(4) — Nutzer eines KI-Systems, das Bild-, Audio- oder Videoinhalte erzeugt oder manipuliert, die einen Deep-Fake darstellen, müssen offenlegen, dass der Inhalt künstlich erzeugt oder manipuliert wurde. Derselbe Absatz erstreckt sich auf Texte, die zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse veröffentlicht werden — mit Ausnahmen für redaktionelle Kontrolle.

Zwei Dinge sind an der Struktur des Artikels 50 zu beachten.

Erstens operieren die Pflichten auf Anbieter (50(1) und 50(2)) und auf Nutzer (50(3) und 50(4)) auf unterschiedlichen Ebenen. Die Pflicht des Anbieters wirkt auf der Designebene — das System muss so gebaut sein, dass die Offenlegung stattfindet. Die Pflicht des Nutzers wirkt auf der Einsatzebene — der Nutzer muss tatsächlich offenlegen, unabhängig davon, was der Anbieter gebaut hat. Ein Nutzer kann sich der Pflicht aus Artikel 50(3) nicht entziehen, indem er sagt: „Der Anbieter hätte das offenlegen müssen." Die Pflicht trifft Sie.

Zweitens sind „informieren" und „offenlegen" nicht dasselbe. Artikel 50(1) sagt „darüber informiert, dass sie mit einem KI-System interagieren" — das kann ein Chatbot-Begrüßungstext sein. Artikel 50(4) sagt „müssen offenlegen, dass der Inhalt künstlich erzeugt oder manipuliert wurde" — das verlangt eine pro-Inhaltsstück-Kennzeichnung in einer Form, mit der der Empfänger etwas anfangen kann.

Die praktische Frage für die meisten Nutzer ist, ob ihre LLM-Nutzung unter die zweite Klausel von Artikel 50(4) fällt — Erzeugen oder Manipulieren von Texten, die zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse veröffentlicht werden. Der Wortlaut ist auslegungsbedürftig. Eine mit LLM-Unterstützung verfasste Pressemitteilung löst sie wahrscheinlich aus. Eine interne Slack-Zusammenfassung wahrscheinlich nicht. Eine Kundenservice-E-Mail, die KI-Output paraphrasiert, liegt in der Grauzone. Die Anleitung des KI-Büros, wenn sie erscheint, wird das eingrenzen; bis dahin ist die konservative Lesart, anzunehmen, dass Offenlegungspflichten für jeden öffentlichkeitsgerichteten KI-generierten Text gelten — und entsprechend zu konstruieren.

Was die Artikel 51–55 für GPAI-Anbieter hinzufügen

Die Artikel 51 bis 56 — gemeinsam Kapitel V genannt — sind die GPAI-Anbieter-Pflichten. Sie wurden am 2. August 2025 anwendbar, aber die Durchsetzungsbefugnisse des KI-Büros und das formale Sanktionsregime beginnen erst am 2. August 2026. Praktiker-Version: Die Regeln gelten seit neun Monaten, aber der Tag, an dem die Aufsichtsbehörde Sie für ihre Missachtung mit Bußgeldern belegen kann, ist der 2. August 2026. Die Hauptpflichten:

• Technische Dokumentation des Modells (Artikel 53(1)(a) + Anhang XI), aktuell zu halten und dem KI-Büro sowie den zuständigen Behörden auf Anfrage zur Verfügung zu stellen.
• Informationen für Nutzer (Artikel 53(1)(b) + Anhang XII) — was nachgelagerte Nutzer benötigen, um das Modell rechtskonform in ihre eigenen KI-Systeme zu integrieren.
• Urheberrechts-Compliance-Strategie (Artikel 53(1)(c)) — schriftliche Strategie zur Frage, wie das Training des Anbieters das EU-Urheberrecht respektiert, einschließlich Text-und-Data-Mining-Opt-outs (Richtlinie 2019/790 Artikel 4).
• Trainingsdaten-Zusammenfassung (Artikel 53(1)(d)) — eine hinreichend detaillierte Zusammenfassung der für das Training verwendeten Inhalte, öffentlich verfügbar gemacht. Es wird erwartet, dass das KI-Büro eine Vorlage veröffentlicht.

Für Modelle mit systemischem Risiko — derzeit ist die Vermutung nach Artikel 51(2) Modelle, die mit mehr als 10^25 Gleitkomma-Operationen Rechenleistung trainiert wurden, wobei die Schwelle revidierbar ist — fügt Artikel 55 weitere Pflichten hinzu: Modellbewertungen einschließlich gegnerischer Tests, Bewertung des systemischen Risikos, Vorfallsmeldung an das KI-Büro und Cybersicherheitsschutz.

Die meisten Unternehmen, die diesen Beitrag lesen, sind keine GPAI-Anbieter. Sie sind Käufer von GPAI-Modellen. Die relevante Frage für sie ist nicht „erfüllen wir Artikel 53"; sie ist „erfüllt unser gewählter GPAI-Anbieter Artikel 53, und wie muss unsere nutzerseitige Dokumentation aussehen, damit wir uns auf seine stützen können". Diese Frage wird vertraglich tragend, sobald der 2. August 2026 verstreicht.

„Hinweis" reicht nicht — die Nachweislücke

Der häufigste Fehlermodus bei der nutzerseitigen Vorbereitung auf Artikel 50 ist, ihn als Hinweistext-Aufgabe zu behandeln.

Ein Team liest Artikel 50, fragt „was müssen wir offenlegen", und produziert drei Dinge: ein Banner in der Chatbot-Oberfläche mit „Sie chatten mit einem KI-Assistenten", eine Zeile in der Datenschutzerklärung mit den verwendeten KI-Anbietern und ein Policy-Memo, dass die Offenlegung KI-erzeugter Inhalte für öffentliche Pressemitteilungen gilt. Sie betrachten Artikel 50 als erledigt.

Das ist nicht falsch. Es ist notwendig. Es ist allein auch unzureichend.

Der Grund wird in einem Untersuchungsszenario klar. Eine Aufsichtsbehörde nach Artikel 74 — eine zuständige Behörde für Marktüberwachung — fordert den Nutzer auf, nachzuweisen, dass die Offenlegung in einem konkreten Vorfall erfolgt ist. Ein Nutzer beschwert sich, er sei nicht darüber informiert worden, dass er mit einer KI sprach. Die Behörde will den Nachweis sehen.

Der Nutzer kann die Policy vorlegen. Der Nutzer kann die Datenschutzerklärung vorlegen. Der Nutzer kann das UI-Banner des Chatbots vorlegen.

Was der Nutzer in den meisten heutigen Aufstellungen nicht vorlegen kann, ist die pro-Inferenz-Aufzeichnung, die zeigt, dass an einem konkreten Datum, in einer konkreten Sitzung, mit einem konkreten Nutzer die Offenlegung dargestellt wurde, der Modellaufruf gegen einen konkret-versionierten vorgelagerten Anbieter erfolgte und die Antwort tatsächlich diesem Modell zuzuordnen war — und nicht etwa einer Content-Moderation-Regel.

Diese Lücke ist die Nachweisschicht von Artikel 50. Hinweistext ist die Oberfläche. Pro-Inferenz signierter Nachweis ist das, was eine Untersuchung übersteht.

Dieselbe Lücke bildet Artikel 50(2) — die Pflicht zur maschinenlesbaren Kennzeichnung — ab. Eine Aufsichtsbehörde kann einen Detektor gegen ein Stück synthetischen Inhalt laufen lassen. Wenn die Markierung fehlt oder entfernt wurde, ist die Verteidigung des Nutzers: „wir haben alles gekennzeichnet, was wir erzeugt haben; dieser Inhalt liegt vor dieser Policy / wurde von einem anderen System als unserem erzeugt / wurde nach der Erzeugung verändert". Jeder dieser Ansprüche verlangt Nachweis. Eine signierte Quittung, die im Moment der Erzeugung produziert wurde, ist Nachweis. Ein Policy-Dokument, das sagt „wir kennzeichnen unsere Inhalte", ist es nicht.

Was heute bereitgestellt wird gegenüber dem, was verlangt ist

Fast jedes Team, das LLMs heute in Produktion betreibt, hat Logging. Die Logs erfassen typischerweise Zeitstempel, Request-IDs und strukturierte Payloads. Sie liegen in einem Log-Aggregator. Die Aufbewahrungsrichtlinie lautet „bis der Speicher zu teuer wird".

Artikel 50 hebt die Latte auf drei spezifische Weisen:

Manipulationssicherheit. Logs, die der Betreiber stillschweigend umschreiben kann, sind kein Nachweis. Die Untersuchung einer Aufsichtsbehörde nach Artikel 74 wird betreiber-kontrollierte Logs als Ausgangspunkt behandeln, nicht als Schlusspunkt. Die Verordnung ist nicht-präskriptiv hinsichtlich der Technik; was übersteht, ist die Verankerung — kryptografische Signatur im Moment der Inferenz, öffentliches Timestamping, Inklusionsbeweise im Transparency-Log. Nichts davon ist nach der Verordnung verpflichtend. All das sind praktische Antworten auf „woher wissen wir, dass Ihre Engineers nicht stillschweigend einen Datensatz verändert haben, nachdem die Beschwerde eingegangen ist".

Pro-Inferenz-Auflösung. Ein Log, das aggregiert „12 Mio. Inferenzen im März bedient", erfüllt nicht eine Untersuchung zu einer konkreten Sitzung eines konkreten Nutzers. Die geforderte Granularität ist eine Aufzeichnung pro Inferenz, mit stabilen Identifikatoren, die die Aufzeichnung an den eingereichten Input zurückbinden. Die meisten LLM-Anwendungen produzieren heute Aufzeichnungen in dieser Granularität in ihrem primären Log; wenige tun es auf eine Weise, die eine Betreiber-Kompromittierung übersteht oder auf Anfrage an eine Aufsichtsbehörde exportiert werden kann.

Querverknüpfung. Artikel 50(1) (Designpflicht des Anbieters), Artikel 50(2) (Kennzeichnungspflicht des Anbieters) und Artikel 50(4) (Offenlegungspflicht des Nutzers) wirken zusammen. Die Offenlegung eines Nutzers muss auf ein konkret-versioniertes vorgelagertes Modell verweisen. Die Kennzeichnung des vorgelagerten Modells muss in der Antwort vorhanden sein. Die Aufzeichnung des Nutzers muss das Offenlegungs-Ereignis, den Modellaufruf und die markierte Ausgabe als eine einzige kausale Kette verknüpfen.

Ein Logging-Stack, der unabhängige Aufzeichnungen jedes Schritts produziert, sie aber nicht mit stabilen Identifikatoren verknüpft, lässt den Nutzer in der Position zurück zu sagen: „wir glauben, diese Offenlegung bezieht sich auf jene Inferenz, die wir glauben, dieses vorgelagerte Modell genutzt zu haben" — wo sie sagen können müssten: „hier ist die kryptografisch verankerte Aufzeichnung, die alle drei zusammen zeigt".

Ein praktischer 12-Wochen-Pfad

Fünfundachtzig Tage von heute reichen für die meisten Teams, um die Lücke zu den August-2026-Pflichten zu schließen — unter der Annahme, dass das Team nicht gleichzeitig die zugrundeliegende Inferenz-Plattform baut. (Für die maschinenlesbare Kennzeichnung nach Artikel 50(2) beträgt der Zeitrahmen rund dreißig Wochen bis zum 2. Dezember 2026 — andere Form, ähnliche Ingenieurarbeit.) Der Pfad:

Woche 1 — Entscheiden Sie Ihre Rolle. Wenn Sie Nutzer sind (die meisten Leser), führen Sie jede Stelle in Ihrem Produkt oder Workflow auf, an der ein LLM aufgerufen wird. Klassifizieren Sie jeden Aufruf als Artikel 50(1) (interaktiv mit Nutzer), 50(2) (Erzeugung synthetischer Inhalte), 50(3) (Emotion oder biometrische Kategorisierung), 50(4) (Deep-Fake oder Text zu Angelegenheiten von öffentlichem Interesse) — oder außerhalb des Anwendungsbereichs. Die Liste wird länger sein als erwartet.

Woche 2 — Kartieren Sie die Offenlegungsoberfläche. Dokumentieren Sie für jeden Aufruf im Anwendungsbereich, wo die Offenlegung gegenüber dem Nutzer stattfindet, in welcher Form, durch welchen Auslöser. Prüfen Sie, ob die Offenlegung tatsächlich jedem Nutzer angezeigt wird (Mobil-Clients, eingebettete Ansichten, API-Konsumenten). Finden Sie die Lücken.

Wochen 3–4 — Kartieren Sie die Nachweisoberfläche. Dokumentieren Sie für jeden Aufruf im Anwendungsbereich, welche Aufzeichnung heute produziert wird. Audit: ist die Aufzeichnung verankert? Ist sie manipulationssicher? Verknüpft sie die Offenlegung, den Modellaufruf und die Ausgabe? Wo die Antwort nein lautet, planen Sie die Behebung.

Wochen 5–8 — Setzen Sie die Nachweis-Pipeline um. Die kostengünstige Variante ist strukturiertes Logging plus periodische Verankerung (ein täglicher Merkle-Root, der irgendwo dauerhaft committet wird). Die robuste Variante ist eine signierte Quittung pro Inferenz, zur Anfragezeit in einem öffentlichen Transparency-Log verankert. Die richtige Wahl hängt vom Risikoprofil des Nutzers ab und davon, ob die Nutzung in den Anhang-III-Hochrisiko-Bereich fällt.

Wochen 9–10 — Üben Sie die Audit-Antwort. Wählen Sie fünf reale Inferenzen aus dem letzten Monat. Rekonstruieren Sie für jede: welches Modell hat sie bedient, in welcher Version, welche Offenlegung wurde dargestellt, mit welcher Ausgabe, zugeordnet zu welcher kausalen Kette. Was länger als dreißig Minuten pro Fall braucht, wird unter regulatorischem Druck scheitern.

Wochen 11–12 — Sichern Sie die Verträge. Wenn Sie von einem GPAI-Anbieter abhängen, muss Ihr Vertrag die Dokumentation nach Artikel 53, die Mitwirkung in Ihren Untersuchungen nach Artikel 74 und die technische Unterstützung für Ihre maschinenlesbare Kennzeichnung nach Artikel 50(2) abdecken. Wenn Ihr Vertrag heute „wir nutzen OpenAI für KI-Funktionen" sagt, ist er nicht ausreichend.

Die Teams, die den 2. August 2026 sauber landen, sind nicht die, die in Woche 12 angefangen haben. Es sind die, die irgendwo in diesem Kalender angefangen haben, bevor die Frist nahe genug für Panik geriet.

Wo Lucairn ins Bild passt

Das Lucairn-Gateway sitzt zwischen Ihrer Anwendung und dem vorgelagerten LLM-Anbieter. Jeder Request, der das Gateway durchläuft, erzeugt eine pro-Inferenz-Aufzeichnung, die von einem In-Process-Witness-Service mit einem Schlüssel signiert wird, den das vorgelagerte Modell nie sieht — gestempelt gegen eine öffentliche RFC-3161-Zeitstempelinstanz und in einem öffentlichen Sigstore-Rekor-Transparency-Log verankert, sodass der Inklusionsbeweis selbst zum Beweis wird, dass die Aufzeichnung im gestempelten Moment existierte.

Das adressiert drei Lücken in der Bereitschaft auf Artikel 50 direkt. Die Aufzeichnung ist pro-Inferenz, sodass Nutzer Artikel-74-Untersuchungen in der richtigen Granularität beantworten können. Die Aufzeichnung ist verankert, sodass sie eine Betreiber-Kompromittierung übersteht. Und die Aufzeichnung verknüpft das Offenlegungs-Ereignis, den Modellaufruf (mit konkreter vorgelagerter Version) und die Ausgabe, sodass die kausale Kette, die eine Aufsichtsbehörde verfolgen will, rekonstruierbar ist.

Lucairn produziert Ihre Artikel-50-Offenlegungstexte nicht für Sie. Das ist Ihre Entscheidung, Ihre Stimme, Ihre Datenschutzerklärung. Lucairn produziert die Nachweisschicht darunter — sodass die Aufzeichnung existiert, wenn die Offenlegung in Frage gestellt wird.

Wir setzen für typische Nutzer in Tagen ein. Für GPAI-Anbieter, die eine Dokumentationsinfrastruktur nach Artikel 53 oder Pipelines zur Attestierung systemischer Risiken nach Artikel 55 brauchen, ist die Arbeit umfangreicher; sprechen Sie uns an.

Weiterlesen

• [Die EU-KI-Verordnung: Vom Verordnungstext zum Deployment](/de/blog/eu-ai-act-architecture-2026) — vollständige Architektur-Übersicht einschließlich des Hochrisiko-Pfads nach Anhang III (der nun nach dem Omnibus-Paket am 2. Dezember 2027 bindend wird).
• [Artikel 12 Logging in der Praxis](/de/blog/ai-act-article-12-logging-in-practice) — der Begleitbeitrag zur Logging-Pflicht für Hochrisiko-Systeme, die mit der Nachweisschicht von Artikel 50 ineinandergreift.
• [EU-KI-Verordnung Compliance-Hub](/de/compliance/eu-ai-act#gpai) — Kontroll-für-Kontroll-Abbildung, einschließlich des Artikel-50-/GPAI-Abschnitts, den dieser Beitrag erweitert.
• [Audit-Trail für KI](/de/audit-trail-for-ai) — der Architektur-Detailbeitrag dazu, wie kryptografische Verankerung funktioniert und warum sie eine Untersuchung übersteht.
• [Compliance-Bewertung](/de/compliance/assessment) — wenn Sie eine konkrete Einschätzung brauchen, wo Ihr Deployment im Verhältnis zu den Pflichten ab dem 2. August 2026 steht, ist das der Einstieg.