simplineers

GDPR-funktionens audit-kravkarta för LLM-applikationsarkitektur

Karta över applikationslager, RAG, minne, inferens/serving, verktyg, loggning och leverantörsled — ur GDPR-, säkerhets- och internrevisionsperspektiv. Modellens interna Transformer-komponenter behandlas endast översiktligt.

Avgränsning: Kartan är ett granskningsunderlag, inte en universell kravlista. Vilka krav som faktiskt gäller beror på användningsfallet — bland annat personuppgiftskategorier (inkl. art. 9 och art. 10), om tjänsten används som personuppgiftsbiträde eller personuppgiftsansvarig, om RAG, långtidsminne, transkript­loggning eller verktyg är aktiverade, om data används för träning eller finjustering, om gränsöverskridande överföringar förekommer, samt om beslut eller rekommendationer kan få rättslig eller annan motsvarande betydande effekt på den registrerade. Termer som tenant, RAG, KV-cache, embeddings, guardrail, DSR och prompt injection förklaras i begreppsnyckeln på LLM-arkitektursidan.
Risk-läckage
Kontroll behövs
Loggningspunkt

Risk-läckage

Moduler där personuppgifter aktivt behandlas, lagras eller kan exfiltreras. De utgör angreppsytan — det är här en GDPR-överträdelse uppstår om något går fel.
Granskningsåtgärd: kartlägg dataflödet, verifiera kryptering och åtkomstkontroll, granska retention och tenant-segmentering, testa motståndskraft mot exfiltrering.

Kontroll behövs

Moduler som själva ÄR kontroller — de implementerar säkerhetsåtgärder, policys eller guardrails som skyddar riskmodulerna.
Granskningsåtgärd: verifiera designspecifikation, granska change governance och ägarskap, mät effektivitet via FP/FN-tester, red team eller stickprov.

Loggningspunkt

Moduler där personuppgifter fångas för observability, felsökning eller DSR. Egen integritetsutmaning — långa retentionstider, bred åtkomst och personuppgifter som lever vidare efter att källan rensats.
Granskningsåtgärd: granska retentionsmatris och access-roller, verifiera PII-redaktion innan loggning, säkerställ att DSR-flödet faktiskt täcker även loggarna.

Arkitekturlager — kartan täcker primärt lager 1, 2 och 4

1

Applikation

Auth, systemprompt, prompt, RAG, långtidsminne, verktyg, konversationshistorik
2

Serving / inferens

Tokenisering, batching, prompt-cache, KV-cache, modellserver, sampling, streaming
3

Modellintern

Embeddings, positional encoding, transformerblock, self-attention, MLP, layer norm, logits — endast översiktligt här
4

Governance / säkerhet

Guardrails, PII-detekt, loggning, telemetri, DSR, retention, region routing, leverantörskontroller
Tvärgående GDPR-baslager: Art. 5, 6, 25, 30, 32 och vid behov 35 gäller för hela behandlingen och bör inte ses som modulbundna.

0 — Identitet & access

1
Auth / IdP
SSO, MFA, scope, sessionshantering — vem ringer in
↓

1 — Inmatning

Kontextfönster — det modellen får se

Prompt
Frågan
Systemprompt
Roll och regler
2
Verktygsspec
Allowlist
3
RAG
Dokumenthämtning
4
Långtidsminne
Cross-session
↑ RAG hämtar från ↓
5
Vektor-store
Embeddings & index — egen PD-yta (inversion-risk)

Förbehandlingsgate och input-kontroller (Prompt + RAG-innehåll)

6
Ändamål + laglig grund
Verifieras före behandling
7
Input-guardrail
Jailbreak / prompt-shield
8
PII-detekt (in)
DLP före loggning
↓
Tokenisering + embeddings
Text → token-ID:n → vektorer (vision encoder för bild)

2 — Resonemang

