Der Check sagt: alles in Ordnung. Der Check irrt.

Du hast eine Analyse automatisiert. Du hast sogar mitgedacht und einen zweiten Agenten dahintergesetzt, der das Ergebnis prüft. Der meldet zurück: plausibel, vollständig, keine Auffälligkeiten. Du atmest auf und gibst das Ergebnis weiter.

Was du nicht weißt: Der prüfende Agent hat dieselbe Brille auf wie der geprüfte. Er teilt dessen blinde Flecken. Er fängt Flüchtigkeitsfehler – aber nicht die systematische Fehllesart, die beide haben. Dein Kontrollpunkt war keiner. Er war ein Echo.

Hier ist das Problem: Die meisten Debatten über Automatisierung drehen sich um die Frage „Wie kriege ich noch mehr automatisch hin?" Das ist die falsche Frage. Die richtige lautet: Welchen Teil dieser Aufgabe darf ich überhaupt abgeben – und wie hart muss der Kontrollpunkt sein, den ich behalte?

Zeit, das zu ändern. In diesem Workshop baust du keine Pipeline, die du mit nach Hause nimmst und die beim nächsten Produkt-Release veraltet ist. Du entwickelst ein Urteil: für jede künftige Research-Aufgabe selbst entscheiden zu können, wo die Automatisierungs-Grenze verläuft und wie stabil der Kontrollpunkt an dieser Grenze sein muss. Das ist unbequemer als ein Rezept. Aber es hält länger.

Warum du dabei sein solltest

• Automatisieren, ohne dass die Qualität leidet: Du lernst, die Grenze aus der Aufgabe abzuleiten – nicht aus dem, was dein Werkzeug gerade hergibt.

• Kontrollpunkte bauen, die halten: Eine Regel in einer Instruktionsdatei ist eine Bitte, kein Befehl. Du lernst, wo du harte Gates brauchst und wie du sie bekommst.

• Nicht in die Verifikations-Falle laufen: Ein Prüfapparat kann eine zuverlässig verzerrte Pipeline zertifizieren – mit Prüfsiegel. Du lernst, das zu erkennen.

• Vier Durchläufe statt einem Rezept: Du machst denselben Schnitt an vier verschiedenen Aufgaben. Erst die Wiederholung macht daraus eine Fähigkeit.

• Ein Wissen, das den Werkzeugwechsel überlebt: Wenn dein Unternehmen morgen die Plattform wechselt, zieht die Landkarte mit um.

Das erwartet dich

Was ändert sich, wenn der Mensch aus dem Loop tritt?

• Warum dein von Hand gebautes Analyse-Verfahren im Kern längst ein Agent ist – und der Schritt zu echten Agenten kleiner als gedacht

• Wie sich ein falscher Input durch eine automatische Kette fortpflanzt: unbeobachtet, geglättet und am Ende überzeugender als vorher

• Warum es keine Magic Pipeline gibt – Kontrolle verschwindet nicht, sie verlagert sich

Gate-Audit: Wo saß die Kontrolle bisher?

• Dein vertrautes Analyse-Verfahren auf den Tisch legen und jedes Gate markieren

• Zwei Fragen pro Gate: Was passiert damit – und wie hart muss es sein?

• Die unbequeme Entdeckung: Mehrere Gates, die du für Garantien gehalten hast, sind bei ehrlicher Betrachtung nur weiche Bitten

Die 2×2-Landkarte: Wo verläuft die Grenze?

• Ist die Aufgabe spezifizierbar? Ist das Ergebnis günstig verifizierbar? Mehr braucht es nicht

• Vier Quadranten, vier Antworten – von „voll automatisieren" bis „beim Menschen lassen"

• Warum die Grenze aus der Aufgabe folgt und nicht aus der Reife deines Setups

Die Härteskala: Wie stabil ist dein Kontrollpunkt wirklich?

• Hart, halbhart, weich, zirkulär – vier Härtegrade und was sie taugen

• Warum Instruktionen an ein Sprachmodell interpretiert werden und nicht ausgeführt

• Der einzige wirklich harte Kontrollpunkt in deinem System bist am Ende du – und du bist nur so hart wie deine Methodenkompetenz

Die Architektur agentischer Systeme – in jedem Werkzeug

• Sechs Schichten: Datenzugang, Dauerregeln, Verfahren, Zerlegung, harte Gates, Konnektoren

• Die Übersetzungstabelle: Wie dieselben Schichten in Claude, ChatGPT und Microsoft Copilot heißen

• Bewusst kurz gehalten – das hier ist kein Tool-Training

Durchlauf A: Der erste eigene Automatisierungs-Schnitt

