
# Policy som kode møder AI: Automatisk generering af compliance‑as‑code til svar på spørgeskemaer

I den hastigt bevægende SaaS‑verden er **sikkerhedsspørgeskemaer** og **compliance‑revisioner** blevet portvagter til hver ny kontrakt. Teams bruger utallige timer på at finde politikker, oversætte juridisk jargon til klar dansk, og manuelt kopiere svar ind i leverandørportaler. Resultatet er en flaskehals, der sænker salgsprocessen og introducerer menneskelige fejl.

Enter **Policy‑as‑Code (PaC)** — praksissen med at definere sikkerheds‑ og compliance‑kontroller i versionsstyrede, maskinlæselige formater (YAML, JSON, HCL osv.). Samtidig er **store sprogmodeller (LLM'er)** modne nok til at forstå kompleks reguleringssprog, syntetisere beviser og generere naturligt sprog‑svar, der tilfredsstiller revisorer. Når disse to paradigmer mødes, opstår en ny evne: **Automatiseret Compliance‑as‑Code (CaaC)**, der kan *generere* svar på spørgeskemaer på efterspørgsel, komplet med sporbare beviser.

I denne artikel vil vi:

1. Forklare grundkonceptet bag Policy‑as‑Code og hvorfor det betyder noget for sikkerhedsspørgeskemaer.  
2. Vise, hvordan en LLM kan kobles ind i et PaC‑arkiv for at producere **dynamiske, revisionsklare svar**.  
3. Gå igennem en praktisk implementering ved brug af **Procurize**‑platformen som eksempel.  
4. Fremhæve bedste praksis, sikkerhedsovervejelser og måder at holde systemet troværdigt på.  

> **TL;DR** – Ved at kode politikker, eksponere dem gennem et API og lade en fintunet LLM oversætte disse politikker til spørgeskema‑svar, kan organisationer reducere svartiden fra dage til sekunder, mens de bevarer compliance‑integriteten.

---

## 1. Stigningen af Policy‑as‑Code

### 1.1 Hvad er Policy‑as‑Code?

Policy‑as‑Code behandler sikkerheds‑ og compliance‑politikker på samme måde som udviklere behandler applikationskode:

| Traditionel politikbehandling | Policy‑as‑Code‑tilgang |
|------------------------------|------------------------|
| PDF‑er, Word‑dokumenter, regneark | Deklarative filer (YAML/JSON) lagret i Git |
| Manuel versionssporing | Git‑commits, pull‑request‑gennemgange |
| Ad‑hoc distribution | Automatiserede CI/CD‑pipelines |
| Svært at søge i teksten | Strukturerede felter, søgbare indekser |

Da politikker lever i en **enkelt kilde til sandhed**, udløser enhver ændring en automatiseret pipeline, der validerer syntaks, kører enhedstests og opdaterer nedstrømssystemer (fx CI/CD‑sikkerhedsgates, compliance‑dashboards).

### 1.2 Hvorfor PaC påvirker spørgeskemaer direkte

Sikkerhedsspørgeskemaer stiller typisk spørgsmål som:

> “Beskriv, hvordan I beskytter data i hvile, og fremlæg bevis for rotering af krypteringsnøgler.”

Hvis den underliggende politik er defineret som kode:

```yaml
controls:
  data-at-rest:
    encryption: true
    algorithm: "AES‑256-GCM"
    key_rotation:
      interval_days: 90
      procedure: "Automatiseret rotering via KMS"
evidence:
  - type: "config"
    source: "aws:kms:key-rotation"
    last_verified: "2025-09-30"
```

Et værktøj kan **ekstrahere** de relevante felter, formatere dem til naturligt sprog og vedhæfte den refererede evidensfil — uden at et menneske skriver et eneste ord.

---

## 2. Store sprogmodeller som oversættelses‑motor

### 2.1 Fra kode til naturligt sprog

LLM'er udmærker sig i **tekstgenerering**, men har brug for en pålidelig kontekst for at undgå hallucinationer. Ved at give modellen en **struktureret politikpayload** plus en **spørgsmålsskabelon**, skaber vi en deterministisk kortlægning.

**Prompt‑mønster** (forenklet):

```
Du er en compliance‑assistent. Oversæt følgende politikfragment til et kort svar på spørgsmålet: "<question>". Angiv eventuelle refererede evidens‑ID'er.
Policy:
<YAML‑blok>
```

Når LLM’en modtager denne kontekst, gætter den ikke; den **spejler** de data, der allerede findes i arkivet.

### 2.2 Fin‑tuning for domænespecifik nøjagtighed

En generisk LLM (fx GPT‑4) indeholder enorm viden, men kan stadig producere vage formuleringer. Ved at **fin‑tune** på et kurateret korpus af historiske spørgeskema‑svar og interne stilguider opnår vi:

- Konsistent tone (formel, risikobewusst).  
- Compliance‑specifik terminologi (fx “SOC 2” – se [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)), “ISO 27001” – se [ISO 27001](https://www.iso.org/standard/27001) / [ISO/IEC 27001 Information Security Management](https://www.iso.org/isoiec-27001-information-security.html).  
- Reduceret token‑forbrug, hvilket sænker inferenskostnaden.

### 2.3 Guardrails og Retrieval‑Augmented Generation (RAG)

For at øge pålideligheden kombinerer vi LLM‑generering med **RAG**:

1. **Retriever** henter det præcise politik‑uddrag fra PaC‑repoet.  
2. **Generator** (LLM) modtager både uddraget og spørgsmålet.  
3. **Post‑processor** validerer, at alle citerede evidens‑ID’er findes i evidens‑lageret.

Opdager man en uoverensstemmelse, flagges svaret automatisk til manuel gennemgang.

---

## 3. End‑to‑End‑workflow på Procurize

Nedenfor er en høj‑niveau oversigt over, hvordan Procurize integrerer PaC og LLM for at levere **real‑time, auto‑genererede svar på spørgeskemaer**.

```mermaid
flowchart TD
    A["Policy‑as‑Code‑repository (Git)"] --> B["Ændringsdetekterings‑service"]
    B --> C["Policy‑indeksering (Elasticsearch)"]
    C --> D["Retriever (RAG)"]
    D --> E["LLM‑motor (Fin‑tuned)"]
    E --> F["Svar‑formatter"]
    F --> G["Spørgeskema‑UI (Procurize)"]
    G --> H["Menneskelig gennemgang & publicering"]
    H --> I["Audit‑log & sporbarhed"]
    I --> A
```

### 3.1 Step‑for‑step gennemgang

| Trin | Handling | Teknologi |
|------|----------|-----------|
| **1** | Et sikkerhedsteam opdaterer en politikfil i Git. | Git, CI‑pipeline |
| **2** | Ændringsdetektering udløser en gen‑indeksering af politikken. | Webhook, Elasticsearch |
| **3** | Når et leverandør‑spørgeskema ankommer, viser UI’et det relevante spørgsmål. | Procurize‑dashboard |
| **4** | Retrieveren forespørger indekset efter matchende politik‑fragmenter. | RAG‑retrieval |
| **5** | LLM’en modtager fragmentet + prompt og genererer et udkastssvar. | OpenAI / Azure OpenAI |
| **6** | Svar‑formattereren tilføjer markdown, vedhæfter evidens‑links og formaterer til mål‑portalen. | Node.js‑mikrotjeneste |
| **7** | Sikkerhedsejer gennemgår svaret (valgfrit, kan auto‑godkendes baseret på tillids‑score). | UI‑gennemgangs‑modal |
| **8** | Endeligt svar indsendes til leverandørportalen; en uforanderlig audit‑log registrerer oprindelse. | Procurement‑API, blockchain‑lignende log |
| **9** | Loggen linker tilbage til politik‑repoet for fremtidig revision. | – |

Hele cyklussen kan færdiggøres på **under 10 sekunder** for et typisk spørgsmål – et skarpt kontrast til de 2‑4 timer, det tager en menneskelig analytiker at finde politik, udforme og verificere et svar.

---

## 4. Sådan bygger du din egen CaaC‑pipeline

Nedenfor er en praktisk guide til teams, der ønsker at reproducere mønsteret.

### 4.1 Definér et politik‑skema

Start med et **JSON‑skema**, der indkapsler nødvendige felter:

```json
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Compliance Control",
  "type": "object",
  "properties": {
    "id": { "type": "string" },
    "category": { "type": "string" },
    "description": { "type": "string" },
    "evidence": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "type": { "type": "string" },
          "source": { "type": "string" },
          "last_verified": { "type": "string", "format": "date" }
        },
        "required": ["type", "source"]
      }
    }
  },
  "required": ["id", "category", "description"]
}
```

Valider hver politikfil via et CI‑trin (fx `ajv-cli`).

### 4.2 Opsæt Retrieval

- Indexér YAML/JSON‑filer i **Elasticsearch** eller **OpenSearch**.  
- Brug **BM25** eller **dense vector‑embeddings** (via Sentence‑Transformer) til semantisk match.

### 4.3 Fin‑tune LLM’en

1. Eksportér historiske Q&A‑par (inkl. evidens‑ID’er).  
2. Konvertér til den prompt‑/completion‑format, din LLM‑udbyder kræver.  
3. Kør **supervised fin‑tuning** (OpenAI `v1/fine-tunes`, Azure `deployment`).  
4. Evaluer med **BLEU** og, vigtigere, **menneskelig validering** for regulatorisk compliance.

### 4.4 Implementér Guardrails

- **Tillids‑score**: Returnér top‑k token‑sandsynligheder; auto‑godkend kun ved score > 0,9.  
- **Evidens‑verificering**: Et post‑processor‑script tjekker, at hver citeret `source` findes i evidens‑lageret (SQL/NoSQL).  
- **Prompt‑injection‑beskyttelse**: Rens enhver bruger‑leveret tekst, før den indsættes i prompten.

### 4.5 Integrér med Procurize

Procurize tilbyder allerede webhook‑hooks for indkomne spørgeskemaer. Kobl dem til en **serverless‑funktion** (AWS Lambda, Azure Functions), som kører pipeline‑trinnene beskrevet i afsnit 3.

---

## 5. Fordele, risici og afbødning

| Fordel | Forklaring |
|--------|------------|
| **Hastighed** | Svar genereres på sekunder, hvilket kraftigt reducerer salgscyklus‑latens. |
| **Ensartethed** | Samme kilde til sandhed sikrer identisk formulering på tværs af leverandører. |
| **Sporbarhed** | Hvert svar linkes til en politik‑ID og evidens‑hash, hvilket tilfredsstiller revisorer. |
| **Skalerbarhed** | Én ændring i politikken påvirker straks alle ventende spørgeskemaer. |

| Risiko | Afbødning |
|-------|-----------|
| **Hallucination** | Anvend RAG; kræv evidens‑verificering før publicering. |
| **Udløbet evidens** | Automatiser friskhedstjek (fx cron‑job, der flagger >30 dages gamle artefakter). |
| **Adgangskontrol** | Gem politik‑repo bag IAM; kun autoriserede roller kan committe ændringer. |
| **Model‑drift** | Re‑evaluer løbende den fin‑tunede model mod friske test‑sæt. |

---

## 6. Real‑world impact – Et kort case‑studie

**Virksomhed:** SyncCloud (et mellemstort SaaS‑dataplatform)  
**Før CaaC:** Gennemsnitlig svartid på spørgeskemaer 4 dage, 30 % manuelt genarbejde pga. inkonsistens i formuleringerne.  
**Efter CaaC:** Gennemsnitlig svartid 15 minutter, 0 % genarbejde, audit‑log viste 100 % sporbarhed.  
**Nøgle‑målinger:**  

- **Sparede tid:** ~2 timer pr. analytiker pr. uge.  
- **Øget deal‑hastighed:** 12 % stigning i lukke‑win‑muligheder.  
- **Compliance‑score:** Forbedret fra “moderat” til “høj” i tredjeparts‑vurderinger.

Transformationen opnåedes ved at konvertere 150 politikdokumenter til PaC, fin‑tune en 6‑B‑parameter LLM på 2 k historiske svar, og integrere pipelinen i Procurize‑spørgeskema‑UI’en.

---

## 7. Fremtidige retninger

1. **Zero‑Trust evidens‑styring** – Kombinér CaaC med blockchain‑notarisering for uforanderlig bevis‑proveniens.  
2. **Flersproget understøttelse** – Udvid fin‑tuning til at inkludere juridiske oversættelser for **GDPR** – se [GDPR](https://gdpr.eu/), **CCPA** – se [CCPA](https://oag.ca.gov/privacy/ccpa) og **CPRA** – se [CPRA](https://thecpra.org/), samt nye data‑suverænitet‑love.  
3. **Selvreparerende politikker** – Anvend reinforcement learning, hvor modellen får feedback fra revisorer og automatisk foreslår politik‑forbedringer.  

Disse innovationer vil flytte CaaC fra et **produktivitetsværktøj** til en **strategisk compliance‑motor**, der proaktivt former sikkerhedsholdningen.

---

## 8. Kom i gang‑tjekliste

- [ ] Definér og versionsstyr en Policy‑as‑Code‑schema.  
- [ ] Populér arkivet med alle eksisterende politikker og evidens‑metadata.  
- [ ] Opsæt en retrieval‑tjeneste (Elasticsearch/OpenSearch).  
- [ ] Indsaml historiske Q&A‑data og fin‑tune en LLM.  
- [ ] Byg en tillids‑score‑ og evidens‑verifikations‑wrapper.  
- [ ] Integrér pipelinen med din spørgeskema‑platform (fx Procurize).  
- [ ] Kør en pilot med et lav‑risiko leverandør‑spørgeskema og iterer.

Ved at følge denne køreplan kan din organisation gå fra **reaktiv manuel indsats** til **proaktiv, AI‑drevet compliance‑automation**.

---

### Referencer til almindelige rammer og standarder (linket for hurtig adgang)

- **SOC 2** – [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)  
- **ISO 27001** – [ISO 27001](https://www.iso.org/standard/27001) & [ISO/IEC 27001 Information Security Management](https://www.iso.org/isoiec-27001-information-security.html)  
- **GDPR** – [GDPR](https://gdpr.eu/)  
- **HIPAA** – [HIPAA](https://www.hhs.gov/hipaa/index.html)  
- **NIST CSF** – [NIST CSF](https://www.nist.gov/cyberframework)  
- **DPAs** – [DPAs](https://www.dpocentre.com/what-is-a-dpa-and-why-do-you-need-one/)  
- **Cloud Security Alliance STAR** – [Cloud Security Alliance STAR](https://cloudsecurityalliance.org/star/)  
- **PCI‑DSS** – [PCI‑DSS](https://www.pcisecuritystandards.org/pci_security/)  
- **CCPA** – [CCPA](https://oag.ca.gov/privacy/ccpa)  
- **CPRA** – [CPRA](https://thecpra.org/)  
- **Gartner Security Automation Trends** – [Gartner Security Automation Trends](https://www.gartner.com/en/documents/5202463)  
- **Gartner Sales Cycle Benchmarks** – [Gartner Sales Cycle Benchmarks](https://www.gartner.com/en/sales)  
- **MITRE AI Security** – [MITRE AI Security](https://www.mitre.org/)  
- **EU AI Act Compliance** – [EU AI Act Compliance](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)  
- **SLAs** – [SLAs](https://www.ibm.com/think/topics/service-level-agreement)  
- **NYDFS** – [NYDFS](https://www.dfs.ny.gov/industry_guidance/cybersecurity)  
- **DORA** – [DORA](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en)  
- **BBB Trust Seal** – [BBB Trust Seal](https://www.bbb.org/)  
- **Google Trust & Safety** – [Google Trust & Safety](https://safety.google/)  
- **FedRAMP** – [FedRAMP](https://www.fedramp.gov/)  
- **CISA Cybersecurity Best Practices** – [CISA Cybersecurity Best Practices](https://www.cisa.gov/topics/cybersecurity-best-practices)  
- **EU Cloud Code of Conduct** – [EU Cloud Code of Conduct](https://eucoc.cloud/en/home)