Vom Test-Assistenten zum Alltags-Assistenten

Ein Assistent wird zum Alltagswerkzeug, wenn er an einem Anlass hängt, den es ohne ihn auch gäbe. Fehlt der Anlass, hilft kein besserer Prompt und keine größere Wissensbasis.

Der Satz im Titel stammt nicht von mir. Er steht so in einem Workshop-Protokoll: „So habe ich eine ‚Test’-Skill aber keinen Alltags-Skill.” Geschrieben von jemandem, der vorher alles richtig gemacht hatte. Aufgabe definiert, Wissensdaten zusammengestellt, Constraints formuliert, gebaut, getestet, funktioniert. Zwei Wochen später lag das Ding trotzdem brach.

Genau diese Lücke behandelt dieser Artikel. Er gehört zum Guide zum Bauen eigener KI-Assistenten mit Firmenwissen und kümmert sich um den Teil, den fast alle Anleitungen auslassen: was zwischen „gebaut” und „benutzt” passiert.

Warum der Assistent nach dem Workshop liegen bleibt

Ich sehe drei Gründe. Sie treten selten einzeln auf.

Kein fester Platz im Arbeitsablauf. Der Assistent existiert in einem Browser-Tab, den niemand öffnet. Die Aufgabe, für die er gebaut wurde, wird weiterhin so erledigt wie vorher, weil der alte Weg bekannt ist und im Kopf keine Verzweigung existiert. Beim Bauen war die Aufgabe präsent. Im Alltag ist sie es nicht, sie taucht einfach auf und wird abgearbeitet.

Kein Anlass. Viele Assistenten werden für Aufgaben gebaut, die zwar nervig sind, aber unregelmäßig auftreten. Ein Assistent für Ausschreibungstexte ist super, wenn dreimal im Jahr eine Ausschreibung kommt. Bis dahin vergisst du, dass er existiert. Und wenn die Ausschreibung dann da ist, hast du vergessen, wie er hieß und was er kann.

Keine Zuständigkeit. Im Workshop hat eine Person gebaut. Danach ist unklar, wer den Assistenten pflegt, wer entscheidet, ob die hinterlegten Dokumente noch stimmen, wer Feedback einsammelt. Ohne Namen dahinter verwaist so ein Ding schneller als jede Excel-Datei. Und weil niemand zuständig ist, meldet auch niemand, dass die Ergebnisse schlechter geworden sind.

Der Kern ist banal: Bauen ist ein Projekt mit klarem Ende, Nutzen ist eine Gewohnheit ohne Ende. Das eine erzeugt das andere nicht automatisch.

Der Trigger: häng ihn an etwas, das sowieso passiert

Der wirksamste Hebel ist auch der langweiligste. Suche den bestehenden Auslöser und häng den Assistenten daran.

Ein Beispiel, konstruiert, aber nah an dem, was ich in Workshops sehe: Eine Steuerkanzlei baut einen Assistenten, der Mandantenanfragen aus dem Postfach in eine strukturierte interne Notiz übersetzt. Als Trigger taugt „wenn ich Lust habe” nicht. „Jeden Morgen beim Durchgehen des Sammelpostfachs” taugt, weil das Postfach ohnehin jeden Morgen aufgemacht wird.

Brauchbare Trigger sind Ereignisse, die dir passieren, nicht Vorsätze, die du fasst:

• die wöchentliche Team-Runde am Montag
• der Moment, in dem eine Anfrage über das Kontaktformular reinkommt
• der Monatsabschluss
• jedes Mal, wenn du ein Angebot rausschickst
• der Kalendereintrag, der ohnehin existiert

Die Verhaltensforschung nennt so etwas Implementierungsintention, also einen Wenn-Dann-Plan. Peter Gollwitzer und Paschal Sheeran haben 2006 in Advances in Experimental Social Psychology eine Metaanalyse dazu veröffentlicht: Über 94 unabhängige Tests hinweg erreichten Wenn-Dann-Pläne eine mittlere bis große Effektstärke von d = .65 auf das Erreichen von Zielen. Das ist keine KI-Forschung, sondern Grundlagenpsychologie. Sie erklärt aber ziemlich gut, warum „ich nutze den Assistenten künftig öfter” nichts bringt und „immer wenn ein Angebot rausgeht, lasse ich den Assistenten vorher gegenlesen” etwas bringt.

