Wenn eine KI-Funktion im Produktivbetrieb schwächelt, ist der erste Reflex, den Prompt umzuformulieren. Meist ist das die falsche Stelle. Die größeren Gewinne — und die größeren Risiken — liegen in dem, was das Modell sieht.
Prompt Engineering hatte seinen Moment, zu Recht: Formulierung zählt, Beispiele helfen, Struktur leitet. Aber es ist zur Pflicht geworden. Jeder im Team kann heute an einem Prompt drehen. Was eine beeindruckende Demo von einer Funktion unterscheidet, die unter echten Nutzern besteht, ist selten die Formulierung der Anweisung. Es ist der Kontext — die gesamte Information, die dem Modell vorliegt, wenn es antwortet.
Was „Kontext” wirklich umfasst
Es ist leicht, „Kontext” auf „den Prompt” zu reduzieren. In der Praxis konkurriert alles Folgende um dasselbe Fenster, und jeder Teil ist eine Design-Entscheidung:
- Die System-Anweisungen und die Rolle, die Sie dem Modell gegeben haben
- Abgerufene Daten — Dokumente, Datensätze, Wissen, das zur Beantwortung herangezogen wird
- Tool-Definitionen und die Ergebnisse, die diese Tools zurückliefern
- Der Gesprächsverlauf, und wie viel davon Sie behalten
- Das Ausgabeformat und die Vorgaben, die Sie verlangen
Prompt Engineering justiert den ersten Punkt. Context Engineering ist die Disziplin, bewusst zu entscheiden, was in alle diese Punkte einfließt — und was draußen bleibt.
Die meisten „schlechten KI-Ausgaben” sind kein Denkfehler. Sie sind ein Kontextfehler — dem Modell fehlte, was es brauchte, oder es ging in dem unter, was es nicht brauchte.
Warum es der Hebel ist
Denken Sie daran, wo echte Fehler herkommen. Das Modell erfindet selbstbewusst ein Policy-Detail — weil die tatsächliche Policy nie in den Kontext geladen wurde. Es ignoriert eine kritische Vorgabe — weil diese vierzig Nachrichten zuvor in einem abgeschnittenen Verlauf lag. Es antwortet auf Basis veralteter Informationen — weil nichts im Kontext ihm sagte, was „aktuell” bedeutet. Keines davon wird durch eine cleverere Anweisung behoben. Sie werden behoben, indem man die Eingaben gestaltet.
Kontext als gestaltete Eingabe zu behandeln, verändert die Art, wie Sie bauen. Sie stellen schärfere Fragen: Was braucht das Modell wirklich, um das gut zu beantworten? Wo liegt diese Information, und wie kommt sie zuverlässig hinein? Was verstopft das Fenster, ohne sich seinen Platz zu verdienen? Ihr Kontextfenster ist ein Budget — geben Sie es für Signal aus, nicht für alles, was Sie zufällig haben.
Kontext ist auch der Ort, an dem Governance lebt
Hier kommt der Teil, der in regulierten Umfeldern am meisten zählt — und der Grund, warum Context Engineering und KI-Governance in Wirklichkeit dasselbe Handwerk aus zwei Blickwinkeln sind. Sobald Sie bewusst steuern, was in den Kontext des Modells gelangt, entscheiden Sie zugleich: welche Datenquellen freigegeben sind, was herausgefiltert werden muss, bevor es überhaupt das Modell erreicht, und was protokolliert werden muss, damit Sie später — einem Auditor gegenüber — genau belegen können, was eine bestimmte Antwort geprägt hat.
Eine ungesteuerte Kontext-Pipeline ist ein Compliance-Problem im Wartestand: sensible Daten fließen ungeprüft in Prompts, keine Aufzeichnung darüber, was verwendet wurde, keine Grenze bei den Quellen. Eine gesteuerte macht aus genau diesen Entscheidungen Kontrollen — freigegebene Quellen, Guardrails und einen Audit-Trail — ohne ein Wort am Prompt zu ändern.
Wo Sie anfangen
Wenn Sie eine KI-Funktion verbessern, widerstehen Sie dem Drang, zuerst den Prompt zu öffnen. Verfolgen Sie stattdessen den Kontext. Schreiben Sie jedes Stück Information auf, das das Modell für eine echte Anfrage erreicht, und markieren Sie, was essenziell ist, was Rauschen ist und was ganz fehlt. Meist liegt die Lösung genau dort — und es ist eine Lösung, die das System zugleich vertrauenswürdiger und leichter steuerbar macht.
Die Prompt-Formulierung ist die letzte Meile. Der Kontext ist die Straße, auf der Sie sie bauen.