Vom Prompt Engineering zum Context Engineering: Warum Kontext der neue Hebel für Unternehmens-KI ist

Die meisten gescheiterten KI-Projekte im Mittelstand scheitern nicht am Modell. Sie scheitern daran, dass das Modell zur falschen Zeit die falschen Informationen sieht — oder die richtigen gar nicht erst bekommt. Wer 2024 noch am perfekten Prompt feilte, optimiert heute etwas Größeres: die gesamte Informationsumgebung, in der ein KI-Modell arbeitet. Context Engineering ist der Name dieses Wandels — und für Unternehmen weit mehr als ein Buzzword. Denn sobald Sie Kontext bewusst gestalten, fließen interne Dokumente, Kundendaten und Tool-Ergebnisse in das Modell. Damit wird aus einer Technikfrage zwangsläufig auch eine Datenschutzfrage. Dieser Beitrag zeigt beide Seiten: die Architektur, die funktioniert — und die Rechtspflichten, die mitlaufen.

Was ist Context Engineering? (Definition)

Context Engineering ist die Disziplin, das Kontextfenster eines KI-Modells gezielt mit genau den richtigen Informationen für den nächsten Schritt zu füllen. Es umfasst nicht nur die einzelne Eingabe (den Prompt), sondern alles, was sonst noch im Kontext landet: System-Anweisungen, abgerufene Dokumente, Werkzeug-Ergebnisse, Gesprächsverlauf und gespeichertes Wissen. Geprägt wurde der Begriff 2025 unter anderem von KI-Forscher Andrej Karpathy und Shopify-CEO Tobi Lütke.

Karpathy beschrieb es als „die delikate Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen”. Lütke fasste es als „die Kunst, den gesamten Kontext bereitzustellen, sodass die Aufgabe für das Modell plausibel lösbar wird”. Anthropic formalisierte den Begriff in einem viel beachteten Engineering-Beitrag vom 29. September 2025 als „die Strategien, um die optimale Menge an Tokens während der Inferenz zu kuratieren und zu pflegen”.

Was gehört alles zum Kontext eines LLM?

Der „Kontext” eines Sprachmodells ist kein einzelner Text, sondern ein dynamisch zusammengesetztes Bündel. Typischerweise gehören dazu:

• System-Prompt / Instruktionen — Rolle, Regeln, Tonalität.
• RAG / Retrieval — zur Laufzeit eingespeiste, relevante Dokumente.
• Tools — definierte Funktionen, die das Modell aufrufen darf (etwa eine Datenbankabfrage).
• Memory — kurzfristiger Gesprächsverlauf und langfristig persistentes Wissen.
• Beispiele — Few-Shot-Vorlagen, an denen sich das Modell orientiert.

Prompt Engineering kümmert sich nur um den ersten Punkt. Context Engineering orchestriert sie alle.

Prompt Engineering vs. Context Engineering — der Unterschied

Die kürzeste Abgrenzung: Prompt Engineering fragt „Wie formuliere ich die Eingabe?”, Context Engineering fragt „Auf welche Informationen muss das Modell gerade zugreifen können?” Prompt Engineering ist eine einmalige Formulierungsaufgabe; Context Engineering ist ein laufender Prozess, der bei jedem Schritt neu entscheidet, was ins Modell wandert.

Dimension	Prompt Engineering	Context Engineering
Gegenstand	Einzelne Eingabe (Wortlaut)	Gesamte Informationsumgebung
Zeithorizont	Punktuell, pro Anfrage	Laufend, über viele Schritte
Persistenz	Flüchtig	Persistent (Memory, Wissensbasis)
Komplexität	Niedrig	System-Ebene (Architektur)
Analogie	Ein gutes Rezept aufschreiben	Eine voll ausgestattete Küche bereitstellen

Wichtig für die Einordnung: Prompt Engineering ist heute eine Teilmenge von Context Engineering, kein Gegensatz. Ein präziser Prompt bleibt nützlich — er ist nur einer von mehreren Hebeln geworden.

Ist Prompt Engineering tot?

Nein. Die Fähigkeit, klar zu instruieren, bleibt relevant; sie ist nur nicht mehr ausreichend. Branchenumfragen aus 2026 zeigen den Verschiebepunkt deutlich: Eine Mehrheit der IT- und Datenverantwortlichen hält Prompt Engineering allein für unzureichend, um KI „at scale” zu betreiben, und ein Großteil der Datenteams plant, 2026 in Context-Engineering-Kompetenz zu investieren (DataHub, 2026). Der Begriff „tot” ist Clickbait — „aufgewertet zur Teildisziplin” trifft es besser.

