KI-Wissensassistent (Enterprise Search)

Annotiertes Prüfbeispiel: RAG-Assistent

Fiktiver Lernfall. Die folgenden Erwartungen sind keine gemessenen Testergebnisse und keine Freigabe. Stand: 9. Oktober 2026.

1. Systemgrenze festlegen

   Ein fiktives Unternehmen möchte interne Richtlinien für seine Beschäftigten leichter auffindbar machen. Der Assistent beantwortet Fragen aus einer abgegrenzten Dokumentensammlung und verlinkt die verwendeten Fundstellen. Er darf weder E-Mails versenden noch Dateien ändern. Für den Pilot werden ausschließlich künstliche Inhalte eingesetzt. Die verantwortliche Fachstelle benennt Dokumenteigentümer, Nutzergruppen und einen technischen Betreiber. Vor einer Prüfung wird festgehalten, welche Version des Modells, welcher Suchindex und welche Berechtigungen gelten. Nicht beantwortet ist zunächst, ob der externe Modelldienst Anfragen speichert. Diese Frage gehört in die Vorbereitung und muss vor echten Daten geklärt werden. „Nur interne Dokumente“ beschreibt eine Herkunft, aber noch keine Vertrauensgrenze: Auch eine interne Datei kann manipulierte Anweisungen enthalten.

2. Angriffsweg und mögliche Folge beschreiben

   Eine präparierte Richtlinie enthält neben sachlichem Text die Anweisung, frühere Gesprächsinhalte an eine fremde Adresse zu übertragen. Die Suche liefert diese Passage als Kontext an das Sprachmodell. Behandelt das Modell den Dokumentinhalt als höherrangige Anweisung, liegt der Angriffsweg der indirekten Prompt Injection vor. Der Versuch muss nicht von der fragenden Person stammen. Im abgegrenzten Pilot ist eine echte Übertragung technisch ausgeschlossen; dennoch kann die Antwort verfälscht werden oder einen schädlichen Link enthalten. Das Team trennt deshalb drei Fragen: Wurde fremder Inhalt gefunden, wurde seine Anweisung befolgt und konnte eine unzulässige Wirkung entstehen? Die Einordnung als indirekte Prompt Injection beschreibt einen Prüfanlass, keine Eintrittswahrscheinlichkeit. Andere Bedrohungen wie unzulässiger Dokumentzugriff bleiben daneben eigenständig zu untersuchen.

3. Zwei Gegenmaßnahmen konkretisieren

   Die erste Maßnahme ist „Validierung der Inhaltsquellen“. Für diesen Pilot bedeutet das: Nur ausdrücklich freigegebene Repositorien werden indexiert; Herkunft, Dokumentversion und berechtigte Nutzergruppe bleiben an jeder Passage erhalten. Importregeln erkennen oder isolieren auffällige Inhalte und protokollieren ihre Entscheidung. Diese Umsetzung muss getestet werden, denn eine erlaubte Quelle kann weiterhin schädlichen Inhalt tragen. Die zweite Maßnahme ist „Sandbox-Verarbeitung externer Inhalte“. Der Verarbeitungsprozess erhält keine Versandwerkzeuge und keine Schreibrechte. Netzwerkzugriffe werden technisch begrenzt; abgerufener Text bleibt als nicht vertrauenswürdiger Inhalt gekennzeichnet. Eine Formulierung im Systemprompt allein belegt diese Grenze nicht. Der Verantwortliche dokumentiert, welche Infrastrukturregel die Beschränkung erzwingt und welche erlaubten Datenwege trotzdem erforderlich sind.

4. Prüfung und Nachweis vorab festlegen

   Das Team erstellt künstliche Testdokumente mit sichtbaren und versteckten Anweisungen sowie normale Vergleichsdokumente. Die Fälle decken erlaubte und unerlaubte Quellen, unterschiedliche Nutzerberechtigungen und Wiederholungen mit derselben Konfiguration ab. Erwartet wird: Unzulässige Quellen gelangen nicht in den Index; Dokumentbefehle lösen keine zusätzlichen Werkzeuge oder Netzwerkverbindungen aus; Antworten nennen überprüfbare Fundstellen. Normale Dokumente müssen weiterhin nutzbar bleiben. Für jeden Versuch werden Testkennung, Eingabe, abgerufene Passagen, Modell- und Regelversion, Antwort und relevante Netzwerkprotokolle zusammengeführt. Eine zweite Person prüft die Zuordnung und dokumentiert Abweichungen. Diese Erwartungen sind ein Prüfplan, keine beobachteten Ergebnisse. Ein fehlender Logeintrag ist nur dann aussagekräftig, wenn die Vollständigkeit der Protokollierung selbst geprüft wurde.

5. Grenzen benennen und nächste Entscheidung vorbereiten

   Auch bestandene Testfälle beweisen keine generelle Sicherheit. Neue Dokumenttypen, Modelländerungen und neue Werkzeuge können den Angriffsweg verändern. Vor einer Freigabe bleiben Aufbewahrung beim Modelldienst, Rechtsgrundlage, Berechtigungsdurchsetzung, Vorfallbehandlung und Wiederholungsprüfung zu klären. Die gesetzliche Einordnung folgt aus Zweck, Rolle und Klasse, nicht aus dem RAG-Begriff: Art. 14 betrifft Hochrisiko-Systeme; Art. 55 richtet sich an Anbieter von GPAI-Modellen mit systemischem Risiko. Ein gewöhnlicher Betreiber wird durch den Bedrohungsverweis nicht automatisch zum Modellanbieter. Die Vorbereitung sammelt den Fall, die Bedrohung, die Quellen und offene Nachweise. Sie vergibt keinen Risikowert und erteilt keine Betriebsfreigabe. Das Handout beschreibt weiterhin den Anwendungsfall; für den individuellen Prüfplan wird die Vorbereitung separat exportiert. Die zuständige Person hält außerdem fest, wer die offenen Punkte bis wann prüft und welche Entscheidung danach möglich ist.

Drei Kontrollfragen für Ihre Vorbereitung

1. Wer darf welche Dokumente vor dem Retrieval sehen?
2. Welche technischen Grenzen verhindern unerlaubte Handlungen?
3. Welche Versionen und Protokolle machen den Test nachvollziehbar?

Bedrohung mit vollständigen Gegenmaßnahmen · Validierung der Inhaltsquellen · Sandbox-Verarbeitung · OWASP LLM01:2026