
# Ontologibaserad Promptmotor för Harmonisering av Säkerhetsfrågeformulär

> **TL;DR** – En ontologicentrerad promptmotor skapar en semantisk brygga mellan motstridande efterlevnadsramverk, vilket gör att generativ AI kan producera enhetliga, auditabla svar på alla säkerhetsfrågeformulär samtidigt som den bevarar kontextuell relevans och regulatorisk korrekthet.

---

## 1. Varför ett Nytt Tillvägagångssätt Behövs

Säkerhetsfrågeformulär är fortfarande en stor flaskhals för SaaS‑leverantörer. Även med verktyg som Procurize som centraliserar dokument och automatiserar arbetsflöden, tvingar **det semantiska gapet** mellan olika standarder säkerhets-, juridik‑ och ingenjörsteam att skriva om samma bevis flera gånger:

| Ramverk | Typisk Fråga | Exempelsvar |
|---------|--------------|-------------|
| **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** | *Beskriv er datakryptering i vila.* | “All kunddata är krypterad med AES‑256…” |
| **[ISO 27001](https://www.iso.org/standard/27001)** | *Hur skyddar ni lagrad information?* | “Vi implementerar AES‑256‑kryptering…” |
| **[GDPR](https://gdpr.eu/)** | *Förklara tekniska skyddsåtgärder för personuppgifter.* | “Data krypteras med AES‑256 och roteras kvartalsvis.” |

Även om den underliggande kontrollen är identisk skiljer sig formulering, omfattning och evidensförväntningar. Existerande AI‑pipelines hanterar detta genom **prompt‑tuning per ramverk**, vilket snabbt blir ohållbart när antalet standarder växer.

En **ontologibaserad promptmotor** löser problemet i dess kärna: den bygger en **enda, formell representation** av efterlevnadskoncept, och **mappar** sedan varje frågeformulärs språk till den delade modellen. AI:n behöver bara förstå en “kanonisk” prompt, medan ontologin sköter tunga lyften med översättning, versionering och motivering.

---

## 2. Huvudkomponenter i Arkitekturen

```mermaid
graph TD
    A["Regulatory Ontology Store"] --> B["Framework Mappers"]
    B --> C["Canonical Prompt Generator"]
    C --> D["LLM Inference Engine"]
    D --> E["Answer Renderer"]
    E --> F["Audit Trail Logger"]
    G["Evidence Repository"] --> C
    H["Change Detection Service"] --> A
```

1. **Regulatorisk Ontologilager** – Ett kunskapsgraf som fångar begrepp (t.ex. *kryptering*, *åtkomstkontroll*), relationer (*kräver*, *ärver*) och juridiska attribut.  
2. **Ramverksmappare** – Lätta adaptrar som parsar inkommande frågeformulär, identifierar motsvarande ontologinoder och tilldelar konfidenspoäng.  
3. **Kanonisk Promptgenerator** – Bygger en enda kontext‑rik prompt för LLM med ontologins normaliserade definitioner och länkad evidens.  
4. **LLM‑inferensmotor** – Vilken som helst generativ modell (GPT‑4o, Claude 3, etc.) som producerar ett naturligt språk‑svar.  
5. **Svarsgenerator** – Formaterar LLM:s råoutput till det kravställda frågeformulärsformatet (PDF, markdown, JSON).  
6. **Auditlogg‑spårare** – Sparar mappningsbeslut, prompt‑version och LLM‑svar för efterlevnadsgranskning och framtida träning.  
7. **Evidensarkiv** – Lagrar policy‑dokument, audit‑rapporter och artefaktslänkar som refereras i svar.  
8. **Ändringsdetekteringstjänst** – Övervakar uppdateringar av standarder eller interna policyer och propagerar automatiskt förändringar genom ontologin.

---

## 3. Bygga Ontologin

### 3.1 Datakällor

| Källa | Exempelentiteter | Extraktionsmetod |
|-------|-------------------|------------------|
| **ISO 27001 Annex A** | “Kryptografiska kontroller”, “Fysisk säkerhet” | Regelbaserad parsning av ISO‑paragrafer |
| **SOC 2 Trust Services Criteria** | “Tillgänglighet”, “Konfidentialitet” | NLP‑klassificering av SOC‑dokumentation |
| **GDPR Recitals & Articles** | “Dataminimering”, “Rätt till radering” | Entitets‑relationsutdrag via spaCy + anpassade mönster |
| **Interna policyskåp** | “Företagets krypteringspolicy” | Direkt import från YAML/Markdown‑policyfiler |

Varje källa bidrar med **konceptnoder** (`C`) och **relationskanter** (`R`). Till exempel är **“AES‑256”** en *teknik* (`C`) som *implementerar* kontrollen “Data at Rest Encryption” (`C`). Länkarna märks med proveniens (källa, version) och konfidens.

### 3.2 Normaliseringsregler

För att undvika dubbletter **normaliseras** begrepp:

| Råterm | Normaliserad form |
|--------|-------------------|
| “Kryptering i vila” | `encryption_at_rest` |
| “Datakryptering” | `encryption_at_rest` |
| “AES‑256‑kryptering” | `aes_256` (sub‑type of `encryption_algorithm`) |

Normaliseringen sker via en **ordboks‑driven fuzzy‑matcher** som lär sig av mänskligt godkända mappningar.

### 3.3 Versionsstrategi

Ontologin använder ett **semantiskt versionsschema** (`MAJOR.MINOR.PATCH`). När en ny klausul tillkommer sker en **minor**‑ökning, vilket triggar omvärdering av påverkade prompts. Audit‑loggaren fångar den exakta ontologiversionen för varje svar, vilket möjliggör spårbarhet.

---

## 4. Promptgenerering i Praktiken

### 4.1 Från frågeformulär till ontologinode

När en leverantör får en fråga som:

> *“Krypterar ni säkerhetskopior lagrade off‑site?”*

Kör **Ramverksmapparen** en likhetsökning mot ontologin och returnerar noden `encryption_at_rest` med en konfidens på 0,96. Den extraherar även eventuella kvalifikatorer (“säkerhetskopior”, “off‑site”) som *attribut*.

### 4.2 Kanonisk Promptmall

En återanvändbar, enda promptmall ser ut så här (pseudo‑kod):

```
You are an expert compliance officer. Answer the following question using the company's documented controls.

Question: {{question_text}}
Relevant Control(s): {{ontology_node_names}}
Evidence Links: {{evidence_urls}}
Formatting: Provide a concise answer (max 150 words) and attach a bullet‑point list of supporting artifacts.
```

Motorn ersätter de mappade ontologinoderna och hämtar de senaste evidens‑URL:erna från **Evidensarkivet**. Eftersom den underliggande kontrollen är densamma för alla ramverk får LLM‑n ett **konsekvent sammanhang**, vilket eliminerar variationer som orsakas av skillnader i formulering.

### 4.3 LLM‑utdataexempel

> **Svar:** Ja, alla off‑site‑säkerhetskopior är krypterade med AES‑256 med en unik nyckel per backup‑set. Krypteringsnycklar hanteras i vårt HSM‑skyddade valv och roteras kvartalsvis.  
> **Stödjande artefakter:**  
> - *Backup‑krypteringspolicy* – `https://repo.company.com/policies/backup-encryption.pdf`  
> - *HSM‑nyckelrotationslogg* – `https://repo.company.com/audit/hsm-rotation.json`

**Svarsgeneratorn** formaterar sedan detta till det specifika frågeformulärets layout (t.ex. en tabellcell för ISO, ett fält för SOC 2).

---

## 5. Fördelar jämfört med Traditionell Prompt‑Tuning

| Mått | Traditionell Prompt‑Tuning | Ontologibaserad Motor |
|------|----------------------------|------------------------|
| **Skalbarhet** | En prompt per ramverk → linjär tillväxt | En kanonisk prompt → konstant |
| **Konsistens** | Divergerande formuleringar mellan ramverk | Uniformt svar genererat från en enda källa |
| **Auditabilitet** | Manuell spårning av prompt‑versioner | Automatisk ontologi‑version + audit‑logg |
| **Anpassningsförmåga** | Omskolning krävs för varje standarduppdatering | Ändringsdetektering propagerar automatiskt via ontologi |
| **Underhållskostnad** | Hög – dussintals prompt‑filer | Låg – enbart ett mappningslager & kunskapsgraf |

I praktiska tester hos Procurize minskade **genomsnittlig svarsgenereringstid** från 7 sekunder (prompt‑tuned) till 2 sekunder, samtidigt som **kors‑ramverk‑likhet** ökade (BLEU‑score‑ökning på 18 %).

---

## 6. Implementeringstips

1. **Börja Små** – Fyll först ontologin med de vanligaste kontrollerna (kryptering, åtkomstkontroll, loggning) innan du expanderar.  
2. **Utnyttja Existerande Grafer** – Projekt som **Schema.org**, **OpenControl** och **CAPEC** erbjuder färdiga vokabulärer som kan utökas.  
3. **Använd en Grafdatabas** – Neo4j eller Amazon Neptune hanterar komplexa traversaler och versionering effektivt.  
4. **Integrera CI/CD** – Behandla ontologiförändringar som kod; kör automatiserade tester som verifierar mappningsnoggrannhet mot ett provuppsättning frågeformulär.  
5. **Människa‑i‑Loop** – Tillhandahåll ett UI där säkerhetsspecialister kan godkänna eller korrigera mappningar, vilket återförslår till fuzzy‑matchern.

---

## 7. Framtida Utökningar

- **Federerad Ontologisynk** – Företag kan dela anonymiserade delar av sina ontologier och skapa en gemensam kunskapsbas för efterlevnad.  
- **Explainable AI‑lager** – Koppla motivationsgrafer till varje svar, så att man kan visualisera hur specifika ontologinoder bidrog till den slutliga texten.  
- **Zero‑Knowledge Proof‑integration** – För starkt reglerade industrier, integrera zk‑SNARK‑bevis som intygar korrektheten i mappningen utan att avslöja känslig policy‑text.

---

## 8. Slutsats

En ontologibaserad promptmotor representerar ett paradigm‑skifte i automatisering av säkerhetsfrågeformulär. Genom att förena disparata efterlevnadsstandarder under ett enda, versionerat kunskapsgraf kan organisationer:

- **Eliminera dubbelarbete** över olika ramverk.  
- **Säkerställa svarskonsistens** och auditabilitet.  
- **Snabbt anpassa** sig till regulatoriska förändringar med minimal ingenjörsinsats.  

När den kombineras med Procurize s samarbetsplattform gör detta tillvägagångssätt att säkerhets-, juridik‑ och produktteam kan svara på leverantörsbedömningar på minuter snarare än dagar, och förvandlar efterlevnad från en kostnadsdrivare till en konkurrensfördel.

## <span class='highlight-content'>Se</span> även

- [OpenControl Github‑arkiv](https://github.com/opencontrol) – Öppen källkod för policy‑as‑code och efterlevnadskontroller.  
- [MITRE ATT&CK® kunskapsbas](https://attack.mitre.org) – Strukturerad attacker‑teknikstaxonomi som är användbar vid byggande av säkerhetsontologier.  
- [ISO/IEC 27001:2025 standardöversikt](https://www.iso.org/standard/82875.html) – Den senaste versionen av standarden för informationssäkerhetshantering.