# 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`