
# Prompt Engineering for pålidelige AI‑genererede svar på sikkerhedsspørgeskemaer

## Introduktion  

Sikkerhedsspørgeskemaer udgør en flaskehals for mange SaaS‑virksomheder. En enkelt leverandørvurdering kan indeholde dusinvis af detaljerede spørgsmål om databeskyttelse, hændelsesrespons, adgangskontrol og mere. Manuel svarproduktion er tidskrævende, fejlbehæftet og fører ofte til duplikeret arbejde på tværs af teams.  

Store sprogmodeller (LLM’er) som GPT‑4, Claude eller Llama 2 har evnen til at udarbejde højkvalitets‑narrative svar på sekunder. Men at frigive den kraft direkte på et spørgeskema giver sjældent pålidelige resultater. Den rå output kan afvige fra politik‑sproget, overse kritiske klausuler eller hallucinerere beviser, der ikke findes.  

**Prompt engineering** — den disciplineret praksis med at udforme den tekst, der guider en LLM — bygger broen mellem rå generativ evne og de strenge compliance‑standarder, som sikkerhedsteams kræver. I denne artikel gennemgår vi et gentageligt prompt engineering‑rammeværk, der forvandler en LLM til en pålidelig assistent for automatisering af sikkerhedsspørgeskemaer.  

Vi vil dække:

* Sådan indlejres politik‑viden direkte i prompts  
* Teknikker til styring af tone, længde og struktur  
* Automatiserede verifikations‑loops, der fanger uoverensstemmelser inden de når auditorerne  
* Integrationsmønstre for platforme som Procurize, inklusiv et Mermaid‑arbejdsflow‑diagram  

Når guiden er gennemgået, vil praktikere have et konkret værktøjssæt, de kan anvende med det samme for at reducere svartiden på spørgeskemaer med 50 % – 70 % og samtidig forbedre svarnøjagtigheden.

---

## 1. Forståelse af prompt‑landskabet  

### 1.1 Prompt‑typer  

| Prompt‑type | Mål | Eksempel |
|-------------|------|---------|
| **Kontekst‑prompt** | Giver LLM’en relevante politikutdrag, standarder og definitioner | “Nedenfor er et uddrag fra vores [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) politik om kryptering i hvile…” |
| **Instruktions‑prompt** | Fortæller modellen præcis, hvordan svaret skal formateres | “Skriv svaret i tre korte afsnit, hver med en fed overskrift.” |
| **Begrænsnings‑prompt** | Sætter hårde grænser som ord­antal eller forbudte termer | “Overskrid ikke 250 ord og undgå ordet ‘måske’.” |
| **Verifikations‑prompt** | Genererer en tjekliste, som svaret skal opfylde | “Efter udarbejdelsen af svaret, list alle politikesektioner, der ikke blev refereret.” |

En robust svar‑pipeline for spørgeskemaer sammenkæder typisk flere af disse prompt‑typer i én enkelt anmodning eller bruger en fler‑trins tilgang (prompt → respons → re‑prompt).

### 1.2 Hvorfor one‑shot prompts fejler  

En naiv one‑shot prompt som *“Besvar følgende sikkerhedsspørgsmål”* producerer ofte:

* **Udeladelse** — vigtige politik‑referencer mangler.  
* **Hallucination** — modellen opfinder kontroller, der ikke findes.  
* **Inkonsekvent sprog** — svaret bruger uformuleringer, der konflikterer med virksomhedens compliance‑tone.  

Prompt engineering afbøder disse risici ved at tilføre LLM’en præcis den information, den behøver, og ved at bede den om selv‑audit af sit output.

---

## 2. Bygning af et prompt engineering‑rammeværk  

Nedenfor er et trin‑for‑trin rammeværk, der kan kodificeres som en genanvendelig funktion i enhver compliance‑platform.

### 2.1 Trin 1 – Hent relevante politik‑fragmenter  

