Die eigentliche Arbeit liegt vor dem Prompt.
Der Prompt-Workshop, der zu spät begann
Der Workshop war gebucht, um Prompts zu verbessern. So stand es im Kalender, mit einem fröhlichen kleinen Zauberstab-Symbol, das später jemand bereute. Eine Gruppe aus Führungskräften, Analysten, Operatoren und Ingenieuren saß um einen Tisch mit einem gemeinsamen Dokument. Der aktuelle Prompt war auf dem Bildschirm. Er bat ein Sprachmodell, Kundenanfragen zu prüfen, die richtige Richtlinie zu identifizieren, eine Antwort zu entwerfen und Risiken zu kennzeichnen. Er war höflich, strukturiert und viel länger, als irgendjemand zugeben wollte. Er war auch nicht das Hauptproblem.
Der erste Testfall war ein Kunde, der nach einer verspäteten Lieferung um eine Ausnahme bat. Das Modell lieferte eine ordentliche Antwort. Dann sagte jemand aus dem Betrieb, dass die Richtlinie auf dem Bildschirm nicht mehr die sei, die das Team freitags verwende, weil eine vorübergehende Spediteursregel zweimal verlängert, aber nie in die Hauptrichtlinienseite eingearbeitet worden war. Jemand aus der Rechtsabteilung sagte, dass Ausnahmen über einem bestimmten Betrag eine Genehmigung erforderten, die Schwelle jedoch von der Produktkategorie abhing. Die Finanzabteilung fragte, wo Kulanzgutschriften erfasst würden. Der Support sagte, der Ton des Modells sei in Ordnung, aber der Kunde würde erneut anrufen, weil die Antwort das fehlende Tracking-Ereignis nicht erwähnte. Der Prompt saß da und wirkte unschuldig.
Keines dieser Probleme würde durch einen besseren Anweisungsabsatz behoben. Das Modell konnte nicht ableiten, welche Richtlinienseite maßgeblich war. Es konnte nicht wissen, dass eine vorübergehende Regel zur operativen Realität geworden war. Es konnte nicht entscheiden, wer Genehmigungsbefugnis hatte. Es konnte nicht erkennen, dass das fehlende Tracking-Ereignis die eigentliche Ursache für den nächsten Kontakt war. Der Prompt wurde gebeten, unklare Arbeit zu kompensieren. Dies ist ein häufiger Fehler. Menschen kommen mit einem Korb voller Prozessmehrdeutigkeit zum Prompt und bitten das Modell, elegant damit umzugehen.
Die eigentliche Arbeit findet vor dem Prompt statt. Es ist die Arbeit, die Aufgabe zu benennen, die Grenzen zu definieren, Quellen auszuwählen, Autorität festzulegen, Beispiele vorzubereiten, Fehlerpfade zu entscheiden, die Ausgabe zu gestalten, Qualität zu messen und Korrekturen zu ermöglichen. Prompting ist wichtig. Ein schlechter Prompt kann ein gutes Setup ungeschickt machen. Aber ein schöner Prompt auf einer unklaren Operation ist nur gut formulierte Verwirrung. Das Modell mag besser klingen. Die Arbeit wird dadurch nicht automatisch sicherer, billiger oder verständlicher.
Ein Prompt ist keine Prozesslandkarte
Ein Prompt kann einem Modell sagen, wie es sich in einem Kontext verhalten soll. Er kann den Kontext nicht erschaffen, wenn die Organisation das nicht getan hat. Er kann um Kürze, Struktur, Bescheidenheit und Quellenangaben bitten. Er kann eine Rolle beschreiben. Er kann ein Format festlegen. Er kann das Modell davor warnen, nicht zu raten. Das ist nützlich. Es ist aber auch wenig im Vergleich zu den Prozessfragen, die darüber entscheiden, ob ein KI-System hilft oder nur selbstbewusst in der Nähe der Arbeit redet.
Was ist die Aufgabe. Ist es Klassifikation, Extraktion, Zusammenfassung, Entwurf, Routing, Empfehlung, Verifikation oder Aktion. Welcher Teil ist automatisiert. Welcher Teil bleibt menschlich. Welcher Zustand ändert sich, wenn die Ausgabe akzeptiert wird. Wer ist betroffen. Welche Datensätze werden berührt. Welche Richtlinie gilt. Welche Belege sind Pflicht. Was passiert, wenn Belege fehlen. Welche Fehler sind tolerierbar. Welche Fehler verursachen Schaden. Diese Fragen bestimmen die Form des Systems. Ein Prompt, der nicht auf klaren Antworten aufbaut, wird zu einer höflichen Vermutung mit einem Namensschild.
Viele gescheiterte KI-Pilotprojekte beginnen mit einem Prompt, weil ein Prompt der sichtbarste Hebel ist. Er fühlt sich kreativ und unmittelbar an. Man kann ihn in einer Besprechung bearbeiten. Man kann eine neue Version ausprobieren, bevor der Kaffee kalt wird. Prozessdesign ist langsamer. Datenbereinigung ist langsamer. Zuständigkeitsklärung ist langsamer. Der Aufbau von Bewertungssätzen ist langsamer. Leider ist langsam nicht dasselbe wie optional. Die Teile, die vor dem Prompt übersprungen werden, tauchen später wieder auf als Halluzination, Nacharbeit, Misstrauen, Richtlinienausnahmen und eine große Tabelle namens Probleme.
Die bessere Reihenfolge ist nicht glamourös. Schreiben Sie die Arbeit auf. Gehen Sie reale Fälle durch. Identifizieren Sie Quellsysteme. Markieren Sie, welche Felder über Ergebnisse entscheiden. Trennen Sie Regeln von Urteilsvermögen. Entscheiden Sie, wo Menschen eingreifen. Definieren Sie Ausgabeverträge. Bauen Sie Beispiele auf. Legen Sie fest, wann abgelehnt wird. Testen Sie mit den Menschen, die mit dem Ergebnis leben werden. Erst dann wird der Prompt zu einem nützlichen Hebel. Davor ist er ein dekoratives Lenkrad auf einem Schreibtisch.
Die Aufgabe braucht eine Grenze, die scharf genug zum Testen ist
KI-Arbeit beginnt oft mit Verben, die zu groß sind. Hilfe beim Kundenservice. Unterstützung der Rechtsprüfung. Verbesserung der Planung. Unterstützung des Einkaufs. Berichte intelligenter machen. Das sind Ambitionen, keine Aufgaben. Ein Modell kann nicht gegen eine Ambition bewertet werden. Es kann gegen eine Aufgabe mit Eingaben, Ausgaben, Einschränkungen, Erfolgskriterien und Fehlerpfaden bewertet werden. Die engere Beschreibung mag sich weniger aufregend anfühlen. Sie ist auch der erste Moment, in dem die Arbeit baubar wird.
Eine scharfe Aufgabengrenze sagt, was das System sehen darf und was es ändern darf. Sie sagt, ob das Modell Quellenmaterial liest, einen Entwurf erstellt, strukturierte Felder extrahiert, eine Aktion empfiehlt oder ein Werkzeug aufruft. Sie sagt, welche Ausgaben endgültig sind, welche beratend und welche geprüft werden müssen. Sie sagt, was das System ablehnt. Sie sagt, wann das Modell nach mehr Belegen fragen sollte, statt die Antwort zu vervollständigen. Sie sagt, was außerhalb des Rahmens liegt, denn außerhalb des Rahmens werden ambitionierte Pilotprojekte zu Vorfallberichten.
Grenzen machen Bewertung möglich. Wenn die Aufgabe darin besteht, eine Antwort mit diesen Quellen und dieser Richtlinie zu entwerfen, kann die Qualität getestet werden. Wenn die Aufgabe darin besteht, die Servicequalität mit KI zu verbessern, kann jedes Ergebnis von jemandem mit genügend Folien als Fortschritt erklärt werden. Eine Grenze schützt auch Nutzer vor versehentlicher Eskalation. Ein Werkzeug, das mit dem Entwerfen beginnt, kann einen Button zum Senden bekommen. Ein Klassifikator kann zu einem Router werden. Ein Router kann zu einer Entscheidung werden. Ohne eine benannte Grenze fühlt sich diese Drift wie Akzeptanz an. Mit einer Grenze wird sie zu einem Änderungsantrag.
Die Grenze sollte in operativer Sprache formuliert sein, nicht nur in technischer Sprache. Der Support-Leiter sollte sie verstehen. Die Rechtsabteilung sollte sie verstehen. Der Datenverantwortliche sollte sie verstehen. Der Ingenieur sollte in der Lage sein, sie zu testen. Wenn der Prompt der einzige Ort ist, an dem die Grenze existiert, ist die Grenze fragil. Prompts sind wichtig, aber sie sind keine tragenden Richtlinien-Dokumente. Sie sind eher wie Anweisungen an eine sehr talentierte temporäre Arbeitskraft, die das Organigramm nie gesehen hat.
Quellen sind kein Stapel von Dokumenten
Viele Teams stellen beim Prompting fest, dass sie nicht wissen, welche Quellen maßgeblich sind. Sie haben Richtlinienseiten, PDFs, E-Mail-Anweisungen, Schulungsmaterial, veraltete Handbücher, Chat-Nachrichten, Ticket-Vorlagen, Tabellen-Tracker und die Erinnerung einer Mitarbeiterin, die alle anrufen, weil sie weiß, wie es wirklich funktioniert. Das Modell wird dann gebeten, aus der Wissensdatenbank zu antworten. Welches Wissen. Welche Datenbank. Diese Formulierung kann ein heldenhaftes Maß an Verschleierung leisten.
Quellenaufbereitung ist nicht glamourös, weshalb sie oft zu spät kommt. Es geht darum zu entscheiden, welches Dokument gewinnt, wenn Quellen widersprüchlich sind, wie Aktualität geprüft wird, wie temporäre Regeln auslaufen, wie Ausnahmen dargestellt werden, wie vertrauliches Material ausgeschlossen wird, wie Quellversionen erhalten bleiben und wie Zitierkennungen die Antwort des Modells überleben. Das ist keine Bürokratie. Es ist der Unterschied zwischen Abruf und Durchwühlen.
KI macht Quelldisziplin wichtiger, weil das Modell schwache Quellenpraktiken akzeptabel aussehen lassen kann. Es kann Fragmente zu flüssiger Prosa zusammennähen. Es kann Widersprüche glätten. Es kann aus veraltetem Material eine plausible Antwort erzeugen. Ein Suchergebnis mit sichtbaren Lücken wirkt unvollständig. Eine generierte Antwort mit denselben Lücken kann vollständig wirken. Je besser die Prosa, desto wichtiger die Herkunft. Vertrauen sollte nicht erlauben, eine schwache Quellenkette zu waschen.
Gute Quellenaufbereitung reduziert auch die Prompt-Komplexität. Ein Prompt voller Warnungen über widersprüchliche Richtlinien, veraltete Dokumente, fehlende Felder und Sonderausnahmen ist oft ein Symptom für Vernachlässigung vorgelagerter Schritte. Wenn die Abrufschicht bereits nach Autorität und Aktualität filtert, kann der Prompt kürzer sein. Wenn die Quelle strukturierte Metadaten trägt, muss das Modell sie nicht aus Absatzüberschriften ableiten. Wenn Ausnahmen als Regeln dargestellt sind, muss das Modell nicht mit Token-Limits zum Detektiv werden. Die beste Prompt-Verbesserung ist manchmal ein besserer Index.
Beispiele sind kleine Bausteine der Governance
Beispiele werden meist als Trainingshilfen betrachtet, aber sie sind auch Governance. Ein gutes Beispiel sagt, was Qualität in einer Situation bedeutet. Es zeigt, wie die Organisation mit Unsicherheit, fehlenden Belegen, widersprüchlichen Richtlinien, heiklem Ton, Eskalation und Verweigerung umgeht. Es zeigt dem Modell und dem Team, wie eine gute Antwort aussieht, aber auch, wie eine gute Nicht-Antwort aussieht. Das ist wichtig, weil viele ernsthafte Systeme versagen, indem sie antworten, wenn sie innehalten sollten.
Beispiele zu erstellen erzwingt Entscheidungen, die abstrakte Diskussionen vermeiden. Nehmen Sie zwanzig reale Fälle. Markieren Sie das korrekte Ergebnis. Markieren Sie akzeptable Alternativen. Markieren Sie inakzeptable Abkürzungen. Erklären Sie, warum. Schließen Sie Grenzfälle ein, die erfahrene Mitarbeitende zögern ließen. Schließen Sie auch alltägliche Fälle ein, denn Systeme, die nur mit Dramatik trainieren, lernen schlechte Manieren. Bitten Sie Fachexperten, uneins zu sein, und dokumentieren Sie die Uneinigkeit. Das ist langsamer, als das Modell zu bitten, vorsichtig zu sein. Es erzeugt auch eine gemeinsame Sprache für Vorsicht.
Beispiele sollten Negativfälle enthalten. Keine Quelle gefunden. Quellenkonflikt. Nutzer ohne Berechtigung. Anfrage außerhalb des Zwecks. Kunde fragt nach etwas, das einfach klingt, aber eine Richtlinie auslöst. Das Modell sollte lernen, wann es ablehnen, eskalieren, fragen oder strukturierte Unsicherheit zurückgeben soll. Wenn Beispiele nur erfolgreiche Antworten zeigen, neigt die Aufforderung zur Vollständigkeit. Vollständigkeit ist nicht immer Erfolg. Manchmal ist die beste Antwort nicht genug Beleg, was in einer Demo schwer zu feiern, aber in einem funktionierenden System nützlich ist.
Beispiele sind auch der Beginn der Evaluierung. Sie können zu Testvorlagen, Regressionsfällen, Schulung für Prüfende und Überwachungsstichproben werden. Wenn ein Vorfall passiert, kann ein korrigierter Fall zu einem neuen Beispiel werden. Das gibt dem System ein Gedächtnis. Ohne Beispiele werden Änderungen an der Aufforderung zu Stimmungsschwankungen. Jemand sagt, die Antwort fühle sich besser an. Jemand anderes sagt, sie fühle sich schlechter an. Das Modell lächelt in der Mitte, unbeirrt von Belegen.
Die Ausgabeform ist eine operative Entscheidung
Diskussionen über Aufforderungen verbringen oft zu viel Zeit mit dem Ton und zu wenig mit der Ausgabeform. Der Ton ist wichtig, besonders in der Kommunikation mit Kunden oder der Öffentlichkeit. Aber die Ausgabeform entscheidet, ob die Antwort geprüft, weitergeleitet, gespeichert, genehmigt, angefochten oder von einem anderen System verwendet werden kann. Ein Absatz kann angenehm sein. Eine strukturierte Ausgabe kann operabel sein. Ernsthafte KI-Arbeit braucht oft beides: lesbare Prosa für Menschen und Felder, die Maschinen verifizieren können.
Das Ausgabeformat umfasst Pflichtfelder, Quellenangaben, Konfidenz oder Unsicherheit, Ablehnungsgründe, Eskalationskennzeichen, betroffene Datensätze, vorgeschlagene Maßnahmen und den Freigabestatus durch Menschen. Es legt fest, ob das Modell ein Feld leer lassen darf. Es legt fest, ob es eine Richtlinienkennung zitieren muss. Es legt fest, ob es Kategorien erfinden darf oder aus einer kontrollierten Liste wählen muss. Es legt fest, was bei mehrdeutigen Eingaben geschieht. Diese Entscheidungen sind keine kosmetischen Prompt-Details. Sie sind Workflow-Design.
Strukturierte Ausgaben halten das Modell außerdem in seinem Zuständigkeitsbereich. Wenn das System ein separates Feld für Belege verlangt, werden unbelegte Behauptungen sichtbar. Wenn es einen Aktionstyp aus einer zulässigen Liste verlangt, wird kreative Werkzeugnutzung erschwert. Wenn es verlangt, dass Unsicherheit explizit ausgewiesen wird, können Prüfende priorisieren. Wenn es einen Ablehnungsgrund verlangt, können blockierte Fälle analysiert werden. Der Prompt kann diese Dinge anfordern, aber das umgebende System sollte sie validieren. Freundlich zu fragen ist keine Kontrolle. Es ist ein Vorschlag mit Formatierung.
Es gibt eine menschliche Seite. Menschen brauchen Ausgaben, die zu ihrem Arbeitsrhythmus passen. Eine Juristin braucht vielleicht Quellklauseln und Risikohinweise. Ein Support-Mitarbeiter braucht vielleicht einen kundenfertigen Entwurf plus interne Begründungscodes. Eine Planerin braucht vielleicht eine Routenempfehlung und die Einschränkung, die dazu geführt hat. Eine Führungskraft braucht vielleicht aggregierte Gründe statt einzelner Prosa. Wenn das Ausgabeformat die Nutzer ignoriert, mag der Prompt technisch korrekt sein und operativ nerven. Das ist eine verbreitete Leistung, aber keine nützliche.
Autorität kann nicht durch Hilfsbereitschaft impliziert werden
Ein hilfsbereites Modell lädt zum Vertrauen ein. Das ist gut, bis Hilfsbereitschaft mit Autorität verwechselt wird. Wenn das Modell einen Antwortentwurf erstellt, wer darf ihn versenden. Wenn es eine Erstattung empfiehlt, wer darf sie genehmigen. Wenn es Risiken einstuft, wer darf auf Grundlage der Einstufung handeln. Wenn es ein Feld extrahiert, wer korrigiert es. Wenn es keine Belege findet, wer entscheidet, ob fortgefahren wird. Diese Fragen müssen vor dem Prompt beantwortet werden, denn der Prompt kann keine institutionelle Autorität verleihen.
Autoritätsdesign umfasst Rollen, Schwellenwerte, Prüfwarteschlangen, Übersteuerungsrechte, Eskalationspfade und Prüfprotokolle. Es unterscheidet Vorschlag von Entscheidung. Es unterscheidet automatisierte Entscheidung von menschlicher Entscheidung, die durch Automatisierung unterstützt wird. Es legt fest, wann ein Mensch Quellmaterial sehen muss statt nur Modellprosa. Es legt fest, wann ein Werkzeugaufruf erlaubt und wann er blockiert ist. Es legt fest, wer für Schaden, Verzögerung, Korrektur und Kommunikation verantwortlich ist. Das Modell kann innerhalb dieses Designs helfen. Es sollte nicht das Design sein.
Das ist besonders wichtig, wenn KI zu bestehenden Arbeitsabläufen hinzugefügt wird. Bestehende Autorität kann informell sein. Eine leitende Person genehmigt Ausnahmen, weil alle wissen, dass man sie fragen muss. Eine Teamleiterin legt Richtlinien aus, weil sie die Grenzfälle gesehen hat. Eine Tabellenkalkulation trägt eine vorläufige Regel, weil das System es nicht kann. Wenn KI hinzukommt, wird informelle Autorität fragil. Das Modell kann die alte Mehrdeutigkeit schneller skalieren, als Menschen sie auffangen können. Die Arbeit vor dem Prompt besteht darin, Autorität so explizit zu machen, dass Skalierung nicht einfach Verwirrung skaliert.
Es ist erwähnenswert, dass Autorität nicht der Feind von Geschwindigkeit ist. Klare Autorität macht Arbeit oft schneller, weil Menschen wissen, was ohne Debatte laufen kann, was pausieren muss und wer entscheiden kann. Vage Autorität fühlt sich flexibel an, bis sie auf Volumen trifft. Dann wird jeder schwierige Fall zu einer kleinen Verfassungskrise, mit Chatverläufen als Fallrecht. Das ist kein empfohlenes Rechtssystem.
Evaluierung ist kein Stimmungscheck
Viele Prompt-Iterationen werden nach Bauchgefühl beurteilt. Diese Version klingt besser. Diese ist prägnanter. Diese hier ist weniger bestimmend. Solche Urteile können nützlich sein, aber sie reichen nicht aus. KI-Operationen brauchen eine Bewertung, die der Aufgabe folgt. Hat das Modell die richtige Quelle verwendet. Hat es Pflichtfelder übersehen. Hat es abgelehnt, wenn Belege fehlten. Hat es Hochrisikofälle eskaliert. Hat es Richtlinienkennungen erhalten. Haben Menschen es überschrieben. Haben Kundinnen und Kunden weniger Rückfragen gestellt. Hatten nachgelagerte Teams weniger Nacharbeit.
Die Bewertung sollte normale Fälle, Randfälle, adversariale Fälle, veraltete Quellen, fehlende Daten, widersprüchliche Richtlinien und Beispiele akzeptabler Ablehnung umfassen. Sie sollte wiederholbar sein. Sie sollte Modellversagen von Quellenversagen, Prompt-Versagen, Schnittstellenversagen und Prozessversagen unterscheiden. Sonst wird jedes Problem zu einem Prompt-Problem, weil der Prompt der Teil ist, den alle sehen können. Der sichtbare Teil ist nicht immer der schuldige Teil. Das gilt in der Software und in Besprechungen.
Die Bewertung entscheidet auch, wann Schluss ist. Ohne einen Testsatz und Freigabekriterien kann die Prompt-Arbeit endlos weitergehen, weil Sprache immer verbessert werden kann. Es wird immer ein weiteres Adjektiv geben, eine weitere Anweisung, ein weiteres Beispiel, eine weitere Formatierungsanpassung. Die Frage ist nicht, ob der Prompt perfekt ist. Die Frage ist, ob das System die Aufgabe innerhalb vereinbarter Risiko-, Kosten- und Qualitätsgrenzen erfüllt. Perfektion ist ein schlechter Release-Manager. Sie trägt keinen Pager.
Die Arbeit nach dem Prompt beginnt vor der Freigabe
Korrekturpfade sollten entworfen werden, bevor der erste Produktionsnutzer ein Problem meldet. Wie meldet ein Nutzer eine falsche Antwort. Wohin geht diese Meldung. Wer prüft sie. Ändert sich die Quelle. Ändert sich der Beispielbestand. Ändert sich der Prompt. Ändert sich eine Regel. Ändert sich ein Schwellenwert. Erhält ein Mensch Feedback. Wird der korrigierte Fall ein Regressionstest. Wenn Korrektur nicht entworfen ist, wird Feedback zu einem Haufen. Haufen sind der Ort, an dem Lernen ein langes Nickerchen macht.
Monitoring sollte ebenfalls vor der Freigabe entschieden werden. Verfolgen Sie nicht nur Latenz und Kosten, sondern auch Ablehnungsraten, Quellenfehlraten, Überschreibungsgründe, Eskalationslast, nachgelagerte Nacharbeit, Beschwerdethemen, veraltete Zitate und Veränderungen in der Aufgabenmischung. Die Antwortqualität des Modells ist nur ein Teil der operativen Qualität. Ein System kann gut antworten und trotzdem zu viel Arbeit an Menschen weiterleiten. Es kann schnell antworten und trotzdem mehr Korrekturen verursachen. Es kann Tickets reduzieren und trotzdem schwierigere Tickets erzeugen. Monitoring sollte Arbeit sehen, nicht nur Tokens.
The pre-prompt work never really ends. New policies appear. Source systems change. Users find shortcuts. The model changes. The business changes. A prompt that worked in May may be wrong in September because the work moved under it. This does not mean everything is fragile. It means AI operations need ownership. Someone must maintain task definition, sources, examples, evaluation, authority, and repair. Otherwise the prompt becomes a fossil with excellent grammar.
The lesson
The real work is before the prompt because prompting is the visible edge of a larger operating system. The model needs a task it can perform, sources it can trust, boundaries it cannot cross, outputs that can be checked, examples that encode judgement, authority that tells humans and tools what they may do, and evaluation that can distinguish improvement from nicer prose. Without that, the prompt carries responsibilities it cannot fulfil.
This view does not diminish prompting. It makes prompting more valuable. A prompt inside a prepared operation can be short, clear, testable, and maintainable. It can focus the model instead of compensating for ambiguity. It can evolve with examples and evidence. It can be changed with confidence because the team knows what good means. That is better than prompt mysticism, which mostly produces longer prompts and quieter doubts.
Before asking how to prompt the model, ask what work the organisation has already done for the model. Is the task named. Are sources authoritative. Are examples marked. Is output structured. Is authority explicit. Is failure safe. Is evaluation real. Is repair designed. If those answers are weak, start there. The most useful prompt in the room may be the one that makes everyone admit the prompt is not where the work begins.