
# Privatlivsbevarende Prompt‑justering for Multi‑Tenant Sikkerhedsspørgeskema‑automatisering

## Introduktion

Sikkerhedsspørgeskemaer, leverandørvurderinger og overholdelsesrevisioner er en vedvarende kilde til friktion for SaaS‑udbydere. Den manuelle indsats, der kræves for at indsamle beviser, formulere svar og holde dem opdaterede, kan forsinke salgsprocesser med uger og øge risikoen for menneskelige fejl. Moderne AI‑platforme har allerede demonstreret, hvordan store sprogmodeller (LLM‑er) kan syntetisere beviser og generere svar på få sekunder.

Dog antager de fleste eksisterende implementeringer en **single‑tenant**‑kontekst, hvor AI‑modellen har ubegrænset adgang til alle underliggende data. I et ægte multi‑tenant SaaS‑miljø kan hver kunde (eller intern afdeling) have sine egne politikker, bevisarkiver og krav til dataprivatliv. At lade LLM‑en se de rå data fra alle tenants bryder både regulatoriske forventninger (f.eks. [GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa)) og kontrakter, der udtrykkeligt forbyder datalækage på tværs af tenants.

**Privatlivsbevarende prompt‑justering** bygger bro over dette hul. Den tilpasser de generative evner i LLM‑erne til hver tenants unikke vidensbase, samtidig med at den garanterer, at rå data aldrig forlader deres silo. Denne artikel gennemgår de centrale begreber, arkitektoniske komponenter og praktiske trin, der er nødvendige for at implementere en sikker, skalerbar og overensstemmende multi‑tenant spørgeskema‑automatiseringsplatform.

---

## 1. Centrale Begreber

| Begreb | Definition | Hvorfor det er vigtigt |
|---|---|---|
| **Prompt‑justering** | Fin‑tuning af en frosset LLM ved at lære et lille sæt kontinuerlige prompt‑vektorer, der styrer modellens adfærd. | Muliggør hurtig tilpasning uden at træne den fulde model, sparer beregningsressourcer og bevarer modellens oprindelige egenskaber. |
| **Differentiel Privatliv (DP)** | En matematisk garanti for, at output fra en beregning ikke afslører, om en enkelt inputpost var til stede. | Beskytter følsomme bevisdetaljer, når de aggregeres på tværs af tenants eller når feedback indsamles til løbende forbedring. |
| **Secure Multi‑Party Computation (SMPC)** | Kryptografiske protokoller, der gør det muligt for parter at beregne en funktion over deres input, mens de holder inputtene private. | Giver en måde at træne eller opdatere prompt‑indlejringer i fællesskab uden at afsløre rå data for en central tjeneste. |
| **Rollebaseret Adgangskontrol (RBAC)** | Tilladelser tildeles baseret på brugerroller frem for individuelle identiteter. | Sikrer, at kun autoriseret personale kan se eller redigere tenant‑specifikke prompts eller bevissamlinger. |
| **Tenant‑Isolation Layer** | Logisk og fysisk adskillelse (fx separate databaser, containeriserede køretider) af hver tenants data og prompt‑indlejringer. | Garanterer overholdelse af data‑suverænitet og forenkler auditability. |

---

## 2. Arkitektonisk Oversigt

Diagrammet nedenfor viser end‑til‑end‑flowet fra en tenants spørgeskema‑forespørgsel til det AI‑genererede svar, med fokus på de privatlivsbevarende kontroller.

```mermaid
graph TD
    "User Request\n(Questionnaire Item)" --> "Tenant Router"
    "Tenant Router" --> "Policy & Evidence Store"
    "Tenant Router" --> "Prompt Tuning Service"
    "Prompt Tuning Service" --> "Privacy Guard\n(Differential Privacy Layer)"
    "Privacy Guard" --> "LLM Inference Engine"
    "LLM Inference Engine" --> "Answer Formatter"
    "Answer Formatter" --> "Tenant Response Queue"
    "Tenant Response Queue" --> "User Interface"
```

### Nøglekomponenter

1. **Tenant Router** – Bestemmer tenants kontekst ud fra API‑nøgler eller SSO‑tokens og videresender forespørgslen til de relevante isolerede tjenester.  
2. **Policy & Evidence Store** – En per‑tenant krypteret datalake (fx AWS S3 med bucket‑politikker) der indeholder sikkerhedspolitikker, revisionslogfiler og bevisartefakter.  
3. **Prompt Tuning Service** – Genererer eller opdaterer tenant‑specifikke prompt‑indlejringer ved hjælp af SMPC for at holde de rå beviser skjult.  
4. **Privacy Guard** – Påtvinger differentiel‑privatlivsstøj på aggregeret statistik eller feedback, der bruges til modelforbedring.  
5. **LLM Inference Engine** – En statsløs container, der kører den frosne LLM (fx Claude‑3, GPT‑4) med tenant‑specifikke prompt‑vektorer.  
6. **Answer Formatter** – Anvender efterbehandlingsregler (fx redaktion, indsættelse af overholdelsesmærkater) før det endelige svar leveres.  
7. **Tenant Response Queue** – En meddelelses‑drevet buffer (fx Kafka‑topic per tenant) der sikrer eventual consistency og revisionsspor.

