Context Engineering: Warum Prompt Engineering für KI im Unternehmen nicht mehr ausreicht

Zwei Jahre lang lautete der Rat an Unternehmen gleich: Schreibt bessere Prompts. Baut eine Prompt-Bibliothek. Stellt einen Prompt Engineer ein. Dann kamen die Ergebnisse. Die MIT-NANDA-Studie zu KI in Unternehmen stellte fest, dass rund 95 Prozent der generativen KI-Pilotprojekte keinen messbaren Effekt auf Gewinn und Verlust hatten⁴. Die Fehlschläge lagen selten daran, dass das Modell zu schwach war. Sie lagen daran, dass das Modell nichts über das Unternehmen wusste, dem es helfen sollte.

Genau diese Lücke schließt Context Engineering. Ein Prompt sagt dem Modell, was es tun soll. Der Kontext sagt ihm, womit es arbeitet: Ihre Verträge, Ihre Auftragshistorien, Ihre Produktspezifikationen, die Entscheidung, die Ihr Team letztes Quartal getroffen hat, und warum. Kein noch so cleverer Prompt kann Fakten erfinden, die das Modell nie erhalten hat. Der eigentliche Hebel für Unternehmens-KI ist nicht die Formulierung der Anfrage. Es ist die kontrollierte Informationsumgebung, in der das Modell arbeitet.

Dieser Leitfaden ist für den CTO, die Operations-Leitung oder die Geschäftsführung, die immer wieder “Context Engineering” hört und wissen will, was es tatsächlich bedeutet, warum Prompt-Bibliotheken bei der Skalierung scheitern und wie man die kontrollierte Kontextebene aufbaut, die KI verlässlich macht. Bei Superkind hat diese Ebene einen Namen: das Company Brain.

Die Grenze des Prompt Engineering

Prompt Engineering brachte Unternehmen durch die Demo-Phase. Bis in den Produktivbetrieb bringt es sie selten. Der Grund ist strukturell: Ein Prompt arbeitet mit dem, was das Modell bereits weiß, und ein allgemeines Modell kennt das Internet, nicht Ihr Unternehmen. Sobald eine Frage von internen Fakten abhängt, stößt der Prompt an eine Grenze.

• Pilotprojekte bleiben beim Skalieren stecken - Der MIT-NANDA-Bericht “The GenAI Divide: State of AI in Business 2025” fand heraus, dass rund 95 Prozent der generativen KI-Pilotprojekte kaum oder keinen messbaren Gewinnbeitrag zeigen, während nur etwa 5 Prozent schnelle Erfolge sehen⁴.
• Die Ursache ist Kontext, nicht Fähigkeit - Der Bericht führt die Lücke vor allem auf brüchige Arbeitsabläufe, schwaches kontextbezogenes Lernen und schlechte Passung zum Tagesgeschäft zurück. Generische Werkzeuge scheitern, weil sie nicht lernen, wie das Unternehmen wirklich arbeitet⁵.
• Agentenprojekte werden abgebrochen - Gartner prognostiziert, dass bis Ende 2027 mehr als 40 Prozent der agentischen KI-Projekte eingestellt werden, wegen steigender Kosten, unklaren Nutzens und unzureichender Kontrollen⁶.
• Wissen ist verstreut - Das McKinsey Global Institute stellte fest, dass Wissensarbeiter fast ein Fünftel der Arbeitswoche allein damit verbringen, interne Informationen zu suchen oder die Kollegin zu finden, die sie hat¹⁰. Genau diesen Kontext braucht eine KI und erreicht ihn nicht.
• Prompts können die Lücke nicht füllen - Sie können die Formulierung endlos verfeinern, aber wenn die Auftragshistorie, die Vertragsklausel oder die Entscheidung des letzten Technikers nicht vor dem Modell liegt, ist die Antwort ein Ratespiel im Gewand von Selbstsicherheit.

Jedes dieser Symptome weist auf dieselbe Wurzel: Das Modell arbeitet ohne den richtigen Kontext. Die Formulierung zu korrigieren behebt nicht die fehlende Information. Deshalb verschiebt sich die Disziplin.

