
# Komponerbar AI‑mikrotjänstarkitektur för skalbar automatisering av säkerhetsfrågeformulär

Företag drunknar i en ständigt växande mängd säkerhetsfrågeformulär, leverantörsbedömningar och efterlevnadsgranskningar. Traditionella monolitiska verktyg hinner inte med, särskilt när de måste integreras med olika produkt‑ekosystem, stödja flerspråkiga förfrågningar och tillhandahålla realtids‑audit‑spår.  

En **komponerbar mikrotjänstarkitektur**, byggd kring stora språkmodeller (LLM) och retrieval‑augmented generation (RAG), erbjuder ett sätt att skala automatiseringen samtidigt som den flexibilitet och styrning som reglerade branscher kräver bevaras. I den här guiden kommer vi att:

* Redogöra för de viktigaste designprinciperna som håller systemet **säkert, granskningsbart och utbyggbart**.  
* Gå igenom en referensimplementation diagrammerad med Mermaid.  
* Visa hur varje tjänst kan distribueras oberoende på Kubernetes, server‑lös FaaS eller edge‑miljöer.  
* Ge konkreta rekommendationer för bästa praxis kring datastyrning, observabilitet och kontinuerlig förbättring.

> **TL;DR:** Dela upp plattformen för automatisering av frågeformulär i små, väl definierade tjänster, låt LLM‑erna ligga bakom ett tillståndslöst inferens‑lager och använd händelsedrivna pipelines för att hålla en enda sanningskälla för bevis och versionskontroll.

---

## 1. Varför komponera i stället för att bygga en gigantisk monolit?

| Monolitisk strategi | Komponerbar mikrotjänst |
|---------------------|---------------------------|
| En enda kodbas, svårt att skala specifika arbetsbelastningar (t.ex. LLM‑inferens). | Oberoende skalning – AI‑inferens kan köras på GPU‑noder, medan lagring förblir på kostnadseffektiva objektlagringar. |
| Tät koppling gör uppdateringar riskfyllda; en bugg i UI:t kan fälla hela systemet. | Lös koppling via asynkrona händelser eller HTTP‑API:er isolerar fel. |
| Begränsad språkagnostisk integration – ofta låst till en stack. | Polyglot‑stöd – varje tjänst kan skrivas i det språk som passar bäst för uppgiften (Go för auth, Python för LLM‑orchestrering, Rust för hög‑genomströmning pipelines). |
| Granskning och efterlevnad blir en mardröm när loggar sammanflätas. | Centraliserad händelselagring + oföränderlig audit‑logg ger en klar, frågbar spårning för regulatorer. |