↓
9
Prompt-cache (cross-request)
Hash-uppslag innan modell
↓
10
KV-cache
Per request
11
Modellvikter
10B–1T+ parametrar
Sampling
Temperature, top-p
12
Säkerhetsfilter
Klassificerare
8
PII-detekt (out)
Post-redaktion
Avkodning
Logits → token-ID → text
13
Output streaming
Token för token

3 — Verktygsanrop

↓
Modellvikter
Tool-call tokens
14
Tool router
ACL + dispatch
15
Python-runtime
Sandbox-körning
Resultat → kontext
Tool-respons

4 — Slutsvar med uppdaterad kontext

Engine + output körs igen — samma audit-punkter som FAS 2 (9, 10, 11, 12, 8, 13)
↓
10
KV-cache
Med tool-resultat
11
Modellvikter
Forward pass #2
Sampling
Slutsvar-tokens
12
Säkerhetsfilter
Klassificerare
8
PII-detekt (out)
Post-redaktion
Avkodning
Logits → token-ID → text
13
Output streaming
Token för token
16
Slutsvaret till användaren — aggregeringspunkt
Genererat svar — kan aggregera PII från prompt, RAG och tool-output
↓
17
Konversations-DB / sessionhistorik
Persistent lagring av prompt + svar + ev. tool-output

Tvärgående kontroller — täcker hela flödet ovan

18
Loggning / observability
Varje pil i flödet ovan = möjlig loggningspunkt. Bedöm om, vad och hur länge utifrån risk, ändamål, uppgiftsminimering och incidentbehov.
19
Telemetri till leverantör
Abuse-detection, model improvement. Schrems II + Art. 44–49
20
DSR-endpoint
Art. 15–22-flöde. Måste täcka alla lager: kontext-DB, vektor-store, loggar, långtidsminne
21
Region-routing / dataresidens
Tvingar trafik och lagring till valt geo. Schrems II-bedömning per komponent
22
Incident- och breach-anmälan
Art. 33: 72-timmarsflöde till tillsyn. Art. 34: kommunikation till registrerade vid hög risk

Bakom kulisserna — formar varje token-val

23
Förträning
Petabytes text
Finjustering
Bra exempel
24
RLHF / CAI
Värderingar, stil
Utvärdering
Röd team & eval

Audit-krav per modul (rad 1: risk + artiklar — rad 2: evidens)

1

Auth / IdP — Kontroll — Art. 25, 32

Evidens: MFA-täckning, scope-design för API-nycklar, federation mot kund-IdP, account-takeover-detektion, sessionsretention

2

Verktygsspec / allowlist — Kontroll — Art. 25

Evidens: allowlist per användarroll och miljö, change management

3

RAG-källor — Risk — Art. 5(1)b/c, 6, 25

Evidens: ACL-konfig, lawful basis-matris per dokumenttyp, retrieval-loggar

4

Långtidsminne — Risk — Art. 5(1)e, 17 (Art. 22 om minnet styr automatiserade beslut med rättslig effekt)

Evidens: opt-in-mekanism, raderingsrutin, profiling-bedömning per use-case

5

Vektor-store (RAG-backend) — Risk — Art. 5(1)c/f, 17, 25

Evidens: tenant-segmentering på index-nivå, embedding-radering vid DSR, inversion-bedömning (embeddings ≈ personuppgifter), indirect prompt injection-testning

6

Ändamål + laglig grund — Kontroll — Art. 5(1)a/b, 6 (och Art. 9 vid särskilda kategorier av personuppgifter)

Evidens: registrerade ändamål per use-case, dokumenterad laglig grund, godkännandeflöde och ROPA-koppling

7

Input-guardrail — Kontroll — Art. 25, 32

Evidens: jailbreak-eval, FP/FN-rate, regelversion, change governance

8

PII-detekt (in/out) — Kontroll — Art. 5(1)c, 25, 32

Evidens: precision/recall, false negatives för särskilda kategorier av personuppgifter, redaktions-policy, testdata, drift-övervakning

9

