Sammensætbar AI Mikro‑service Arkitektur for Skalerbar Automatisering af Sikkerhedsspørgeskemaer

Virksomheder drukner i en stadigt voksende strøm af sikkerhedsspørgeskemaer, leverandørvurderinger og compliance‑audits. Traditionelle monolitiske værktøjer har svært ved at holde trit, især når de skal integreres med forskellige produktøkosystemer, understøtte flersprogede anmodninger og levere real‑time revisionsspor.

En sammensætbar mikro‑service arkitektur, bygget omkring store sprogmodeller (LLM’er) og retrieval‑augmented generation (RAG), giver en måde at skalere automatiseringen på, mens fleksibilitet og styring—som regulerede industrier kræver—bevares. I denne guide vil vi:

• Skitsere de centrale designprincipper, der holder systemet sikkert, auditabelt og udvidbart.
• Gå igennem en referenceimplementation illustreret med Mermaid.
• Vise, hvordan hver tjeneste kan udgives uafhængigt på Kubernetes, serverless FaaS eller edge‑runtime.
• Give konkrete anbefalinger til data‑styring, observabilitet og løbende forbedring.

TL;DR: Del automatiseringsplatformen for spørgeskemaer op i små, veldefinerede tjenester, lad LLM’er ligge bag et statsløst inferenslag, og brug begivenhedsdrevne pipelines til at opretholde en enkelt kilde til sandhed for beviser og versionskontrol.

1. Hvorfor sammensætte i stedet for at bygge en kæmpemonolit?

Den sammensættelige model omfavner filosofien “du bygger kun, hvad du har brug for, og udskifter kun, hvad du ikke har brug for”. Den matcher den dynamiske karakter af sikkerhedsspørgeskemaer, hvor nye kontrolrammer (fx ISO 27001 Rev 2) dukker op regelmæssigt, og teams skal kunne tilpasse sig hurtigt.

2. Kernearchitektoniske Søjler

1. Stateless API‑gateway – indgangspunkt for UI, SaaS‑connectors og eksterne værktøjer. Håndterer godkendelse, anmodningsvalidering og throttling.
2. Domænespecifikke Mikro‑services – hver indkapsler en afgrænset kontekst:
   • Spørgeskema‑service – gemmer spørgeskema‑metadata, versionering og opgavefordeling.
   • Bevis‑service – administrerer artefakter (politikker, skærmbilleder, revisionslogge) i et uforanderligt objektlager.
   • AI‑orchestreringstjeneste – sammensætter prompts, kører RAG‑pipelines og returnerer svar‑udkast.
   • Ændrings‑detekteringstjeneste – overvåger bevis‑opdateringer, udløser gen‑evaluering af berørte svar.
   • Notifikationstjeneste – skubber Slack, Teams eller e‑mail‑begivenheder til interessenter.
3. Begivenheds‑bus (Kafka / Pulsar) – garanterer mindst‑en‑gang‑levering af domænebegivenheder (fx EvidenceUploaded, AnswerDrafted).
4. Observabilitets‑stack – OpenTelemetry‑spor på tværs af tjenester, Prometheus‑metrics og Loki‑logge.
5. Policy‑as‑Code Motor – evaluerer compliance‑regler (skrevet i Rego eller OPA) før et svar marker­es “endeligt”.

Alle tjenester kommunikerer via gRPC (for lav latency) eller REST (for eksterne integrationer). Designet opfordrer til dumme rør, smarte endepunkter—forretningslogikken bor, hvor den hører hjemme, mens bussen kun transporterer beskeder.

3. Dataflow – Fra Spørgsmål til Auditabelt Svar

  flowchart TD
    subgraph UI["Brugergrænseflade"]
        UI1["\"Web‑UI\""] -->|Indsend spørgeskema| AG["\"API‑gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Spørgeskema‑service\""]
    QMS -->|Hent skabelon| AIOS["\"AI‑orchestreringstjeneste\""]
    AIOS -->|Hent relevant bevis| ES["\"Bevis‑service\""]
    ES -->|Bevis‑objekter| AIOS
    AIOS -->|Generer udkast svar| RAG["\"RAG‑pipeline\""]
    RAG -->|LLM‑output| AIOS
    AIOS -->|Gem udkast| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Begivenheds‑bus\""]
    EB -->|Trigger| CDS["\"Ændrings‑detekteringstjeneste\""]
    CDS -->|Gen‑kør hvis bevis ændret| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notifikationstjeneste\""]
    NS -->|Push til Slack/E‑mail| 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

Vigtige øjeblikke i flowet:

1. Bruger indsender et nyt spørgeskema eller vælger et eksisterende.
2. API‑gateway validerer JWT, tjekker rate‑limits og sender videre til Spørgeskema‑service.
3. Spørgeskema‑service henter spørgeskema‑skabelonen og sender en begivenhed til AI‑orchestreringstjenesten.
4. AI‑orchestreringstjenesten udfører et retrieval‑step—den forespørger Bevis‑service på alle artefakter, der er relevante for den aktuelle kontrol (ved hjælp af vektor‑similaritet eller nøgleords‑match).
5. De hentede kontekster, sammen med prompt‑skabelonen, sendes gennem en RAG‑pipeline (fx openAI/gpt‑4o‑preview).
6. Udkastet gemmes tilbage i Spørgeskema‑service, markeret “venter på godkendelse.”
7. Ændrings‑detekteringstjenesten overvåger nye bevis‑uploads. Hvis en politik opdateres, udløser den RAG‑pipeline for berørte svar igen.
8. Endelige anmeldere accepterer eller redigerer udkastet; ved accept validerer Policy‑as‑Code Motoren, at svaret opfylder alle regel‑konfigurationer, før det bliver forankret i et uforanderligt revisionslog.

