Så kopplar ni en säker chatt till verksamhetens egna data

En gemensam chatt kan ge medarbetare en snabb ingång till verksamhetens kunskap. Frågan kan vara enkel – ”vilken rutin gäller för det här ärendet?” – men lösningen bakom behöver hantera datakällor, identitet, behörighet, modellval, källor och uppföljning.

Det viktigaste säkerhetskravet är att chatten inte skapar en ny, bredare åtkomst än användaren redan har. Två personer kan använda samma gränssnitt och ändå få olika underlag beroende på roll och dokumentbehörighet.

Vad menas med en chatt på egna data?

En chatt på egna data låter användaren ställa frågor i ett naturligt språk till information som organisationen har godkänt. Det kan vara policyer, manualer, rapporter, ärenden eller strukturerade databaser.

Vanligen används RAG för dokumentbaserad kunskap. Lösningen söker fram relevanta textavsnitt och skickar dem som kontext till en språkmodell, som formulerar ett svar. För strukturerade uppgifter kan chatten i stället anropa ett API eller en databasfråga under kontrollerade former.

”Egna data” betyder inte nödvändigtvis att allt finns i samma lagringssystem eller att modellen körs lokalt. Det betyder att organisationen styr vilka källor som ansluts, vilka användare som får åtkomst och hur informationen behandlas.

En gemensam ingång till verksamhetens kunskap ska inte innebära gemensam åtkomst till allt.

Från datakälla till sökbart innehåll

Första steget är en källinventering. Var finns informationen, vem äger den, hur uppdateras den och vilka behörigheter gäller? SharePoint, filytor, intranät och verksamhetssystem kan ha olika tekniska och organisatoriska regler.

Dokument behöver sedan läsas, delas upp och indexeras. Metadata som titel, datum, dokumenttyp, avdelning och åtkomstgrupp bör följa med. När källan ändras behöver indexet uppdateras utan att gamla versioner fortsätter påverka svaren.

Datakvalitet är en produktfråga. Om samma rutin finns i fyra versioner behöver organisationen bestämma vilken som är giltig. Chatten ska inte tvingas gissa vilken informationsförvaltning som gäller.

Identitet och åtkomst följer användaren

Inloggning, till exempel med Microsoft Entra ID, identifierar användaren. Därefter måste lösningen avgöra vilka funktioner och källor den identiteten får använda.

Åtkomst kan behöva kontrolleras på flera nivåer:

• tillgång till själva plattformen

• tillgång till en viss assistent eller funktion

• tillgång till en datakälla, mapp eller dokumenttyp

• tillgång till en handling, till exempel export eller systemuppdatering

Behörighetsfilter ska användas före informationshämtningen, inte bara efter att modellen har sett materialet. Annars finns risk att känslig information påverkar svaret även om den slutliga texten filtreras.

När en medarbetare byter roll eller slutar behöver åtkomsten ändras genom organisationens ordinarie identitetslivscykel. Undvik parallella manuella användarlistor som snabbt blir inaktuella.

Så används RAG

När användaren ställer en fråga omvandlas den till en sökrepresentation. Systemet söker endast i de källor som användaren är behörig att nå och väljer relevanta avsnitt. Dessa skickas till språkmodellen tillsammans med instruktioner om att hålla sig till underlaget och visa källor.

RAG-forskningen visar värdet av att kombinera modellens generativa förmåga med ett externt sökbart minne.[1] I företagsmiljö behöver metoden kompletteras med behörighet, källförvaltning och tester för den faktiska dokumentmängden.

Sökning och svar bör mätas separat. Om rätt dokument inte hämtas är problemet sannolikt index, filter eller sökstrategi. Om rätt dokument hämtas men svaret blir fel behöver instruktioner, modell eller efterbehandling granskas.

Vilken modell ska svara?

Modellvalet beror på språk, uppgift, informationsklass, svarstid, kostnad och driftkrav. En extern modell via API kan ge hög kapacitet och snabb tillgång till nya funktioner. En lokal modell kan vara nödvändig när information inte får lämna en kontrollerad miljö.

