
# AI‑drevet Intent‑baseret Routing‑motor til Realtids‑Samarbejde om Leverandørspørgeskemaer

Leverandør‑sikkerhedsspørgeskemaer er blevet en flaskehals for hurtigt voksende SaaS‑virksomheder. Hver ny kunde‑anmodning udløser en kæde af manuelle overleveringer: en sikkerhedsanalytiker henter den seneste politik, en juridisk reviewer validerer formuleringen, en produkt‑ingeniør præciserer den tekniske implementering, og det endelige svar samles i en PDF. Denne fragmenterede arbejdsproces fører til **lange svartider, inkonsistente svar og audit‑risiko**.

Hvad hvis platformen selv kunne forstå *hvorfor* et spørgsmål stilles, *hvem* der er bedst egnet til at besvare det, og *hvornår* et svar er nødvendigt, og derefter automatisk dirigere anmodningen til den rette person – *i realtid*? Mød **AI‑drevet Intent‑baseret Routing‑motor (IBRE)**, en kernekomponent i Procurize AI‑platformen, der kombinerer **knowledge‑graph‑semantik**, **retrieval‑augmented generation (RAG)** og **kontinuerlig feedback** for at orkestrere samarbejdet om spørgeskema‑svar på maskinens hastighed.

> **Vigtige pointer**
> - Intent‑detektion omsætter rå spørgeskema‑tekst til strukturerede forretnings‑intents.  
> - Et dynamisk knowledge‑graph forbinder intents med ejere, evidens‑artefakter og politik‑versioner.  
> - Realtids‑routing udnytter LLM‑drevet tillids‑scoring og belastnings‑balancering.  
> - Kontinuerlige lærings‑loops forfiner intents og routing‑politikker ud fra post‑submission audits.

---

## 1. Fra Tekst til Intent – Det Semantiske Parsingslag

Det første skridt i IBRE er at konvertere et frit formuleret spørgsmål (fx *“Do you encrypt data at rest?”*) til en **kanonisk intent**, som systemet kan handle på. Dette gøres med en to‑trins pipeline:

1. **LLM‑baseret Entity Extraction** – En letvægts‑LLM (fx Llama‑3‑8B) udtrækker nøgle‑enheder: *encryption*, *data at rest*, *scope*, *compliance framework*.  
2. **Intent Classification** – De udtrukne enheder fodrer en fin‑tuned klassifikator (BERT‑baseret), der kortlægger dem til en taksonomi af **~250 intents** (fx `EncryptDataAtRest`, `MultiFactorAuth`, `IncidentResponsePlan`).

