Compliance, integritet och datalivscykel

Compliance är inte ett dokumentlager. Det är ett observerbart beteende.

En policy kan säga att intervjutext gallras efter 90 dagar. Först när Matrix kan visa populationen, klockan, körningen, raderna som påverkades, återstående överträdelser och nästa körning finns evidens för att policyn verkställs. Samma fyrdelning som i resten av boken gäller:

regelverk och beslut → datalivscykeldefinition → faktisk behandling → evidens och bedömning

Kapitlet är systemdesign, inte juridisk rådgivning. Juridisk auktoritet avgör bland annat tillämplighet, roll, rättslig grund och undantag. Arkitektens ansvar är att göra besluten uttryckbara, verkställbara och verifierbara.

1. Börja med behandling, inte teknik

“Matrix använder AI” säger nästan inget om vilka krav som gäller. Scope måste göras per behandling eller användning:

• vilka personer och organisationer berörs,
• vilket ändamål och vilken förväntad nytta finns,
• vilken data samlas in eller härleds,
• vilka roller och mottagare finns,
• vilka beslut eller handlingar påverkas,
• vilka jurisdiktioner och avtal gäller,
• vilken riskklass och vilka rättigheter aktualiseras.

Matrix regelverksregister har en nyttig tvådelning: vår egen efterlevnad och lösningens förmåga att hjälpa en kund. Ett system kan stödja en kontroll utan att leverantören kan garantera kundens efterlevnad. En complianceprodukt får aldrig sälja “certifiering på knapptryck”; den kan göra bevisläget och gapen granskningsbara [CLAIM-DATA-001].

EU AI Acts skyldigheter varierar med roll och riskklass. För relevanta högrisksystem finns krav på bland annat dokumentation, loggar, mänsklig översyn och kvalitetsstyrning; vissa dokument ska bevaras tio år och loggar som aktören kontrollerar normalt minst sex månader. Det är inte en generell retentionregel för all AI-data. Kravet måste mappas till den specifika användningen och andra tillämpliga regler.

2. Datalivscykelkontraktet

Varje beständig eller exporterad datapopulation bör ha ett kontrakt:

Retention är inte bara “90 dagar”. Klockan behöver ett startvillkor: från insamling, senaste aktivitet, avslutad relation, återkallat samtycke eller avslutat ärende. Den behöver även avgöra vad som händer med radens metadata, härledningar och backups [CLAIM-DATA-003].

Matrix connector framework kräver retention när en connector producerar beständig data. data_stores.toml inventerar flera lager. Detta är en god birth invariant: ingen ny store utan ägare och livscykel. Men katalogen måste jämföras med observerade filer, tabeller, buckets, index och exports; annars kan en okänd kopia ligga utanför registret.

3. Pseudonymisering är en kontroll, inte ett trollslag

Ett slumpmässigt ID minskar direkt exponering, men data är inte anonym om en auktoriserad eller annan realistisk part kan återlänka den. EDPB:s konsultationsriktlinje 01/2025 uttrycker samma kärna: pseudonymiserad data förblir personuppgift när kopplingen kan återställas. Matrix egen DPO-analys noterar dessutom att ett pseudonym-ID ger nästan noll praktisk anonymitet om det bara finns en möjlig person i rollen [CLAIM-DATA-002].

Pseudonymisering kan ändå vara mycket värdefullt. Kopplingstabellen kan separeras, åtkomsten begränsas, event kan minimera payload och analys kan ske utan namn. Men retention, rättigheter, incidenthantering och mottagare måste fortfarande omfatta populationen.

4. Minimering sker i flera led

Minimering betyder inte bara att samla in färre fält. Den gäller:

1. insamling: behövs innehållet alls?
2. transport: kan payload tas bort ur event och trace?
3. lagring: kan fulltext ersättas med claim, klass eller räknare?
4. åtkomst: kan tenant, zon, roll och ändamål begränsa läsning?
5. observation: behöver logs, prompts och tool arguments innehålla data?
6. export: kan rapporten bära aggregat i stället för individrader?
7. slut: vad raderas, anonymiseras eller bevaras med särskilt stöd?

Matrix eventanalys visar varför eventlager är riskabla. Ett minimerat envelope kan ta bort etikett, diff, snapshot och actor-ID. Men om personhändelser lagras i Git saknas naturlig tidsstyrd radering och historiken replikeras. Personrika event hör därför i ett retentionkapabelt lager; ofta räcker ett aggregat för det operativa värdet [CLAIM-DATA-004].

5. Radering är en grafoperation

En persons ord kan ha blivit:

informant → pseudonym → session → yttrande → claim → konflikt → leverans
                                      └────→ index/logg/backup

Att radera profilraden är då otillräckligt. Samtidigt kan blind kaskadradering förstöra ett legitimt beslut och göra leveranshistoriken obegriplig.

Matrix erase_informant löser en svår del explicit. Varje verbatim claim måste antingen raderas eller skrivas om till ett tredjepersonsbehov. Omskrivningen degraderar extraction till inferred, sänker confidence, ersätter lineage med <erased-origin> och märker leveranser med öppen risk. Operationen vägrar hela transaktionen om någon berörd verbatim claim saknar hantering. Postcondition kontrolleras innan pseudonymkopplingen försvinner; efteråt skulle frågan hitta noll per konstruktion och bevisa ingenting [CLAIM-DATA-005].