Was Context Engineering wirklich ist

Der Begriff wurde Mitte 2025 bekannt, als Shopify-CEO Tobi Lütke argumentierte, “Context Engineering” beschreibe die eigentliche Fähigkeit besser als “Prompt Engineering”, und Andrej Karpathy ihm öffentlich zustimmte². Seitdem ist er von den Entwicklerkreisen ins Unternehmen gewandert. Hier eine präzise Definition.

Context Engineering ist die Praxis, die gesamte Informationsumgebung zu gestalten und zu kontrollieren, in der ein Modell arbeitet: welches Wissen, welche Daten, früheren Entscheidungen, welches Memory und welche Werkzeuge im Moment der Anfrage verfügbar sind. Anthropic, das einen viel beachteten Leitfaden dazu veröffentlicht hat, beschreibt Kontext als die Menge der Token, die das Modell bei der Antwort sieht, und Context Engineering als die Arbeit, diese Token innerhalb der Grenzen des Modells so nützlich wie möglich zu machen¹.

Prompt Engineering ist eine Teilmenge, kein Synonym

Prompt Engineering fragt: Wie formuliere ich diese Anfrage? Context Engineering stellt die größere Frage: Was muss das Modell wissen, sich merken und tun können, um diese Anfrage gut zu beantworten? Die Formulierung ist nur einer von vielen Bausteinen.

Warum Prompt-Bibliotheken im Unternehmen nicht skalieren

Viele Unternehmen reagieren auf die Prompt-Grenze mit einer Prompt-Bibliothek: einem geteilten Ordner mit “guten Prompts”, der Unternehmensfakten in sorgfältig formulierten Anweisungen festhält. Das fühlt sich nach Fortschritt an. Es skaliert nicht, und zwar aus diesen Gründen.

1. Prompts verdrahten Fakten, die sich ändern - Ein Prompt, der sagt “unsere Rückgabefrist beträgt 14 Tage”, wird an dem Tag zur Belastung, an dem sich die Regel ändert. Jemand muss jeden Prompt finden und umschreiben, der sie nannte. In der Praxis tut das niemand, also verrottet die Bibliothek stillschweigend.
2. Sie sind personengebunden, nicht geteilt - Der großartige Prompt, den eine Kollegin schrieb, liegt in ihren Notizen. Die nächste Person erfindet ihn neu, etwas schlechter. Es gibt keine einzige Wahrheitsquelle, also ist die Qualität im Unternehmen uneinheitlich.
3. Sie tragen keine Berechtigungen - Ein Prompt, der einen sensiblen Vertrag einfügt, funktioniert, bis die falsche Person ihn ausführt. Prompt-Bibliotheken kennen kein Konzept davon, wer was sehen darf.
4. Sie brechen bei realer Varianz - Prompts sind auf den Normalfall getrimmt. Die Ausnahme, der Sonderfall, der ungewöhnliche Auftrag ist genau dort, wo sie scheitern - und Ausnahmen sind der Großteil der Unternehmensarbeit.
5. Sie können sich nichts merken - Jede Sitzung beginnt bei null. Der Agent, der diesen Kunden gestern betreute, weiß heute nichts über ihn, weil das Wissen in einem wegwerfbaren Chat lag, nicht in einer dauerhaften Ebene.
6. Sie verbessern sich nicht - Wenn eine Antwort falsch ist, hilft das Korrigieren des Prompts nur diesem einen Prompt. Es gibt keinen Mechanismus, durch den die Korrektur jede künftige Antwort im Unternehmen verbessert.

Der Punkt ist nicht, dass Prompts nutzlos sind. Der Punkt ist, dass ein Prompt eine Anweisung ist, und eine Anweisung ohne verlässliche Informationsumgebung dahinter ist bloße Hoffnung. Das skalierbare Gut ist die Ebene, nicht die Bibliothek.

Die Anatomie einer kontrollierten Kontextebene

Eine kontrollierte Kontextebene hat Struktur. Sie ist keine Vektordatenbank mit hineingeworfenen Dokumenten. Fachbeiträge zum Wandel von Prompts hin zu geregeltem Wissen beschreiben vier Teile, die zusammenarbeiten^7,8.

