Kontext schlägt Modell: Warum datenschutzkonforme LLMs meist genügen

Wer über KI im Träger nachdenkt, fragt reflexhaft zuerst nach dem Modell: GPT, Claude, ein offenes Modell? Wer zusätzlich Datenschutz ernst nimmt, spürt hier sofort einen Zielkonflikt, denn die stärksten Modelle stehen bei US-Anbietern. Die gute Nachricht: Diese Frage steht meist an der falschen Stelle. Für die Aufgaben, die im Alltag tatsächlich anfallen, ist selten das Modell der Engpass, sondern der Kontext, den man ihm gibt.

Was „Kontext” konkret meint

Kontext ist nicht das, worauf das Modell trainiert wurde, sondern das, was man ihm zur Laufzeit vorlegt: die passenden Textstellen aus den eigenen Dokumenten (per RAG, siehe die vorige Ausgabe), die saubere Aufbereitung dieser Dokumente und der Prompt. Bei einer geerdeten Aufgabe, also einer, die aus vorgegebenen Unterlagen beantwortet wird, erfindet das Modell kein Wissen. Es arbeitet mit dem, was es bekommt. Die Qualität der Antwort hängt dann an der Qualität dieses Kontexts.

Warum das mehr zählt als Modellgröße

Genau so beschreibt es auch die Aufsicht. Die DSK-Orientierungshilfe zu RAG-Systemen (Oktober 2025) macht die Richtigkeit einer Antwort an mehreren Stellschrauben fest, und keine davon ist die Größe des Modells: an Qualität, Aktualität und Vollständigkeit der Referenzdokumente, an der Datenaufbereitung (Kopf- und Fußzeilen bereinigen, sinnvolle Chunk-Größe und Überlappung), an der Qualität des Embedding-Modells (für deutsche Texte ein deutschsprachig trainiertes) und an der Kontexttreue des Modells. Als wirksame Maßnahme nennt sie einen Systemprompt, der das System anweist, „ausschließlich mithilfe der referenzierten Quellen zu antworten.”

Bemerkenswert ist, wohin die Orientierungshilfe bei der Modellwahl zeigt: Sie empfiehlt ein eher kleineres Sprachmodell, das weniger Fakten auswendig speichert, und verlangt, die Eignung dieser Wahl zu prüfen und zu dokumentieren. Das ist das Gegenteil der Modelljagd. Die Guidance selbst legt nahe, das kleinste Modell zu nehmen, das die Aufgabe besteht.

Die ehrliche Einordnung

Das heißt nicht, dass alle Modelle gleich gut sind. Die großen Spitzenmodelle führen bei harten Aufgaben weiterhin: komplexes mehrstufiges Schließen, anspruchsvolle Programmierung, offene Synthese ohne Vorlage. Wo eine Aufgabe das wirklich braucht, kann der Abstand zählen. Nur ist das die Minderheit dessen, was ein Träger tatsächlich zu tun hat. Der Großteil ist geerdete, deutschsprachige Büro- und Wissensarbeit: aus Unterlagen antworten, zusammenfassen, aus einer Vorlage entwerfen, Informationen finden. Für diese Aufgaben schließt ein leistungsfähiges, in der EU betreibbares offenes Modell mit gutem Kontext den praktischen Abstand in der Regel.

Der Preis der Modelljagd

Immer das neueste Modell haben zu wollen, hat zwei Kosten. Entweder gehen die Daten an einen US-Spitzenanbieter, das ist der Datenschutz-Konflikt vom Anfang. Oder man baut das System bei jedem Modellwechsel neu an. Steckt man denselben Aufwand stattdessen in den Kontext, also in saubere Daten, gutes Retrieval, ein deutschsprachiges Embedding und präzise Prompts, zahlt sich das unabhängig vom Modell aus. Und es bleibt übertragbar: Wer auf offene Modelle setzt, kann dasselbe System in der EU-Cloud oder auf dem eigenen Server betreiben und das Modell später austauschen, ohne den Kontext wegzuwerfen.

Was das praktisch heißt

Die Reihenfolge der Investition kehrt sich um:

1. Datenaufbereitung zuerst. Schlechte Eingangsdaten kann kein Modell reparieren.
2. Retrieval-Qualität: deutschsprachiges Embedding, sinnvolles Chunking.
3. Prompt und Kontextgestaltung: das Modell an die Quellen binden.
4. Erst dann die Modellwahl, und unter den geeigneten das kleinste, das die Qualitätsschwelle erreicht.

Und ein wichtiger Zusatz: Testen sollte man an den eigenen Aufgaben, nicht an öffentlichen Ranglisten. Die Leaderboards messen oft etwas anderes als die Arbeit, die im Haus anfällt.

Die Frage „reicht ein datenschutzkonformes Modell?” beantwortet sich dann meist durch eine Gegenfrage: „ist der Kontext gut genug?” Dort gehört die Arbeit hin, und dieser Teil bleibt der eigene.

Quellen

• DSK, Orientierungshilfe „Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode”, Oktober 2025: PDF
• Lewis et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, arXiv:2005.11401: Link
• Gao et al., „Retrieval-Augmented Generation for Large Language Models: A Survey”, arXiv:2312.10997: Link
• Fraunhofer IESE, Blog zu Retrieval-Augmented Generation: Link