---

## 3. Implementering af Privatlivsbevarende Prompt‑justering

### 3.1 Forberedelse af Datalake

1. **Kryptering i hvile** – Brug server‑side kryptering med kundestyrte nøgler (CMK‑er) for hver tenant‑bucket.  
2. **Metadata‑tagging** – Tilføj compliance‑relaterede tags (`iso27001:true`, `gdpr:true`) for at muliggøre automatisk politik‑hentning.  
3. **Versionering** – Aktivér objekt‑versionering for at opretholde et komplet revisionsspor for bevisændringer.

### 3.2 Generering af Tenant‑Specifikke Prompt‑vektorer

1. **Initialiser Prompt‑indlejring** – Generer tilfældigt en lille (fx 10‑dimensional) tæt vektor pr. tenant.  
2. **SMPC‑træningsløb**  
   - **Trin 1**: Tenantens sikre enclave (fx AWS Nitro Enclaves) indlæser sit subset af beviser.  
   - **Trin 2**: Enclave beregner gradienten af et tabs‑funktion, der måler, hvor godt LLM’en svarer på simulerede spørgeskema‑elementer med den aktuelle prompt‑vektor.  
   - **Trin 3**: Gradienterne deles som hemmelige andele via additiv hemmelig deling mellem den centrale server og enclave’en.  
   - **Trin 4**: Serveren aggregerer andelene, opdaterer prompt‑vektoren og returnerer de opdaterede andele til enclave’en.  
   - **Trin 5**: Gentag indtil konvergens (typisk ≤ 50 iterationer på grund af den lave dimensionalitet).  

3. **Gem Prompt‑vektorer** – Persister de færdige vektorer i en tenant‑isoleret nøgleværks‑butik (fx DynamoDB med per‑tenant partitionsnøgler), krypteret med tenantens CMK.

### 3.3 Gennemførelse af Differentiel Privatliv

Når systemet aggregerer brugsstatistik (fx hvor mange gange et bestemt bevis‑artefakt refereres) for fremtidige modelforbedringer, anvendes Laplace‑mekanismen:

\[
\tilde{c} = c + \text{Laplace}\left(\frac{\Delta f}{\epsilon}\right)
\]

- **\(c\)** – Den egentlige optælling af en bevis‑reference.  
- **\(\Delta f = 1\)** – Sensitivitet (tilføjelse/fjernelse af én reference ændrer tællingen med højst 1).  
- **\(\epsilon\)** – Privatlivsbudget (vælg 0,5–1,0 for stærke garantier).  

Alle downstream‑analyser bruger \(\tilde{c}\), så ingen tenant kan inferere tilstedeværelsen af et specifikt dokument.

### 3.4 Real‑time Inference‑flow

1. **Modtag Forespørgsel** – UI sender et spørgeskema‑element med tenant‑token.  
2. **Hent Prompt‑vektor** – Prompt Tuning Service henter tenantens vektor fra KV‑butikken.  
3. **Indsprøjt Prompt** – Vektoren sammenkædes med LLM‑ens input som en “soft prompt”.  
4. **Kør LLM** – Inference udføres i en sandboxed container med zero‑trust netværk.  
5. **Efterbehandling** – Rediger eventuel utilsigtet datalækage med mønstergenkendelses‑filter.  
6. **Returnér Svar** – Det formaterede svar sendes tilbage til UI og logges til revision.

---

## 4. Sikkerheds‑ og Overholdelsestjekliste

