Maskera persondata före AI-loggen – filtret måste sitta före exporten

För att hindra personuppgifter från att hamna i en LLM-applikations loggar behöver du maskera promptar, modellsvar, metadata och spårattribut innan de skickas till lagring eller observabilitet. Upptäck känsliga värden i applikationen, ersätt dem med platshållare och granska den färdiga loggposten eller telemetrin vid varje utgående väg.

En kontroll av enbart prompttexten räcker inte. Automatisk instrumentering kan senare lägga samma värde i ett OpenTelemetry-span, och en separat loggskrivare kan exportera en annan kopia. Behåll originalet där arbetsflödet behöver det, men låt bara rensade uppgifter nå loggning och spårexport.

Bygg en svensk testkorpus

Börja med syntetiska exempel som liknar tjänstens verkliga indata: namn i löptext, e-postadresser, svenska telefonnummer med olika avskiljare, postadresser och personnummer i flera skrivsätt. Placera samma påhittade värde i en användarprompt, ett modellsvar, ett verktygsresultat och ett metadatafält. Markera vilka tecken som ska ersättas och vilka som ska vara kvar, så att testet kan jämföra hela den exporterade posten med ett förväntat resultat.

Lägg även till negativa fall: produktkoder som liknar identitetsnummer, organisationsnamn som innehåller ett personnamn och vanliga tal som passar ett enkelt telefonmönster. De fallen visar när filtret förstör användbar felsökningsinformation. Håll korpusen syntetisk; verkliga kunduppgifter skulle skapa ytterligare en datamängd som måste skyddas.

Om du väljer en extern detektor kan Azure Languages Text PII behandla strängbaserad text och ge identifierade kategorier, konfidensvärden och redigerad text. Resultatet är ett underlag för maskering, inte en garanti för att varje personuppgift hittas. Ett anrop till tjänsten skickar dessutom råtext utanför den egna processen; om det inte är tillåtet måste detekteringen ske lokalt.

Microsofts språklista för PII anger stöd för svenska i Text PII, men inte i Conversation PII. Välj därför funktion efter både språk och indatans form. En svensk chatt kan exempelvis behandlas som textfält utan att man förutsätter att den separata konversationsfunktionen stöder svenska.

Detektera och ersätt utan att tappa sammanhanget

Låt detektorn lämna träffarnas position och typ. Komplettera vid behov med regler för format som är särskilt viktiga i tjänsten, men validera en möjlig identifierare innan ett siffermönster får styra beslutet. Bestäm också hur överlappande träffar ska hanteras; annars kan samma text maskeras olika beroende på i vilken ordning reglerna körs.

Ersätt varje träff med en typad platshållare. I ett uttryckligen påhittat exempel kan samma namn bli [PERSON_1] i både prompt och svar, medan en e-postadress blir [EPOST_1]. En mappning inom en förfrågan bevarar sambandet mellan fälten utan att exportera originalvärdet. Låt inte numreringen följa personen mellan förfrågningar, eftersom en beständig beteckning då kan användas för att koppla ihop aktivitet.

Förvara en eventuell mappning mellan original och platshållare endast där applikationen behöver återställa värdet, och rensa den när behovet upphör. Skriv inte mappningen i undantagsmeddelanden eller felsökningsloggar. För fält som inte behövs i observabiliteten är det enklare att ta bort hela fältet än att försöka avgöra om varje delsträng är känslig.

Rensa metadata, även när de är nästlade

Gå igenom mer än fält med namn som ”prompt” och ”svar”. Användar-ID, filnamn, sökfrågor, verktygsargument och feltexter kan bära personuppgifter. Börja med en tillåtelselista över metadata som faktiskt behövs för felsökning. Maskera strängvärden även i nästlade objekt och listor; ett rent toppfält hjälper inte om samma råvärde ligger längre ned i strukturen.

Bevara fälttypen när ett värde ersätts. Om ett metadatafält innehåller strukturerad data behöver filtret läsa strukturen, ändra rätt värde och serialisera den igen; ett sök-och-ersätt på den färdiga strängen kan missa escapade tecken eller ändra annan data. Lägg därför korpusens identiska testvärde på flera nivåer i samma post och kontrollera att samtliga förekomster försvinner.

Granska spanattribut vid exporten

Langfuses maskeringsguide rekommenderar Python-kroken mask_otel_spans för nya installationer: den körs vid export och kan ändra attribut även på span från tredjepartsinstrumentering som den aktuella Langfuse-klienten exporterar. Den äldre mask-kroken arbetar när data sätts via Langfuses egna SDK-anrop. Exportkroken är därmed en användbar sista kontroll av attribut som tillkommit efter applikationens första maskering.

Kroken får dock en exportbatch som inte säkert innehåller hela förfrågan eller spåret. Skapa därför konsekventa platshållare tidigare i applikationens flöde och använd exportkontrollen för att ta bort eller ersätta kvarvarande känsliga attribut. Den kan inte ändra spannamn, resursattribut, händelser eller länkar; sätt aldrig råa personvärden i sådana delar om de ska exporteras.

Inventera också varje loggskrivare och exportör. Maskering i en Langfuse-export ändrar inte den kopia som en separat OpenTelemetry-exportör skickar. Om flera mottagare ska få samma skydd måste rensningen ske före förgreningen eller tillämpas på varje utgående väg. Det gäller även vanliga applikationsloggar som inte passerar spårkroken.

Testa den data som lämnar applikationen

Kör korpusen efter ändringar i promptmallar, verktyg, instrumentering och exportkonfiguration. Jämför den faktiska utgående loggposten och den serialiserade spårlasten med förväntad data, inte bara detektorns returvärde. Ta med ett fall där ett tredjepartsbibliotek skapar spanet och ett där samma syntetiska uppgift finns i både modellsvar och metadata.

Räkna falska negativa som känsliga testvärden som överlever i exporten. Räkna falska positiva som ofarliga värden som ändras eller försvinner och därmed försämrar felsökningen. Kontrollera också att samma platshållare används inom förfrågan och att den tillfälliga mappningen själv saknas i varje utgående post.

Avsluta med ett kontrollerat feltest. Om maskeringen inte kan köras ska den berörda loggvägen stoppas eller begränsas i stället för att skicka råtext. Registrera ett felmått utan promptinnehåll, så att ett trasigt filter kan upptäckas utan att felhanteringen blir en ny läcka.

Läs också:

• Skriv en AI-policy för jobbet – avtalet måste komma före prompten
• AI-agenter lade 13 000 interna bilder öppet – kontrollera personliga GitHub-konton
• Spåra AI-agentens verktyg – loggen kan annars dölja felet