Der Prompt ist nicht das System.

Wir verwechselten eine Anweisung mit einem Betriebsmodell.

Die erste Welle von KI am Arbeitsplatz lehrte alle dasselbe Ritual. Ein leeres Feld öffnen. Den Wunsch erklären. Die Antwort prüfen. Drei weitere Adjektive hinzufügen. Wiederholen, bis die Arbeit plausibel wirkt oder das Meeting beginnt.

Für persönliche Aufgaben ist das nützlich. Für umsatzbezogene Arbeit, die sich über Menschen, Systeme und Kunden wiederholt, ist es eine schlechte Grundlage. Ein Prompt beschreibt ein Ergebnis. Selten definiert er Entscheidungsverantwortung, maßgebliche Daten, erlaubte Änderungen, Qualitätsbewertung oder den Umgang mit Situationen außerhalb des Idealfalls.

Das Ergebnis ist Prompt-Folklore. Ein Kollege hat einen magischen Absatz. Eine andere hat siebzehn Beispiele in einem Dokument namens FINAL_v6. Die Organisation hat Aktivität, aber kein gemeinsames System, das sie prüfen oder verbessern kann.

Ein Prompt kann die Arbeit starten. Er kann sie nicht steuern.

Die Spezifikation wird zum wertvollen Artefakt.

Softwareteams entdecken Spezifikationen wieder, weil KI Implementierungen schneller erzeugen kann, als Menschen ihre Absicht erklären. In spezifikationsgetriebener Entwicklung wandert die wichtige Arbeit nach vorn: definieren, was das System tun muss, daraus einen Plan machen, die Arbeit zerlegen und einen Agenten unter expliziten Vorgaben implementieren lassen.

Dieselbe Umkehrung zählt für Revenue-Teams. Erstellt ein KI-System Kundenrecherche, sollte die Spezifikation nicht mit der Tonalität beginnen. Sie sollte bei der unterstützten Entscheidung beginnen. Was muss der Verkäufer vor dem Gespräch wissen? Welche Quellen sind erlaubt? Wie aktuell muss ein Signal sein? Welche Aussagen brauchen Quellenverweise? Was wird bei geringer Sicherheit weggelassen?

Sobald die Spezifikation explizit ist, werden Prompts zu Implementierungsdetails. Modelle können wechseln. Tools können wechseln. Die geschäftliche Absicht bleibt verständlich.

Spezifizieren Sie das Revenue System in fünf Teilen.

Eine nützliche Spezifikation ist kein 90-seitiges Anforderungsdokument. Sie ist ein kompakter Vertrag zwischen dem Unternehmen, den arbeitenden Menschen und dem System, das in ihrem Auftrag handelt.

„Recherchiere diesen Kunden“ ist eine Anfrage. Kein System.

Angenommen, ein Vertriebsteam möchte KI-generierte Gesprächsbriefings. Die Anfrage klingt einfach. Die verborgenen Entscheidungen sind es nicht. Welches Unternehmen ist bei Namensgleichheit gemeint? Gilt eine Stellenanzeige als Beleg für eine strategische Priorität? Wie alt darf eine Finanzierungsankündigung sein, bevor sie zur Nebensache wird? Soll das System aus einer Technologieentscheidung Probleme ableiten?

Eine Systemspezifikation macht diese Fragen sichtbar, bevor sie zu inkonsistenten Ergebnissen werden. Sie kann zwei Quellen für wesentliche Aussagen verlangen, Beobachtung von Ableitung trennen, Signale über sechs Monate ignorieren, Unsicherheit zeigen und Freigabe verlangen, bevor etwas ins CRM gelangt.

Das generierte Briefing kann weiterhin variieren. Der Prozess darum herum sollte es nicht. Eingaben, Berechtigungen, Entscheidungsregeln, Prüfungen und Zuständigkeit können explizit bleiben, auch wenn Sprache probabilistisch ist.

• Definieren Sie die Entscheidung vor dem Arbeitsergebnis.
• Benennen Sie maßgebliche Quellen, bevor Sie Tools verbinden.
• Schreiben Sie den Ausnahmefall, bevor Sie den Idealfall polieren.
• Wählen Sie den Freigabepunkt, bevor Sie Autonomie gewähren.
• Entscheiden Sie, welche Belege die Spezifikation nach dem Start verändern.

Eine Spezifikation sollte lernen, ohne wieder zu Folklore zu werden.

Die erste Spezifikation wird falsch sein. Echte Kunden erzeugen Ausnahmen, die Workshops nicht hervorbringen. Das Ziel ist nicht, jeden Sonderfall vorherzusagen. Es ist, neuem Wissen einen Ort zu geben.

Verwechselt ein Briefing wiederholt Tochtergesellschaften mit Muttergesellschaften, ändern Sie die Entitätsregel. Ignorieren Verkäufer einen Abschnitt, prüfen Sie, ob die Information schwach oder nur schlecht platziert ist. Lehnt eine Compliance-Prüfung eine Aussage ab, ändern Sie die Belegschwelle. Das System verbessert sich, weil betriebliches Feedback ein explizites Artefakt verändert, nicht weil jemand heimlich einen Satz zu einem privaten Prompt hinzufügt.

Das ist der Wandel von KI-Nutzung zu KI-Betrieb. Der Prompt ist nicht länger das Produkt. Der betreute Kreislauf wird zum Produkt.