| Område | Kontrol | Frekvens |
|---|---|---|
| **Dataisolation** | Verificer bucket‑politikker, så kun den respektive tenant har adgang. | Kvartalsvis |
| **Prompt‑vektor‑fortrolighed** | Roter CMK‑er og kør SMPC‑justering igen ved rotation. | Årligt / ved behov |
| **DP‑budget** | Gennemgå \(\epsilon\)-værdier og sikre, at de opfylder regulatoriske krav. | Halvårligt |
| **Audit‑logning** | Gem uforanderlige logs over prompt‑hentning og svar‑generering. | Kontinuerligt |
| **Penetrationstest** | Udfør red‑team‑øvelser mod inference‑sandboxen. | Halvårligt |
| **Compliance‑kortlægning** | Matche hver tenants bevis‑tags med [ISO 27001](https://www.iso.org/standard/27001), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), GDPR‑kontroller osv. | Løbende |

---

## 5. Ydeevne og Skalerbarhed

| Måling | Mål | Optimerings‑tips |
|---|---|---|
| **Latency (95‑percentil)** | < 1,2 sekunder pr. svar | Brug “warm” containere, cache prompt‑vektorer i hukommelsen, forvarm LLM‑model‑shards. |
| **Throughput** | 10 k forespørgsler/sekund på tværs af alle tenants | Horisontal pod‑autoscaling, batch‑forespørgsler med lignende prompts, GPU‑accelereret inference. |
| **Prompt‑justeringstid** | ≤ 5 minutter pr. tenant (initial) | Paralleliser SMPC på flere enclaves, reducer vektor‑dimensionalitet. |
| **DP‑støj‑indvirkning** | ≤ 1 % tab af nytte på aggregeret statistik | Juster \(\epsilon\) baseret på empiriske nytte‑kurver. |

---

## 6. Praktisk Eksempel: FinTech SaaS‑Platform

En FinTech‑SaaS‑udbyder leverer en compliance‑portal til over 200 partnere. Hver partner gemmer proprietære risikomodeller, KYC‑dokumenter og revisionslogfiler. Ved at adoptere privatlivsbevarende prompt‑justering:

- **Responstid** for **SOC 2**‑spørgeskema‑svar faldt fra 4 dage til < 2 timer.  
- **Cross‑tenant datalækage‑hændelser** gik til nul (verificeret af ekstern revision).  
- **Compliance‑omkostninger** blev reduceret med ca. 30 % gennem automatisering af bevis‑hentning og svar‑generering.  

Udbyderen udnyttede også DP‑beskyttede brugs‑metrikker til at drive en **kontinuerlig forbedrings‑pipeline**, der foreslog nye bevis‑artefakter, uden nogensinde at afsløre partnerdata.

---

## 7. Trin‑for‑Trin Implementeringsguide

1. **Provisioner Infrastruktur**  
   - Opret separate S3‑buckets per tenant med CMK‑kryptering.  
   - Deploy Nitro Enclaves eller Confidential VMs til SMPC‑arbejdsbelastninger.  

2. **Opsæt KV‑butik**  
   - Opret en DynamoDB‑tabel med partitionsnøgle `tenant_id`.  
   - Aktivér point‑in‑time recovery for rollback af prompt‑vektorer.  

3. **Integrer Prompt Tuning Service**  
   - Deploy en mikrotjeneste (`/tune-prompt`) med REST‑API.  
   - Implementér SMPC‑protokollen ved hjælp af **MP‑SPDZ**‑biblioteket (open‑source).  

4. **Konfigurer Privacy Guard**  
   - Tilføj middleware, der injicerer Laplace‑støj i alle telemetri‑endpoints.  

5. **Deploy Inference Engine**  
   - Brug OCI‑kompatible containere med GPU‑passthrough.  
   - Load den frosne LLM‑model (fx `claude-3-opus`).  

6. **Implementér RBAC**  
   - Map tenant‑roller (`admin`, `analyst`, `viewer`) til IAM‑politikker, der begrænser læs‑/skrivetilgang til prompt‑vektorer og bevis‑samlinger.  

7. **Byg UI‑laget**  
   - Lever et spørgeskema‑editor‑værktøj, der henter prompts via `/tenant/{id}/prompt`.  
   - Vis audit‑logs og DP‑justerede brugs‑analyser i dashboardet.  

8. **Kør Accepttest**  
   - Simulér cross‑tenant forespørgsler for at bekræfte ingen datalækage.  
   - Validér DP‑støj‑niveauer mod defineret privatlivsbudget.  

9. **Go Live & Overvåg**  
   - Aktiver auto‑scaling‑politikker.  
   - Opsæt alarmer for latenstid‑spidser eller IAM‑tilladelses‑anomalier.  

---

## 8. Fremtidige Forbedringer

- **Federated Prompt Learning** – Tillad tenants at forbedre en fælles basis‑prompt gennem federeret gennemsnit, mens privatliv bevares.  
- **Zero‑Knowledge Proofs** – Generér verificerbare beviser for, at et svar er afledt fra specifikke beviser uden at afsløre dem.  
- **Adaptiv DP‑budgettering** – Dynamisk alloker \(\epsilon\) baseret på forespørgsels‑sensitivitet og tenant‑risikoprofil.  
- **Explainable AI (XAI) Overlay** – Tilføj begrundelses‑uddrag, der refererer til de specifikke politik‑paragrafer, der bruges til at generere hvert svar, hvilket øger audit‑parathed.  

---

## Konklusion

Privatlivsbevarende prompt‑justering åbner den gyldne mellemvej mellem **høj‑præcision AI‑automatisering** og **streng multi‑tenant data‑isolation**. Ved at kombinere SMPC‑baseret prompt‑læring, differentiel privatliv og robust RBAC, kan SaaS‑udbydere levere øjeblikkelige, præcise sikkerhedsspørgeskema‑svar uden at risikere datalækage på tværs af tenants eller brud på regulatoriske krav. Den beskrevne arkitektur er både **skalerbar**—den kan håndtere tusindvis af samtidige forespørgsler—og **fremtidssikret**, klar til at inkorporere nye privatlivsteknologier, efterhånden som de modnes.

Ved at adoptere denne tilgang forkortes ikke kun salgsprocesser og reduceres manuel arbejdsbyrde, men virksomheder får også den ro i sindet, der følger af at deres mest følsomme compliance‑beviser forbliver præcis, hvor de hører hjemme: bag deres egne firewalls.

---

## Se Også

- Differentiel Privatliv i Produktion – En Introduktion (Google AI Blog)  
- Prompt‑justering vs Fine‑tuning: Hvornår skal man bruge hvad (OpenAI Teknisk Rapport)