Prompt-cache — Risk — Art. 5(1)f, 32

Evidens: cache-key-policy som utesluter PII-känslig kontext, TTL, audit-loggar

10

KV-cache — Risk — Art. 5(1)f, 32

Evidens: tenant-isoleringspolicy, eviction-konfig, batch-inferens-bedömning

11

Modellvikter / memorisering — Risk — Art. 5(1)a/c/f, 6, 9 (vid särskilda kategorier av personuppgifter), 25, 32, 35

Evidens: memorization-eval, extraction-test, canary-tester, dedup-rapport, träningsdata-lineage, anonymitetsbedömning (jfr EDPB Opinion 28/2024)

12

Säkerhetsfilter (output) — Kontroll — Art. 25, 32

Evidens: red-team-rapport, drift-monitor, regelägarskap

13

Transcript (prompt + reasoning + tool) — Loggning — Art. 5(1)c/e, 17

Evidens: retention, raderingsendpoint, separat klassning för reasoning-tokens

14

Tool router / MCP-hub — Risk — Art. 25, 28, 32

Evidens: ACL-policy per verktyg och roll, dispatcher-loggar, change log

15

Python-runtime — Risk — Art. 32; DORA-relevant vid finansiell verksamhet eller omfattat leverantörsled

Evidens: sandbox-spec, nät-policy, ephemeral FS, exekverings-loggar

16

Slutsvar (aggregering) — Risk — Art. 5(1)b/c, 35

Evidens: post-DLP, klassningsregler för kombinerad output

17

Konversations-DB / sessionhistorik — Risk — Art. 5(1)e/f, 17, 32

Evidens: kryptering at-rest med tenant-nyckel, retentionsmatris, raderingsbevis kopplat till DSR (#20), backup-undantag dokumenterat

18

Loggning-pipeline (central) — Loggning — Art. 5(1)e, 17, 32

Evidens: retentionsmatris, access-roller, raderingsbevis per ärende

19

Telemetri till leverantör — Risk — Art. 28, 44–49

Evidens: opt-out-konfig, DPA, TIA, SCC, Schrems II-bedömning

20

DSR-endpoint — Loggning + Kontroll — Art. 12, 15–22 (särskilt 15, 16, 17, 18, 19, 20, 21, 22)

Evidens: täckningsmatris (kontext-DB #17, vektor-store #5, loggar #18, långtidsminne, embeddings, telemetri), SLA mot 1+2-månadersfrist, raderingsbevis, identitetsverifiering av begäran, underrättelse till mottagare (Art. 19)

21

Region-routing / dataresidens — Kontroll — Art. 44–49

Evidens: residens-matris per komponent, supportåtkomst per land, underbiträdeslista, SCC/TIA, failover-policy, åtkomstloggar, krypterings- och nyckelhanteringsmodell. Obs: dataresidens löser inte tredjelandsöverföring i sig — support, fjärradmin och telemetri kan fortfarande utgöra åtkomst från tredje land.

22

Incident- och breach-anmälan — Risk — Art. 33, 34

Evidens: incident-detektion (LLM-specifika scenarion: prompt injection-läcka, modell-extraktion, cross-tenant), anmälan utan onödigt dröjsmål och om möjligt inom 72 timmar (Art. 33.1) — såvida det inte är osannolikt att incidenten medför risk för fysiska personers rättigheter och friheter, kommunikation till registrerade vid hög risk (Art. 34), modellrollback som dokumenterat scenario

23

Förträning — Leverantörs-/modellrisk — Art. 6, 9, 28 (Art. 22 endast om modellen styr automatiserade beslut)

Evidens: leverantörens lawful basis-bedömning, opt-out, data-lineage, dataset-filtrering, EDPB Opinion 28/2024

24

Finjustering / RLHF / CAI — Behandlingsfas + leverantörskontroll — Art. 28, 30

Evidens: annotator-DPA, dataset-lineage, biträdesvillkor, opt-out för användarfeedback som flödar tillbaka