Warum Prompt Engineering im Unternehmen anders aussieht

In der öffentlichen Diskussion wird Prompt Engineering oft auf „gute Fragen stellen" reduziert. Im Unternehmenskontext ist damit etwas anderes gemeint: die bewusste Gestaltung der Instruktionen, die ein produktives System jedes Mal wieder an ein Modell schickt, bevor eine Nutzerfrage überhaupt ankommt. Ein Prompt in einem produktiven Assistenten ist kein Satz im Chatfenster, sondern ein versionierter Baustein, der das Verhalten für tausende Anfragen pro Woche prägt.

Damit verschieben sich die Anforderungen. Ein guter Prompt zählt nicht mehr nach einem einzelnen beeindruckenden Ergebnis, sondern danach, ob er über viele verschiedene Eingaben hinweg konsistente, belastbare und prüfbare Antworten erzeugt. Das ist keine Kreativdisziplin, sondern eine Entwicklungsdisziplin mit Tests, Versionierung und Review.

Experimentieren vs. Systemarbeit

Die meisten Unternehmen kennen zwei Modi im Umgang mit Prompts, oft unbewusst. Der erste Modus ist Experimentieren: Eine Einzelperson probiert verschiedene Formulierungen, bis eine davon in einem Beispiel überzeugt. Dieser Modus ist sinnvoll als erster Schritt, trägt aber nicht in Produktion. Was an einem Beispiel funktioniert, kann an fünf anderen scheitern.

Der zweite Modus ist Systemarbeit: Prompts werden gemeinsam mit einem Testdatensatz, klaren Erwartungen und einer definierten Bewertung entwickelt. Jede Änderung wird gegen denselben Maßstab geprüft, und Verbesserungen in einem Fall dürfen nicht Verschlechterungen in einem anderen erzeugen. Erst dieser Modus liefert Prompts, die produktiv tragen.

Was einen belastbaren Prompt ausmacht

Drei Eigenschaften kehren in Prompts wieder, die im Betrieb halten. Erstens: klare Rolle und klarer Zweck. Ein Modell, das weiß, in welcher Rolle es antwortet und welches Ziel die Antwort erfüllen soll, trifft weniger Eigenheiten. „Du bist ein interner Support-Assistent für Bestellprozesse und antwortest ausschließlich auf Basis der bereitgestellten Richtlinien" ist schlanker und wirksamer als zehn Bullet-Punkte.

Zweitens: explizit erlaubtes Nicht-Antworten. Wenn im Prompt klar steht, dass „dazu liegen keine Informationen vor" eine akzeptable Antwort ist, reduziert sich die Neigung zu raten deutlich. Dieser Punkt überschneidet sich direkt mit dem Umgang mit Halluzinationen.

Drittens: eine klare Struktur der Ausgabe. Freier Text ist flexibel, aber schwer weiterverarbeitbar. Ein vorgegebenes Schema — ob JSON, Markdown-Abschnitte oder definierte Felder — diszipliniert das Modell und erleichtert Folgeschritte. Wer später einen Feldwert in ein Zielsystem schreiben oder eine Zusammenfassung in ein Ticket überführen will, profitiert davon in jedem einzelnen Fall.

System-Prompt, User-Prompt und Kontext

In produktiven Setups gehört der schöpferische Teil fast immer in den System- Prompt: Rolle, Regeln, Formatvorgaben, zulässige Auslassungen, Ton. Der User- Prompt liefert die eigentliche Frage plus Kontext — Texte, Datensätze, abgerufene Quellen aus einem Retrieval. Diese Trennung ist wichtig, weil sie dem Modell signalisiert, welche Teile fest sind und welche variabel.

Wer Rollen- und Regelanweisungen in den User-Prompt mischt, erzeugt ein System, das schlechter skaliert: Jede Änderung an der Regel verlangt eine Anpassung an der Anfrageschicht. Ein gepflegter System-Prompt lässt sich dagegen wie Software verantworten, mit Review, Versionierung und Release-Notizen.

Prompts als versionierte Artefakte

Ein Prompt, der produktiv läuft, gehört in ein Repository, nicht in ein Tabellenblatt. Es muss nachvollziehbar sein, welche Version wann in Produktion war, wer sie geändert hat und warum. Nur so lässt sich bei sinkender Qualität zurückverfolgen, ob ein Prompt-Wechsel, ein Modell-Update oder veränderte Daten den Unterschied gemacht haben.

Diese Disziplin klingt übertrieben, ist aber entscheidend, sobald mehrere Personen an einer Anwendung arbeiten oder sobald Modelle gewechselt werden. Ein Prompt, der auf einem Modell glänzt, kann auf einem anderen schwächer sein — genau dann ist ein Verlauf mit Tests Gold wert. Dieser Aspekt ist eng mit der Modellauswahl verknüpft.

Evaluation: woran man erkennt, dass ein Prompt besser ist