Warum der Wandel? Der Paradigmenwechsel 2026

Der Engpass moderner Unternehmens-KI ist selten das Modell selbst. Die Spitzenmodelle sind fähig — sie wissen nur nichts über Ihr Unternehmen. Der eigentliche Hebel liegt in den proprietären Daten drumherum: Verträge, Wissensdatenbanken, Tickets, interne Richtlinien. Wer KI vom Prototyp in den Produktivbetrieb bringt, stellt fest: Die meisten Fehler in Agentensystemen sind keine Modellfehler mehr, sondern Kontextfehler — das Modell bekam die falschen, veralteten oder unvollständigen Informationen.

Genau das markiert den Paradigmenwechsel: weg von „besser fragen”, hin zu „besser versorgen”. RAG, Tools und Memory sind die Mechanik dieser Versorgung.

Der Engpass verschiebt sich: Nicht die Modellfähigkeit entscheidet über den Erfolg eines KI-Projekts, sondern die Qualität des Kontexts, den Sie dem Modell bereitstellen — Daten, Tools und Memory.

Der neue Hebel im Detail — RAG, Tools, Memory, Kontextfenster

RAG / Retrieval — Wissen zur Laufzeit einspeisen

Retrieval-Augmented Generation (RAG) holt zur Anfragezeit passende Dokumente aus einer Wissensbasis und legt sie dem Modell als Kontext vor. So antwortet die KI auf Basis aktueller, firmeneigener Inhalte statt aus dem Trainingsgedächtnis. RAG ist mächtig — aber nur eine Komponente von Context Engineering, nicht das Ganze. Wann RAG und wann stattdessen Fine-Tuning das richtige Werkzeug ist, hängt vom Use-Case ab; für sich verändernde, belegpflichtige Inhalte ist RAG fast immer die robustere Wahl.

Tools — was das Modell tun darf

Tools sind definierte Funktionen, die das Modell aufrufen kann: eine Suche, eine Berechnung, ein Datenbankzugriff. Hier zählt das Design: Ein überladenes, mehrdeutiges Tool-Set führt laut Anthropic zu schlechteren Entscheidungen als wenige, klar abgegrenzte Werkzeuge.

Memory — kurz- und langfristig

Memory unterscheidet den Gesprächsverlauf (kurzfristig) vom persistenten Wissen (langfristig), das etwa in einer Vektordatenbank liegt. Eine bewährte Technik ist strukturiertes Notieren: Der Agent schreibt Zwischenstände außerhalb des Kontextfensters fort und ruft sie später gezielt ab.

Das Kontextfenster managen

Das Kontextfenster ist die begrenzte Token-Kapazität, die ein Modell pro Anfrage „im Blick” hat. Die Fenster sind zuletzt stark gewachsen — Google kündigte mit Gemini 2.5 Pro am 25. März 2025 ein Fenster von einer Million Tokens an. Doch es bleibt endlich, und mehr Inhalt ist nicht automatisch besser; warum es trotz wachsender Fenstergrößen ein knappes Gut bleibt, vertiefe ich im Beitrag zu Kontextfenster und Token-Limits. Gängige Techniken, um es sauber zu halten:

• Compaction / Zusammenfassung — bei Annäherung an die Grenze den Verlauf verdichten.
• Offloading — Wissen nach außen auslagern und nur bei Bedarf zurückholen.
• Isolation über Sub-Agenten — spezialisierte Teilagenten arbeiten mit sauberem Kontext und liefern nur eine destillierte Zusammenfassung (oft 1.000–2.000 Tokens) zurück.

Warum mehr Kontext nicht automatisch besser ist

Ein zentrales Praxiswissen: Qualität sinkt, wenn das Fenster überläuft. Drei Failure-Modi, die Unternehmen kennen sollten:

• Context Rot — die Genauigkeit der Informationsabfrage nimmt ab, je voller das Fenster wird (Anthropic, 2025).
• Context Poisoning — eine einmal eingeschleppte Halluzination oder Fehlinformation reproduziert sich über Folgeschritte.
• Context Distraction / Confusion — zu viele, teils widersprüchliche Inhalte lenken das Modell vom Ziel ab.

Die Konsequenz: Context Engineering ist Kuratieren, nicht Anhäufen.

