Beeing "Human-in-the-Loop" - ein persönlicher Bericht

In der useai.community treibt uns seit Monaten eine sehr einfache Grundfrage:

Wie kann KI bei möglichst vielen Aufgaben unterstützen und Arbeit abnehmen?

Wir versuchen „AI-first“ nicht als Etikett, sondern als Arbeitsweise zu verstehen. Diese Frage führt automatisch zu einer zweiten: Was kann KI zu 100 % übernehmen – und an welchen Stellen muss ein Mensch als Human-in-the-Loop bleiben?

Was kann KI zu 100 % übernehmen – und an welchen Stellen muss ein Mensch als Human-in-the-Loop bleiben?

Bei der Veröffentlichung von Content war das für uns nie unklar. Der letzte Schritt bleibt beim Menschen. Nicht, weil die KI „gefährlich“ wäre, sondern weil Außenwirkung Verantwortung ist. Die eigentliche Frage war eine andere – und sie hat uns länger beschäftigt, als wir erwartet hätten: Wie viele Schritte und wie viel Involvierung braucht es davor? Wie viel Feinjustierung ist notwendig, bevor ein Text oder ein Bild in der Pipeline weitergegeben werden kann? Wo endet hilfreiche Iteration – und wo beginnt eine Endlosschleife, die nur Output produziert, aber keine Qualität?

Relativ früh wurde sichtbar: Human-in-the-Loop ist weniger eine Frage der Einbindung als eine Frage der Urteilskompetenz. Ein Mensch kann formal „drin“ sein und trotzdem nicht in der Lage sein, die Rolle sinnvoll auszufüllen.

Warum ausgerechnet Content zum Prüfstein wurde

Für uns war früh klar, dass Contentgenerierung ein Schlüsselthema wird. Sichtbarkeit in der Community, Bewerbung von Events, Ankündigungen, Follow-ups, Einordnungen – alles Dinge, die regelmäßig passieren müssen und die in einem kleinen Team schnell zur Dauerlast werden. Also lag es nahe, ein KI-System zu bauen, das Content für Blogartikel, LinkedIn-Posts und begleitende Bilder erzeugt – in unserem Stil, mit unserem Kontext, ohne jedes Mal bei null zu beginnen.

Klaus und ich bauen dieses System gemeinsam. Die Schwerpunkte liegen dabei unterschiedlich. Ich komme stärker aus der System- und Umsetzungsperspektive: Pipeline, Parameter, Interfaces, Zusammenstecken von Bausteinen, damit am Ende reproduzierbar Output entsteht. Klaus schaut stärker auf Wirkung, Tonalität, Struktur und Passung: Wie klingt das nach uns? Wie liest sich das im Kanal? Trägt das, was da steht, auch den Anspruch, den wir damit verbinden? Diese Kombination ist hilfreich – und sie macht gleichzeitig sichtbar, wo es knirscht.

Der Moment, in dem „läuft“ nicht mehr gereicht hat

Irgendwann waren wir an einem Punkt, an dem „Input rein, Output raus“ zuverlässig funktioniert hat. Dazwischen lagen viele Schritte: Parameter, Adjustierungen, kleine Entscheidungen, UI-Fragen, Iterationen. Und dann liegt plötzlich ein fertiges Contentstück vor einem. Genau dort verschiebt sich die Arbeit. Bis dahin ging es um das Bauen. Ab da geht es um das Beurteilen.

Und dieses Beurteilen hat uns mehr Zeit und mehr Energie gekostet als erwartet. Ein Text kann formal korrekt sein und trotzdem nicht passen. Man kann auf ein Stück Content schauen und sofort spüren: irgendwie stimmt das noch nicht. Das ist oft das Leichte. Das Schwierige beginnt bei dem Wort „weil“.

„Es gefällt mir nicht“ ist eine Reaktion. „Es gefällt mir nicht, weil …“ ist ein Urteil. Und dieses „weil“ war für uns die eigentliche Herausforderung.