4. Implementeringsdetaljer

4.1. API‑gateway (Envoy + OIDC)

• Routing – POST /questionnaires/:id/answers → spørgeskema‑service.
• Sikkerhed – Gennemtving scopes (questionnaire:write).
• Rate limiting – 100 anmodninger/min per tenant for at beskytte nedstrøms LLM‑omkostninger.

4.2. Spørgeskema‑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
}

• Bruger PostgreSQL til relationsdata, EventStoreDB til domænebegivenheder.
• Eksponerer gRPC‑metoder GetTemplate, SaveDraft, FinalizeAnswer.

4.3. Bevis‑service (Python + FastAPI)

• Gemmer filer i MinIO eller AWS S3 med bucket‑niveau kryptering.
• Indexerer indhold i Qdrant (vektor‑DB) for lignende‑søgning.
• Tilbyder endpoint POST /search som accepterer en forespørgsel og returnerer top‑k artefakt‑ID’er.

4.4. AI‑orchestreringstjeneste (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 – Kombiner vektor‑søgning med et system‑prompt, der instruerer modellen i at citere bevis‑ID’er.
• Caching – Gemmer genererede svar i 24 t for at undgå dubletter af LLM‑kald.

4.5. Ændrings‑detekteringstjeneste (Rust)

• Abonnerer på EvidenceUploaded‑begivenheder.
• Beregner en hash af det nye artefakt og kører en diff mod eksisterende bevis knyttet til hver kontrol.
• Hvis diff‑en overstiger en konfigurerbar tærskel, udgiver den AnswerRequiresRegen.

4.6. Notifikationstjeneste (Node.js)

• Lytter på AnswerDrafted, AnswerFinalized, AnswerRequiresRegen.
• Formaterer Slack‑blocks, Teams Adaptive Cards eller e‑mail‑templates.
• Støtter deduplikation – notificerer kun én gang pr. ændring pr. spørgeskema.

5. Sikkerhed & Styring

6. Skaleringstrategier

1. Horizontal Pod Autoscaling (HPA) – Skaler AI‑orchestrering‑pods baseret på GPU‑udnyttelse (nvidia.com/gpu).
2. Burst‑able Queues – Brug Kafka‑partitionering til at isolere høj‑trafik‑tenants.
3. Cold‑Start Reducering – Hold en varm pulje af containere til LLM‑inferens‑serveren (fx med KEDA og en custom scaler).
4. Omkostningsstyring – Anvend token‑baseret budgettering pr. tenant; throttle eller fakturér over‑forbrug automatisk.

7. Observabilitet & Kontinuerlig Forbedring

• Distribueret Sporing – OpenTelemetry‑spænd fra UI‑request → API‑gateway → AI‑orchestrering → RAG → Bevis‑service.
• Metrics – answer_draft_latency_seconds, evidence_upload_bytes, llm_token_usage.
• Log‑aggregering – Strukturere JSON‑logge med request_id propagere på tværs af tjenester.
• Feedback‑Loop – Efter endelig godkendelse, indfang reviewer‑kommentarer (review_score). Brug disse i en reinforcement learning‑model, der justerer prompt‑temperatur eller vælger alternative bevis‑kilder.

8. Trin‑for‑Trin Migrationsvej for Eksisterende Teams

Ved gradvis at adoptere den sammensætbare arkitektur undgår teams “big‑bang”‑risikoen og kan demonstrere tidlig ROI (ofte en 30‑50 % reduktion i håndterings‑tid).

9. Fremtidssikring af Stakken

• Federated Learning – Træn letvægts‑adapters på hver tenants data uden at flytte rå‑beviser udenfor, hvilket forbedrer svar‑relevans og respekterer data‑suverænitet.
• Zero‑Trust Service Mesh – Brug Istio eller Linkerd med mutual TLS til at sikre intern trafik.
• Semantisk Governance – Udvid Policy‑as‑Code‑motoren til også at validere den semantiske lighed mellem bevis og kontroltekst.
• Generativ Sporbarhed – Gem den præcise LLM‑temperature, top‑p og system‑prompt ved siden af hvert svar for revisor‑inspektion.

10. Konklusion

En sammensætbar mikro‑service arkitektur forvandler automatisering af sikkerhedsspørgeskemaer fra et besværligt manuelt arbejde til en skalerbar, auditabel og løbende forbedrende motor. Ved at adskille ansvarsområder, udnytte LLM’er via et statsløst RAG‑lag og sammenkoble alt med et begivenhedsdrevet backbone, kan organisationer:

• Besvare leverandør‑vurderinger på minutter i stedet for dage.
• Holde compliance‑beviser altid opdateret med automatisk ændrings‑detektion.
• Give regulatorer et klart, uforanderligt revisionsspor.

Start i det små, iterer hurtigt, og lad mikro‑service‑filosofien guide dig mod en fremtid, hvor compliance er en funktion, ikke en flaskehals.

Se Også

• OPA Policy-as‑Code for Micro‑services