Was bedeutet das für Unternehmen?

Von Einmal-Prompts zu gewarteten Kontext-Systemen

Ein guter Prompt war ein Einzelartefakt. Ein Kontext-System ist Infrastruktur: Es braucht Wartung, Freigabeprozesse, Budget-Kontrolle für Token-Kosten und nachvollziehbare Protokolle, welche Informationen die KI bei einer Entscheidung „gesehen” hat. Wer RAG, Memory und Tools einführt, übernimmt damit auch dauerhaften Betriebs- und Governance-Aufwand — das ist eine bewusste Investitionsentscheidung, kein Nebeneffekt.

Kontext ist (oft) personenbezogen — die Datenschutz-Dimension

Hier liegt der blinde Fleck der meisten Context-Engineering-Beiträge. Sobald RAG-Dokumente, Memory-Inhalte und Tool-Ergebnisse in das Kontextfenster fließen, werden in aller Regel personenbezogene oder sensible Unternehmensdaten verarbeitet — und das ist ein Verarbeitungsvorgang im Sinne der DSGVO.

Die Datenschutzkonferenz (DSK) hat dazu am 17. Oktober 2025 eine Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode veröffentlicht. Kernaussagen für die Praxis:

• Es braucht eine Rechtsgrundlage nach Art. 6 DSGVO — eine pauschale Berufung auf „berechtigtes Interesse” trägt nicht automatisch.
• Die Verarbeitung findet sowohl in der Retriever- als auch in der LLM-Komponente statt; beide sind zu betrachten.
• RAG heilt nicht die Datenschutzprobleme eines rechtswidrig trainierten Basismodells.
• Erforderlich sind technisch-organisatorische Maßnahmen wie Mandantentrennung, rollenbasierte Zugriffsrechte auf die Vektordatenbank, ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) und ggf. eine Datenschutz-Folgenabschätzung (Art. 35 DSGVO).

Übersetzt: Wer den Kontext gestaltet, gestaltet einen Datenverarbeitungsprozess. Die Frage „Was darf die KI sehen?” ist immer auch eine Rechtsfrage. Ob im konkreten Fall eine Pflicht zur Datenschutz-Folgenabschätzung besteht, hängt von Umfang und Sensibilität der Daten ab — bei umfangreichen oder besonders schützenswerten Beständen ist sie regelmäßig angezeigt.

Governance und Haftung des Kontexts

Wer verantwortet, was die KI „weiß”? Diese Frage gehört in eine KI-Nutzungsrichtlinie. Hinzu kommt die KI-Kompetenz-Pflicht: Art. 4 der EU-KI-Verordnung (AI Act) ist seit dem 2. Februar 2025 in Kraft und verpflichtet Unternehmen, ein angemessenes KI-Verständnis bei Beschäftigten sicherzustellen (Art. 4 AI Act praktisch umsetzen). Die nationale Durchsetzung soll ab dem 2. August 2026 greifen.

Zur Einordnung des Gesamtrahmens: Über mögliche Verschiebungen einzelner Fristen für Hochrisiko-KI (Anhang I und III des AI Act) wird auf EU-Ebene weiterhin verhandelt — die EU-Kommission hat dazu am 19. November 2025 einen Vorschlag („Digital Omnibus on AI”) vorgelegt. Wichtig für die Praxis: Eine verschobene Frist ändert nichts an den inhaltlichen Pflichten — verschoben heißt nicht abgeschafft. Da sich der Zeitplan hier bewegt (Stand: Januar 2026), sollten Sie den jeweils aktuellen Stand vor konkreten Projektentscheidungen gegen die amtlichen Quellen (EUR-Lex, DSK) prüfen.

Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.

Wie fängt mein Unternehmen an?

Pragmatisch und datenschutzbewusst in kleinen Schritten:

1. Use-Case eng eingrenzen — ein klar umrissenes Problem statt „KI für alles”.
2. Datenquellen inventarisieren — was soll die KI sehen, und enthält es personenbezogene Daten?
3. Rechtsgrundlage klären, bevor die Technik steht — die Reihenfolge entscheidet über Auditfestigkeit.
4. Pilot mit EU-/On-Prem-Datenresidenz — Risiko klein halten, dann skalieren.

Diesen Weg — RAG-Systeme und KI-Agenten so zu bauen, dass sie technisch funktionieren und beim Kontext datenschutzrechtlich sauber bleiben — gehen wir bei MusketierSoftware aus einer Hand: Wirtschaftsjurist und Entwickler in einer Person.

