Oliver G
de1d62c6f7
Die Freigabe ist jetzt der taegliche Arbeitsschritt und bekommt eine eigene Seite: /admin/freigabe listet alle wartenden Artikel mit Bild, Score, Tags und dem umgeschriebenen Text lesbar gerendert, dazu die drei Aktionen Freigeben, Neu schreiben, Verwerfen. Nach jeder Aktion geht es zurueck in die Liste, damit sich eine Warteschlange am Stueck abarbeiten laesst. Der Vorschautext ist Modell-Ausgabe ueber fremde Webseiten und laeuft deshalb durch einen Tag-Whitelist-Filter statt roh ins Template. Aufgeraeumt: - Artikelliste zeigte interne Kuerzel statt Klartext - Status `review` (Relevanz-Warnzone) wurde als "Rewrite" ausgegeben - `Rewrite -> Freigegeben` entfernt: zweiter Weg an der Freigabe vorbei - `Freigegeben -> Veroeffentlicht` entfernt: das macht der WP-Sync - API-Statusliste wird abgeleitet statt handgepflegt, sie kannte den neuen Status nicht und lehnte den Wechsel mit 422 ab Behoben: list_articles las content_rewritten nicht mit, die neue Seite haette nie einen Text angezeigt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
131 lines
6.1 KiB
Markdown
131 lines
6.1 KiB
Markdown
# KI-Verordnung: redaktionelle Freigabe vor der Veröffentlichung
|
||
|
||
Stand: 24.08.2026. Keine Rechtsberatung — die Umsetzung folgt der Auslegung, die
|
||
unten begründet ist. Bei wirtschaftlich kritischen Fällen juristisch prüfen.
|
||
|
||
## Warum das Gate existiert
|
||
|
||
Die Pipeline lässt ein Sprachmodell (OpenAI) Nachrichtentexte **neu schreiben**,
|
||
verschlagwortet sie und bewertet ihre Relevanz. Das Ergebnis wird als Beitrag auf
|
||
`vanityontour.de` veröffentlicht — also ein KI-erzeugter Text, der die
|
||
Öffentlichkeit informiert.
|
||
|
||
Art. 50 Abs. 4 UAbs. 2 KI-VO (Verordnung (EU) 2024/1689, Transparenzpflichten
|
||
anwendbar seit dem 02.08.2026) verlangt für solche Texte die Offenlegung, dass
|
||
sie künstlich erzeugt oder manipuliert wurden. **Ausgenommen** sind Inhalte, die
|
||
|
||
- einer **menschlichen Überprüfung bzw. redaktionellen Kontrolle** unterzogen
|
||
wurden **und**
|
||
- für die eine natürliche oder juristische Person die **redaktionelle
|
||
Verantwortung** trägt.
|
||
|
||
Der KI-Transparenzhinweis auf dem Blog (Plugin `vot-ki-hinweis`) sagt genau das
|
||
zu: „Jeder Text wird von mir redaktionell geprüft, auf Fakten kontrolliert und
|
||
inhaltlich verantwortet." Bis zum 24.08.2026 lief die News-Pipeline jedoch
|
||
vollautomatisch: Rewrite, WordPress-Beitrag und geplante Veröffentlichung ohne
|
||
menschlichen Zwischenschritt. Die zugesagte Kontrolle fand faktisch nicht statt.
|
||
|
||
Das Freigabe-Gate schließt diese Lücke: Es macht die Aussage wahr und
|
||
dokumentiert sie nachprüfbar.
|
||
|
||
## Der Ablauf
|
||
|
||
```
|
||
N8N (2× täglich) → POST /api/n8n/pipeline
|
||
├── RSS-Ingestion
|
||
├── Relevanz-Score (GPT)
|
||
│ ├── < 60 → abgelehnt
|
||
│ ├── 60–79 → Telegram-Warnung, Übernahme per Button möglich
|
||
│ └── ≥ 80 → Rewrite + Tags (GPT)
|
||
│
|
||
└── Status: pending_review ──► KEIN WordPress-Beitrag, KEIN Slot
|
||
Telegram: Info + Link ins Portal
|
||
│
|
||
Mensch öffnet /admin/freigabe und liest den Artikel
|
||
│
|
||
┌─────────────────────────┼──────────────────────────┐
|
||
▼ ▼ ▼
|
||
„✅ Freigeben" „✏️ Neu schreiben" „❌ Verwerfen"
|
||
│
|
||
▼
|
||
Stempel: editorial_review_at / _by / _note (Systemzeit, nicht editierbar)
|
||
Status: approved → Publish-Slot reservieren → WordPress-Beitrag (future)
|
||
→ WordPress veröffentlicht zum Slot
|
||
```
|
||
|
||
Wichtig an der Reihenfolge:
|
||
|
||
- **Kein WordPress-Beitrag vor der Freigabe.** Sonst läge dort ein
|
||
`future`-Beitrag, der sich selbst veröffentlicht, bevor jemand hingesehen hat.
|
||
- **Kein Slot vor der Freigabe.** Es gibt vier feste Slots pro Tag; ein Artikel,
|
||
der stundenlang auf die Prüfung wartet, darf keinen davon blockieren. Der Slot
|
||
wird im Moment der Freigabe reserviert, der Scheduler füllt Lücken auf.
|
||
|
||
## Die Freigabe-Seite
|
||
|
||
`/admin/freigabe` ist die Arbeitsliste: alle Artikel im Status „Wartet auf
|
||
Freigabe", jeweils mit Hauptbild, Relevanz-Score samt Begründung, Tags, Link zum
|
||
Originalartikel — und dem **umgeschriebenen Text lesbar gerendert**, nicht als
|
||
Markup. Darunter die drei Aktionen. Nach jeder Aktion landet man wieder in der
|
||
Liste, sodass eine Warteschlange von oben nach unten abgearbeitet werden kann.
|
||
|
||
Der Text stammt aus einem Sprachmodell, das mit fremden Webseiten gefüttert
|
||
wurde. Für die Anzeige wird er deshalb durch einen Tag-Whitelist-Filter geschickt
|
||
(`_sanitize_preview_html`): Absätze, Überschriften, Listen und http(s)-Links
|
||
bleiben, alles andere fällt weg.
|
||
|
||
## Wo der Nachweis liegt
|
||
|
||
| Ort | Inhalt |
|
||
|-----|--------|
|
||
| `articles.editorial_review_at` | Zeitpunkt der Freigabe (UTC, ISO 8601), vom System gesetzt |
|
||
| `articles.editorial_review_by` | angemeldeter Benutzer, der freigegeben hat |
|
||
| `articles.editorial_review_note` | optionale Notiz zur Prüfung |
|
||
| `meta_json.review_events[]` | Ereignis `editorial_review` im Audit-Trail, zusätzlich der Statuswechsel |
|
||
|
||
Der Zeitstempel ist **nie** ein Eingabefeld. Er entsteht ausschließlich beim
|
||
Klick auf „Redaktionell geprüft & freigeben" (bzw. beim manuellen Statuswechsel
|
||
nach `publish`) und kann in der Oberfläche nicht nachträglich gesetzt werden.
|
||
|
||
## Kein Schlupfloch nach `publish`
|
||
|
||
Jeder Weg in den Status `approved` stempelt die Freigabe:
|
||
|
||
- `POST /admin/articles/{id}/approve` — der reguläre Button
|
||
- `POST /admin/articles/{id}/transition` mit Ziel `publish` — leitet auf denselben
|
||
Weg um, wenn noch kein Stempel vorliegt
|
||
- `POST /api/articles/{id}/transition` mit Ziel `publish` — stempelt ebenfalls
|
||
|
||
Die Pipeline selbst erreicht `approved` nicht mehr, solange
|
||
`EDITORIAL_REVIEW_REQUIRED=true` gesetzt ist.
|
||
|
||
## Altbestand
|
||
|
||
Artikel, die vor dem 24.08.2026 freigegeben oder veröffentlicht wurden, haben
|
||
keinen Stempel und brauchen keinen: Sie durchlaufen die neue Pipeline nicht
|
||
erneut, und der Publisher blockiert sie nicht. Das Gate greift ausschließlich für
|
||
Artikel, die ab sofort neu verarbeitet werden.
|
||
|
||
## Konfiguration
|
||
|
||
| Variable | Default | Wirkung |
|
||
|----------|---------|---------|
|
||
| `EDITORIAL_REVIEW_REQUIRED` | `true` | Gate aktiv; `false` stellt den alten vollautomatischen Ablauf wieder her |
|
||
| `PORTAL_BASE_URL` | `https://news.vanityontour.de` | Basis für die Deep-Links in Telegram |
|
||
|
||
Wird das Gate abgeschaltet, ist der KI-Hinweistext auf dem Blog anzupassen — die
|
||
Zusage der redaktionellen Prüfung träfe dann nicht mehr zu.
|
||
|
||
## Was bewusst nicht umgesetzt ist
|
||
|
||
- **Maschinenlesbare Markierung der KI-Ausgabe** (Art. 50 Abs. 2) ist eine
|
||
Pflicht des Anbieters des KI-Systems, nicht des Betreibers. Sie liegt bei
|
||
OpenAI.
|
||
- **Ein zweiter, abweichender Hinweistext für vollautomatische Beiträge** wird
|
||
nicht gebraucht, solange das Gate aktiv ist: Es gibt dann keine
|
||
vollautomatischen Beiträge mehr.
|
||
|
||
## Referenzen
|
||
|
||
- Verordnung (EU) 2024/1689 (KI-VO), Art. 50: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202401689
|
||
- Plugin `vot-ki-hinweis` (Hinweistext auf dem Blog): eigenes Repository `VoT-KI-Hinweis`
|