KI-Textvorschläge einrichten und betreiben

Diese Anleitung richtet sich an Personen, die das CMS bereitstellen, absichern oder abnehmen. Der redaktionelle Ablauf steht unter KI-Textvorschläge nutzen.

Aktivieren und Anbieter wählen

Textvorschläge sind standardmäßig deaktiviert. Wählen Sie einen Anbieter und setzen Sie seine Variablen als Laufzeitkonfiguration des CMS. Nach einer Änderung ist ein Neustart des CMS nötig.

# Ollama-Dienst, etwa in einer lokalen Entwicklungsumgebung
TEXT_GENERATION_ENABLED=true
TEXT_PROVIDER=ollama
TEXT_OLLAMA_URL=http://127.0.0.1:11434
TEXT_OLLAMA_MODEL=qwen3:14b

# Direkte OpenAI-API
TEXT_GENERATION_ENABLED=true
TEXT_PROVIDER=openai
TEXT_OPENAI_MODEL=gpt-6-luna
OPENAI_API_KEY=<serverseitiges-secret>

Die Ollama-Adresse muss aus dem CMS-Prozess erreichbar sein. In einem Container zeigt 127.0.0.1 auf den Container selbst; bei einem separaten Ollama-Dienst muss eine passende interne Adresse verwendet werden. Das CMS wechselt bei einem Ausfall nicht automatisch den Anbieter. Der OpenAI-Key gehört ausschließlich in geschützte Laufzeit-Secrets und nie in Git, Logs oder ein öffentliches Variablenpräfix. Modellverfügbarkeit und Anbieterbedingungen prüft der Betreiber für seine Umgebung.

Nur der gewählte Feldtext und optionale redaktionelle Hinweise werden als Nutzinhalt an den konfigurierten Anbieter geschickt. Sie liegen außerdem als Request-Payload im privaten CMS-Queue-Eintrag. Bei OpenAI weist die CMS-API erkennbare E-Mail-Adressen und Telefonnummern im Text oder in den Hinweisen zurück; dieser einfache Filter erkennt nicht alle personenbezogenen oder sensiblen Daten. Die redaktionelle Vorprüfung bleibt erforderlich. Ein lokal betriebener Ollama-Dienst vermeidet die Übermittlung an die OpenAI-API, muss aber selbst passend abgesichert sein.

Queue und Grenzen

Mehrere Aufträge für verschiedene Felder dürfen warten. Der Worker bearbeitet sie mit der konfigurierten Parallelität; der Standard ist ein Job zurzeit. Ein neuer Auftrag derselben Person für dieselbe Aufgabe und dasselbe Feld ersetzt einen noch ausstehenden oder laufenden Auftrag, wenn sich die Eingabe geändert hat. Ein identischer aktiver Auftrag wird wiederverwendet. Bei mehreren CMS-Instanzen arbeitet die Queue mit atomarer Reservierung; das Rate-Limit gilt jedoch je Instanz. Falls ein globales Limit nötig ist, muss der Reverse Proxy es zusätzlich durchsetzen.

Textjobs haben die Zustände pending, running, done, failed und cancelled. Ein ungültiges oder unpassendes Modellergebnis wird nicht als fertiger Vorschlag ausgegeben. Bei einem Antwortformatfehler versucht der Adapter die Generierung einmal erneut; danach erscheint ein Fehler. Timeout, Konfigurations- oder Anbieterfehler bleiben am Job sichtbar. Der Betreiber prüft dabei zuerst Dienst-Erreichbarkeit, Modell, Key, Timeout und Worker-Logs.

Die Queue speichert Provider, Modell, Adapter- und Promptversion, Zeitpunkte, technische Nutzungswerte und die redaktionelle Entscheidung. Sie speichert keinen API-Key. Eine verbindliche Kostenberechnung, Preisobergrenze oder ein Budgetlimit für Textvorschläge gibt es derzeit nicht; Verbrauch und aktuelle Preise müssen Betreiber beim Anbieter prüfen. Verworfene Vorschlagstexte werden nach sieben Tagen, andere Textinhalte aus abgeschlossenen Jobs nach 30 Tagen bereinigt. Technische Entscheidungsmetadaten bleiben bestehen.

Zugriff und Freigabe

Die Text-Routen verlangen eine aktive Strapi-Admin-Session. Zum Lesen ist read, zum Erzeugen, Abbrechen und Entscheiden update für den jeweiligen Content-Type Category oder Story nötig. Vorschlagsdetails und frühere offene Vorschläge sind zusätzlich an die Person gebunden, die den Job angelegt hat. Öffentliche Content-API-Tokens geben keinen Zugriff auf die Queue. Das Einsetzen eines Vorschlags verändert nur das Admin-Formular; Speichern und Veröffentlichen bleiben separate redaktionelle Schritte.

Vergabe der Content-Manager-Rechte, Anbieterwahl und Secrets liegen beim CMS-Betrieb. Die Redaktion prüft Bedeutungs- und Fachtreue vor der Übernahme. Eine fachlich verantwortliche Person gibt Gesundheitsinformationen gemäß Freigabecheckliste frei. Modell und Prompt beanspruchen keine Zertifizierung nach den genannten Sprachnormen.

Funktionsprüfung nach der Einrichtung

1. Mit einem berechtigten Redaktionskonto einen kurzen Titel, einen längeren Slide-Text und einen Linktext vereinfachen. In Deutsch stehen Leichte und Einfache Sprache getrennt zur Verfügung, in anderen Sprachen Plain Language.
2. Ein gespeichertes Feld aus einer anderen vorhandenen Sprachfassung übersetzen. Zielsprachfassung und Zielfeld müssen zuvor angelegt sein. Auch die Meldung bei fehlendem Zielfeld prüfen.
3. Einen noch ungespeicherten Slide-Text in einer bereits angelegten Story vereinfachen. Vorschlag bearbeiten, übernehmen und anschließend den Eintrag speichern; die Übernahme allein darf nichts veröffentlichen.
4. Einen zweiten Auftrag für ein anderes Feld starten und Wartestatus, Abbruch sowie einen Anbieterfehler prüfen. Ohne Admin-Session muss die Route 401, ohne passendes Content-Manager-Recht 403 liefern.
5. Original und Ergebnis fachlich auf Namen, Zahlen, Fristen, Links, medizinische Aussagen, Bedingungen und Warnungen vergleichen. Die Redaktion bewertet Verständlichkeit, Bedeutungstreue und Vollständigkeit vor der Veröffentlichung.

Für automatisierte Prüfungen enthält das CMS unter tests/fixtures/text-evaluation.json kurze Beschriftungen, Linktexte und einen längeren Slide mit Fachbegriff. Der optionale echte Provider-Test wird mit RUN_LIVE_TEXT_PROVIDER_TEST=true gestartet. Er kontrolliert Format und ausgewählte Pflichtangaben. Die fehlende Zielfeld-Übersetzung wird in einem Admin-Komponententest geprüft. Modellantworten brauchen zusätzlich eine fachliche Prüfung durch Menschen.