Det resulterende intent‑objekt indeholder:
- `intent_id`  
- `confidence_score`  
- `linked_policy_refs` (**[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, **[ISO 27001](https://www.iso.org/standard/27001)**, interne politik‑ID’er)  
- `required_evidence_types` (konfigurationsfil, audit‑log, tredjeparts‑attestation)

**Hvorfor intent betyder noget:**  
Intents fungerer som en *stabil kontrakt* mellem spørgeskemaindholdet og den efterfølgende arbejdsproces. Selv hvis formuleringen ændres (“Is your data encrypted while stored?” vs. “Do you use encryption for data at rest?”) genkendes den samme intent, hvilket sikrer ensartet routing.

---

## 2. Knowledge Graph som den Kontekstuelle Rygrad

En **property‑graph database** (Neo4j eller Amazon Neptune) gemmer relationerne mellem:

- **Intents** ↔ **Ejere** (sikkerheds‑ingeniører, juridisk rådgiver, produkt‑ledere)  
- **Intents** ↔ **Evidens‑Artefakter** (politik‑dokumenter, konfigurations‑snapshots)  
- **Intents** ↔ **Regulatoriske Rammer** (**SOC 2**, **ISO 27001**, **[GDPR](https://gdpr.eu/)**)  
- **Ejere** ↔ **Arbejdsmængde & Tilgængelighed** (nuværende opgavekø, tidszone)

Hver nodes etiket er en streng omsluttet af dobbelte anførselstegn, så den overholder Mermaid‑syntaks til senere visualiseringer.

```mermaid
graph LR
    "Intent: EncryptDataAtRest" -->|"owned by"| "Owner: Security Engineer"
    "Intent: EncryptDataAtRest" -->|"requires"| "Evidence: Encryption Policy"
    "Intent: EncryptDataAtRest" -->|"complies with"| "Regulation: ISO 27001"
    "Owner: Security Engineer" -->|"available"| "Status: Online"
    "Owner: Security Engineer" -->|"workload"| "Tasks: 3"
```

Grafen er **dynamisk** – hver gang et nyt spørgeskema uploades, matches intent‑noden enten til en eksisterende node eller oprettes på stedet. Ejer‑kanter genberegnes med en **bipartit matching‑algoritme**, der balancerer ekspertise, nuværende belastning og **[SLA](https://www.ibm.com/think/topics/service-level-agreement)**‑deadlines.

---

## 3. Realtids‑Routing‑mekanik

Når et spørgeskema‑element ankommer:

1. **Intent‑detektion** leverer en intent med en tillids‑score.  
2. **Graf‑opslag** henter alle kandidatomarnere og tilknyttet evidens.  
3. **Scoring‑motor** evaluerer:  
   - **Ekspertise‑fit** (`expertise_score`) – baseret på historisk svarkvalitet.  
   - **Tilgængelighed** (`availability_score`) – real‑time status fra Slack/Teams‑presence‑API’er.  
   - **SLA‑haster** (`urgency_score`) – udledt fra spørgeskema‑deadline.  
4. **Sammensat routing‑score** = vægtet sum (konfigurerbar via policy‑as‑code).

Ejeren med den højeste samlede score modtager en **auto‑genereret opgave** i Procurize, forudfyldt med:  
- Det oprindelige spørgsmål,  
- Den detekterede intent,  
- Links til den mest relevante evidens,  
- Foreslåede svar‑snippets fra RAG.

Hvis tillids‑scoren falder under en tærskel (fx 0,65), dirigeres opgaven til en **human‑in‑the‑loop‑review‑queue**, hvor en compliance‑leder validerer intent’en, før den tildeles.

### Eksempel på Routing‑beslutning

| Ejer | Ekspertise (0‑1) | Tilgængelighed (0‑1) | Haster (0‑1) | Sammensat |
|------|------------------|----------------------|--------------|-----------|
| Alice (Sec Eng) | 0.92 | 0.78 | 0.85 | **0.85** |
| Bob (Legal) | 0.68 | 0.95 | 0.85 | 0.79 |
| Carol (Prod) | 0.55 | 0.88 | 0.85 | 0.73 |

Alice modtager opgaven med det samme, og systemet logger routing‑beslutningen for audit‑sporbarhed.

---

## 4. Kontinuerlige Læringssløjfer

IBRE forbliver ikke statisk. Efter et spørgeskema er afsluttet, indtager platformen **post‑submission feedback**:

- **Answer Accuracy Review** – Auditors scorer relevansen af svaret.  
- **Evidence Gap Detection** – Hvis den refererede evidens er forældet, flagges politik‑noden.  
- **Owner Performance Metrics** – Success‑rate, gennemsnitlig svartid og gen‑tildelings‑frekvens.

Disse signaler føres tilbage i to lærings‑pipelines:

1. **Intent‑forfinelse** – Mis‑klassifikationer udløser semi‑supervised retræning af intent‑klassifikatoren.  
2. **Routing‑policy‑optimering** – Reinforcement Learning (RL) opdaterer vægtninger for ekspertise, tilgængelighed og hastende for at maksimere SLA‑overholdelse og svarkvalitet.

Resultatet er en **selv‑optimerende motor**, der bliver bedre for hvert spørgeskema‑cirkul.

---

## 5. Integrationslandskab

IBRE er designet som en **mikro‑service**, der kan kobles på eksisterende værktøjer:

| Integration | Formål | Eksempel |
|-------------|--------|----------|
| Slack / Microsoft Teams | Realtids‑notifikationer & opgaveaccept | `/procure assign @alice` |
| Jira / Asana | Oprettelse af tickets for kompleks evidens‑indsamling | Auto‑opret en *Evidence Collection* ticket |
| Document Management (SharePoint, Confluence) | Hent opdaterede politik‑artefakter | Pull seneste krypterings‑politik version |
| CI/CD Pipelines (GitHub Actions) | Udløs compliance‑tjek på nye releases | Kør en policy‑as‑code test efter hver build |

Al kommunikation foregår over **mutual TLS** og **OAuth 2.0**, så følsomme spørgeskema‑data aldrig forlader den sikre perimeter.

---

## 6. Auditerbar Sporingssti & Overholdelsesfordele

Hver routing‑beslutning genererer en uforanderlig log‑post:

```json
{
  "question_id": "Q-2025-437",
  "intent_id": "EncryptDataAtRest",
  "assigned_owner": "alice@example.com",
  "routing_score": 0.85,
  "timestamp": "2025-12-11T14:23:07Z",
  "evidence_links": [
    "policy://encryption/2025-09",
    "artifact://config/production/db"
  ],
  "confidence": 0.93
}
```

Dette JSON gemmes i et **append‑only ledger** (fx Amazon QLDB eller en blockchain‑baseret ledger), hvilket opfylder **SOX**‑ og **GDPR**‑krav til sporbarhed. Auditors kan rekonstruere den præcise begrundelse bag hvert svar, hvilket dramatisk reducerer *evidence‑request*‑cyklussen under **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** audits.

---

## 7. Virkelige Resultater – Et Kort Casestudie

**Virksomhed:** FinTech SaaS “SecurePay” (Series C, 200 ansatte)  
**Problem:** Gennemsnitlig spørgeskema‑svartid – 14 dage, 30 % missed SLA.  
**Implementering:** Deploy IBRE med en 200‑node knowledge graph, integreret med Slack og Jira.  
**Resultater (90‑dages pilot):**

| Måling | Før | Efter |
|--------|-----|-------|
| Gns. svartid | 14 dage | 2,3 dage |
| SLA‑overholdelse | 68 % | 97 % |
| Manuel routing‑indsats (timer/uge) | 12 t | 1,5 t |
| Audit‑fund på evidens‑huller | 5 pr. audit | 0,8 pr. audit |

ROI blev beregnet til **6,2×** i de første seks måneder, primært fra reduceret tab af forretning og lavere audit‑omkostninger.

---

## 8. Fremtidige Retninger

1. **Cross‑Tenant Intent Federation** – Tillad flere kunder at dele intent‑definitioner mens dataisolation bevares, ved hjælp af federeret læring.  
2. **Zero‑Trust Verification** – Kombinér homomorfisk kryptering med intent‑routing, så selv routing‑motoren ikke kan se det følsomme spørgsmålindhold.  
3. **Predictive SLA Modeling** – Anvend tidsserie‑prognoser til at forudsige spidsbelastninger (fx efter produkt‑lancering) og for‑skalere routing‑kapacitet proaktivt.

---

## 9. Sådan Kommer Du i Gang med IBRE

1. **Aktivér Intent‑motoren** i Procurize → Settings → AI Modules.  
2. **Definér din intent‑taksonomi** (eller importér standard‑taksonomien).  
3. **Kortlæg ejere** ved at linke bruger‑konti til intent‑tags.  
4. **Forbind evidens‑kilder** (dokument‑lager, CI/CD‑artefakter).  
5. **Kør et pilot‑spørgeskema** og observer routing‑dashboardet.

En trin‑for‑trin‑vejledning findes i **Procurize Help Center** under *AI‑Driven Routing*.

---

## <span class='highlight-content'>Se</span> Også
- [Zero‑Trust Architecture for AI‑Driven Automation – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)