En modellneutral arkitektur gör det möjligt att välja modell per användningsfall och byta när krav eller prestanda förändras. Det minskar inte allt leverantörsberoende – integrationer och testning behöver fortfarande uppdateras – men gör modellen till en utbytbar komponent i stället för hela produkten.

Känsliga frågor kan också dirigeras till en annan modell än allmänna frågor. Sådan routing kräver tillförlitlig klassning och testning så att data inte hamnar fel.

Loggning, källor och uppföljning

Källhänvisningar gör att användaren kan kontrollera svaret och gå vidare till originalet. Visa helst dokumenttitel, relevant avsnitt och aktualitet. En länk till ett stort dokument utan markerat stöd ger begränsad transparens.

Loggar behövs för felsökning, säkerhet, kostnadsuppföljning och kvalitetsarbete. Men loggar kan själva innehålla känslig information. Definiera därför vilka fält som sparas, vem som får läsa dem, retention och hur personuppgifter hanteras.

Följ upp vanliga frågor, uteblivna svar, felaktiga källor och feedback. Utvärdera också beteendet efter varje ändring av modell, indexering eller instruktioner. NIST rekommenderar löpande mätning och hantering av generativa systems risker över livscykeln.[2]

Säkerhet som måste testas

Instruktioner från användare eller dokument kan försöka påverka modellen att agera i strid med sina regler. Detta kallas promptinjektion. Innehåll i källmaterial ska alltid behandlas som data, aldrig som betrodda systeminstruktioner.

Testa även frågor som försöker sammanställa mer information än användaren får se, dolda instruktioner i filer, ovanliga filformat och utdata som kan bli farlig när den skickas vidare till ett annat system. Tekniska kontroller, minsta behörighet och avgränsade verktyg är viktiga säkerhetsinställningar.

Vad krävs innan start?

En bra pilot börjar med ett avgränsat kunskapsområde och en tydlig användargrupp. Inventera:

• system och datakällor som ska anslutas

• informationsägare och uppdateringsprocess

• informationsklass och personuppgifter

• användargrupper, roller och dokumentbehörigheter

• språk, filformat och tabeller som måste fungera

• krav på lokal, svensk eller europeisk databehandling

• testfrågor, förbjudna svar och acceptanskriterier

• ansvar för support, incidenter och innehåll efter piloten

Välj inte hela intranätet som första test. Ett mindre område gör det möjligt att förstå både nyttan och kvalitetsproblemen innan fler källor och användare läggs till.

Exempel på användningsområden

Intern kunskap

Medarbetare hittar policyer och rutiner med direkt länk till källan.

Teknisk dokumentation

Ingenjörer söker i manualer, rapporter och historiska analyser utan att känslig data lämnar den kontrollerade miljön.

Kundservice

Handläggare får förslag grundade i aktuella villkor och produktinformation, men godkänner svaret före utskick.

Reglerad dokumentanalys

Användaren extraherar uppgifter, jämför versioner och skapar rapportutkast med spårbarhet till dokumentnivå.

Talk to your Data

Chatten kombinerar dokument med strukturerade datakällor och kan svara på frågor utifrån användarens behörighet.

Från gemensam ingång till kontrollerad användning

Den tekniska arkitekturen behöver utgå från hur ansvar och behörigheter är fördelade i organisationen. Datakällor har tydliga ägare, användare har olika roller och varje svar ska användas i ett bestämt sammanhang. När dessa delar samverkar kan chatten göra kunskap mer tillgänglig utan att kringgå befintliga gränser.

Källor

1. Lewis, P. m.fl., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks:
   https://arxiv.org/abs/2005.11401

2. NIST, Generative AI Profile:
   https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

3. IMY, Vägledning om GDPR och AI:
   https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/

4. Microsoft, Azure OpenAI on your data:
   https://learn.microsoft.com/en-us/azure/foundry-classic/openai/concepts/use-your-data