Fragen Sie Ihren gesamten Dokumentenbestand — ohne dass er das Haus verlässt

Wer einer KI eine Frage zu den eigenen Unterlagen stellt („Wie hoch ist die Instandhaltungsrücklage in der WEG Musterstraße?“), braucht zwei Dinge: eine Suche, die die richtige Textstelle im Bestand findet, und ein Sprachmodell, das daraus eine Antwort formuliert. Diese Kombination heißt RAG (Retrieval-Augmented Generation) und hat eine oft übersehene Eigenschaft: Nur der zweite Schritt braucht überhaupt ein externes Modell. Die Suche selbst, also das Durchforsten hunderter Verträge, Protokolle und Abrechnungen, kann vollständig auf dem eigenen Rechner laufen. Dann verlässt nicht „der Bestand” das Haus, sondern nur die wenigen, vorher pseudonymisierten Textausschnitte, die zur Frage passen. Das ist der Unterschied zwischen „wir laden unsere Dokumente in eine Cloud-KI“ und „wir schicken drei Absätze ohne Klarnamen an ein Sprachmodell“, rechtlich (Datenminimierung, Art. 5 Abs. 1 lit. c DSGVO) wie praktisch. Dieser Beitrag erklärt, wie lokale hybride Suche und Multi-Query-RAG funktionieren und wie porthor daraus die Bestandsfrage macht.

Was ist RAG — und warum reicht „Chat mit einem Dokument“ nicht?

RAG (Retrieval-Augmented Generation) bezeichnet KI-Systeme, die vor der Antwort relevante Textstellen aus einem Dokumentenbestand suchen (Retrieval) und dem Sprachmodell nur diese Fundstellen als Arbeitsgrundlage mitgeben. Ohne Retrieval kennt das Modell die eigenen Unterlagen schlicht nicht; mit Retrieval antwortet es aus belegbaren Quellen statt aus Trainingswissen.

Der einfache Fall skaliert nicht: Ein einzelnes Dokument in den Chat zu laden hilft wenig, denn eine Hausverwaltung mit 80 Objekten hat die Antwort selten in dem einen geöffneten Vorgang. Die eigentlich wertvolle Frage lautet „Wo in meinem gesamten Bestand steht das?“. Genau dafür braucht es eine Suche über alle Vorgänge, nicht ein größeres Kontextfenster.

Warum ist die Suche der datenschutzkritische Teil?

Bei Cloud-RAG-Diensten (etwa dem Hochladen ganzer Ordner in einen KI-Assistenten) wird der komplette Klartext-Bestand indexiert und liegt beim Anbieter — inklusive aller personenbezogenen Daten, für die dann Art. 28 DSGVO (Auftragsverarbeitung) und je nach Anbieter auch Drittlandtransfer-Fragen zu klären sind. Läuft die Suche dagegen lokal, existieren Index und Suchanfragen nur auf dem eigenen Gerät; an das Sprachmodell gehen ausschließlich die wenigen Treffer-Ausschnitte — bei porthor zusätzlich pseudonymisiert nach Art. 4 Nr. 5 DSGVO.

Zwei Belege, warum diese Trennung rechtlich trägt: Der EuGH hat in C-413/23 P (04.09.2025) den relativen Personenbezug bestätigt — pseudonymisierte Daten sind für einen Empfänger ohne Zuordnungsschlüssel unter Umständen keine personenbezogenen Daten. Und die EDPB-Leitlinie 01/2025 zur Pseudonymisierung betont das Trennungsgebot: Zuordnungsschlüssel und pseudonymisierte Daten gehören in getrennte Hände. Genau das leistet eine lokale Suche mit lokalem Schlüssel: Der Anbieter des Sprachmodells sieht nie beides.

Was bedeutet „hybride Suche“ (BM25 + Embeddings)?

Hybride Suche kombiniert zwei Suchverfahren: Stichwortsuche (BM25, der seit den 1990ern etablierte Standard-Algorithmus der Volltextsuche) findet exakte Fachbegriffe wie „Instandhaltungsrücklage“ oder „§ 558 BGB“ zuverlässig. Semantische Suche über Embeddings — Zahlenvektoren, die die Bedeutung eines Textabschnitts abbilden — findet zusätzlich Stellen, die dasselbe meinen, aber anders formuliert sind: die Frage nach der „Rücklage“ trifft auch das Protokoll, in dem nur „finanzielle Reserve“ steht. Beide Ranglisten werden per Reciprocal Rank Fusion (Cormack u. a. 2009) zu einem Ergebnis verschmolzen.

