This commit is contained in:
@@ -0,0 +1,52 @@
|
||||
# Article 50 Decision Support
|
||||
|
||||
Die Anwendung bildet Artikel 50 des EU AI Act nicht als binäre „compliant / non-compliant“-Entscheidung ab. Sie erfasst stattdessen Tatsachen und erzeugt daraus eine konservative, nicht bindende technische Einordnung.
|
||||
|
||||
## Erfasste Tatsachen
|
||||
|
||||
`regulatoryContext` kann enthalten:
|
||||
|
||||
```json
|
||||
{
|
||||
"framework": "EU-AI-Act-Article-50",
|
||||
"publicInterestText": true,
|
||||
"deepfake": false,
|
||||
"artisticCreativeSatiricalFictional": false,
|
||||
"substantialHumanReview": true,
|
||||
"editorialResponsibilityConfirmed": true,
|
||||
"firstExposureDisclosure": true,
|
||||
"accessibilityConsidered": true
|
||||
}
|
||||
```
|
||||
|
||||
Zusätzlich kann `editorialResponsibility` Name und URL der verantwortlichen Person oder Organisation dokumentieren.
|
||||
|
||||
## Ergebnis-Codes
|
||||
|
||||
- `not_assessed` — kein regulatorischer Kontext angegeben;
|
||||
- `voluntary_transparency` — kein typischer Deepfake-/Public-Interest-Textfall markiert;
|
||||
- `deepfake_disclosure_relevant` — Deepfake-/realitätsähnlicher Manipulationskontext angegeben;
|
||||
- `public_interest_text_disclosure_relevant` — Text zu öffentlichem Interesse, Ausnahmevoraussetzungen nicht vollständig bestätigt;
|
||||
- `public_interest_text_possible_exemption` — substanzielle menschliche Prüfung/redaktionelle Kontrolle **und** redaktionelle Verantwortung bestätigt;
|
||||
- `multiple_article50_contexts` — mehrere regulatorische Kontexte (z. B. Deepfake-Bild und Public-Interest-Text) liegen gleichzeitig vor. Die einzelnen Befunde bleiben zusätzlich in `findings` erhalten.
|
||||
|
||||
Zusätzliche Warnungen betreffen insbesondere:
|
||||
|
||||
- nicht bestätigte Offenlegung bei erster Exposition;
|
||||
- nicht bestätigte Barrierefreiheitsberücksichtigung;
|
||||
- fehlende redaktionelle Verantwortung trotz angegebener substantieller Prüfung;
|
||||
- angemessene Offenlegungsform bei offensichtlich künstlerischen, kreativen, satirischen oder fiktionalen Werken.
|
||||
|
||||
## Sichtbares Badge
|
||||
|
||||
Bei einem markierten Deepfake- oder relevanten Public-Interest-Textfall verwendet die Standarddarstellung ein deutlicheres amberfarbenes Badge und eine explizitere Beschriftung. Die ausführliche Seite bleibt die zweite Informationsebene.
|
||||
|
||||
## Rechtliche Grenze
|
||||
|
||||
Die Funktion ist eine technische Entscheidungshilfe. Sie ersetzt weder die Prüfung des konkreten Anwendungsfalls noch andere Pflichten des EU AI Act oder sonstiges Unions-/nationales Recht.
|
||||
|
||||
Offizielle Ausgangspunkte:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
- https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
|
||||
- https://digital-strategy.ec.europa.eu/en/policies/guidelines-transparency-ai-generated-content
|
||||
@@ -1,6 +1,6 @@
|
||||
# Mehrsprachige Hintergrundseite
|
||||
|
||||
Version 1.8.0 stellt unter `/background` eine eigenständige Informationsseite zur KI-Kennzeichnung und zu Artikel 50 des EU AI Act bereit.
|
||||
Version 2.0.0 stellt unter `/background` eine eigenständige Informationsseite zur KI-Kennzeichnung und zu Artikel 50 des EU AI Act bereit.
|
||||
|
||||
## Routen
|
||||
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
# Bulk API
|
||||
|
||||
Der Bulk-Dienst ist für Publisher, CMS-Integrationen, Agenturen und andere Server-to-Server-Workflows gedacht.
|
||||
|
||||
## Capability
|
||||
|
||||
Die Runtime-Lizenz benötigt:
|
||||
|
||||
```text
|
||||
bulk_api
|
||||
```
|
||||
|
||||
Optional kann die Lizenzplattform ein Limit liefern:
|
||||
|
||||
```text
|
||||
bulk_items=250
|
||||
```
|
||||
|
||||
Der effektive Grenzwert ist der kleinere Wert aus Lizenzlimit und `BULK_MAX_ITEMS`.
|
||||
|
||||
## Dedizierter Container
|
||||
|
||||
`Dockerfile.bulk` verwendet dasselbe getestete Go-Binary, setzt aber sichere Betriebsdefaults:
|
||||
|
||||
```text
|
||||
SERVICE_MODE=bulk
|
||||
REQUIRE_LICENSE=true
|
||||
BULK_REQUIRE_API_KEY=true
|
||||
API_ALLOWED_ORIGIN=
|
||||
```
|
||||
|
||||
Damit enthält die Angriffsoberfläche keine Generator-, Produkt- oder Hintergrundseite.
|
||||
|
||||
## Authentifizierung
|
||||
|
||||
Bei aktivierter API-Key-Pflicht:
|
||||
|
||||
```http
|
||||
Authorization: Bearer <key>
|
||||
```
|
||||
|
||||
oder:
|
||||
|
||||
```http
|
||||
X-API-Key: <key>
|
||||
```
|
||||
|
||||
Der Schlüssel kann über `BULK_API_KEY_FILE` aus einem Container-/Kubernetes-Secret gelesen werden.
|
||||
|
||||
## Anfrage
|
||||
|
||||
```http
|
||||
POST /v1/bulk/declarations
|
||||
Content-Type: application/json
|
||||
Authorization: Bearer ...
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"items": [
|
||||
{
|
||||
"id": "post-1001",
|
||||
"parameters": {
|
||||
"mode": "article",
|
||||
"lang": "de",
|
||||
"textExtent": "none",
|
||||
"textReview": "none",
|
||||
"coverImageExtent": "full",
|
||||
"coverImageReview": "editorial",
|
||||
"researchExtent": "assisted",
|
||||
"researchReview": "expert",
|
||||
"assurance": "technicallyRecorded"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Jedes Element wird unabhängig verarbeitet. Ein fachlich fehlerhaftes Element führt zu einem Item-Fehler, ohne die übrigen Elemente zu verwerfen.
|
||||
|
||||
## Betriebsgrenzen
|
||||
|
||||
- `BULK_MAX_ITEMS` begrenzt Items pro Request;
|
||||
- `BULK_MAX_BODY_BYTES` begrenzt die Requestgröße;
|
||||
- ein Lizenzlimit `bulk_items` kann die Itemzahl weiter reduzieren;
|
||||
- der Dedicated Container wird ohne gültige `bulk_api`-Capability nicht ready;
|
||||
- bei `REQUIRE_LICENSE=true` werden fachliche Requests ohne gültige Runtime-Lizenz mit 503 blockiert;
|
||||
- Prometheus exportiert Bulk-Request-, Item- und Failure-Counter.
|
||||
|
||||
## Netzwerk
|
||||
|
||||
Der Bulk-Service sollte standardmäßig intern betrieben werden. Die Kubernetes-Vorlage liefert nur einen `ClusterIP`-Service und bewusst keinen Ingress. Bei externer Veröffentlichung empfiehlt sich zusätzlich ein API-Gateway mit TLS, Rate-Limiting und organisationsspezifischer Authentifizierung.
|
||||
|
||||
## Getrennte Runtime- und Ausgabe-URL
|
||||
|
||||
Bei einer separaten Bulk-Instanz kann `BASE_URL` die interne bzw. lizenzgebundene Adresse des Bulk-Dienstes sein, während `OUTPUT_BASE_URL` auf die öffentliche Full-/API-Instanz zeigt:
|
||||
|
||||
```env
|
||||
BASE_URL=http://ai-disclosure-bulk
|
||||
OUTPUT_BASE_URL=https://ai.example.org
|
||||
```
|
||||
|
||||
Dadurch enthalten Bulk-Ergebnisse nutzbare öffentliche Deklarations-, Manifest- und Badge-URLs.
|
||||
@@ -0,0 +1,88 @@
|
||||
# Commercial Deployment
|
||||
|
||||
Diese Datei beschreibt die technische Härtung der offiziellen, lizenzierten Distribution. Sie ist keine Vertrags- oder Lizenzvorlage.
|
||||
|
||||
## Runtime-Secrets
|
||||
|
||||
Bevorzugt werden Datei-Secrets:
|
||||
|
||||
```env
|
||||
LICENSE_TOKEN_FILE=/run/secrets/license/token
|
||||
BULK_API_KEY_FILE=/run/secrets/bulk/key
|
||||
```
|
||||
|
||||
statt Secrets direkt in Prozesslisten, Compose-Dateien oder Git-Repositories zu hinterlegen.
|
||||
|
||||
## Lizenzmodi
|
||||
|
||||
- `offline`: vollständig lokale Signaturprüfung;
|
||||
- `hybrid`: zentrale Prüfung mit signiertem Lease-Cache und Offline-Grace-Periode;
|
||||
- `online`: aktuelle zentrale Prüfung erforderlich.
|
||||
|
||||
Für hochverfügbare Publisher-Installationen ist `hybrid` meist der geeignetste technische Kompromiss. Für einen streng kontrollierten, zentral widerrufbaren Dienst kann `online` sinnvoll sein.
|
||||
|
||||
## Full-/API-Container
|
||||
|
||||
Ein lizenziertes Full-Deployment kann beispielsweise setzen:
|
||||
|
||||
```env
|
||||
REQUIRE_LICENSE=true
|
||||
LICENSE_MODE=hybrid
|
||||
WHITE_LABEL=true
|
||||
```
|
||||
|
||||
`WHITE_LABEL=true` wirkt nur mit der Capability `white_label`.
|
||||
|
||||
## Bulk
|
||||
|
||||
Der Bulk-Dienst sollte separat skaliert werden. Er benötigt:
|
||||
|
||||
```text
|
||||
bulk_api
|
||||
```
|
||||
|
||||
und sollte mit `BULK_REQUIRE_API_KEY=true` betrieben werden. Das mitgelieferte `Dockerfile.bulk` erzwingt diese Defaults bereits.
|
||||
|
||||
## Kubernetes
|
||||
|
||||
`deploy/kubernetes-bulk.yaml` enthält:
|
||||
|
||||
- 3 Replikate;
|
||||
- Rolling Update ohne geplante Unterbrechung;
|
||||
- PodDisruptionBudget;
|
||||
- HPA;
|
||||
- Topology Spread;
|
||||
- non-root;
|
||||
- read-only root filesystem;
|
||||
- seccomp `RuntimeDefault`;
|
||||
- keine Linux-Capabilities;
|
||||
- deaktiviertes ServiceAccount-Token;
|
||||
- Lizenz- und API-Key-Secrets als Dateien;
|
||||
- internen ClusterIP-Service;
|
||||
- keinen öffentlichen Ingress.
|
||||
|
||||
## CORS
|
||||
|
||||
`API_ALLOWED_ORIGIN=*` ist für offen konsumierbare Badge-/Manifest-APIs bequem. Für interne kommerzielle APIs kann CORS vollständig deaktiviert werden:
|
||||
|
||||
```env
|
||||
API_ALLOWED_ORIGIN=
|
||||
```
|
||||
|
||||
oder auf einen kontrollierten Origin beschränkt werden.
|
||||
|
||||
## Observability
|
||||
|
||||
- `X-Request-ID` wird übernommen oder erzeugt;
|
||||
- Requests werden strukturiert als JSON protokolliert;
|
||||
- `/metrics` liefert Prometheus-Metriken;
|
||||
- `/healthz` ist reine Liveness;
|
||||
- `/readyz` berücksichtigt bei Bulk die Lizenz-Capability und die notwendige API-Key-Konfiguration.
|
||||
|
||||
## Supply Chain
|
||||
|
||||
Die GitHub-Actions-Vorlage baut Full- und Bulk-Images für amd64/arm64, erzeugt BuildKit-Provenance und SBOMs und signiert den veröffentlichten Multi-Arch-Digest keyless mit Sigstore/Cosign über GitHub OIDC. Produktive Deployments sollten freigegebene Digests statt ausschließlich `latest` verwenden und die Signatur vor dem Rollout prüfen. Siehe [`SUPPLY-CHAIN.md`](SUPPLY-CHAIN.md).
|
||||
|
||||
## Getrennte Bulk-Topologie
|
||||
|
||||
In einer professionellen Topologie sollte der interne Bulk-Dienst `BASE_URL` für seine eigene Instanz-/Domainbindung verwenden und `OUTPUT_BASE_URL` auf die öffentlich erreichbare Deklarationsinstanz setzen. So bleiben erzeugte Links gültig, obwohl `SERVICE_MODE=bulk` selbst keine HTML-Deklarationen oder Badge-Endpunkte bereitstellt.
|
||||
@@ -1,229 +0,0 @@
|
||||
# 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.
|
||||
|
||||
Offizielle Quelle:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3
|
||||
|
||||
## 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:
|
||||
|
||||
- Badge oder Klartext unmittelbar am betroffenen Inhalt platzieren;
|
||||
- nicht ausschließlich im Footer, Impressum oder auf einer erst später erreichbaren Unterseite;
|
||||
- aussagekräftigen Alternativtext verwenden;
|
||||
- bei der quadratischen Emoji-Variante zusätzlich einen unmittelbar verständlichen Text oder eine gleichwertig eindeutige sichtbare Kennzeichnung verwenden.
|
||||
|
||||
Offizielle Quellen:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
- https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
|
||||
- https://digital-strategy.ec.europa.eu/en/policies/guidelines-transparency-ai-generated-content
|
||||
|
||||
## 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.
|
||||
|
||||
Offizielle Quelle:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
|
||||
## 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.
|
||||
|
||||
Offizielle Quellen:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-85
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
|
||||
## 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.
|
||||
|
||||
Offizielle Quelle:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
Offizielle Quellen:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
- https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
|
||||
- https://digital-strategy.ec.europa.eu/en/library/commission-opinion-assessment-code-practice-transparency-ai-generated-content
|
||||
|
||||
## 9. Artikel 4: AI Literacy
|
||||
|
||||
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.
|
||||
|
||||
Offizielle Quelle:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4
|
||||
|
||||
## 10. Risiko- und Rollenprüfung vor Produktivnutzung
|
||||
|
||||
Vor dem Einsatz sollte die Organisation dokumentieren:
|
||||
|
||||
1. Ist die eingesetzte Software überhaupt ein KI-System im Sinne von Artikel 3 Absatz 1?
|
||||
2. Welche Rolle liegt vor: Anbieter, Betreiber, Importeur, Distributor oder Produkthersteller?
|
||||
3. Fällt das konkrete KI-System unter ein Verbot des Artikels 5?
|
||||
4. Ist es ein Hochrisiko-KI-System nach Artikel 6 bzw. Anhang III?
|
||||
5. Handelt es sich um ein General-Purpose-AI-Modell oder ein darauf basierendes System mit zusätzlichen Pflichten?
|
||||
6. Greift eine Transparenzpflicht aus Artikel 50?
|
||||
7. Welche anderen Rechtsgebiete sind zusätzlich betroffen, insbesondere DSGVO, Urheberrecht, Verbraucher- und Medienrecht?
|
||||
|
||||
Offizielle Einstiegsquellen:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-2
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-5
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
|
||||
|
||||
## 11. Zeitlicher Stand
|
||||
|
||||
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.
|
||||
|
||||
Offizielle Quellen:
|
||||
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113
|
||||
- https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
|
||||
- https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
|
||||
|
||||
## 12. Praktische Mindestregel für dieses Projekt
|
||||
|
||||
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.
|
||||
|
||||
`legalContext` unterstützt:
|
||||
|
||||
- `categories`: `deepfake`, `publicInterestText`, `artisticCreativeSatiricalFictional`, `otherVoluntary`;
|
||||
- `actorRole`: `deployer`, `provider`, `both`, `unsure`;
|
||||
- `useContext`: `professional`, `personalNonProfessional`, `unsure`;
|
||||
- `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;
|
||||
- unvollständiger freiwilliger Beschwerde-/Rückmeldestelle.
|
||||
|
||||
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.
|
||||
@@ -1,101 +0,0 @@
|
||||
# EU AI Act Review – Ergänzung vom 21.07.2026
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Die zusätzlichen Anforderungen wurden in Version 1.6.3 / Declaration Schema 1.2 aufgenommen. Das Projekt trennt nun ausdrücklich zwischen freiwilliger KI-Transparenz und einem vom Nutzer selbst angegebenen rechtlichen Kontext für Artikel 50.
|
||||
|
||||
Eine Nutzung des Standards allein begründet weiterhin keine vollständige EU-AI-Act-Konformität. Die konkrete Rolle (Provider/Deployer), das eingesetzte KI-System, der Inhalt, der Veröffentlichungskontext sowie weitere Pflichten des AI Act müssen separat geprüft werden.
|
||||
|
||||
## Neu aufgenommen
|
||||
|
||||
### 1. Strukturierter rechtlicher Kontext
|
||||
|
||||
`legalContext.categories` unterstützt:
|
||||
|
||||
- `deepfake`
|
||||
- `publicInterestText`
|
||||
- `artisticCreativeSatiricalFictional`
|
||||
- `otherVoluntary`
|
||||
|
||||
Die Angaben sind als Selbsteinordnung konzipiert und nicht als automatische rechtliche Subsumtion.
|
||||
|
||||
### 2. Deepfake-Abgrenzung
|
||||
|
||||
Der Generator erklärt, dass nicht jedes KI-generierte Bild ein Deepfake ist. Die Kategorie ist für KI-generierte oder manipulierte Bild-, Audio- oder Videoinhalte vorgesehen, die bestehenden oder plausibel existierenden Personen, Objekten, Orten, Entitäten oder Ereignissen ähneln und fälschlich authentisch oder wahr erscheinen können.
|
||||
|
||||
### 3. Texte zu Angelegenheiten von öffentlichem Interesse
|
||||
|
||||
Für `publicInterestText` berücksichtigt die vorsichtige Einschätzung:
|
||||
|
||||
- ob eine substanzielle menschliche Prüfung oder redaktionelle Kontrolle dokumentiert wurde (`editorial` oder `expert`), und
|
||||
- ob eine redaktionell verantwortliche natürliche oder juristische Person ausdrücklich benannt wurde.
|
||||
|
||||
Formale Prüfung (`basic`) wird nicht als ausreichende inhaltliche Prüfung behandelt.
|
||||
|
||||
### 4. Redaktionelle Verantwortung
|
||||
|
||||
Die Verantwortung wird nun expliziter gespeichert:
|
||||
|
||||
```json
|
||||
{
|
||||
"editorialResponsibility": {
|
||||
"assumed": true,
|
||||
"role": "publisher",
|
||||
"name": "Beispielredaktion",
|
||||
"url": "https://example.org/impressum"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Unterstützte Rollen:
|
||||
|
||||
- `publisher`
|
||||
- `other`
|
||||
|
||||
Eine bloße URL ohne benannte verantwortliche Stelle wird nicht akzeptiert.
|
||||
|
||||
### 5. Zwei Ebenen der Kennzeichnung
|
||||
|
||||
Bei freiwilliger Transparenz kann weiterhin z. B. „Artikeltransparenz“ verwendet werden.
|
||||
|
||||
Wenn die Selbsteinordnung auf einen voraussichtlich kennzeichnungspflichtigen Artikel-50-Fall hindeutet, wird die Erstkennzeichnung klarer formuliert, z. B.:
|
||||
|
||||
- „KI-generierter / manipulierter Inhalt“
|
||||
- „KI-generierte / bearbeitete Inhalte“
|
||||
|
||||
Die ausführliche zweite Ebene bleibt die `/declaration`-Seite.
|
||||
|
||||
### 6. Emoji-Modus
|
||||
|
||||
Der quadratische Emoji-Modus bleibt verfügbar. Bei einem als wahrscheinlich offenlegungspflichtig eingeordneten Fall ergänzt der generierte HTML-/Markdown-Einbettungscode neben dem Emoji zusätzlich sichtbaren Klartext. Das Emoji wird weiterhin nicht als offizielles EU-Icon oder als alleiniger Konformitätsnachweis dargestellt.
|
||||
|
||||
### 7. Custom-Badge-Schutz
|
||||
|
||||
In einem vom Nutzer als wahrscheinlich gesetzlich relevanten Artikel-50-Fall kann ein Pro-Custom-Text die eindeutige Erstkennzeichnung nicht mehr durch eine abstrakte Badge-Botschaft ersetzen. Farben und linke Beschriftung bleiben anpassbar; die entscheidende Offenlegungsbotschaft bleibt verständlich.
|
||||
|
||||
### 8. Vorsichtige Einschätzung auf der Declaration-Seite
|
||||
|
||||
Die Seite zeigt nun eine gesonderte „Vorsichtige Art.-50-Einschätzung“.
|
||||
|
||||
Beispiele:
|
||||
|
||||
- Deepfake: „spricht vieles dafür“, dass eine klare Offenlegung spätestens bei erster Exposition erforderlich ist.
|
||||
- Public-Interest-Text ohne dokumentierte Ausnahmevoraussetzungen: „spricht vieles dafür“, dass eine Offenlegung erfolgen sollte.
|
||||
- Public-Interest-Text mit substantieller Prüfung und ausdrücklich benannter redaktioneller Verantwortung: die Ausnahme „kann in Betracht kommen“.
|
||||
|
||||
Es werden bewusst keine verbindlichen Formulierungen wie „rechtlich zwingend“ oder „AI-Act-konform“ ausgegeben.
|
||||
|
||||
## Aktuelle offizielle Grundlagen
|
||||
|
||||
- Artikel 50 AI Act: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
|
||||
- Kommissionsleitlinien vom 20.07.2026: https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
|
||||
- FAQ zu Artikel 50: https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
|
||||
- EU-Icons: https://digital-strategy.ec.europa.eu/en/policies/eu-icons-labelling-ai-generated-content
|
||||
- Code of Practice: https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
|
||||
- Kommissionsbewertung des Code of Practice: https://digital-strategy.ec.europa.eu/en/library/commission-opinion-assessment-code-practice-transparency-ai-generated-content
|
||||
|
||||
## Verbleibende rechtliche Grenze
|
||||
|
||||
Der Standard kann Transparenz- und Dokumentationsprozesse unterstützen. Er kann nicht automatisch prüfen oder erfüllen, ob beispielsweise Artikel 4 (AI Literacy), Artikel 5 (verbotene Praktiken), Hochrisiko-Pflichten, GPAI-Pflichten, Datenschutz-, Urheber-, Medien- oder Verbraucherrecht im konkreten Einsatzfall greifen.
|
||||
|
||||
Daher sollte öffentlich weiterhin nicht pauschal mit „EU AI Act compliant“ oder „erfüllt alle Anforderungen des EU AI Act“ geworben werden.
|
||||
@@ -1,148 +0,0 @@
|
||||
# Rechtlicher und sicherer Produktivbetrieb
|
||||
|
||||
Stand: 20. Juli 2026
|
||||
|
||||
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;
|
||||
- Erklärung zur Verbraucherstreitbeilegung.
|
||||
|
||||
Offizielle Grundlagen:
|
||||
|
||||
- § 5 DDG: https://www.gesetze-im-internet.de/ddg/__5.html
|
||||
- § 18 MStV: https://www.gesetze-bayern.de/Content/Document/MStV-18
|
||||
- § 36 VSBG: https://www.gesetze-im-internet.de/vsbg/__36.html
|
||||
|
||||
## 3. Datenschutz
|
||||
|
||||
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.
|
||||
|
||||
Offizielle Grundlagen:
|
||||
|
||||
- Art. 13 DSGVO: https://eur-lex.europa.eu/eli/reg/2016/679/oj
|
||||
- § 25 TDDDG: https://www.gesetze-im-internet.de/ttdsg/__25.html
|
||||
|
||||
## 4. Barrierefreiheit
|
||||
|
||||
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;
|
||||
- Alternativtexte eingebetteter Badges;
|
||||
- Barrierefreiheit des vollständigen Bestell- oder Vertragspfads;
|
||||
- gesetzlich verlangte Informationen zur Barrierefreiheit.
|
||||
|
||||
Offizielle Informationen: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz
|
||||
|
||||
## 5. Sicherheitsstandard
|
||||
|
||||
Mitgeliefert werden unter anderem:
|
||||
|
||||
- restriktive Content Security Policy mit zufälliger Nonce je HTML-Antwort;
|
||||
- `frame-ancestors 'none'`, `X-Frame-Options: DENY`, `nosniff`, Referrer- und Permissions-Policy;
|
||||
- HSTS bei HTTPS-Basis-URL;
|
||||
- Größenlimit und striktes JSON-Decoding für den Validator;
|
||||
- Begrenzung paralleler Validierungsanfragen;
|
||||
- validierte und begrenzte Request-IDs;
|
||||
- Proxy-Header nur aus ausdrücklich konfigurierten Proxy-Netzen;
|
||||
- standardmäßig deaktivierte Client-IP-Logs und Prometheus-Metriken;
|
||||
- verpflichtender Bearer-Schutz bei aktiviertem `/metrics`;
|
||||
- Non-Root-Container, schreibgeschütztes Dateisystem, entfernte Linux-Capabilities und `no-new-privileges`.
|
||||
|
||||
Zusätzlich in der Betriebsumgebung erforderlich:
|
||||
|
||||
- TLS-Terminierung und sichere Zertifikatsverwaltung;
|
||||
- Rate Limits am Edge/Ingress;
|
||||
- regelmäßige Image- und Abhängigkeitsupdates;
|
||||
- Secret-Management statt Klartext-Umgebungsvariablen, soweit möglich;
|
||||
- Netzwerksegmentierung für Metriken und Lizenzserver;
|
||||
- zentrale Log-Löschung entsprechend `LOG_RETENTION`;
|
||||
- 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
|
||||
- Leitlinien: https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
|
||||
- FAQ: https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
|
||||
- Code of Practice: https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
|
||||
@@ -16,7 +16,7 @@ Initialization is performed in `internal/app/server.go`. The product ID and embe
|
||||
```go
|
||||
licenses := licenseclient.New(ctx, licenseclient.Config{
|
||||
Product: "ai-disclosure-standard",
|
||||
ClientVersion: "1.8.0",
|
||||
ClientVersion: "2.0.0",
|
||||
Token: cfg.LicenseToken,
|
||||
TrustStore: trustStore,
|
||||
BaseURL: cfg.BaseURL,
|
||||
|
||||
@@ -119,7 +119,7 @@ Anfrage:
|
||||
"baseUrl": "https://ai.example.org",
|
||||
"host": "ai.example.org",
|
||||
"instanceId": "production-eu-1",
|
||||
"clientVersion": "1.8.0"
|
||||
"clientVersion": "2.0.0"
|
||||
}
|
||||
```
|
||||
|
||||
@@ -170,3 +170,23 @@ Unter `third_party/license-platform-client` liegt eine client-only, protokollkom
|
||||
Private-Key-Handling, Signierfunktionen, Admin-Server und Persistenz wurden bewusst nicht übernommen.
|
||||
|
||||
Sobald das eigenständige Modul über einen stabilen Go-Modul-Tag erreichbar ist, kann in `go.mod` der lokale `replace`-Eintrag entfernt und direkt die veröffentlichte SDK-Version verwendet werden.
|
||||
|
||||
## Capabilities used by 2.0
|
||||
|
||||
```text
|
||||
custom_text
|
||||
custom_badge
|
||||
white_label
|
||||
bulk_api
|
||||
export_bundle
|
||||
```
|
||||
|
||||
The optional numeric limit `bulk_items` caps the number of items accepted by a single Bulk API request. The application always applies the stricter value of the runtime configuration and the signed licence limit.
|
||||
|
||||
For an official deployment that must fail closed when the licence is unavailable, set:
|
||||
|
||||
```env
|
||||
REQUIRE_LICENSE=true
|
||||
```
|
||||
|
||||
This affects both readiness and ordinary application requests. Liveness, readiness, metrics and capability inspection remain available for operations and diagnosis.
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
# Licensing Strategy
|
||||
|
||||
## Aktueller Stand
|
||||
|
||||
Der Quellstand enthält derzeit die MIT-Lizenz. Sie erlaubt ausdrücklich Nutzung, Änderung, Weitergabe, Unterlizenzierung und Verkauf von Kopien unter Einhaltung der Lizenzbedingungen.
|
||||
|
||||
Die Runtime-Lizenz der Universal License Platform ist deshalb primär eine **technische und vertragliche Grenze der offiziellen Distribution**, nicht ein Ersatz für eine bewusst gewählte Software-Lizenzstrategie.
|
||||
|
||||
## Mögliche Produktstrategien
|
||||
|
||||
### Permissive Open Source + kommerzielle Dienste
|
||||
|
||||
MIT/Apache-2.0 bleibt bestehen. Monetarisiert werden beispielsweise:
|
||||
|
||||
- offizielle Managed-/Hosted-Dienste;
|
||||
- Support und SLA;
|
||||
- Verifikations- und Signaturdienste;
|
||||
- Marken-/Trust-Programme;
|
||||
- offizielle Images und Updatekanäle.
|
||||
|
||||
Das maximiert Adoption, schützt aber einzelne lokal vorhandene Funktionen nicht exklusiv.
|
||||
|
||||
### Dual Licensing
|
||||
|
||||
Eine häufige Alternative ist eine Copyleft-Open-Source-Lizenz für die Community-Ausgabe und eine separate kommerzielle Lizenz für Kunden, die die Copyleft-Bedingungen nicht übernehmen möchten. Eine solche Umstellung sollte nur vorgenommen werden, wenn die erforderlichen Rechte an allen Beiträgen vorliegen.
|
||||
|
||||
### Open Core
|
||||
|
||||
Ein vollständig offener Kern und separat lizenzierte, nicht unter der Open-Source-Lizenz veröffentlichte Enterprise-Komponenten sind ebenfalls möglich. Dabei muss die Lizenzgrenze im Repository und in Build-Artefakten eindeutig dokumentiert werden.
|
||||
|
||||
## Empfehlung vor öffentlichem Launch
|
||||
|
||||
Vor einer kommerziellen Veröffentlichung sollten insbesondere entschieden und juristisch geprüft werden:
|
||||
|
||||
1. welche Teile tatsächlich Open Source sein sollen;
|
||||
2. ob MIT beibehalten, Dual Licensing verwendet oder ein Open-Core-Modell gewählt wird;
|
||||
3. welche Marken/Logos ausschließlich für offizielle bzw. verifizierte Implementierungen verwendet werden dürfen;
|
||||
4. welche Vertragsbedingungen für Runtime-Lizenzen, Support, SLA und Verifikation gelten.
|
||||
|
||||
Diese Datei beschreibt Produktarchitektur und ersetzt keine Rechtsberatung.
|
||||
@@ -1,35 +0,0 @@
|
||||
# Marketing page
|
||||
|
||||
The product page is served by the same Go binary as the badge and declaration API.
|
||||
|
||||
## Routes
|
||||
|
||||
- `/product` — complete product, feature, pricing and installation page
|
||||
- `/pricing` — redirects to `/product#pricing`
|
||||
- `/install` — redirects to `/product#install`
|
||||
|
||||
All routes support `?lang=de|en|fr|es|it|nl|pt|pl` and `Accept-Language` negotiation.
|
||||
|
||||
## Runtime configuration
|
||||
|
||||
```text
|
||||
SALES_URL=https://example.org/contact
|
||||
PRICE_COMMUNITY=0 €
|
||||
PRICE_PRO=19 €
|
||||
PRICE_PUBLISHER=79 €
|
||||
PRICE_AGENCY=199 €
|
||||
```
|
||||
|
||||
`SALES_URL` is used by paid-plan calls to action. When it is empty, the service falls back to `CONTACT_URL`.
|
||||
|
||||
The page deliberately markets only capabilities that exist in the current build. Domain counts, support levels and commercial terms are offer definitions; adjust them before publication.
|
||||
|
||||
## Editing content
|
||||
|
||||
- Page structure: `web/templates/marketing.html`
|
||||
- Styling: `web/static/style.css`
|
||||
- Copy controls and language switch: `web/static/marketing.js`
|
||||
- Localised product copy: `internal/marketing/content.go`
|
||||
- Generator navigation label: `internal/i18n/marketing.go`
|
||||
|
||||
No external fonts, scripts, images, analytics or cookies are required.
|
||||
@@ -1,85 +0,0 @@
|
||||
# Rechts- und Sicherheitsreview
|
||||
|
||||
Stand: 20. Juli 2026
|
||||
|
||||
## Einordnung
|
||||
|
||||
Dieses Review verbessert den technischen Standardzustand und stellt konfigurierbare Vorlagen für zentrale Betreiberinformationen bereit. Es ist keine individuelle Rechtsberatung und keine Garantie vollständiger Rechtskonformität. Die abschließende Prüfung muss anhand des tatsächlichen Betreibers, Sitzes, Geschäftsmodells, Hostings, Vertragsangebots und aller eingebundenen Dienste erfolgen.
|
||||
|
||||
## Ausgangslage
|
||||
|
||||
Im geprüften Archiv fehlten eigene Seiten für Anbieterkennzeichnung, Datenschutz und Barrierefreiheit. Zudem wurde die Client-IP bei jedem Request protokolliert, Proxy-Header konnten ohne explizite Netzbindung vertraut werden, der Metrik-Endpunkt war grundsätzlich registriert und der öffentliche Capability-Endpunkt konnte interne Lizenzmetadaten ausgeben.
|
||||
|
||||
## Umgesetzte Änderungen
|
||||
|
||||
### Rechtliche Informationen
|
||||
|
||||
- neue Routen `/impressum`, `/datenschutz` und `/barrierefreiheit`;
|
||||
- zentrale Footer-Verlinkung auf allen HTML-Seiten;
|
||||
- konfigurierbare Betreiber-, Register-, Steuer-, Datenschutz-, Hosting-, Streitbeilegungs- und Barrierefreiheitsangaben;
|
||||
- sichtbare Warnung bei fehlenden Angaben;
|
||||
- `LEGAL_STRICT=true` verhindert einen Produktivstart mit fehlenden Kernangaben oder typischen Platzhaltern;
|
||||
- keine erfundenen Betreiberangaben und keine pauschale Behauptung vollständiger Barrierefreiheit;
|
||||
- Hinweise auf die tatsächliche Verarbeitung von URL-Parametern, Infrastruktur-Logs und optionaler Online-Lizenzprüfung;
|
||||
- kein veralteter Link zur eingestellten EU-OS-Plattform.
|
||||
|
||||
### Anwendungssicherheit und Datenschutz durch Voreinstellungen
|
||||
|
||||
- Client-IP-Logging standardmäßig deaktiviert;
|
||||
- Query-Strings werden nicht in Anwendungslogs übernommen;
|
||||
- Proxy-Header werden nur von explizit konfigurierten CIDR-Netzen ausgewertet;
|
||||
- die weitergeleitete IP wird von rechts nach links über die vertrauenswürdige Proxy-Kette bestimmt, damit vorgeschobene Header-Werte nicht als Client-IP gelten;
|
||||
- validierte und auf 64 Zeichen begrenzte Request-IDs;
|
||||
- restriktive Content Security Policy mit zufälliger Nonce je HTML-Antwort;
|
||||
- HSTS nur bei HTTPS-Konfiguration und ohne pauschales `includeSubDomains`;
|
||||
- `frame-ancestors 'none'`, `X-Frame-Options: DENY`, `nosniff`, Referrer- und Permissions-Policy;
|
||||
- Validator mit 1-MiB-Limit, strikt erlaubten JSON-Feldern, Content-Type-Prüfung und Parallelitätsgrenze;
|
||||
- `/metrics` standardmäßig nicht registriert; bei Aktivierung ist ein Bearer-Token zwingend;
|
||||
- öffentliche Capability-Antwort enthält keine Lizenz-ID, Kundendaten, internen Serveradressen oder Diagnosedetails;
|
||||
- externe Konfigurations-URLs werden auf absolute HTTP(S)-URLs ohne Zugangsdaten begrenzt;
|
||||
- rechtliche Kontaktfelder werden als reine E-Mail-Adressen validiert;
|
||||
- fehlerhafte boolesche Umgebungsvariablen und ungültige Proxy-CIDRs führen zum Startfehler statt zu einem stillen Fallback.
|
||||
|
||||
### Deployment
|
||||
|
||||
- Compose-, Kubernetes- und Swarm-Beispiele um die Rechts- und Sicherheitskonfiguration erweitert;
|
||||
- sichere Containeroptionen beibehalten: Non-Root, read-only Root-Dateisystem, keine Linux-Capabilities, `no-new-privileges`;
|
||||
- öffentliche Prometheus-Autodiscovery aus dem Kubernetes-Beispiel entfernt;
|
||||
- Dokumentation für TLS, Rate Limits, Secrets, Netzsegmentierung, Löschfristen, Backups, Updates und Incident Response ergänzt.
|
||||
|
||||
## Noch durch den Betreiber zu erledigen
|
||||
|
||||
Vor einem öffentlichen Start sind mindestens folgende Punkte mit echten Angaben und der tatsächlichen Infrastruktur abzugleichen:
|
||||
|
||||
1. Firma/Name, ladungsfähige Anschrift, Vertretungsberechtigte, Register, Umsatzsteuer-ID und gegebenenfalls berufsrechtliche Angaben.
|
||||
2. Redaktionell Verantwortliche, falls journalistisch-redaktionelle Inhalte unter § 18 Abs. 2 MStV angeboten werden.
|
||||
3. Hosting-Anbieter, eingesetzte Reverse Proxies/CDNs, tatsächliche Logfelder, Löschfristen, Auftragsverarbeitungsverträge und mögliche Drittlandübermittlungen.
|
||||
4. Anwendbarkeit und zutreffender Status nach dem Verbraucherstreitbeilegungsgesetz.
|
||||
5. Anwendbarkeit von BFSG/BFSGV sowie ein tatsächlicher Accessibility-Test des vollständigen Angebots.
|
||||
6. Datenschutzrechtliche Einordnung des Lizenzservers bei Hybrid- oder Online-Betrieb.
|
||||
7. TLS, Edge-Rate-Limits, Secret-Management, Patch-Prozess, Schwachstellenscans, Monitoring, Backups und Incident-Response in der Zielumgebung.
|
||||
8. Juristische Schlussprüfung der veröffentlichten Texte, insbesondere bei Verbraucherverträgen, reglementierten Berufen oder internationalen Angeboten.
|
||||
|
||||
## Technische Prüfung
|
||||
|
||||
Ausgeführt wurden:
|
||||
|
||||
```text
|
||||
go test ./...
|
||||
go vet ./...
|
||||
cd third_party/license-platform-client && go test ./... && go vet ./...
|
||||
```
|
||||
|
||||
Alle Prüfungen waren erfolgreich. Da die isolierte Prüfumgebung die in `go.mod` verlangte Go-1.26-Toolchain nicht herunterladen konnte, wurden die Tests mit der lokal vorhandenen Go-Version 1.23.2 und einer nur temporär angepassten Modfile ausgeführt. Die Projektdatei `go.mod` bleibt unverändert bei Go 1.26.
|
||||
|
||||
Zusätzlich wurden alle YAML-Dateien geparst, die Go-Dateien mit `gofmt` geprüft und Templates/JavaScript auf Inline-Eventhandler, Cookies sowie Browser-Speicherzugriffe durchsucht.
|
||||
|
||||
## Offizielle Ausgangspunkte
|
||||
|
||||
- § 5 DDG: https://www.gesetze-im-internet.de/ddg/__5.html
|
||||
- § 18 MStV: https://www.gesetze-bayern.de/Content/Document/MStV-18
|
||||
- Art. 13 DSGVO: https://eur-lex.europa.eu/eli/reg/2016/679/oj
|
||||
- § 25 TDDDG: https://www.gesetze-im-internet.de/ttdsg/__25.html
|
||||
- § 36 VSBG: https://www.gesetze-im-internet.de/vsbg/__36.html
|
||||
- Bundesfachstelle Barrierefreiheit zum BFSG: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz
|
||||
- EU AI Act: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
|
||||
@@ -0,0 +1,33 @@
|
||||
# Supply-chain security
|
||||
|
||||
Die offizielle GitHub-Actions-Pipeline erzeugt für den normalen und den Bulk-Container Multi-Arch-Images für `linux/amd64` und `linux/arm64`.
|
||||
|
||||
Für veröffentlichte Images werden zusätzlich erzeugt:
|
||||
|
||||
- BuildKit-Provenance (`mode=max`);
|
||||
- ein SBOM-Attest;
|
||||
- eine keyless Sigstore/Cosign-Signatur des Multi-Arch-Image-Digests über GitHub OIDC.
|
||||
|
||||
Die Signatur schützt die Herkunft eines offiziellen Image-Digests. Sie ersetzt weder die Runtime-Lizenzprüfung noch eine fachliche Verifikation einer KI-Nutzungserklärung.
|
||||
|
||||
## Verifikation eines offiziellen Images
|
||||
|
||||
Das konkrete Repository und der GitHub-Workflow müssen bei der Verifikation als erwartete Identität verwendet werden. Beispiel:
|
||||
|
||||
```bash
|
||||
cosign verify \
|
||||
--certificate-oidc-issuer=https://token.actions.githubusercontent.com \
|
||||
--certificate-identity-regexp='https://github.com/OWNER/REPOSITORY/.github/workflows/ci.yml@refs/heads/main' \
|
||||
ghcr.io/OWNER/REPOSITORY@sha256:...
|
||||
```
|
||||
|
||||
Für besonders kontrollierte Produktionsumgebungen sollte ein Deployment nur freigegebene Digests verwenden und die Signatur vor dem Rollout durch eine Admission Policy oder die CI/CD-Plattform prüfen.
|
||||
|
||||
## Release-Prinzipien
|
||||
|
||||
- Deployment nach Digest statt ausschließlich nach `latest`;
|
||||
- geschützte Release-Tags und Branch-Protection für `main`;
|
||||
- getrennte Secrets für Runtime-Lizenz und Bulk-API-Key;
|
||||
- keine privaten Lizenzschlüssel in diesem Repository;
|
||||
- regelmäßige Aktualisierung der Build-Images und GitHub Actions;
|
||||
- reproduzierbare Versionierung von Schema, Anwendung und Container.
|
||||
Reference in New Issue
Block a user