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, ISO 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)
• 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.

  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‑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

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:

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:

{
  "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 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):

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.

Se Også

• Zero‑Trust Architecture for AI‑Driven Automation – NIST SP 800‑207