Det illustrerar tre principer:

• radera identitet och innehåll utan att ljuga om kvarvarande härledning,
• utför beroende steg atomiskt eller lämna allt oförändrat,
• verifiera medan identifieringsrelationen fortfarande går att fråga.

6. Gallring som återkommande kontroll

Matrix elicitation-retention har klassvisa regler: yttrandetext, avbrutna claims, informantprofiler/pseudonymer, flags och orphan conflicts. Databasens now() styr tiden, inte callerinput. Dry run är standard och både dry och live journalförs. Sanctioned-delete-flaggan armeras precis runt det skyddade statementet och avaktiveras direkt.

Den viktigaste funktionen är overdue_violations(). Om jobbet stannar ska rader efter hard cap plus grace göra kontrollen röd. “Senaste körning lyckades” är inte nog; även nuvarande population måste frågas [CLAIM-DATA-006].

Den landade tvådatabasdesignen drar nu en fysisk gräns mellan gemensam koordinationsdata och lokal eliciteringspersondata. De tre tidigare cross-family-foreign keys ersätts av fail-closed skrivvalidering mot Coordinator och en fail-open reconciliationvy för senare dangling references. Det möjliggör egna credentials, backup- och flyttlivscykler men gör även deployordningen säkerhetskritisk. Vid read-only-kontrollen den 13 augusti förväntade koden den nya 0022-revisionen medan live-databasen stod på 0021. Designen är alltså landad men ännu inte applicerad i den observerade driften, och den transitionella DSN-fallbacken är fortfarande den aktiva vägen. ADR och runbook refererar dessutom den äldre migrationsbeteckningen 0021 där den lineariserade kedjan kräver 0022. Fallbackens borttagning måste vara en hård postcondition före central flytt, inte ett efterföljande städjobb [CLAIM-DATA-009].

En generell retentionkontroll behöver därför fyra bevislinjer:

• definition: vilken regel gäller denna version?
• execution: körde jobbet, med vilken mode och omfattning?
• postcondition: finns förbjudna rader eller kopior kvar?
• coverage: omfattar kontrollen alla deklarerade och observerade stores?

7. Detaljdata och bevarat analysvärde

Inference economics behöver långsiktiga trender men inte varje model-call för all framtid. Matrix rullar därför upp detaljrader till dagliga aggregat före gallring. usage_unknown bevaras som okänd coverage, aldrig som noll.

Mönstret är starkt men kräver smågruppsanalys. Ett aggregat över en person, tenant eller unik dag kan fortfarande avslöja individen. Aggregation är inte automatiskt anonymisering. Kontraktet behöver minsta grupp, dimensioner, suppression och riskbedömning [CLAIM-DATA-007].

8. Backup, index och bevislager

Rättighets- och retentiondesign måste ange hur sekundärkopior hanteras. Omedelbar selektiv radering ur en append-only backup kan vara olämplig eller omöjlig. Då behövs dokumenterad isolering, åtkomstkontroll, backupens egen livslängd och en restoreprocedur som återapplicerar tombstones/gallring innan data återgår till normal drift.

Samma fråga gäller Qdrant-index, cache, lokala exports, statusfiler och telemetry. Ett primärlager kan vara rent medan sökindexet fortfarande lämnar ut texten. Rättighetsärendet måste följa en store graph, inte en hårdkodad lista i handläggarens huvud.

Auditbevis får inte bli ett bakvägsarkiv över det raderade. Ett bra raderingskvitto kan bevara ärende-ID, policyversion, tid, executor, antal per lager, postcondition och digest utan originalinnehållet [CLAIM-DATA-008].

Eliciteringens privacygräns

Interviewer-motorn skapar nu evidensfakta under en session och skyddar informantidentiteten genom pseudonym-ID. Transkriptet behandlas som otrustat innehåll och en separat role-agent-vy vägrar transcriptfält även om de skulle råka följa med en claimrad. Handover bär payloadhash och metadata, inte själva transkriptet [CLAIM-CLAIM-012].

Det minskar spridningen men löser inte hela livscykeln. En produktionsyta måste fortfarande visa ändamål och mandat före start, inspelningsstatus, lokal modellzon, tillåtna mottagare, retention, playback, rättelse/radering och vilka härledningar som påverkas. “Pseudonymiserad” får inte döljas bakom en allmän säkerhetsetikett.

9. Compliance-dossiern

En dossier bör svara per krav eller kontroll:

krav → scopebeslut → ansvarig kontroll → process → implementation
     → senaste observation → evidens → gap → åtgärd och ägare

Matrix compliance-erbjudande beskriver denna riktning. Dess egen text sätter en sund grind: paketet är inte externt säljbart förrän Swedwise har ett referenscase, egen privacy-/retentionskuld är löst, demovägen är livebevisad och beslut fattats. Dossiern får visa full, partial, missing, stale och not-applicable-with-rationale; den får inte omvandla tre bevisade kontroller till “compliant organisation”.