Den **komponerbara** modellen omfamnar filosofin *„du bygger vad du behöver, och du ersätter vad du inte gör“*. Den matchar den dynamiska naturen hos säkerhetsfrågeformulär, där nya kontrollramverk (t.ex. [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) dyker upp regelbundet och team måste kunna anpassa sig snabbt.

---

## 2. Kärnpelare i arkitekturen

1. **Stateless API‑gateway** – ingångspunkt för UI, SaaS‑kopplingar och externa verktyg. Hanterar autentisering, request‑validering och throttling.  
2. **Domänspecifika mikrotjänster** – var och en kapslar in ett avgränsat sammanhang:
   * **Questionnaire Service** – lagrar metadata för frågeformulär, versionshantering och uppgiftsfördelning.  
   * **Evidence Service** – hanterar artefakter (policyer, skärmdumpar, audit‑loggar) i en oföränderlig objektlagring.  
   * **AI Orchestration Service** – komponera prompts, kör RAG‑pipelines och returnerar svarsutkast.  
   * **Change‑Detection Service** – bevakar uppdateringar av bevis, triggar om‑utvärdering av påverkade svar.  
   * **Notification Service** – pushar Slack, Teams eller e‑post‑händelser till intressenter.  
3. **Event‑bus (Kafka / Pulsar)** – garanterar leverans “minst en gång” av domänhändelser (t.ex. `EvidenceUploaded`, `AnswerDrafted`).  
4. **Observability‑stack** – OpenTelemetry‑spårning över tjänster, Prometheus‑metrik, och Loki‑loggar.  
5. **Policy‑as‑Code‑motor** – utvärderar efterlevnadsregler (skrivna i Rego eller OPA) innan ett svar markeras som “slutgiltigt”.  

Alla tjänster kommunicerar via **gRPC** (för låg latens) eller **REST** (för externa integrationer). Designen uppmuntrar *dumma rör, smarta ändpunkter* – affärslogik lever där den hör hemma, medan busen bara transporterar meddelanden.

---

## 3. Dataflöde – Från fråga till granskningsbart svar

Nedan är ett Mermaid‑diagram som visualiserar en typisk förfrågnings‑livscykel.

```mermaid
flowchart TD
    subgraph UI["User Interface"]
        UI1["\"Web UI\""] -->|Submit questionnaire| AG["\"API Gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Questionnaire Service\""]
    QMS -->|Fetch template| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Retrieve relevant evidence| ES["\"Evidence Service\""]
    ES -->|Evidence objects| AIOS
    AIOS -->|Generate draft answer| RAG["\"RAG Pipeline\""]
    RAG -->|LLM output| AIOS
    AIOS -->|Store draft| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Change‑Detection Service\""]
    CDS -->|Re‑run if evidence changed| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notification Service\""]
    NS -->|Push to Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**Nyckelmoment i flödet**:

1. **Användaren skickar** in ett nytt frågeformulär eller väljer ett befintligt.  
2. **API‑gatewayen** validerar JWT, kontrollerar hastighetsgränser och vidarebefordrar till Questionnaire Service.  
3. **Questionnaire Service** hämtar mall för frågeformuläret och postar en händelse till AI Orchestration Service.  
4. **AI Orchestration** utför ett *retrieval‑steg* – den frågar Evidence Service efter alla artefakter som är relevanta för den aktuella kontrollen (med vektorsökning eller nyckelordsmatchning).  
5. De hämtade kontexterna tillsammans med prompt‑mallen matas in i en **RAG‑pipeline** (t.ex. `openAI/gpt‑4o‑preview`).  
6. Utkastet sparas tillbaka i Questionnaire Service, markerat *“pending review.”*  
7. **Change‑Detection Service** bevakar nya bevisuppladdningar. Om en policy uppdateras triggas RAG‑pipeline på berörda svar på nytt.  
8. Slutgiltiga granskare accepterar eller redigerar utkastet; vid acceptans validerar **Policy‑as‑Code‑motorn** att svaret uppfyller alla regelrestriktioner innan det skrivs till en oföränderlig audit‑logg.  

---

## 4. Implementationsdetaljer

### 4.1. API‑gateway (Envoy + OIDC)

* **Routing** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Säkerhet** – Tvinga scopes (`questionnaire:write`).  
* **Rate limiting** – 100 requests/min per tenant för att skydda nedströms LLM‑kostnader.

### 4.2. Questionnaire Service (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* Använder **PostgreSQL** för relationsdata, **EventStoreDB** för domänhändelser.  
* Exponerar gRPC‑metoder `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. Evidence Service (Python + FastAPI)

* Lagrar filer i **MinIO** eller **AWS S3** med bucket‑nivå kryptering.  
* Indexerar innehåll i **Qdrant** (vektordatabas) för likhetssökning.  
* Tillhandahåller endpoint `POST /search` som tar emot en query och returnerar top‑k artefakt‑ID:n.

### 4.4. AI Orchestration Service (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – Kombinerar vektorsökning med ett *system‑prompt* som instruerar modellen att citera bevis‑ID:n.  
* **Caching** – Sparar genererade svar i 24 h för att undvika dubbla LLM‑anrop.

### 4.5. Change‑Detection Service (Rust)

* Prenumererar på `EvidenceUploaded`‑händelser.  
* Beräknar en **hash** av den nya artefakten och kör en **diff** mot befintligt bevis kopplat till varje kontroll.  
* Om diffen överstiger en konfigurerbar tröskel publiceras `AnswerRequiresRegen`.

### 4.6. Notification Service (Node.js)

* Lyssnar på `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* Formaterar Slack‑blocks, Teams Adaptive Cards eller e‑post‑mallar.  
* Stöder **deduplikation** – notifierar bara en gång per förändring per frågeformulär.

---

## 5. Säkerhet & styrning

| Aspekt | Åtgärd |
|--------|--------|
| **Dataläckage** – LLM‑prompter kan innehålla känslig policy‑text. | Använd **on‑prem LLM‑inferens** (t.ex. Llama 3.2) bakom ett VPC. Maskera PII innan du skickar till externa API:er. |
| **Obehörig åtkomst till bevis** | Tvinga finmaskiga ACL:s med OPA‑policyer i Evidence Service. |
| **Modell‑drift** – svar försämras över tid. | Schemalägg **periodisk utvärdering** mot ett benchmark‑corpus och uppdatera prompt‑mallar. |
| **Spårbarhet** | Alla tillståndsändringar registreras i en oföränderlig händelselogg lagrad på **WORM S3**. |
| **GDPR/CCPA‑efterlevnad** | Implementera ett **right‑to‑be‑forgotten**‑flöde som rensar användarspecifikt bevis från vektordatabasen och objektlagring ([GDPR](https://gdpr.eu/)). |
| **ISO 27001‑efterlevnad** | Validera att bevis‑retention, kryptering och åtkomstkontroller överensstämmer med ISO 27001‑standarden. |
| **HIPAA / SOC 2** | För hälso‑ eller SaaS‑leverantörer, utöka OPA‑regler för att uppfylla de krävs skyddsåtgärderna. |

---

## 6. Skalningsstrategier

1. **Horizontal Pod Autoscaling (HPA)** – Skala AI Orchestration‑pods baserat på GPU‑användning (`nvidia.com/gpu`).  
2. **Burst‑able Queues** – Använd Kafka‑partitionering för att isolera hög‑trafik‑tenanter.  
3. **Cold‑Start‑reducering** – Håll en varm pool av containrar för LLM‑inferens‑servern (t.ex. via **KEDA** med en anpassad scaler).  
4. **Kostnadskontroller** – Tilldela **token‑baserade budgetar** per tenant; throttla eller fakturera över‑användning automatiskt.

---

## 7. Observabilitet & kontinuerlig förbättring

* **Distribuerad spårning** – OpenTelemetry‑spår från UI‑request → API‑gateway → AI‑orchestration → RAG → Evidence Service.  
* **Metriker** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Logg‑aggregering** – Strukturerade JSON‑loggar med `request_id` som propageras över tjänster.  
* **Feedback‑loop** – Efter att ett svar markerats som slutgiltigt, samla in granskningskommentarer (`review_score`). Använd dessa i en **reinforcement‑learning**‑modell som justerar prompt‑temperatur eller väljer alternativa beviskällor.

---

## 8. Steg‑för‑steg migreringsplan för befintliga team

| Fas | Mål | Aktiviteter |
|-----|-----|--------------|
| **0 – Upptäckt** | Kartlägga nuvarande arbetsflöde för frågeformulär. | Identifiera datakällor, definiera kontroll‑taxonomi. |
| **1 – Bygg grunder** | Distribuera API‑gateway, autentisering och bas‑tjänster. | Containerisera `questionnaire-service` och `evidence-service`. |
| **2 – Introducera AI** | Köra RAG på ett pilot‑frågeformulär. | Använd en sandbox‑LLM, verifiera manuellt utkast. |
| **3 – Händelsedriven automatisering** | Koppla in Change‑Detection‑pipeline. | Aktivera auto‑regen vid bevis‑uppdatering. |
| **4 – Styrning & hårdning** | Lägg till OPA‑policyer, oföränderlig audit‑logg. | Byt till produktions‑LLM (on‑prem). |
| **5 – Skala & optimera** | Autoskala GPU‑pods, införa kostnadskontroller. | Distribuera observability‑stack, sätta SLO:n. |

Genom att gradvis anta den komponerbara arkitekturen undviker teamen riskerna med en *big‑bang*‑lansering och kan visa tidig avkastning (ofta en **30‑50 %** minskning av svarstiden för frågeformulär).

---

## 9. Framtidssäkring av stacken

* **Federated Learning** – Träna lätta adaptrar på varje tenants data utan att flytta råa bevis, vilket förbättrar svarens relevans samtidigt som datasegrering respekteras.  
* **Zero‑Trust Service Mesh** – Använd **Istio** eller **Linkerd** med mutual TLS för att säkra intern trafik.  
* **Semantisk styrning** – Utöka Policy‑as‑Code‑motorn för att validera inte bara svarsinnehåll utan även den **semantiska likheten** mellan bevis och kontrollspråk.  
* **Generativ spårbarhet** – Spara exakt LLM‑temperatur, top‑p och system‑prompt tillsammans med varje svar för forensisk granskning.

---

## 10. Slutsats

En komponerbar mikrotjänstarkitektur omvandlar automatiseringen av säkerhetsfrågeformulär från en **smärtsam manuell börda** till en **skalbar, granskningsbar och ständigt förbättrande motor**. Genom att frikoppla ansvarsområden, utnyttja LLM‑er via ett stateless RAG‑lager och binda ihop allt med ett händelsedrivet ryggstöd, kan organisationer:

* Besvara leverantörsbedömningar på minuter istället för dagar.  
* Hålla efterlevnadsbevis alltid uppdaterade med automatiserad förändringsdetektering.  
* Ge regulatorer en tydlig, oföränderlig audit‑spårning.  

Börja i liten skala, iterera snabbt, och låt mikrotjänstfilosofin leda er mot en framtid där efterlevnad blir en **funktion**, inte ett flaskhals.

---

## Se även

- [OPA Policy‑as‑Code för mikrotjänster](https://www.openpolicyagent.org/docs/latest/policy-language/)