• Einen klar automatisierbaren Schritt als wiederverwendbares Verfahren bauen

• PII-Redaktion und Auszählung – und warum es hier zwingend einen harten Check braucht

• Der Klick: Ich kann automatisieren und wissen, dass es stimmt – weil die Aufgabe es hergibt

Durchlauf B: Wenn der Check „alles gut" sagt und trotzdem irrt

• Eine thematische Clusterung automatisieren und einen KI-gestützten Verlässlichkeits-Check einbauen

• Das Ergebnis gegen ein von Hand erstelltes Referenzergebnis halten

• Zirkularität am eigenen Leib erleben: Ein KI-Prüfer erbt die Blindheit dessen, was er prüfen soll

Durchlauf C: Wenn sich eine Aufgabe wehrt

• Eine echte Interpretations- und Priorisierungsfrage automatisieren wollen – mit wenig Hilfe

• Zwei ehrliche Ausgänge, und beide sind ein Ergebnis

• Warum das Ergebnis fertig aussieht, lange bevor es richtig ist

Verifikation, die trägt

• Daten-Test-Sets: ein starkes Werkzeug – und trotzdem kein Beweis für Richtigkeit

• Selbst-Fänge, erzwungene Stopps, risikoorientierte Stichproben, deterministische Prüfschritte – jeweils mit ehrlichem Härtegrad-Etikett

• Warum der answer key selbst der Kompetenz-Ort ist: Wer das Referenzergebnis schreibt, braucht Forschungsmethodik

Multi-Agent: Hebel oder Overkill?

• Wo parallele Sub-Agenten die Qualität heben – und wo sie Schein-Präzision erzeugen

• Drei Agenten, die sich einig sind, sind nicht drei unabhängige Meinungen

Womit wir arbeiten

Als roter Faden läuft ein durchgehendes Szenario mit – ein fiktives Startup, das die Customer Journey rund um Zahnarztbesuche verbessern will. Fiktive Daten, echte Probleme. Das hat zwei Gründe: Ein Agent, der sich selbstständig durch einen Ordner mit echten Transkripten arbeitet, vergrößert die Angriffsfläche erheblich. Und Kunden-Sandboxes sind für Agenten-Zugriff oft schlicht nicht ausgelegt.

Den Umgang mit personenbezogenen Daten lernst du trotzdem – am fiktiven Material. Fehler machen, ohne dass sie wehtun.

Und wenn ihr eine Umgebung habt, die es hergibt – Sandbox tauglich, Datenschutz geklärt: Dann arbeiten wir im Inhouse-Format gern an euren eigenen Cases. Sag uns rechtzeitig Bescheid, dann klären wir vorab, ob es trägt.

In welchem Werkzeug?

In eurem. Der Workshop läuft mit Claude, mit ChatGPT und mit Microsoft Copilot – das Referenz-Werkzeug legen wir bei der Buchung gemeinsam fest.

Das ist keine Konzession an eure IT, sondern der Punkt: Was du hier lernst, sind Eigenschaften von Aufgaben, nicht Eigenschaften von Werkzeugen. Ob eine Aufgabe spezifizierbar ist, ändert sich nicht, wenn ihr das Produkt wechselt. Ein Workshop, der überall läuft, beweist genau das.

Für wen ist der Workshop?

Für UX-Researcher:innen, die den ersten Schritt schon gemacht haben.

Dieser Workshop setzt Handwerk voraus: Du weißt, wie ein LLM funktioniert. Du weißt, warum Halluzinationen kein Bug sind, sondern zur Bauart gehören. Und du hast schon mit Prompt-Ketten gearbeitet, statt nur Fragen zu stellen.

Konkret heißt das: Du hast entweder unseren Workshop „Effizienter Umgang mit AI und fortgeschrittenes Prompting für UXler:innen" besucht – oder du bist im Umgang mit LLMs deutlich fortgeschritten und bringst das Wissen auf anderem Weg mit. Beides ist uns gleich willkommen.

Warum wir das so deutlich sagen: Weil wir dir einen Tag ersparen wollen, an dem du Grundlagen nachholst, während die Gruppe weitergeht. Dieser Workshop fängt dort an, wo der andere aufhört. Wenn du unsicher bist, ob du reinpasst – schreib uns kurz. Wir sagen dir ehrlich, was wir denken.

Und falls du befürchtest, unterfordert zu sein, weil du schon Agenten gebaut hast: Die Frage, welche davon du besser nicht gebaut hättest, ist auch für technisch Versierte neu. Zehn Skills gebaut zu haben heißt noch nicht, eine Stunde darauf verwendet zu haben, zu entscheiden, welcher davon nicht hätte entstehen dürfen.