Schema-valide KI-Jobs außerhalb des TYPO3-Requests

Ein langsamer Dienst ist kein guter Web-Request

Ein KI-Aufruf passt technisch leicht in einen Controller: Eingabe sammeln, Modell anfragen, Antwort speichern. Im Betrieb ist das eine schlechte Grenze. Die Laufzeit ist nicht zuverlässig kurz, ein externer Dienst kann vorübergehend nicht erreichbar sein und ein syntaktisch korrektes Ergebnis kann fachlich trotzdem unbrauchbar sein. Wenn all das innerhalb eines TYPO3-Requests passiert, wird aus einer redaktionellen Hilfe schnell eine hängende Seite mit unklarer Fehlerlage.

Für die Homepage beginnt KI-Arbeit deshalb nicht mit einem langen Request, sondern mit einem begrenzten Datenbankauftrag. Der Request bestätigt nur, dass die Arbeit angenommen wurde. Ein einzelner Worker verarbeitet die Aufträge außerhalb der HTTP-Laufzeit. Das wirkt zunächst aufwendiger, trennt aber drei verschiedene Wahrheiten: Was der Nutzer angefordert hat, was der Worker gerade tut und welches Ergebnis tatsächlich gespeichert werden darf.

Der Vertrag ist kleiner als der Prompt

Freitext ist nützlich für die Aufgabe, aber ungeeignet als Rückgabevertrag. Der Worker sendet deshalb neben dem Prompt ein JSON-Schema. Der entfernte Lauf darf nur ein Objekt mit den erwarteten Eigenschaften liefern; zusätzliche Felder sind nicht erlaubt. Größen- und Zeitgrenzen verhindern, dass aus einem kleinen Redaktionsjob ein unbegrenzter Prozess wird.

Diese erste Validierung reicht nicht aus. Ein Schema beweist nur Form, nicht Bedeutung. Die Anwendung prüft die Antwort ein zweites Mal: Sind genau die fehlenden Felder enthalten? Stimmen Längen und Typen? Gehört ein Wert wirklich zu diesem Datensatz? Erst danach schreibt TYPO3. Bei Bildern kommen Dateityp, Abmessungen und Größenlimit hinzu. Eine vom Modell genannte Datei ist noch kein zulässiges öffentliches Asset.

Der doppelte Vertrag hat einen praktischen Vorteil: Fehler werden dort sichtbar, wo sie entstehen. Ein ungültiges Remote-Ergebnis ist kein halb gespeicherter Datensatz. Eine nicht erreichbare Laufzeit ist kein angeblich erfolgreicher Scheduler-Job. Und ein redaktioneller Entwurf bleibt ein Entwurf, bis ein Mensch ihn geprüft hat.

Ein Worker braucht ehrliche Zustände

Asynchron bedeutet nicht unsichtbar. Jeder Auftrag braucht einen Zustand, begrenzte Wiederholungen und eine dauerhafte Fehlermeldung. Der Worker der Homepage führt den TYPO3 Scheduler regelmäßig aus; Übersetzung, Blog-Vorschläge und Metadaten bleiben getrennte, kleine Arbeitswege. Ein Lauf erzeugt höchstens die vorgesehene Menge, statt bei einem Fehler eine große unübersichtliche Charge zu hinterlassen.

Das schützt auch die Oberfläche. Sie kann „wartet“, „wird verarbeitet“ und „fehlgeschlagen“ unterscheiden, statt jede Verzögerung als drehenden Spinner darzustellen. Eine gute asynchrone Oberfläche verspricht nicht, dass externe Arbeit sofort fertig wird. Sie verspricht, dass ihr Zustand nachvollziehbar bleibt.

Was das Schema nicht löst

Ein striktes Schema verhindert keine falsche Behauptung und ersetzt keine redaktionelle Verantwortung. Aktuelle öffentliche Fakten können eine begrenzte Recherche erfordern; private Daten gehören trotzdem nicht in den Prompt. Übersetzungen brauchen Sprachprüfung, veröffentlichte Texte eine Freigabe und fehlgeschlagene Jobs eine verständliche Wiederaufnahme.

Die wichtigste Entscheidung ist daher nicht das konkrete Modell. Es ist die Systemgrenze: Der Web-Request nimmt Arbeit an, der Worker führt sie begrenzt aus, das Schema begrenzt die Form und TYPO3 entscheidet unabhängig, was gespeichert und später veröffentlicht wird. So bleibt KI ein Werkzeug im System und wird nicht zum System selbst.