Die vier Teile

• Wissen - Der kuratierte Bestand an Unternehmensfakten: Prozesse, Produkte, Richtlinien, Kundenhistorien und die Begründung hinter früheren Entscheidungen. Das macht aus, dass die KI Ihr Unternehmen kennt, nicht das Internet.
• Retrieval - Das System, das für jede Anfrage entscheidet, welchen Ausschnitt dieses Wissens es vor das Modell bringt. Gutes Retrieval ist selektiv, weil Kontext eine endliche Ressource ist¹.
• Memory - Die Beständigkeit, die Kontext über Sitzungen und Nutzer hinweg trägt, sodass die KI sich erinnert, was letztes Mal geschah, statt bei jeder Anfrage bei null zu beginnen.
• Governance - Die Regeln, die den Kontext vertrauenswürdig machen: Eigentum, Quellennachweis, Berechtigungen, Aktualitätsdaten und ein Audit-Trail für jede Antwort.

Context Engineering vs. RAG vs. Fine-Tuning

Teams verwechseln Context Engineering oft mit den Techniken darin. RAG und Fine-Tuning sind Werkzeuge. Context Engineering ist das System, das entscheidet, wann und wie sie eingesetzt werden. So hängen sie zusammen.

• Retrieval-Augmented Generation (RAG) - Holt relevante Dokumente zur Laufzeit und fügt sie in den Prompt ein. Es ist eine der wichtigsten Techniken, um Kontext bereitzustellen, hat für sich allein aber keine Governance, kein Memory und keine Aktualitätslogik.
• Fine-Tuning - Passt die Gewichte des Modells an Ihre Daten an. Nützlich für Ton und Format, schlecht für Fakten, die sich ändern, weil Nachtraining langsam ist und das Wissen im Modell einfriert.
• Context Engineering - Die Disziplin, die Retrieval, Memory, Werkzeuge und Governance zusammen orchestriert und entscheidet, was abgerufen, was gemerkt und wer etwas sehen darf.

Ein größeres Kontextfenster ersetzt nichts davon. Es ist sitzungsgebunden, wird bei jedem Prompt neu bezahlt und unterliegt Context Rot. Eine kontrollierte Kontextebene ist dauerhaft, geteilt und berechtigungsbewusst - Eigenschaften, die ein reines Fenster für sich nie haben wird.

Das Company Brain: Context Engineering, das bleibt

Context Engineering beschreibt die Disziplin. Ein Company Brain ist, wie sie aussieht, wenn Sie daraus ein dauerhaftes Gut machen. Statt den Kontext in jeder Anfrage neu zusammenzustellen, bauen Sie eine dauerhafte, kontrollierte Ebene aus Ihrem Mitarbeiterwissen, Ihren Prozessen und Daten, auf die jeder KI-Mitarbeiter zugreift.

• Es lernt Ihr Unternehmen, nicht das Internet - Das Company Brain hält fest, wie Ihr Geschäft wirklich läuft: Ihre Begriffe, Ihre Ausnahmen, Ihre Kunden, Ihre Arbeitsweise. Ein allgemeines Modell kann das nicht wissen. Das Company Brain ist der Ort, an dem dieses Wissen lebt.
• Es ist dauerhaft und geteilt - Eine vertrauenswürdige Ebene bedient jeden KI-Mitarbeiter und jeden Menschen, der mit ihm arbeitet. Der Kontext verschwindet nicht, wenn ein Chat schließt oder eine Mitarbeiterin geht.
• Es ist berechtigungsbewusst - Der Zugriff spiegelt Ihre bestehenden Regeln. Ein KI-Mitarbeiter greift immer nur auf den Kontext zu, für den der anfragende Nutzer freigegeben ist.
• Es wird durch Feedback besser - Wenn Ihr Team eine Antwort korrigiert, verbessert die Korrektur die Ebene, sodass die nächste Antwort im ganzen Unternehmen besser ist. Kontext kumuliert, statt zu verfallen.
• Es sitzt auf Ihren Systemen - Das Company Brain verbindet sich mit E-Mail, Teams, SharePoint, CRM, ERP und DATEV, wo Ihr Wissen bereits liegt. Kein Rip-and-Replace, kein Migrationsprojekt.