Das Bauchgefühl sagt: Die Absätze wirken schief. Die Formulierungen sind zu vage. Aber was heißt „zu vage“ konkret? Wie müsste es stattdessen sein – kürzer, präziser, konkreter, mit anderer Gewichtung, mit einem anderen Rhythmus? Und passt das, was als „besser“ empfunden wird, wirklich zu dem Kanal, in dem es später erscheinen soll? Ein Blogtext verträgt andere Gedankengänge als ein LinkedIn-Post. Ein Event-Teaser braucht andere Energie als eine Reflexion. Ohne diese Kriterien bleibt Feedback beliebig – und ein System kann aus beliebigem Feedback nichts lernen.

Feedback ist nur dann hilfreich, wenn es urteilsfähig ist

Für uns wurde daraus ein sehr praktischer Zusammenhang: Iteratives Feedback ist nur dann der Motor, wenn das Feedback überhaupt „verwertbar“ ist. Und verwertbar wird es erst, wenn es begründet werden kann. Wir wollen Entscheidungen gemeinsam treffen – und wir versuchen, diese Entscheidungen nicht nur zu fällen, sondern auch zu erklären. Gerade weil diese Begründungen später wieder ins System zurückfließen sollen.

Das ist der Punkt, an dem Human-in-the-Loop seinen Charakter verändert. Es geht nicht mehr darum, am Ende „ja“ oder „nein“ zu sagen. Es geht darum, eine Qualitätslogik aufzubauen, die wiederholbar wird. Nicht perfekt. Aber nachvollziehbar. Und vor allem: kommunizierbar zwischen Menschen – und dadurch auch anschlussfähig für das System.

Bei Bildern ist das noch einmal schwieriger als bei Text. Beim Bild ist das Urteil oft noch stärker gefühlt: Stimmung, Komposition, Detailgrad, „wirkt billig“ versus „wirkt klar“. Text ist schon anspruchsvoll genug. Bild legt eine Schicht drauf, die sich noch weniger in Worte fassen lässt, obwohl sie sofort erkannt wird.

Warum wir mit Beispielen arbeiten mussten

Wir haben deshalb begonnen, systematisch mit Beispielen zu arbeiten. Nicht als Sammlung für „best practices“, sondern als Spiegel für den eigenen Anspruch. Welche Texte empfinden wir als gut – und warum? Welche Tonalität trägt? Welche Struktur wirkt nicht nur sauber, sondern stimmig? Wo sitzt die Präzision? Wo entsteht Wärme, ohne beliebig zu werden?

Diese Beispiele sind für uns weniger Inspiration als Referenz. Ohne Referenz bleibt Urteil eine Tagesform. Mit Referenz wird Urteil langsam zu einer Kompetenz. Und erst wenn diese Kompetenz entsteht, kann ein KI-System wirklich kontinuierlich besser werden – nicht, weil es mehr generiert, sondern weil die Rückmeldungen klarer werden.

Was ich daraus mitnehme

Wenn ich unsere Lernreise bisher zusammenfasse, bleibt vor allem ein Satz hängen: Output skaliert schneller als Urteil. Genau darin liegt die Gefahr bei Content – und vermutlich auch bei vielen anderen Einsatzfällen.

Human-in-the-Loop ist in unserem Alltag keine Kontrollinstanz, die „Schlimmes verhindert“. Der Mensch bleibt zwar die letzte Instanz vor der Veröffentlichung, aber die eigentliche Arbeit passiert vorher: im Begründen, im Sortieren, im Definieren von Kriterien, die zum Zweck und zum Kanal passen. Das ist anstrengend, weil es weniger technisch ist, als es am Anfang wirkt. Es ist auch nicht abgeschlossen. Wir sind weit davon entfernt, das als „fertig“ zu betrachten.

Aber genau deshalb lohnt es sich, darüber zu schreiben: Weil diese Phase zwischen „System läuft“ und „System liefert Qualität“ die ist, in der viele Teams steckenbleiben – und weil das Steckenbleiben selten am Output hängt, sondern am Urteil darüber.