Kan ett hybrid-RAG-system hålla känsliga dokument lokalt samtidigt som det använder en molnmodell?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Can a Hybrid RAG System Keep Sensitive Documents Local While Using a Cloud Model? - Zima Store Online

Ja, men hybrid-RAG håller dokument lokala endast när hämtning, policytillämpning och promptkonstruktion förhindrar att känsliga textavsnitt passerar molngränsen.

Ett family office kan lagra avtal på en hem-NAS, skapa embeddings lokalt och endast anropa en molnmodell för svåra resonemang. Originalen laddas aldrig upp som filer, men ett hämtat stycke kan ändå visas ordagrant i en API-prompt. Sekretessen beror därför på vilken text som passerar gränsen, leverantörens lagringskontroller och om den lokala routern kan besvara frågan eller redigera texten innan någon extern förfrågan skickas.

Lokal lagring innebär inte automatiskt lokal informationsdelning

Ett hybrid-RAG-system separerar dokumentplanet från resonemangsplanet. Filer, tolkad text, metadata, embeddings och vektorindex kan förbli på en hemserver. Vid frågetillfället väljer lokal hämtning ut några få textsegment, och endast dessa segment – tillsammans med frågan och instruktionerna – behöver nå molnmodellen. Det minskar exponeringen kraftigt, men eliminerar den inte.

Den ursprungliga RAG-arkitekturen kombinerar en hämtare med en generator genom att tillhandahålla hämtade textavsnitt som modellkontext. Den kopplingen utgör sekretessgränsen: embeddings kan stanna lokalt, men generatorn kan fortfarande se den valda texten. Att kryptera NAS-enheten eller dölja korpusens filnamn skyddar inte ett textavsnitt efter att applikationen har placerat innehållet i en utgående prompt.

En användbar utformning märker varje dataobjekt efter dess roll. Original och hela textlagret är endast lokala; embeddings och index är lokalt sökbara; hämtade textavsnitt kan släppas under vissa villkor; promptar och svar följer den valda leverantörens policy. Denna lagerindelning stämmer överens med att använda en privat AI-assistent som kontrollerad gateway, i stället för att betrakta en lokal disk som hela sekretesslösningen.

En policyspärr måste köras efter hämtningen, inte före

Behörigheter som endast tillämpas vid import är för grova. Ett dokument kan innehålla offentligt produktspråk, interna priser, personliga adresser och konfidentiella anteckningar. Systemet behöver en spärr efter hämtningen som utvärderar exakt de textsegment som valts för den här användaren och den här destinationen. Den kan blockera, redigera, sammanfatta lokalt eller dirigera hela frågan till en lokal modell.

Verktyg som Presidio-detektering kan identifiera och anonymisera vanlig personligt identifierbar information innan text lämnar den betrodda miljön. Detektering är dock inget bevis på säkerhet: projektnamn, kommersiella villkor, medicinsk kontext eller en ovanlig kombination av vanliga fakta kan vara känsliga utan att matcha ett standardmönster för personuppgifter. Klassificeringsreglerna måste återspegla den faktiska korpusen.

Policyn bör utvärdera användarens behörighet och molnberättigande separat. En person kan ha rätt att läsa ett lokalt dokument men inte rätt att överföra det till en tredje part. Omvänt bör ett textsegment som godkänts för molnbearbetning ändå begränsas till det minsta avsnitt som behövs för svaret. Mer hämtad kontext är inte automatiskt säkrare eller mer korrekt; den ökar både exponeringen och bruset i prompten.

Leverantörskontroller minskar risken men gör inte molnet lokalt

Molnets sekretessvillkor är viktiga eftersom utgående promptar blir leverantörsbearbetade data även när källfilen stannar hemma. Kryptering under överföring skyddar nätverksvägen, medan lagringstid, missbruksövervakning, lagring av applikationstillstånd, regional bearbetning och policyer för modellträning styr vad som händer därefter. Dessa kontroller kan göra en hybriddesign acceptabel, men de gör inte molninferens lokal.

OpenAI:s aktuella datakontroller för API skiljer mellan loggar för missbruksövervakning och applikationstillstånd samt dokumenterar vilka slutpunkter som kan omfattas av nollagring. Detaljerna kan variera beroende på funktion, kontots behörighet och konfiguration. En sekretessgranskning måste därför binda routern till en godkänd slutpunkt och godkända inställningar, i stället för att förlita sig på ett allmänt löfte om att API-data inte används för träning.

Påståendet om lokal användning faller när råa textsegment, filnamn, konversationshistorik, verktygsspår eller cachade promptar lämnar systemet utan ett uttryckligt policybeslut. Det faller också när en applikation tyst byter leverantör efter ett fel. Hybrid routing bör stänga ned säkert för skyddade samlingar: om den godkända molnvägen inte är tillgänglig ska systemet svara lokalt med lägre kvalitet eller avstå, i stället för att skicka samma kontext någon annanstans.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Använd en informationsdelningslogg för att verifiera gränsen

Testa sekretessen vid den utgående förfrågan, inte i lagringsöversikten. Fyll en testkorpus med unika kanarietexter som representerar personuppgifter, konfidentiella projektnamn och begränsade avtalsklausuler. Ställ frågor som är utformade för att hämta dem, fånga den fullständigt renderade API-nyttolasten och dokumentera vilken policyregel som tillät, ändrade eller blockerade varje textdel.

Skydd av företagsdata kan omfatta kryptering, regional bearbetning och konfigurerbar lagringstid, vilket sammanfattas i OpenAI:s åtaganden för företagsdata. Informationsdelningsloggen bör dokumentera exakt tjänst, slutpunkt, lagringsläge, destinationsregion, promptfält och redigeringsresultat för varje externt anrop. Kör om testet efter ändringar av modell, ramverk eller leverantör.

Godkänn arkitekturen först när lokal-only-kanarier aldrig förekommer i fångade utgående nyttolaster, när textsegment som får lämna systemet minimeras och när leverantörens reservvägar följer samma policy. Om en känslig kanarietext läcker ska du åtgärda spärren efter hämtningen i stället för att flytta originalen till en annan mapp. Gränsen utgörs av den serialiserade förfrågan som lämnar hemnätverket, inte av källdokumentets fysiska placering.

Lager	Standardplats	Molnregel
Originalfiler	Hemserver	Skicka aldrig
Embeddings och index	Hemserver	Håll lokala om de inte uttryckligen godkänts
Hämtade textsegment	Lokal mellanlagring	Klassificera, minimera och tillåt eller blockera därefter
Fråga och instruktioner	Lokal router	Ta bort identifierare där det är möjligt
Molnsvar	Åter till lokal app	Tillämpa policy för lagringstid och granskning

Vanliga frågor

Avslöjar lokala embeddings originaltexten?

Embeddings ersätter inte åtkomstkontroll. De är mindre direkt läsbara än källtexten, men kan innehålla semantisk information och vara sårbara för inferensattacker. Lagra och auktorisera dem som känsliga härledda data.

Kan den lokala modellen sammanfatta ett textsegment före användning i molnet?

Ja, men en sammanfattning kan bevara känsliga fakta eller införa missvisande ersättningar. Tillämpa samma klassificering på sammanfattningen, jämför den med källan och behandla den som ett nytt utgående dataobjekt i stället för en automatisk sekretessgaranti.

Räcker nollagring i sig?

Nej. Det hanterar en risk på leverantörssidan. Applikationen behöver fortfarande hämtning med minsta möjliga behörighet, granskning av utgående data, identitetskontroller, låsta slutpunkter, loggar som undviker lagring av hemligheter och en regel för vad som aldrig får lämna hemservern.