# EU AI Act: Compliance-Grenzen und Betreiber-Checkliste
**Rechtsstand: 22. Juli 2026**
Diese Datei beschreibt, welche Teile des EU AI Act (Verordnung (EU) 2024/1689) dieses Projekt technisch unterstützen kann und welche Pflichten außerhalb seines Funktionsumfangs liegen. Sie ersetzt keine Prüfung des konkreten Einsatzes.
## 1. Was dieses Projekt ist
Die mitgelieferte Anwendung erzeugt deterministisch SVG-Hinweise, Erklärungsseiten und JSON-LD aus den vom Nutzer eingegebenen Angaben. Sie enthält selbst kein KI-Modell und führt keine Modellinferenz aus.
Der AI Act erfasst nur Systeme, die unter die Definition eines „AI system“ in Artikel 3 Absatz 1 fallen. Ob eine konkrete, veränderte oder erweiterte Installation diese Definition erfüllt, ist anhand der tatsächlichen technischen Funktion zu prüfen.
## 2. Dieses Projekt ist keine vollständige AI-Act-Compliance-Lösung
Der Generator unterstützt vor allem die **sichtbare und dokumentierte Offenlegung von KI-Nutzung**. Er kann insbesondere bei freiwilliger Transparenz und bei bestimmten Betreiberpflichten aus Artikel 50 Absatz 4 helfen.
Er erfüllt oder prüft **nicht automatisch**:
- die Anbieterpflicht zur technischen, maschinenlesbaren Markierung von generierten oder manipulierten Ausgaben nach Artikel 50 Absatz 2;
- die Transparenzpflicht bei direkter Mensch-KI-Interaktion nach Artikel 50 Absatz 1;
- Informationspflichten bei Emotionserkennung oder biometrischer Kategorisierung nach Artikel 50 Absatz 3;
- die Pflicht zur AI Literacy nach Artikel 4;
- Verbote nach Artikel 5;
- die Einstufung und Pflichten für Hochrisiko-KI nach Kapitel III;
- Pflichten für Anbieter von General-Purpose-AI-Modellen nach Kapitel V;
- sonstige Pflichten aus Datenschutz-, Urheber-, Verbraucher-, Medien- oder Produktsicherheitsrecht.
## 3. Artikel 50: sichtbare Offenlegung durch Betreiber
Artikel 50 gilt ab **2. August 2026**. Betreiber bestimmter generativer KI-Systeme müssen insbesondere Deepfakes und bestimmte KI-generierte oder manipulierte Texte zu Angelegenheiten von öffentlichem Interesse offenlegen.
Für solche sichtbaren Offenlegungen gilt nach Artikel 50 Absatz 5 und den Leitlinien der Kommission insbesondere:
1. Der Hinweis muss **klar und unterscheidbar** sein.
2. Er muss **spätestens bei der ersten Exposition** gegenüber der betroffenen natürlichen Person erscheinen.
3. Er muss die geltenden Anforderungen an **Barrierefreiheit** berücksichtigen.
4. Bei Deepfakes genügt eine nur maschinenlesbare Markierung des Anbieters nicht als sichtbare Betreiber-Offenlegung.
Daher gilt für die Einbettung dieses Projekts:
- den empfohlenen `embedHtml`-Baustein oder eine gleichwertige Umsetzung unmittelbar am betroffenen Inhalt platzieren;
- nicht ausschließlich im Footer, Impressum oder auf einer erst später erreichbaren Unterseite;
- sichtbaren, verständlichen Text als Bestandteil des Links bereitstellen, damit die Offenlegung nicht nur über eine Grafik wahrnehmbar ist;
- das Badge im empfohlenen Embed mit `alt=""`/`aria-hidden="true"` dekorativ behandeln, weil derselbe Bedeutungsgehalt bereits als sichtbarer Linktext vorhanden ist und sonst doppelt angesagt würde;
- bei einer alleinstehenden Badge-Grafik weiterhin einen aussagekräftigen Alternativtext bereitstellen;
- ausreichende Kontraste und ein ausreichend großes, tastaturerreichbares Linkziel sicherstellen. Der mitgelieferte Renderer wählt bei flachen Badges automatisch Schwarz/Weiß für mindestens 4,5:1 Textkontrast und korrigiert Emoji-/Icon-Farben unter 3:1.
## 4. Menschliche Prüfung und redaktionelle Kontrolle
Für bestimmte veröffentlichte KI-generierte oder manipulierte Texte zu Angelegenheiten von öffentlichem Interesse kann die Kennzeichnungspflicht nach Artikel 50 Absatz 4 entfallen, wenn die gesetzlichen Voraussetzungen tatsächlich erfüllt sind.
Die Kommission stellt klar:
- „human review“ erfordert eine bewusste inhaltliche Prüfung durch Personen mit einschlägigem Wissen und professionellem Urteil;
- „editorial control“ setzt tatsächliche inhaltliche Entscheidungsbefugnis voraus, also insbesondere die Möglichkeit, Inhalte aus sachlichen Gründen zu genehmigen, zu ändern oder abzulehnen;
- rein oberflächliche, formale oder prozedurale Prüfungen wie Rechtschreib- oder Grammatikprüfung genügen nicht;
- zusätzlich muss eine natürliche oder juristische Person die redaktionelle Verantwortung für die Veröffentlichung tragen.
Aus diesem Grund setzt der Generator seit dieser Härtung **keine menschliche oder redaktionelle Prüfung mehr automatisch voraus**. Der Nutzer muss den tatsächlich durchgeführten Prozess ausdrücklich auswählen.
Die Felder `editorialResponsibility.role`, `editorialResponsibility.name` und `editorialResponsibility.url` dienen nur der Dokumentation. Der Generator berücksichtigt eine mögliche Ausnahme nur, wenn mindestens Rolle und verantwortliche Person/Organisation ausdrücklich angegeben sind. Auch diese Dokumentation beweist nicht automatisch, dass die gesetzlichen Voraussetzungen tatsächlich vorliegen.
**Autor/Byline und redaktionelle Verantwortung sind getrennt.**`author` beschreibt die Urheberschaft bzw. Veröffentlichungs-Byline. `editorialResponsibility` beschreibt dagegen diejenige natürliche oder juristische Person, die letztlich die rechtliche redaktionelle Verantwortung für die Veröffentlichung trägt. Beides kann zusammenfallen, muss es aber nicht.
## 5. Besondere Ausnahme für gesetzlich autorisierte Strafverfolgungsnutzung
Artikel 50 Absatz 4 enthält für Deepfakes und Public-Interest-Texte eine besondere Ausnahme, soweit die konkrete Nutzung **gesetzlich zur Aufdeckung, Verhütung, Ermittlung oder Verfolgung von Straftaten autorisiert** ist.
Schema 1.3 kann diese Selbsteinordnung in `legalContext.lawEnforcementAuthorization` (`yes`, `no`, `unsure`) dokumentieren. Das Feld erscheint im Generator nur, wenn zuvor eine Deepfake- oder Public-Interest-Konstellation ausgewählt wurde. Ein bloßer Behördenstatus genügt nicht als Grundlage für „yes“; die konkrete gesetzliche Autorisierung des konkreten Einsatzes sollte intern nachvollziehbar dokumentiert sein. Bei `unsure` warnt der Generator davor, die Ausnahme ohne weitere Prüfung zugrunde zu legen.
## 6. Beschwerde-/Rückmeldestelle: Best Practice, nicht Art.-50-Pflicht
Eine eigene interne Beschwerde- oder Rückmeldestelle für jeden gekennzeichneten Inhalt ist **keine allgemeine Pflicht aus Artikel 50**. Das Projekt bietet `complaintsContact` deshalb ausdrücklich als Best-Practice-Metadatum an und trennt es von rechtlich erforderlichen Feldern.
Daneben enthält der AI Act in Artikel 85 ein eigenständiges Recht, bei einer Marktüberwachungsbehörde Beschwerde über einen Verstoß gegen den AI Act einzulegen. Eine freiwillige interne Anlaufstelle des Publishers ersetzt dieses gesetzliche Beschwerderecht nicht. Zusätzlich können Medien-, Verbraucher-, Plattform-, Datenschutz- oder andere Fachregeln eigene Kontakt- oder Beschwerdepflichten begründen.
## 7. Mögliche Konsequenzen bei Verstößen gegen Artikel 50
Artikel 99 Absatz 4 ordnet Verstöße gegen die Transparenzpflichten des Artikels 50 grundsätzlich einem Bußgeldrahmen von **bis zu 15 Mio. EUR** oder – bei Unternehmen –**bis zu 3 % des weltweiten Jahresgesamtumsatzes des vorangegangenen Geschäftsjahres** zu. Für KMU einschließlich Start-ups enthält Artikel 99 Absatz 6 eine besondere Deckelungsregel; außerdem müssen Art, Schwere, Dauer, Verantwortungsgrad und weitere Umstände des Einzelfalls berücksichtigt werden.
Der Generator zeigt diesen Rahmen als Risikohinweis, aber **nicht als Prognose einer konkreten Geldbuße**. Ob ein Verstoß vorliegt, welche Maßnahmen angemessen sind und ob bzw. in welcher Höhe eine Geldbuße verhängt wird, ist Sache der zuständigen Behörden bzw. Gerichte.
## 8. Artikel 50 Absatz 2: JSON-LD ist kein Ersatz für Provider-Marking
Anbieter generativer KI-Systeme müssen in den erfassten Fällen dafür sorgen, dass generierte oder manipulierte Inhalte maschinenlesbar markiert und als künstlich generiert oder manipuliert erkennbar sind. Nach Artikel 50 Absatz 2 müssen die technischen Lösungen wirksam, interoperabel, robust und zuverlässig sein, soweit dies technisch machbar ist.
Artikel 50 Absatz 2 nimmt Systeme aus, die lediglich Standard-Bearbeitungsfunktionen ausführen oder die vom Betreiber bereitgestellten Eingabedaten bzw. deren Semantik nicht wesentlich verändern. Ob diese Ausnahme tatsächlich greift, hängt von der konkreten Funktion und Veränderungswirkung ab; der sichtbare Generator kann diese technische Anbieterfrage nicht automatisch entscheiden.
Das von diesem Projekt erzeugte **JSON-LD ist ergänzende Dokumentation**. Es ist nicht als Ersatz für die technische Markierung gedacht, die der Anbieter des generativen KI-Systems in oder an der Ausgabe implementieren muss. Der Endpunkt `/v1/render` kann es über `embedHtml` direkt zusammen mit der sichtbaren Offenlegung als `<script type="application/ld+json">` ausgeben; dadurch lässt sich die menschlich sichtbare und die ergänzende strukturierte Information in einem Integrationsschritt einbauen, ohne beide Pflichten begrifflich gleichzusetzen.
Wer selbst Anbieter eines generativen KI-Systems im Sinne des AI Act ist, muss deshalb zusätzlich eine geeignete Provider-Marking-Lösung umsetzen und dokumentieren. Der von der Kommission positiv bewertete Code of Practice kann hierfür als freiwilliger Compliance-Rahmen genutzt werden.
Artikel 4 gilt bereits seit **2. Februar 2025**. Anbieter und Betreiber von KI-Systemen müssen nach besten Kräften Maßnahmen treffen, um ein ausreichendes Maß an AI Literacy bei Mitarbeitenden und sonstigen Personen sicherzustellen, die in ihrem Auftrag mit Betrieb oder Nutzung von KI-Systemen befasst sind.
Ein Badge oder eine Veröffentlichungserklärung erfüllt diese Organisationspflicht nicht. Betreiber sollten mindestens dokumentieren:
- welche KI-Systeme eingesetzt werden;
- welche Rollen sie bedienen;
- welche Kenntnisse und Schulungen erforderlich sind;
- welche internen Regeln für Prüfung, Freigabe und Eskalation gelten;
- wann Schulungen oder Richtlinien zuletzt aktualisiert wurden.
Nach Artikel 113 gilt der AI Act grundsätzlich ab 2. August 2026; einzelne Teile gelten bereits früher. Insbesondere gelten Kapitel I und II, einschließlich Artikel 4 und der Verbote des Artikels 5, seit 2. Februar 2025.
Für Artikel 50 beginnen die Transparenzpflichten am 2. August 2026. Die Kommission weist für bestimmte bereits vor diesem Datum in Verkehr gebrachte generative KI-Systeme auf eine begrenzte Übergangsregel für die Anbieter-Markierung nach Artikel 50 Absatz 2 bis 2. Dezember 2026 hin.
Wenn ein Inhalt **möglicherweise** unter Artikel 50 Absatz 4 fällt, ist die rechtlich defensivere Konfiguration:
- KI-Nutzung wahrheitsgemäß als `partial`, `mostly` oder `full` angeben;
- die konkrete Tätigkeit angeben;
-`humanReview` nur dann auf `editorial` oder `expert` setzen, wenn eine tatsächlich substanzielle inhaltliche Prüfung stattgefunden hat;
- die redaktionell verantwortliche Person oder Organisation dokumentieren, wenn dies zutrifft;
- einen sichtbaren textlichen Hinweis oder ein verständliches Standard-Badge spätestens bei der ersten Exposition platzieren;
- das Emoji nicht als alleinige gesetzliche Kennzeichnung verwenden;
- das JSON-LD nur als zusätzliche Dokumentation behandeln.
Bei Zweifeln über die Ausnahme wegen menschlicher Prüfung ist eine **zusätzliche Offenlegung regelmäßig die risikoärmere technische Entscheidung**, solange dadurch keine anderen rechtlichen Pflichten verletzt werden.
## 13. Strukturierter rechtlicher Kontext in Schema 1.3
Schema 1.3 erweitert die rechtliche Selbsteinordnung und trennt sie von allgemeinen Veröffentlichungsmetadaten.
-`outputDate`: Datum des betroffenen KI-Outputs für die zeitliche Einordnung;
-`deepfakeAssessment`: `yes`, `no`, `unsure` für die Deepfake-Einordnung, wenn KI-beteiligte Bild-/Audio-/Videoinhalte vorliegen;
-`publicInterestAssessment`: `yes`, `no`, `unsure` für die Public-Interest-Text-Einordnung, wenn KI-beteiligter Text vorliegt;
-`creativeWorkAssessment`: `yes`, `no`, `unsure` für die kreative/satirische/fiktionale Sonderform, wenn zuvor ein Deepfake bejaht wurde;
-`lawEnforcementAuthorization`: `yes`, `no`, `unsure` für die besondere Ausnahme des Art. 50 Abs. 4.
Daneben stehen getrennt:
-`author`: Autor/in bzw. Byline und optionale Profil-URL;
-`editorialResponsibility`: Rolle, verantwortliche Person/Organisation und optionale Nachweis-/Impressums-URL;
-`complaintsContact`: freiwillige Beschwerde-/Feedback-Anlaufstelle mit Name sowie E-Mail und/oder URL.
### Abhängigkeitslogik im Generator
Der Generator zeigt Felder nur in sachlich passenden Konstellationen:
1.**Keine KI-Beteiligung:** rechtlicher Art.-50-Kontext, Review- und Tätigkeitsfelder werden ausgeblendet bzw. nicht übertragen.
2.**Rolle und Nutzungskontext zuerst:** bei KI-Beteiligung werden zunächst AI-Act-Rolle und beruflicher/persönlicher Nutzungskontext verlangt. Bei rein persönlicher nicht-beruflicher Nutzung oder ausschließlich `provider`-seitiger Rolle werden die deployerspezifischen Inhaltsfragen nicht eingeblendet.
3.**KI-Bild/Audio/Video:** erst danach wird eine verpflichtende `yes`/`no`/`unsure`-Deepfake-Prüfung sichtbar; nach `yes`/`unsure` wird zunächst eine mögliche Strafverfolgungs-Ausnahme geprüft. Die kreative/satirische/fiktionale Sonderform erscheint bei bestätigtem Deepfake erst, wenn diese Ausnahme nicht als einschlägig angegeben wurde.
4.**KI-Text:** erst danach wird eine verpflichtende `yes`/`no`/`unsure`-Public-Interest-Prüfung sichtbar.
5.**Deepfake/Public-Interest = `yes` oder `unsure`:** die Frage nach gesetzlich autorisierter Strafverfolgungsnutzung wird sichtbar.
6.**Public-Interest + substanzielle Prüfung:** Felder zur redaktionellen Verantwortung werden eingeblendet, sofern nicht bereits die Strafverfolgungs-Ausnahme angegeben wurde und die Nutzung nicht rein persönlich bzw. ausschließlich providerseitig ist.
7.**Autor/Byline:** erscheint nur bei KI-Beteiligung in artikelförmiger bzw. textbezogener Nutzung; eine Profil-URL erst nach Eingabe eines Namens.
8.**Beschwerde-/Rückmeldestelle:** erscheint nur in rechtlich sensiblen Deepfake-/Public-Interest-Konstellationen und ist als Best Practice gekennzeichnet.
9.**Unvollständige Pflichtfragen:** solange eine aktuell erforderliche Selbsteinordnung leer ist, gibt die Vorschau bewusst noch kein „Pflicht / keine Pflicht“-Ergebnis aus.
### Plausibilitäts- und Rechtswarnungen
Der Generator warnt unter anderem bei:
- nur formaler (`basic`) Prüfung in einer Public-Interest-Konstellation;
- substantieller Prüfung ohne vollständig benannte redaktionelle Verantwortung;
- Provider-Rolle, weil ein Veröffentlichungs-Badge Art. 50 Abs. 2 nicht ersetzt;
- rein persönlicher, nicht beruflicher Nutzung;
- Output-Datum vor dem 2. August 2026;
- unklarer Strafverfolgungs-Autorisierung;
- widersprüchlicher Kombination von Deepfake/Public-Interest und den strukturierten Inhaltsbestandteilen;
Das System formuliert bewusst vorsichtig („spricht vieles dafür“, „kann in Betracht kommen“) und gibt keine verbindliche Rechtsentscheidung aus. Bei Grenzfällen sollte die tatsächliche Rechtslage des konkreten Einsatzes individuell geprüft werden.
Diese Datei beschreibt die mitgelieferten technischen Schutzmaßnahmen und die Punkte, die ein Betreiber vor einer öffentlichen Bereitstellung selbst prüfen und vervollständigen muss. Sie ersetzt keine Rechtsberatung für den konkreten Einzelfall.
## 1. Vor dem ersten öffentlichen Start
1.`.env.example` nach `.env` kopieren und alle `REPLACE_ME`-Werte durch zutreffende Angaben ersetzen.
2.`LEGAL_STRICT=true` aktiv lassen. Der Dienst verweigert dann den Start, wenn Kernangaben fehlen.
3. Impressum, Datenschutzerklärung und Barrierefreiheitserklärung im fertig deployten System prüfen:
-`/impressum`
-`/datenschutz`
-`/barrierefreiheit`
4. Tatsächliche Hosting-, Proxy-, CDN-, DNS-, Logging-, Backup-, Monitoring- und Lizenzdienste mit der Datenschutzerklärung abgleichen.
5. Bei Verbraucherverträgen prüfen, welche Angaben nach dem Verbraucherstreitbeilegungsgesetz erforderlich sind. Die frühere EU-OS-Plattform wurde eingestellt; ein alter OS-Link sollte nicht übernommen werden.
6. Bei journalistisch-redaktionellen Angeboten prüfen, ob ein Verantwortlicher nach § 18 Abs. 2 MStV benannt werden muss.
7. Bei Angeboten an Verbraucher prüfen, ob das BFSG und die BFSGV anwendbar sind. Eine bloße Selbsterklärung ersetzt keinen Accessibility-Audit.
## 2. Anbieterkennzeichnung
Die Vorlage deckt typische Felder für § 5 DDG und § 18 MStV ab. Je nach Betreiber können weitere Angaben erforderlich sein, etwa:
- Rechtsform und Vertretungsberechtigte;
- Register, Registernummer und Registergericht;
- Umsatzsteuer-Identifikationsnummer;
- Aufsichtsbehörde und berufsrechtliche Angaben;
- redaktionell Verantwortliche mit Name und Anschrift;
Die ausgelieferte Weboberfläche verwendet keine Cookies, kein Tracking und keine Browser-Speicher wie Local Storage. Das allein macht einen Betrieb nicht automatisch datenschutzkonform. Relevant sind insbesondere die tatsächlichen Infrastruktur-Logs und zusätzlich eingebundene Dienste.
Technischer Standardzustand:
- kein Datenbank- oder Session-Speicher für Generator-Eingaben;
- keine Query-Strings in den Anwendungslogs;
- keine Client-IP in den Anwendungslogs, solange `LOG_CLIENT_IP=false` bleibt;
- URL-Parameter können dennoch in Browser-Verläufen, Reverse-Proxy-, CDN- oder Hosting-Logs erscheinen;
- Hybrid- und Online-Lizenzmodi kommunizieren mit dem konfigurierten Lizenzserver;
- öffentliche Erklärungs-URLs dürfen keine vertraulichen oder unnötigen personenbezogenen Daten enthalten.
Der Betreiber muss insbesondere festlegen und umsetzen:
- Rechtsgrundlagen und Zwecke;
- Empfänger und Auftragsverarbeiter;
- Lösch- und Aufbewahrungsfristen;
- Drittlandübermittlungen;
- technisch-organisatorische Maßnahmen;
- Prozesse für Betroffenenrechte und Datenschutzvorfälle.
Die Anwendung nutzt semantische Formulare und Tabellen, sichtbare Fokuszustände, responsive Layouts und Textalternativen. Sie erhebt ohne gesonderten Audit keinen Anspruch auf vollständige WCAG- oder EN-301-549-Konformität.
Für ein erfasstes Verbraucherangebot sind unter anderem zu prüfen:
- Tastaturbedienung und Fokusreihenfolge;
- Kontraste, Zoom und Reflow;
- verständliche Fehlermeldungen;
- Screenreader-Ausgabe;
- sichtbarer Text neben eingebetteten Badges; bei dekorativen Badges im empfohlenen Embed `alt=""`, bei alleinstehenden Badge-Grafiken ein aussagekräftiger Alternativtext;
- Link-/Klickzielgröße und sichtbare Tastaturfokussierung;
- Barrierefreiheit des vollständigen Bestell- oder Vertragspfads;
- gesetzlich verlangte Informationen zur Barrierefreiheit.
- Backup-, Restore- und Incident-Response-Verfahren;
- Überwachung ohne unnötige personenbezogene Telemetrie.
## 6. Reverse Proxy
`TRUST_PROXY=true` darf nur zusammen mit `TRUSTED_PROXY_CIDRS` verwendet werden. Trage ausschließlich Netze ein, aus denen dein kontrollierter Reverse Proxy die Anwendung tatsächlich erreicht. Andernfalls könnten Clients weitergeleitete IP-Header vortäuschen.
Beispiel für einen ausschließlich lokalen Proxy:
```env
TRUST_PROXY=true
TRUSTED_PROXY_CIDRS=127.0.0.1/32,::1/128
```
Docker-, Kubernetes- oder Cloud-Netze unterscheiden sich je Umgebung und dürfen nicht pauschal kopiert werden.
## 7. Metriken
`/metrics` ist standardmäßig nicht registriert. Für eine Aktivierung:
```env
METRICS_ENABLED=true
METRICS_TOKEN_FILE=/run/secrets/metrics-token
```
Der Bearer-Token schützt den Endpunkt auf Anwendungsebene. Zusätzlich sollte der Endpunkt nicht über den öffentlichen Ingress erreichbar sein.
## 8. KI-Transparenz und EU AI Act
Der Standard unterstützt freiwillige Dokumentation und bestimmte Transparenz-Workflows, insbesondere sichtbare Offenlegungen. Er entscheidet nicht automatisch, ob Artikel 50 des AI Act auf einen konkreten Inhalt anwendbar ist. Die offiziellen Transparenzleitlinien der Europäischen Kommission wurden am 20. Juli 2026 veröffentlicht; Artikel 50 gilt ab dem 2. August 2026.
Wichtige Grenzen:
- Presets unterstellen keine menschliche oder redaktionelle Prüfung mehr. Ein solcher Prozess muss ausdrücklich angegeben werden.
- Eine bloß formale Prüfung wie Rechtschreibung oder Grammatik ist nach den Kommissionsleitlinien keine substantielle menschliche Prüfung oder redaktionelle Kontrolle im Sinne der Ausnahme für bestimmte Texte nach Artikel 50 Absatz 4.
- Ein sichtbarer Hinweis muss bei einer einschlägigen Pflicht klar und unterscheidbar spätestens bei der ersten Exposition erscheinen.
- Die Emoji-Variante ist nur ein kompakter Zusatz und sollte bei einer gesetzlichen Kennzeichnung nicht ohne verständlichen Text eingesetzt werden.
- Das erzeugte JSON-LD ist ergänzende Dokumentation und kein automatischer Ersatz für die Provider-Markierung nach Artikel 50 Absatz 2.
- Der AI Act enthält weitere Pflichten außerhalb dieses Projekts, unter anderem AI Literacy nach Artikel 4 sowie gegebenenfalls Verbote, Hochrisiko- oder GPAI-Pflichten.
Siehe die ausführliche Checkliste in [`EU-AI-ACT-COMPLIANCE.md`](EU-AI-ACT-COMPLIANCE.md).
- AI Act: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
