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?

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) 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.

  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)

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)

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

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

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