Context Assembly ist eine Governance-Entscheidung

Jeder kennt das Phänomen: Je voller das Kontextfenster, desto unzuverlässiger das Modell. Halluzinationen nehmen zu, die sorgfältig definierte Rolle franst aus - irgendwann benimmt sich der nüchterne Projektassistent wie Captain Jack Sparrow. Die Reaktion darauf ist überall dieselbe: Token sparen. Verdichten, zusammenfassen, nur das Relevante einspielen.

Alles richtig. Aber die Diskussion optimiert durchgehend auf Kapazität und Kosten - und übersieht die Frage, die eigentlich zuerst kommt: Was fließt da eigentlich, und wer hat entschieden, dass es fließen darf?

Eine LLM weiß über dich, dein Projekt und euer Gespräch exakt das, was im Kontextfenster steht. Nicht mehr. Dort landet alles: System-Prompt, Gesprächshistorie, Meetingprotokoll, Wiki-Auszug, Suchergebnis. Je länger die Zusammenarbeit, desto voller das Fenster. Sobald es um private oder berufliche Informationen geht, ist das Kontextfenster der Ort, an dem all diese Daten zusammenlaufen - und damit der Ort, an dem sich entscheidet, welche Information welchen Agenten erreicht.

Verdichtung ist Datenweitergabe mit unscharfem Filter

Die Standard-Antwort auf ein volles Fenster ist Verdichtung. Ein zweiter LLM-Aufruf extrahiert „alles zum Thema XY”. Technisch funktioniert das. Aber schauen wir genau hin.

Erstens: Das komplette Protokoll fließt durch den Extraktions-Aufruf. Auch die Gehaltsdiskussion, die Kundennamen, das versehentlich gepastete Passwort. Der Extraktor selbst hat alles gesehen - bevor der Filter greift. Wer dafür einen externen Frontier-Anbieter nutzt, hat die Daten bereits weitergegeben.

Zweitens: Ein probabilistisches System entscheidet, was „relevant” ist. Die Zusammenfassung erbt keine Berechtigungen des Originals. Sie ist ein neues Artefakt ohne Zugriffskontrollen und landet im Kontext eines Agenten, der über Tools mit der Außenwelt spricht.

Verdichtung löst das Kapazitätsproblem. Sie erzeugt dabei ein Governance-Problem: An jedem Verdichtungspunkt verlassen Informationen die Kontrolle ihres Ursprungssystems - und niemand hat entschieden, ob sie das dürfen.

Erinnerungen brauchen ein Policy-Schema, keinen Dump

Der Ausweg liegt nicht in besseren Prompts für den Extraktor. Sondern darin, dass Erinnerungen von Anfang an so abgelegt werden, dass die Weitergabeentscheidung deterministisch getroffen werden kann - bevor ein LLM ins Spiel kommt.

Jede abgelegte Information braucht vier Attribute:

• Gruppierung - zu welchem Projekt, Mandanten, Themengebiet gehört sie?
• Erfassungsdatum - Informationen altern. Der Architekturstand von vor acht Monaten ist keine Erinnerung, sondern eine Falle.
• Kontext - „Der Kunde will Feature X” aus einem Brainstorming ist etwas anderes als derselbe Satz aus einem unterschriebenen Angebot.
• Berechtigung - wer darf diese Information erfahren und weiterverarbeiten? Das Attribut, das in fast jedem Memory-Setup fehlt.

Mit diesen Attributen ändert sich die Kontext-Assembly grundlegend. Zuerst filtert eine deterministische Schicht nach Berechtigung, Mandant und Kanal. Erst danach darf ein LLM innerhalb dieser Teilmenge verdichten. Das LLM entscheidet, was wichtig ist. Es entscheidet nie, was fließen darf.

Das ist dieselbe Logik, die bei Tool-Zugriffen längst Standard ist. Auf der Informationsebene fehlt diese Disziplin fast überall.

Der Extraktor ist selbst das Problem

Ein Einwand liegt nahe: Wenn die deterministische Schicht vorfiltert, kann man dem LLM-Verdichtungsschritt dann nicht einfach vertrauen? Nein. LLMs scheitern plausibel, nicht offensichtlich.

Ein Extraktor, der PII durchlässt, produziert keinen Fehler. Er produziert eine sauber formulierte Zusammenfassung, in der zufällig eine Kundennummer steht. Was das erste Modell plausibel falsch macht, winkt das zweite oft plausibel durch.

Deshalb brauchen wir deterministische Schichten um den LLM-Schritt herum:

• Vor der Extraktion: Nur freigegebene Dokumente gelangen überhaupt in den Aufruf.
• Nach der Extraktion: Regelbasierte Prüfung auf strukturierte PII (IBANs, E-Mails, Kundennummern, Secrets).
• Am Egress: Ein Policy-Check, bevor Inhalte das System verlassen. Die letzte Instanz ist eine Regel, kein Modell.

Die verbleibende Lücke - unstrukturierte sensible Information ohne klares Muster - bleibt eine ehrliche Restgröße, abgedeckt durch stichprobenhafte menschliche Prüfung, nicht durch ein weiteres Modell. Wer behauptet, sie sei mit einem zweiten LLM geschlossen, verkauft Wahrscheinlichkeit als Garantie.

Kein Kapazitätsproblem

Kontextfenster-Management gilt als gelöstes Problem: Verdichtung, RAG, sauberes Chunking. Das stimmt, solange man es als Kapazitätsproblem behandelt.

Es stimmt nicht mehr, sobald man es als das behandelt, was es architektonisch ist: der Punkt, an dem Informationen aus Systemen mit Zugriffskontrolle in ein System ohne Zugriffskontrolle übergehen. Jede Zusammenfassung ist ein neues Artefakt ohne die Berechtigungen des Originals. Jeder Extraktions-Aufruf ist eine Weitergabe.

Wer Erinnerungen als getaggten, policy-gefilterten Bestand aufbaut statt als Dump, holt sich diese Kontrolle zurück - mit vier Attributen und einer deterministischen Schicht, nicht mit besseren Prompts.

Das Kontextfenster ist kein Speicher. Es ist ein Egress-Punkt.