Wenn du merkst, dass du für deinen Assistenten keinen ehrlichen Trigger findest: Das ist ein Befund, kein Versagen. Er gehört zu der Frage, wann sich ein eigener KI-Assistent überhaupt lohnt, und die hätte man auch vorher stellen können.

Einstiegshürde senken, bis es peinlich einfach ist

Zwischen „ich könnte den Assistenten nutzen” und „ich nutze ihn” liegen im Zweifel vier Klicks. Vier Klicks reichen, damit du es lässt.

Was hilft, in absteigender Wirkung:

Ein Lesezeichen an einer Stelle, die du sowieso ansiehst. Browser-Lesezeichenleiste, Pin im Tool, Verknüpfung im Team-Channel. Klingt nach nichts. Wirkt.

Ein Startsatz, den du nicht neu erfinden musst. Lege dir eine Zeile zurecht, mit der du das Gespräch immer beginnst, und leg sie dorthin, wo der Trigger passiert. In einem Textbaustein, im Notizzettel neben dem Monitor, in der Beschreibung des Assistenten selbst. Wer bei jedem Aufruf überlegen muss, wie er anfängt, hört nach drei Malen auf.

Der Assistent liegt dort, wo die Arbeit liegt. Wenn dein Team ohnehin in einem Tool arbeitet, ist ein Assistent in einem zweiten Tool im Nachteil. Das ist einer der Gründe, warum die Frage, wo du deinen Assistenten baust, keine reine Feature-Frage ist.

Kein Perfektionsanspruch beim Input. Wenn du erst eine saubere Aufgabenbeschreibung tippen musst, wird der Assistent nur benutzt, wenn du Zeit hast. Ein guter Assistent verträgt hingerotzten Input und fragt nach. Das gehört in die Constraints, nicht in deine Disziplin.

Eine Woche bewusst erzwingen

Der unangenehme Teil. Nach dem Bauen brauchst du eine Phase, in der du die Nutzung bewusst herstellst, auch wenn es sich langsamer anfühlt als der alte Weg.

Ich empfehle eine Woche. Nicht, weil eine Woche eine Gewohnheit erzeugt, sondern weil eine Woche reicht, um herauszufinden, ob es eine werden kann. Wie lange echte Automatisierung dauert, hat eine Gruppe um Phillippa Lally am University College London untersucht und 2010 im European Journal of Social Psychology veröffentlicht: 96 Teilnehmende, zwölf Wochen, ein selbst gewähltes tägliches Verhalten in einem festen Kontext. Der Median bis zum Erreichen von 95 Prozent der individuellen Automatisierungskurve lag bei 66 Tagen, die Spanne bei 18–254 Tagen. Die berühmten 21 Tage sind also Folklore, und die Streuung ist riesig.

Für die Praxis heißt das zweierlei. Erstens: Erwarte nicht, dass sich der Assistent nach drei Tagen von selbst trägt. Zweitens: Der feste Kontext gehört in dieser Forschung zum Versuchsaufbau dazu. Zurück zum Trigger.

Konkret sieht die Woche so aus:

1. Montag: Trigger festlegen und aufschreiben. Ein Satz, Wenn-Dann-Form.
2. Täglich: Bei jedem Auftreten des Triggers zuerst den Assistenten öffnen, auch wenn du die Aufgabe schneller selbst könntest.
3. Notieren, wo es hakt. Zwei Stichworte reichen. „Antwort zu lang.” „Kennt die neue Preisliste nicht.”
4. Freitag: 20 Minuten nachschärfen. Meist sind es die Constraints, seltener die Wissensbasis.

Punkt drei ist der wertvollste. Aus diesen Notizen entsteht die eigentliche Verbesserung, und sie sind die Grundlage dafür, den Assistenten systematisch zu testen und seine Qualität zu prüfen. Ohne die Woche hast du diese Daten nicht.