Ohne Messung ist jede Prompt-Änderung Bauchgefühl. In Produktion braucht es einen stabilen Testdatensatz mit typischen Anfragen, bewussten Grenzfällen und markierten Fallen, bei denen das Modell eigentlich zurückhaltend antworten sollte. Jede Prompt-Version läuft gegen diesen Datensatz, und das Ergebnis wird anhand definierter Kriterien bewertet.

Diese Bewertung ist selten eine einzelne Zahl. Es lohnt sich, faktische Richtigkeit, Format-Treue, Zurückhaltungsverhalten und — je nach Anwendung — Tonalität getrennt zu messen. Eine Prompt-Änderung, die die Richtigkeit um einen Prozentpunkt erhöht und gleichzeitig die Format-Treue bricht, ist keine Verbesserung. Diese Disziplin gehört klar in den Rahmen strukturierter LLM-Qualitätssicherung.

Wenige Techniken, die in der Praxis tragen

Einige Techniken haben sich über viele Projekte hinweg als belastbar erwiesen. Ein paar typische Beispiele helfen dem Modell, die gewünschte Struktur und den gewünschten Ton zu treffen, solange sie echte Grenzfälle abdecken und nicht nur einfache Fälle illustrieren. Ein klar benannter Output-Block, der den eigentlichen Antworttext vom Reasoning trennt, macht Antworten weiterverarbeitbar, ohne das Denken des Modells zu beschneiden.

Explizite Anti-Muster helfen ebenfalls. Eine Anweisung wie „Gib keine Quelle an, die nicht im bereitgestellten Kontext steht" ist wirksamer als eine vage Aufforderung zur Korrektheit. Und: Weniger ist oft mehr. Lange Prompts mit widersprüchlichen Regeln verlieren gegen kurze Prompts mit klar priorisierten Anweisungen.

Häufige Fehler im Unternehmenseinsatz

Der erste Fehler ist, Prompts nur in der Anwendungsschicht zu pflegen und als Text-Literal in den Code einzubauen. Sobald mehrere Personen beteiligt sind, verliert man so den Überblick. Prompts gehören in einen klar benannten Ort, idealerweise mit Test- und Review-Zyklen.

Der zweite Fehler ist, Prompts stillschweigend zu ändern, ohne die gleiche Sorgfalt wie bei Code anzusetzen. Ein Satz mehr oder weniger kann das Verhalten spürbar verschieben. Jede Änderung verdient einen kurzen Review und einen Vergleich gegen den Testdatensatz.

Der dritte Fehler ist, zu viel in den Prompt zu stopfen. Wer Rolle, Format, Fachregeln, Beispiele, Anti-Muster und Tonalität in ein einziges Textstück wirft, erzeugt widersprüchliche Anweisungen. Eine bewusste Trennung — etwa System-Prompt, Beispielblock und Kontext-Einspielung — ist stabiler.

Der vierte Fehler ist, Prompt-Qualität nur auf Chat-Fälle zu beziehen. In Extraktions- oder Klassifikationsaufgaben sind andere Kriterien zentral: Feld-Treue, Robustheit bei ungewöhnlichen Eingaben, sauberer Umgang mit fehlenden Werten. Ein Prompt, der für Dialog optimiert ist, kann bei strukturierter Ausgabe schwächer sein.

Einordnung in das Gesamtsystem

Prompts sind ein Hebel, aber nur einer von mehreren. In vielen Projekten wird stundenlang am Prompt geschraubt, obwohl der eigentliche Engpass in den Daten oder im Retrieval liegt. Eine gute Faustregel: Wenn ein Prompt-Problem sich partout nicht mit Prompt-Mitteln lösen lässt, lohnt der Blick auf Datenaufbereitung, Retrieval, Tool-Use oder Modellwahl.

Im Rahmen unseres Bereichs AI Engineering behandeln wir Prompt Engineering deshalb als Teil einer Architektur, nicht als eigenständige Disziplin. Prompts, Modelle, Daten und Auswertung greifen ineinander. Wer das trennt, optimiert an der Oberfläche und verschiebt Probleme, statt sie zu lösen.

Wann professionelle Unterstützung sinnvoll ist

Für kleine, explorative Use Cases reicht interne Neugier und ein gutes Modell. Sobald eine Anwendung aber gegenüber Kunden oder Fachbereichen stabil funktionieren soll, ändert sich der Anspruch. Dann braucht es Tests, Versionierung, definierte Evaluation und ein Prompt-Regime, das auch bei Teamwechseln hält.

Wir arbeiten mit Unternehmen, die Prompt Engineering nicht als Kür, sondern als Teil ihres KI-Betriebs verstehen. In der Praxis heißt das: Prompts als versionierte Artefakte führen, gegen Testdatensätze bewerten, bei Modellwechseln gezielt neu prüfen und mit Monitoring im Betrieb verbinden. Wer an diesem Punkt steht, sollte ihn nicht dem Zufall überlassen.