So bauen Sie Ihre Kontextebene auf

Sie bauen eine Kontextebene nicht, indem Sie das ganze Meer auskochen. Sie beginnen mit einem Arbeitsablauf und dem Wissen, von dem er abhängt, beweisen es und erweitern dann. Hier die praktische Reihenfolge.

1. Wählen Sie einen wertvollen Arbeitsablauf - Nehmen Sie eine wiederkehrende, wissensintensive Aufgabe, deren Antworten von internen Fakten abhängen: Rechnungseingang, Auftragserfassung, Mahnwesen oder Support-Triage. Enger Umfang macht das erste Ergebnis schnell.
2. Erfassen Sie das benötigte Wissen - Listen Sie genau auf, von welchen Fakten die Aufgabe abhängt und wo sie liegen. Hier entdecken die meisten Teams, dass ihr Wissen über Postfächer, Laufwerke und Köpfe verstreut ist.
3. Verbinden Sie die Quellen, migrieren Sie nicht - Binden Sie die Ebene über APIs an die Systeme an, die das Wissen bereits halten. Ziel ist, aus der Wahrheitsquelle zu lesen, nicht sie in ein weiteres Silo zu kopieren.
4. Definieren Sie Governance von Anfang an - Legen Sie Eigentum, Zugriffsregeln, Quellennachweis und Aktualität vor dem Go-Live fest, nicht danach. Eingeplante Governance ist günstig; nachträglich aufgesetzte ist ein Neubau.
5. Fügen Sie selektives Retrieval hinzu - Konfigurieren Sie die Ebene so, dass sie für jede Anfrage den richtigen Wissensausschnitt vor das Modell bringt und dabei im Attention-Budget bleibt, statt das Fenster zu fluten¹.
6. Schließen Sie den Feedback-Loop - Geben Sie den Menschen, die die Arbeit tun, eine einfache Möglichkeit, Antworten zu korrigieren, und lassen Sie Korrekturen in die Ebene zurückfließen, sodass sie jede Woche besser wird.
7. Messen Sie gegen eine Basislinie - Halten Sie die heutigen Kosten des Arbeitsablaufs fest (Zeit, Fehler, Verzögerungen), bevor Sie live gehen, und verfolgen Sie dieselben Kennzahlen danach. Die Kontextebene muss ihren Platz in Zahlen verdienen.

Kontrollierter Kontext: DSGVO und EU-KI-Verordnung

Für ein deutsches oder europäisches Unternehmen ist “kontrolliert” nicht optional. Die Kontextebene ist genau der Ort, an dem Datenschutz und KI-Regulierung auf die betriebliche Realität treffen - deshalb muss Governance in sie eingebaut sein.

• Berechtigungen spiegeln Ihre Organisation - Die Kontextebene erbt Ihre bestehenden Zugriffsregeln, sodass ein KI-Mitarbeiter nie ein Dokument zutage fördert, das der anfragende Nutzer nicht selbst öffnen könnte. Das ist die erste DSGVO-Verteidigungslinie.
• Daten bleiben in Ihrer Infrastruktur - Eine gut gebaute Kontextebene liest über verschlüsselte Verbindungen aus Ihren Systemen und hält personenbezogene Daten in Ihrer Umgebung und unter Ihren Aufbewahrungsregeln, statt sie zu exportieren.
• Jede Antwort ist nachvollziehbar - Weil Antworten ihre Quelle zitieren, können Sie zeigen, warum die KI gesagt hat, was sie sagte. Diese Nachvollziehbarkeit unterstützt die Transparenz- und Dokumentationspflichten der EU-KI-Verordnung, die ab August 2026 vollständig anwendbar ist¹¹.
• Aktualität verhindert veraltete Entscheidungen - Governance umfasst Aktualitätsdaten, sodass die Ebene keine Richtlinie oder keinen Preis ausgibt, der sich letztes Quartal geändert hat. Aktueller Kontext ist eine Compliance-Eigenschaft, nicht nur eine der Qualität.
• Audit-Trails machen Prüfungen überstehbar - Wenn ein Aufseher, Prüfer oder Kunde fragt, wie eine Entscheidung zustande kam, hat eine kontrollierte Ebene den Nachweis. Ein ungeregelter Haufen Dokumente hat ihn nicht.