Wichtig für den Datenschutz: Semantische Suche braucht kein Cloud-Embedding-API. Es gibt kompakte mehrsprachige Modelle, die auf jedem Bürorechner laufen — porthor liefert dafür multilingual-e5-small gleich mit (384 Dimensionen, int8-quantisiertes ONNX-Format, rund 115 MB, deutschstark). Es wird mit der App installiert; zur Laufzeit findet kein Modell-Download statt, und die Vektoren werden ausschließlich über bereits pseudonymisiertem Text gebildet — auch der gespeicherte Suchindex enthält damit keine Klarnamen.

Was ist eine Multi-Query-Pipeline — und warum ist sie gründlicher als ein Chat?

Eine Multi-Query-Pipeline (auch „Fan-out-RAG“, bekannt aus Werkzeugen wie NotebookLM/Open Notebook) beantwortet eine Frage nicht mit einem einzigen Suchlauf, sondern in drei Stufen: Zuerst zerlegt ein Modell die Frage in mehrere fokussierte Teil-Suchen (aus „Wie steht die WEG finanziell da?“ werden etwa „Instandhaltungsrücklage Höhe“, „Wirtschaftsplan“, „offene Forderungen“). Dann wird jede Teil-Suche einzeln im Bestand recherchiert und nur aus ihren Treffern beantwortet. Zuletzt führt eine Synthese die belegten Teilantworten zusammen — jede Aussage mit Quellenangabe.

Der Gewinn ist Gründlichkeit: Ein einzelner Suchlauf findet die eine beste Stelle; der Fan-out deckt die Facetten einer Frage systematisch ab und macht sichtbar, was sich nicht belegen lässt — statt es zu erfinden. In porthor heißt dieses Feature Bestandsfrage (🧭-Symbol im Chat).

Wie setzt porthor das konkret um?

porthor trennt die drei Rollen sauber: Die Suche (BM25 + lokales Embedding-Modell) läuft vollständig on-device über alle Vorgänge; die Pseudonymisierung ersetzt Namen, Adressen und Kennungen lokal durch Platzhalter; nur die Antwortformulierung nutzt das vom Anwender selbst konfigurierte Sprachmodell (Bring-your-own-Credentials, z. B. Azure OpenAI EU oder lokales Ollama — dann bleibt sogar alles im Haus). Drei Schutzstufen kommen dazu:

1. Bewusstes Opt-in: Der Zugriff über Vorgangsgrenzen hinweg ist nie Standard. Erst wenn der Anwender die Chat-Datenbasis ausdrücklich auf „Alle Vorgänge (systemweit)“ stellt, existiert das Suchwerkzeug für die KI überhaupt.
2. Gate pro Fundstelle (fail-closed): Jeder einzelne Treffer wird vor dem Versand geprüft; Ausschnitte mit Klartext-Resten (etwa einer nicht erfassten IBAN) werden verworfen und in der Antwort als „aus Datenschutzgründen zurückgehalten“ ausgewiesen — im Zweifel lieber keine Fundstelle als eine ungeschützte.
3. Quellenpflicht: Jede Aussage der Bestandsfrage trägt ihre Herkunft (Vorgang / Dokument / Seite) und ist in der App per Klick nachprüfbar; ins Audit-Protokoll gehen nur Zähler, nie der Frage-Text.

Dieselbe lokale Suche steht übrigens auch ganz ohne KI zur Verfügung: als globale Volltextsuche (Strg+Shift+F), die über alle Vorgänge hinweg direkt auf die Fundseite im Dokument springt — dabei verlässt gar nichts das Gerät. Wie porthor Daten grundsätzlich schützt, lesen Sie im Tor-Abschnitt der Startseite.

Worauf sollte ich bei „KI-Suche im Dokumentenbestand“ generell achten?

Vier Prüffragen trennen datenschutzfreundliche von riskanten Lösungen: Wo liegt der Suchindex? (lokal oder beim Anbieter), Was genau geht an das Sprachmodell? (ganze Dokumente oder pseudonymisierte Ausschnitte), Ist der bestandsweite Zugriff ein bewusster Schalter oder Dauerzustand?, und Sind Antworten quellenbelegt und nachprüfbar? Wer alle vier Fragen mit der jeweils ersten Option beantworten kann, erfüllt Datenminimierung und Zweckbindung deutlich leichter — und merkt Halluzinationen sofort, weil jede Aussage eine anklickbare Fundstelle hat.

porthor führt die Bestandsfrage, die wählbare Chat-Datenbasis und die globale Volltextsuche mit dem nächsten Update ein — die Suche läuft dabei vollständig auf Ihrem Gerät.