Punkt zwei klingt streng, ist aber der eigentliche Test. Wenn du am Mittwoch merkst, dass du die Aufgabe konsequent lieber selbst machst, obwohl der Assistent bereitsteht, hast du eine Antwort. Entweder ist das Ergebnis zu schwach, oder der Weg dorthin ist zu umständlich, oder die Aufgabe war nie das Problem. Alle drei Befunde sind brauchbar. Nur „ich komme nie dazu” ist keiner, weil das der Zustand ist, den die Woche gerade auflösen soll.

Ein Einwand, den ich für berechtigt halte: Eine erzwungene Woche kostet real Zeit, und zwar in der Woche, in der du sie am wenigsten hast. Wer im Tagesgeschäft steckt, empfindet das als Zumutung. Meine Antwort darauf ist keine Motivationsrede, sondern eine Reihenfolge. Erzwinge die Woche nur für einen Assistenten, für den mit dem klarsten Trigger. Die anderen warten.

Manche Assistenten gehören nach dem Test gelöscht

Jetzt der Teil, den Tool-Anbieter ungern schreiben. Nicht jeder gebaute Assistent verdient eine zweite Chance.

Löschkandidaten erkennst du an drei Merkmalen:

• Die Aufgabe tritt zu selten auf. Alles unter „einmal im Monat” hat es schwer. Bei „dreimal im Jahr” schreibst du beim nächsten Mal ohnehin einen frischen Prompt, und das ist völlig in Ordnung.
• Die Nacharbeit ist so groß wie die Aufgabe. Wenn du jedes Ergebnis komplett umschreibst, hast du einen Rechercheanlass, keinen Assistenten.
• Du hast ihn gebaut, weil es ging. Der Klassiker aus Workshops. Technisch beeindruckend, im Alltag irrelevant.

Löschen ist hier keine Niederlage. Ein Assistent, der nach der Testwoche stirbt, hat dir für wenig Aufwand gezeigt, wo dein Prozess nicht das Problem ist. Was du dabei über die Zerlegung in Aufgabe, Wissensdaten und Constraints gelernt hast, bleibt dir. Die Spezifikation ist wiederverwendbar, der konkrete Assistent nicht unbedingt.

Und was du behältst, braucht Pflege. Ein Assistent mit veralteter Wissensbasis wird schneller wieder abgeschaltet als einer, der nie lief, weil er falsche Antworten mit vollem Selbstbewusstsein liefert. Wie du ihn aktuell hältst, ohne dass es zum Zweitjob wird, ist der nächste logische Schritt.

Die Frage, die ich dir stellen würde

Welchen deiner gebauten Assistenten hast du in den letzten sieben Tagen tatsächlich geöffnet?

Wenn die Antwort „keinen” lautet, liegt das mit hoher Wahrscheinlichkeit nicht an der Qualität deiner Prompts. Es liegt daran, dass niemand definiert hat, wann das Ding drankommt. Und wenn du merkst, dass diese Frage bei euch im Team gar nicht beantwortbar ist, weil unklar ist, wer was nutzt und wer wofür zuständig ist, dann fangt eine Ebene früher an. Der KI-Readiness-Check führt euch strukturiert durch genau diese Standortbestimmung, bevor ihr den nächsten Assistenten baut.

Meine Klären-Bauen-Befähigen-Reihenfolge steht nicht zufällig so herum. Befähigen ist der Teil, der nach dem Bauen kommt, und der Teil, den fast alle streichen, wenn es eng wird. Er ist der Grund, warum der eine Assistent nach vier Wochen noch läuft und der andere nur im Protokoll steht.

Quellen

• How are habits formed: Modelling habit formation in the real world – Lally, van Jaarsveld, Potts & Wardle, European Journal of Social Psychology 40(6), 2010
• How are habits formed: Modelling habit formation in the real world (Eintrag) – Semantic Scholar
• How are habits formed: Modeling habit formation in the real world (Eintrag) – ResearchGate
• How to form a habit (Research Digest zur Lally-Studie) – British Psychological Society
• Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes – Gollwitzer & Sheeran, Advances in Experimental Social Psychology 38, 2006
• Implementation intentions and goal achievement: a meta-analysis of effects and processes (Volltext) – KOPS, Universität Konstanz
• Implementation intentions and goal achievement: A meta-analysis of effects and processes (Eintrag) – Semantic Scholar
• Implementation Intentions (Übersichtskapitel, PDF) – National Cancer Institute, Division of Cancer Control and Population Sciences