Wie Superkind hier ansetzt

Superkind baut maßgeschneiderte KI-Mitarbeiter für mittelständische und große Unternehmen, und das Company Brain ist die kontrollierte Kontextebene, auf der sie laufen. Der Ansatz ist prozessorientiert: Ausgangspunkt ist, wie Ihre Teams tatsächlich arbeiten, nicht eine generische Vorlage, an die Sie sich anpassen müssen.

• Company Brain als Kontextebene - Ihr Mitarbeiterwissen, Ihre Prozesse und Daten werden zu einer dauerhaften, kontrollierten Ebene. KI-Mitarbeiter greifen darauf zu, sodass sie Ihr Unternehmen kennen, nicht das Internet.
• Prozessorientierte Analyse - Wir beobachten, wie Menschen ihre Zeit verbringen, und bilden den echten Arbeitsablauf ab, bevor wir bauen. Keine Annahmen, keine Vorlagen.
• Sitzt auf Ihrem bestehenden Stack - Das Company Brain verbindet sich mit E-Mail, Teams, SharePoint, CRM, ERP und DATEV. Kein Rip-and-Replace, nichts Neues, das Ihr Team lernen muss.
• Erster Anwendungsfall in Wochen - Ein fokussierter Arbeitsablauf geht in Wochen live statt in Sechs-Monats-Rollouts, weil der Umfang eng beginnt und dann wächst.
• Berechtigungsbewusst von Grund auf - Zugriffsregeln spiegeln Ihre Organisation, sodass KI-Mitarbeiter immer nur Kontext nutzen, für den der anfragende Nutzer freigegeben ist.
• Wird jeden Tag besser - Ihr Team arbeitet ab dem ersten Tag mit der KI und gibt Feedback, und die Kontextebene verbessert sich dadurch, statt zu verfallen.
• Ergebnisse statt Lizenzen - Die Preisgestaltung ist an Anwendungsfälle mit messbarem ROI gebunden, der vor dem Bau definiert wird, nicht an Lizenzen pro Platz.
• Daten bleiben Ihre - Personen- und Unternehmensdaten bleiben in Ihrer Infrastruktur unter Ihren Aufbewahrungsregeln, mit Antworten, die bis zur Quelle nachvollziehbar sind.

Entscheidungsrahmen: Brauchen Sie eine Kontextebene?

Nicht jedes Team muss heute eine kontrollierte Kontextebene bauen. So erkennen Sie, wo Sie stehen.

Häufig gestellte Fragen

Verwandte Artikel

• Ein größeres Kontextfenster ist kein Unternehmensgedächtnis
• Warum 400.000 Copilot-Agenten Ihr Unternehmen immer noch nicht kennen
• Der Feedback-Loop: Wie Ihre KI-Mitarbeiter jede Woche besser in Ihrem Unternehmen werden
• Persistenter Kontext für KI-Agenten: Was Mittelstands-IT-Teams 2026 über Memory-Design wissen müssen
• Der Context Graph: Warum das Speichern von Ergebnissen nicht reicht

Henri Jung

Mitgründer von Superkind, wo er KMU und Großunternehmen hilft, maßgeschneiderte KI-Agenten einzusetzen, die wirklich zu ihrer Arbeitsweise passen. Henri treibt es an, die Lücke zwischen dem, was KI kann, und dem Wert, den sie in echten Unternehmen schafft, zu schließen. Er hat zu viele KI-Pilotprojekte scheitern sehen - nicht weil das Modell schwach war, sondern weil es ohne den Kontext des Unternehmens arbeitete. Er ist überzeugt, dass der Mittelstand alles hat, um bei KI vorauszugehen - er braucht nur den richtigen Ansatz.