FAQ

Was ist Context Engineering einfach erklärt?

Context Engineering ist die Disziplin, das Kontextfenster eines KI-Modells gezielt mit den richtigen Informationen zu füllen — aus System-Anweisungen, abgerufenen Dokumenten (RAG), Werkzeugen, Memory und Verlauf. Ziel ist, dass das Modell eine Aufgabe zuverlässig lösen kann.

Was ist der Unterschied zwischen Prompt Engineering und Context Engineering?

Prompt Engineering optimiert die einzelne Eingabe („Wie formuliere ich?”). Context Engineering gestaltet die gesamte Informationsumgebung („Worauf muss das Modell zugreifen können?”). Prompt Engineering ist heute eine Teilmenge von Context Engineering.

Ist Context Engineering dasselbe wie RAG?

Nein. RAG (Retrieval-Augmented Generation) ist eine wichtige Komponente — das Einspeisen relevanter Dokumente zur Laufzeit. Context Engineering umfasst zusätzlich Tools, Memory, das Management des Kontextfensters und die Vermeidung von Failure-Modi wie Context Rot.

Warum ist mehr Kontext nicht automatisch besser?

Weil die Modellqualität mit überfülltem Kontextfenster sinkt. Phänomene wie Context Rot (sinkende Abrufgenauigkeit), Context Poisoning (sich reproduzierende Fehler) und Context Distraction führen dazu, dass Kuratieren wichtiger ist als Anhäufen.

Ist Context Engineering DSGVO-relevant?

Ja. Sobald RAG-Dokumente, Memory oder Tool-Ergebnisse personenbezogene Daten enthalten, liegt eine Verarbeitung nach DSGVO vor. Die DSK-Orientierungshilfe (Oktober 2025) verlangt u. a. eine Rechtsgrundlage, einen Auftragsverarbeitungsvertrag, technische Maßnahmen wie Mandantentrennung und ggf. eine Datenschutz-Folgenabschätzung. Keine Rechtsberatung im Einzelfall.

Fazit

Der Wandel vom Prompt zum Kontext ist kein Hype-Begriff, sondern eine Reifung: Unternehmens-KI gewinnt man nicht über cleverere Sätze, sondern über sauber gestaltete, gewartete und rechtssichere Informationsumgebungen. Wer Context Engineering ernst nimmt, behandelt es als das, was es ist — Architektur, Betrieb und Datenschutz in einem.

Sie wollen KI im Unternehmen einsetzen, ohne beim Kontext datenschutzrechtlich aufzulaufen? Sprechen wir in einem Erstgespräch über Ihren konkreten Use-Case.

— Leon Lotz, Wirtschaftsjurist (MusketierSoftware)

---

Quellen — Stand 04.01.2026

• Anthropic — „Effective context engineering for AI agents” (29.09.2025): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Andrej Karpathy, Definition „delicate art and science of filling the context window” (X, 2025): https://x.com/karpathy/status/1937902205765607626
• Google — „Gemini 2.5: Our newest Gemini model with thinking” (1-Mio.-Token-Kontextfenster, 25.03.2025): https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/
• DataHub — „Context Engineering vs Prompt Engineering” (Branchenumfrage 2026): https://datahub.com/blog/context-engineering-vs-prompt-engineering/
• Elastic — „Context engineering vs. prompt engineering”: https://www.elastic.co/search-labs/blog/context-engineering-vs-prompt-engineering
• DSK — „Orientierungshilfe: Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode” (17.10.2025): https://www.datenschutzkonferenz-online.de/orientierungshilfen.html
• SKW Schwarz — Einordnung der DSK-Orientierungshilfe zu RAG: https://www.skwschwarz.de/news/KI-Flash-Neue-Orientierungshilfe-der-DSK-zu-RAG-basierten-kI-Systemen
• Fraunhofer Academy — „AI Literacy: EU AI Act Art. 4 zu KI-Kompetenz” (in Kraft seit 02.02.2025): https://blog.academy.fraunhofer.de/blogbeitraege/ai-literacy/
• TÜV Rheinland Consulting — „Digital Omnibus on AI: Fristen der KI-Verordnung” (zum Kommissionsvorschlag vom 19.11.2025): https://consulting.tuv.com/aktuelles/ki-im-fokus/digital-omnibus-ki-verordnung-fristen