Brug en søgbar vidensbase (vektor‑store, graf‑DB eller simpel nøgleords‑index) til at trække de mest relevante politik‑afsnit.  
*Eksempel‑spørgsmål*: “kryptering i hvile” + “[ISO 27001](https://www.iso.org/standard/27001)” eller “SOC 2 CC6.1”.

Resultatet kan være:

```
Policy Fragment A:
“All production data must be encrypted at rest using AES‑256 or an equivalent algorithm. Encryption keys are rotated every 90 days and stored in a hardware security module (HSM).”
```

### 2.2 Trin 2 – Saml prompt‑skabelonen  

En skabelon, der kombinerer alle prompt‑typer:

```
[CONTEXT] 
{Policy Fragments}

[INSTRUCTION] 
You are a compliance specialist drafting an answer for a security questionnaire. The target audience is a senior security auditor. Follow these rules:
- Use the exact language from the policy fragments where applicable.
- Structure the answer with a short intro, a detailed body, and a concise conclusion.
- Cite each policy fragment with a reference tag (e.g., [Fragment A]).

[QUESTION] 
{Security Question Text}

[CONSTRAINT] 
- Maximum 250 words.
- Do not introduce any controls not mentioned in the fragments.
- End with a statement confirming that evidence can be provided on request.

[VERIFICATION] 
After answering, list any policy fragments that were not used and any new terminology introduced.
```

### 2.3 Trin 3 – Send til LLM’en  

Send den samlede prompt til den valgte LLM via dens API. For reproducerbarhed, sæt `temperature = 0.2` (lav tilfældighed) og `max_tokens` i overensstemmelse med ord‑begrænsningen.

### 2.4 Trin 4 – Parse og verifikér responsen  

LLM’en returnerer to sektioner: **svaret** og **verifikations‑tjeklisten**. Et automatiseret script kontrollerer:

* At alle nødvendige fragment‑tags er til stede.  
* At ingen nye kontrol‑navne forekommer (sammenlign med en whitelist).  
* At ord‑tællingen overholder begrænsningen.

Hvis en regel fejler, udløser scriptet et **re‑prompt** med feedback:

```
[FEEDBACK]
You missed referencing Fragment B and introduced the term “dynamic key rotation” which is not part of our policy. Please revise accordingly.
```

### 2.5 Trin 5 – Tilføj bevis‑links  

Efter en vellykket verifikation tilføjer systemet automatisk links til understøttende beviser (f.eks. logfiler for nøgle‑rotation, HSM‑certifikater). Det endelige output gemmes i Procurizes evidens‑hub og gøres synligt for reviewererne.

---

## 3. Real‑World workflow‑diagram  

Det følgende Mermaid‑diagram visualiserer den ende‑til‑ende flow i en typisk SaaS‑compliance‑platform.

```mermaid
graph TD
    A["User selects questionnaire"] --> B["System fetches relevant policy fragments"]
    B --> C["Prompt Builder assembles multi‑part prompt"]
    C --> D["LLM generates answer + verification checklist"]
    D --> E["Automated validator parses checklist"]
    E -->|Pass| F["Answer stored, evidence links attached"]
    E -->|Fail| G["Re‑prompt with feedback"]
    G --> C
    F --> H["Reviewers view answer in Procurize dashboard"]
    H --> I["Audit completed, response exported"]
```

Alle node‑labels er indkapslet i dobbelte anførselstegn som påkrævet.

---

## 4. Avancerede prompt‑teknikker  

### 4.1 Few‑shot demonstrationer  

At give et par *eksempel* – spørgsmål‑svar‑par i prompten kan dramatisk forbedre konsistensen. Eksempel:

```
Example 1:
Q: How do you protect data in transit?
A: All data in transit is encrypted using TLS 1.2 or higher, with forward‑secrecy ciphers. [Fragment C]

Example 2:
Q: Describe your incident response process.
A: Our IR plan follows the [NIST CSF](https://www.nist.gov/cyberframework) (NIST 800‑61) framework, includes a 24‑hour escalation window, and is reviewed bi‑annually. [Fragment D]
```

LLM’en får nu en konkret stil at efterligne.

### 4.2 Chain‑of‑Thought prompting  

Opfordr modellen til at tænke trin‑for‑trin før den svarer:

```
Think about which policy fragments apply, list them, then craft the answer.
```

Dette mindsker hallucination og giver et gennemsigtigt ræsonnement, som kan logges.

### 4.3 Retrieval‑Augmented Generation (RAG)  

I stedet for at trække fragmenter inden prompten, lad LLM’en forespørge en vektor‑store under genereringen. Denne tilgang fungerer godt, når politik‑korpuset er meget stort og konstant i udvikling.

---

## 5. Integration med Procurize  

Procurize tilbyder allerede:

* **Policy repository** (centraliseret, versionskontrolleret)  
* **Questionnaire tracker** (opgaver, kommentarer, audit‑spor)  
* **Evidence hub** (fil‑lagring, auto‑linking)  

Indlejring af prompt engineering‑pipelineen indebærer tre nøgle‑API‑kald:

1. `GET /policies/search` – hent fragmenter baseret på nøgleord udtrukket fra spørgsmålet.  
2. `POST /llm/generate` – send den samlede prompt og modtag svar + verifikation.  
3. `POST /questionnaire/{id}/answer` – indsend det verificerede svar, tilknyt bevis‑URL’er, og marker opgaven som færdig.

Et letvægts‑Node.js‑wrapper kan se sådan ud:

```javascript
async function answerQuestion(questionId) {
  const q = await api.getQuestion(questionId);
  const fragments = await api.searchPolicies(q.keywords);
  const prompt = buildPrompt(q.text, fragments);
  const { answer, verification } = await api.llmGenerate(prompt);
  if (verify(verification)) {
    await api.submitAnswer(questionId, answer, fragments.evidenceLinks);
  } else {
    const revisedPrompt = addFeedback(prompt, verification);
    // recursion or loop until pass
  }
}
```

Når dette er vævet ind i Procurize‑UI’et, kan sikkerhedsanalytikere klikke på *“Auto‑Generate Answer”* og følge fremdriftslinjen gennem de trin, der er defineret i Mermaid‑diagrammet.

---

## 6. Måling af succes  

| Målepunkt | Baseline | Mål efter prompt engineering |
|-----------|----------|------------------------------|
| Gennemsnitlig tid pr. svar | 45 min | ≤ 15 min |
| Korrektionsrate ved menneskelig review | 22 % | ≤ 5 % |
| Overholdelse af politik‑referencer (tags) | 78 % | ≥ 98 % |
| Auditor‑tilfredshed (score) | 3.2/5 | ≥ 4.5/5 |

Indsamles via Procurizes analyse‑dashboard. Kontinuerlig overvågning gør det muligt at fin‑justere prompt‑skabeloner og fragment‑udvælgelse.

---

## 7. Faldgruber og hvordan de undgås  

| Faldgrube | Symptom | Løsning |
|-----------|---------|----------|
| Overbelastning af prompten med irrelevante fragmenter | Svaret driver, længere LLM‑latens | Implementer en relevans‑threshold (fx cosine similarity > 0.78) før inklusion |
| Ignorering af model‑temperature | Tilfældige, men unøjagtige uddata | Fast‑sæt temperature til lav værdi (0.1‑0.2) for compliance‑opgaver |
| Manglende versionering af politik‑fragmenter | Svar refererer til forældede klausuler | Gem fragmenter med versions‑ID og håndhæv “seneste‑kun” politik, medmindre historisk version eksplicit anmodes |
| Kun én verifikations‑pass | Oversete edge‑case overtrædelser | Kør et sekundært regel‑engine‑tjek (fx regex for forbudte termer) efter LLM‑pass |

---

## 8. Fremtidige retninger  

* **Dynamisk prompt‑optimering** – brug reinforcement learning til automatisk at justere prompt‑formulering baseret på historisk succesrate.  
* **Multi‑LLM ensembles** – forespørg flere modeller parallelt og udvælg svaret med højeste verifikations‑score.  
* **Explainable AI‑lag** – vedlæg et “hvorfor dette svar” afsnit, der citerer præcise politik‑sætningsnumre, så audit‑spor er fuldt traceable.  

Disse fremskridt vil flytte automatiseringen fra *“hurtigt udkast”* til *“audit‑klar uden menneskelig indgriben.”*

---

## Konklusion  

Prompt engineering er ikke et enkelt trick; det er en systematisk disciplin, der transformerer kraftfulde LLM’er til pålidelige compliance‑assistenter. Ved:

1. Præcis hentning af politik‑fragmenter,  
2. Konstruktion af fler‑delte prompts, der kombinerer kontekst, instruktion, begrænsninger og verifikation,  
3. Automatisering af et feedback‑loop, der tvinger modellen til selv‑korrektion, og  
4. Sømløs integration af hele pipeline’en i en platform som Procurize,  

kan organisationer skære svartiden på spørgeskemaer drastisk ned, minimere manuelle fejl, og samtidig opretholde de strengeste audit‑spor, som regulatorer og kunder kræver.  

Start med at pilotere rammeværket på et lav‑risiko spørgeskema, indsamle KPI‑forbedringer, og iterer prompt‑skabelonerne. I løbet af få uger vil du opleve den samme nøjagtighed, som en senior compliance‑ingeniør leverer – kun med en brøkdel af indsatsen.

---  

## Se også  

- Prompt Engineering best practices for LLM’er  
- Retrieval‑Augmented Generation: design patterns and pitfalls  
- Compliance automation trends and forecasts for 2025  
- Procurize API overview and integration guide