sendnrw/ai-disclosure-standard
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1.6
ai-disclosure-standard/docs/LEGAL-AND-SECURITY.md
T
jbergner 862f86dc3e
release-tag / release-image (push) Successful in 6m37s
Details
RC-4 nach umfangreichen Updates
2026-07-21 16:28:24 +02:00

7.8 KiB
Raw Permalink Blame History

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:

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:

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:

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:

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.

Reference in New Issue View Git Blame Copy Permalink