10. Gränssnittshierarki

Styrning och data
├── Regelverk och scope
│   ├── egen tillämplighet / kundmöjliggörande
│   └── beslut, version, ägare och nästa omprövning
├── Behandlingar
│   ├── ändamål, population, dataflöde och mottagare
│   ├── risk/DPIA och kontroller
│   └── datalager, kopior och retention
├── Rättighetsärenden
│   ├── sök och identitetsmatchning
│   ├── preview, beslut och approval
│   └── execution, postcondition och kvitto
├── Datalivscykel
│   ├── jobb, senaste körning, overdue och coverage
│   └── backup/index/export-undantag
└── Revision
    ├── kontroll → process → evidens → gap
    └── exporterat, signerat och versionsbundet dossierpaket

11. Användningsfall

UC14.1 — Scopea ett regelverk

Juridisk ägare bedömer en användning, sparar frågor, underlag, beslut, giltighet och nästa omprövning utan att klassa hela Matrix med ett enda ord.

UC14.2 — Registrera en behandling

DPO registrerar ändamål, personer, dataklasser, mottagare, stores, retention, rättigheter, risk och ägare innan connectorn får producera data.

UC14.3 — Upptäck oregistrerad store

Dataarkitekten jämför runtimeinventering med katalog och får ett blockerande gap för databas, fil, index eller export utan livscykelkontrakt.

UC14.4 — Granska dataflödet

En granskare följer fält från källa via event, modell, agent och export och ser var innehåll minimeras, pseudonymiseras eller lämnar en zon.

UC14.5 — Bedöm en pseudonym

DPO ser återlänkningsnyckel, möjliga angripare, gruppstorlek och åtkomst och kan inte märka datan anonym enbart för att namnet saknas.

UC14.6 — Förhandsgranska gallring

Operatören kör dry run per lager och ser regelversion, cutoff, antal, exempel-ID och beräknad påverkan utan att data ändras.

UC14.7 — Verkställ gallring

Behörig aktör godkänner population och kör jobben; receipt visar rader per lager, tid, kodrevision och postcondition.

UC14.8 — Upptäck försenad gallring

Overdue-gaten visar kvarvarande rader efter hard cap som rött med ägare och deadline även om senaste schemakörning saknas.

UC14.9 — Ta emot rättighetsbegäran

Handläggaren registrerar identitetsbevis, scope, deadlines, undantag och kommunikationskanal utan att lägga mer persondata än ärendet kräver.

UC14.10 — Hitta den registrerades data

Matrix söker primärlager, index, exports, logs och backup-policy och redovisar coverage och osäker identitetsmatchning.

UC14.11 — Radera en informant

Systemet kräver explicit hantering av varje verbatim claim, utför operationen atomiskt och vägrar om en härledning annars lämnar personens ord kvar.

UC14.12 — Verifiera radering

En oberoende läsväg testar postconditions per store och visar residualer, undantag, backupkarantän och ett payload-minimerat kvitto.

UC14.13 — Rätta en claim

En behörig person ersätter felaktig uppgift men bevarar tidigare kännedom, orsak, aktör och downstream-impact utan att den gamla versionen visas aktuell.

UC14.14 — Begränsa behandling

Ett ärende kan frysa användning och nya härledningar medan data bevaras för prövning; agents och exports får policyavslag.

UC14.15 — Bygg revisionsdossier

Complianceansvarig exporterar kontroll, scope, implementation, observation, evidens, freshness och gap med låsta källrevisioner.

UC14.16 — Ompröva efter förändring

En ny modell, connector, dataklass eller mottagare invalidierar berörda scope-/riskbeslut och skapar ägda omprövningar innan release.

12. Sammanfattning

Ett trovärdigt compliance-lager kan inte bara svara “vilka regler har vi?”. Det måste svara vilken data som finns nu, varför den får finnas, hur den används, när den ska försvinna och hur vi vet att den gjorde det. Matrix har starka byggblock i retention och erasure. Den största återstående frågan är operabilitet och coverage över hela store graph.

FIG-14-01 — Eliciteringens separerade artefakter och verifierade datalivscykel

Visa diagramdefinition

flowchart LR
  A[Ändamål, mandat och scope] --> B[Intervjusession\nen fråga per tur]
  B --> T[Transkript\notrustat + pseudonymiserat]
  T --> C[Interviewer → atomära claims\nevidensfakta + ursprung]
  C --> H[Challenger\nflaggar utan mutation]
  C --> P[Playback\nbekräfta / korrigera / avvisa]
  C --> R[Role-agent\nclaims + probes]
  T -. vägras vid rollgränsen .-> Z[Ingen transcriptåtkomst<br/>för role-agent]
  P --> E{Store graph + livscykel}
  H --> E
  E -->|behåll| F[Begränsad åtkomst]
  E -->|aggregat| G[Rollup + riskkontroll]
  E -->|radera / rätta| X[Grafoperation + postcondition]
  X --> J[Minimerat kvitto och dossier]
  J -. coverage/gap .-> N[Nästa livscykel:<br/>ändamål, mandat och scope]