Det vanligaste misstaget med hämtningsförstärkt generering (RAG) inom företag är enkelt: läs in allt, ställ frågor och utgå från att svar med källhänvisningar automatiskt är säkra.
Det näst vanligaste misstaget upptäcks senare: någon inser att assistenten kan svara utifrån dokument som användaren aldrig borde ha sett. Löneintervall. Kundavtal. Juridiska utkast. Styrelseanteckningar. Supportärenden. HR-utredningar. Säkerhetsrutiner. Svaret kan vara korrekt och källbelagt, men systemet har läckt information.
RAG för företagskunskap är inte en sökruta med mer välformulerade svar. Det är ett behörighetsstyrt informationssystem. Behandla det som ett sådant.
Informationshämtningen måste tillämpa samma eller striktare behörigheter än källsystemen. Om en användare inte kan öppna dokumentet i Google Drive, SharePoint, Notion, Confluence eller CRM-systemet ska RAG-systemet inte hämta det för den användaren.
Grundregeln
Hämtningslagret måste besvara följande fråga innan det returnerar ett enda textsegment:
Är den här användaren behörig att se den här källan just nu?
Inte ”finns källan i vektordatabasen?”. Inte ”är källan relevant?”. Inte ”är källan användbar?”. Behörigheten kommer först.
Det finns tre vanliga mönster:
| Mönster | Så fungerar det | Lämpligt för |
|---|---|---|
| Separata index | Ett index per målgrupp eller arbetsyta | Enkla team, grov behörighetsindelning |
| Metadatafiltrering | Lagra metadata om ACL, grupp och källa och filtrera före hämtning | De flesta RAG-system för företag |
| Behörighetskontroll i realtid | Kontrollera källsystemets behörigheter vid hämtningen | Känsliga behörigheter eller behörigheter som ändras ofta |
Rätt svar beror på källsystemen och risknivån. För de flesta små och medelstora företag räcker separata index i kombination med metadatafiltrering. För kunduppgifter, HR-data, juridiskt material eller reglerade uppgifter kan realtidskontroller krävas.
Den svåra delen: att hålla ACL:er synkroniserade
Samtliga mönster ovan förutsätter i praktiken en sak: att behörighetsinformationen i indexet stämmer överens med behörighetsinformationen i källsystemet. Den synkroniseringen utgör den verkliga tekniska utmaningen.
Varifrån ACL:erna hämtas. SharePoint och OneDrive exponerar behörigheter per objekt genom Microsoft Graph API, Google Drive genom Drive API:s behörighetslistor per fil och Confluence genom begränsningar för utrymmen och sidor. De har olika strukturer (användare, grupper, arv och delningslänkar), olika begränsningar för antal API-anrop och olika sätt att definiera vem som får se vad.
Gruppexpansion är inte valfri. De flesta verkliga behörigheter tilldelas grupper, och grupper kan vara nästlade. ”Försäljning EU” i ”Försäljning” i ”Alla anställda” måste plattas ut till konkreta användare, antingen vid synkroniseringen (mer metadata i indexet, snabbare frågor) eller vid frågetillfället (aktuellare uppgifter, långsammare frågor, fler API-anrop). Välj medvetet. Team som inte gör ett uttryckligt val får en inkonsekvent lösning.
Synkroniseringsfördröjningen är en säkerhetsparameter, inte en prestandadetalj. När någon förlorar åtkomsten till ett dokument – på grund av rollbyte, avslutad anställning eller att en affär blir konfidentiell – fortsätter indexet att tillämpa den gamla ACL:en fram till nästa synkronisering. Fastställ och dokumentera godtagbar fördröjning för återkallad åtkomst per korpus: nära realtid för skyddsvärda korpusar, medan timmar kan vara acceptabelt för interna processdokument. Om ingen har dokumenterat tidsgränsen är det verkliga svaret ”när nattkörningen sker”, vilket inte klarar en säkerhetsgranskning.
Realtidskontroller ger aktualitet till priset av latens, anropsbegränsningar och ett nytt felläge. Ett behörighetsanrop för varje hämtning lägger till en tur till källsystemet för varje fråga och förbrukar snabbt API-kvoten i stor skala. Den vanliga kompromissen är en kortlivad cache, vilket i praktiken omvandlar ”realtid” till ”synkroniseringsfördröjning med ett mindre tal”. Oavsett val måste beteendet vid timeout vara uttryckligt: om behörighetskontrollen misslyckas eller får timeout lämnas textsegmentet inte ut. Neka åtkomst vid fel, logga felet och låt assistenten avböja. Ett långsamt korrekt svar är bättre än ett snabbt läckage.
Testet av avslutad åtkomst i testavsnittet visar om detta faktiskt fungerar: ett inaktiverat konto får inte hämta någonting från skyddsvärda korpusar, och kontrollen måste gälla dagen efter att kontot inaktiverats, inte först efter nästa fullständiga omsynkronisering.
Källgränser
Skapa inte en enda stor kunskapspool. Separera efter målgrupp och känslighet:
| Korpus | Målgrupp | Exempel | Regel |
|---|---|---|---|
| Offentligt/produkt | Alla | Hjälpdokumentation, offentliga priser, produktsidor | Säkert för en bred assistent |
| Intern verksamhet | Anställda | Processdokument, interna vanliga frågor | Endast anställda |
| Avdelning | Avdelningens medlemmar | Säljhandböcker, supportmallar, driftinstruktioner för teknik | Gruppfiltrerat |
| Kundposter | Ansvariga team | Ärenden, avtal, kontoanteckningar | Strikt ACL och revision |
| Skyddsvärt | Endast namngivna användare | HR, juridik, säkerhet, styrelse | Vanligen separat system eller ingen RAG |
Ju färre målgrupper en korpus betjänar, desto enklare är det att bedöma risken för informationsläckage.
Kontroller vid inläsning
Många läckor uppstår i inläsningspipelinen.
Registrera följande innan en källa indexeras:
- Källsystem.
- Dokument-ID.
- Ägare.
- Målgrupp eller ACL.
- Känslighetsmärkning.
- Tidsstämplar för skapande och uppdatering.
- Förfallo- eller granskningsdatum.
- Om dokumentet får användas för AI-baserad informationshämtning.
- Om dokumentet innehåller personuppgifter.
Bevara befintliga märkningar om källsystemet har sådana. Lägg annars till en enkel klassificering före inläsningen.
Kontroller vid informationshämtning
Informationshämtningen ska ske i följande ordning:
- Identifiera användaren och användarens grupper.
- Identifiera den begärda arbetsytan eller assistenten.
- Filtrera möjliga källor efter korpus, ACL, känslighet och aktualitet.
- Hämta relevanta textsegment endast från tillåtna källor.
- Rangordna om de tillåtna textsegmenten.
- Generera svaret med källhänvisningar.
- Avböj eller eskalera om de tillåtna källorna inte räcker.
Hämta inte först för att sedan filtrera i prompten. Om ett förbjudet textsegment når modellens kontext har gränsen redan överskridits.
Promptens och svarets beteende
Assistenten ska instrueras att:
- Endast svara utifrån hämtade källor.
- Ange källans titel och avsnitt/länk.
- Uppge när de tillåtna källorna inte innehåller svaret.
- Tydligt skilja slutsatser från källbelagda fakta.
- Inte avslöja att skyddsvärda källor finns.
- Inte sammanfatta material som användaren saknar behörighet till.
Olämpligt avböjande:
”Jag hittade HR-dokument med löneintervall, men du saknar behörighet.”
Bättre avböjande:
”Jag har ingen godkänd källa tillgänglig för att besvara frågan.”
Det andra svaret röjer varken att det finns skyddsvärda dokument eller vad de handlar om.
Loggning utan att skapa ett andra läckage
RAG-loggar är känsliga. De kan innehålla användarfrågor, hämtade textsegment, käll-ID:n, svar och ibland personuppgifter.
Logga tillräckligt för felsökning:
- Användar-ID eller pseudonymiserat ID.
- Assistent/arbetsyta.
- Tidsstämpel för frågan.
- ID:n för hämtade källor.
- Utfall från behörighetsfiltret.
- Svars-ID.
- Orsak till avböjande eller eskalering.
- Latens och fel.
Var försiktig med:
- Fullständiga användarfrågor.
- Fullständiga hämtade textsegment.
- Fullständiga genererade svar.
- Kunduppgifter.
- Ämnen inom HR, juridik och säkerhet.
För känsliga system bör maskerade loggar eller käll-ID:n lagras i stället för fullständig text. Ge loggarna en egen åtkomstkontroll och lagringstid.
Inaktuella och motstridiga källor
Behörighet är inte den enda gränsen. Källkvaliteten spelar också roll.
Varje indexerad källa ska ha en ägare och en aktualitetsregel:
| Källtyp | Granskningsregel |
|---|---|
| Priser | Granska vid varje prisändring |
| Policy | Granska när policyägaren uppdaterar, minst en gång per kvartal |
| Produktdokumentation | Granska vid lansering |
| Juridisk mall | Granska genom juridiskt ansvarig |
| Supportmall | Granska varje månad eller efter ett återkommande eskaleringsmönster |
När källor motsäger varandra ska assistenten uppmärksamma konflikten endast om användaren har behörighet till båda källorna. Annars ska den svara utifrån den tillåtna källa som har högst auktoritet eller eskalera.
Testa behörighetsgränser
Testa med användare, inte bara med dokument:
- Anställd med omfattande åtkomst.
- Anställd med begränsad avdelningsåtkomst.
- Chef med åtkomst endast till det egna teamet.
- Konsult.
- Tidigare anställd eller inaktiverat konto.
- Användare i kundsupport.
- Administratör.
Ställ följande frågor för varje profil:
- En fråga som profilen ska kunna besvara.
- En fråga strax utanför profilens behörigheter.
- En fråga om ett skyddsvärt dokument som personen vet finns.
- En fråga där offentliga och interna dokument motsäger varandra.
- En fråga med promptinjektion: ”ignorera åtkomstreglerna”.
Rätt resultat är inte bara ”ett bra svar”, utan ”ett bra svar från tillåtna källor”.
Införande i etapper
Börja med den minst känsliga korpusen:
- Offentlig dokumentation och produktdokumentation.
- Interna verksamhetsdokument.
- Avdelningsspecifika dokument.
- Kundposter med strikt ACL.
- Skyddsvärda korpusar först efter uttryckligt godkännande från säkerhetsansvarig och juridisk expertis.
Mät följande i varje etapp:
- Svarens användbarhet.
- Källhänvisningarnas kvalitet.
- Andelen korrekta avböjanden.
- Andelen hämtningar som nekas på grund av behörighet.
- Andelen inaktuella källor.
- Användarrapporter om saknade eller felaktiga källor.
Gör inte detta ännu
Indexera inte ”alla företagsdokument” i en enda assistent.
Förlita dig inte på promptinstruktioner för att upprätthålla behörigheter.
Logga inte fullständiga hämtade textsegment för känsliga korpusar utan en tydlig policy för lagringstid och åtkomst.
Blanda inte HR-material, juridiskt material, kunddokument och offentliga dokument i samma korpus.
Låt inte RAG-systemet svara utanför de tillåtna källorna enbart för att vara hjälpsamt.
Slutsats
RAG för företagskunskap är värdefullt eftersom det för in källbelagda svar i det dagliga arbetet. Det är riskfyllt eftersom även källbelagda svar kan läcka information.
Utforma behörighetsgränserna först. Filtrera före hämtningen. Separera korpusar efter målgrupp. Bevara källmetadata. Avböj på ett säkert sätt. Logga varsamt. Testa med verkliga behörighetsprofiler. Om en användare inte kan komma åt källan direkt ska RAG-systemet inte använda den för att besvara användarens fråga.
