
# Componabele AI Micro‑services Architectuur voor Schaalbare Automatisering van Veiligheidsvragenlijsten

Bedrijven verdrinken in een steeds groter wordende golf van veiligheidsvragenlijsten, leveranciersbeoordelingen en compliance‑audits. Traditionele monolithische tools hebben moeite om bij te blijven, vooral wanneer ze moeten integreren met uiteenlopende product‑ecosystemen, meertalige verzoeken moeten ondersteunen en real‑time audit‑trails moeten leveren.  

Een **componabele micro‑services architectuur**, gebouwd rond grote taalmodellen (LLM's) en retrieval‑augmented generation (RAG), biedt een manier om automatisering op te schalen terwijl de flexibiliteit en governance behouden blijven die gereguleerde sectoren eisen. In deze gids laten we:

* De kern‑ontwerprincipes zien die het systeem **veilig, auditbaar en uitbreidbaar** houden.  
* Een referentie‑implementatie stap‑voor‑stap doorlopen, weergegeven met Mermaid.  
* Demonstreren hoe elke service onafhankelijk kan worden ingezet op Kubernetes, serverless FaaS of edge‑omgevingen.  
* Concreet best‑practice advies geven over datagovernance, observability en continue verbetering.

> **TL;DR:** Splits het platform voor vragenlijstautomatisering op in kleine, goed gedefinieerde services, plaats LLM's achter een stateless inferentielag en gebruik event‑gedreven pipelines om een enkele bron van waarheid voor bewijs en versiebeheer te behouden.

---

## 1. Waarom Componeren in Plaats van een Reusachtige Monoliet?

| Monolithische aanpak | Componabele micro‑services |
|----------------------|----------------------------|
| Eén code‑basis, moeilijk om specifieke workloads (bijv. LLM‑inference) te schalen. | Onafhankelijke schaal­baarheid – AI‑inference kan draaien op GPU‑nodes, terwijl opslag op kostenefficiënte object‑stores blijft. |
| Strakke koppeling maakt updates riskant; een bug in de UI kan het hele systeem laten vallen. | Losse koppeling via asynchrone events of HTTP‑API's isoleert storingen. |
| Beperkte taalonafhankelijke integratie – vaak vastgelegd op één stack. | Polyglotte ondersteuning – elke service kan geschreven worden in de taal die het beste bij de taak past (Go voor authenticatie, Python voor LLM‑orchestratie, Rust voor high‑throughput pipelines). |
| Auditing en compliance worden een nachtmerrie omdat logs door elkaar lopen. | Gecentraliseerde event‑store + immutable audit‑log biedt een helder, doorzoekbaar spoor voor toezichthouders. |

Het **Componabele** model omarmt de *“bouw alleen wat je nodig hebt, en vervang wat je niet meer wilt”* filosofie. Het past bij de dynamische aard van veiligheidsvragenlijsten, waar regelmatig nieuwe controle‑kaders (bijv. [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) verschijnen en teams snel moeten aanpassen.

---

## 2. Kern‑Architecturale Pilaren

1. **Stateless API‑gateway** – toegangspunt voor UI, SaaS‑connectors en externe tools. Handelt authenticatie, request‑validatie en throttling af.  
2. **Domeinspecifieke micro‑services** – elke service kapselt een begrensde context:
   * **Vragenlijstservice** – slaat metadata, versiebeheer en taaktoewijzingen van vragenlijsten op.  
   * **Bewijsmateriaalservice** – beheert artefacten (beleidsdocumenten, screenshots, audit‑logs) in een immutable object store.  
   * **AI‑Orkestratieservice** – stelt prompts samen, draait RAG‑pipelines en retourneert concept‑antwoorden.  
   * **Detectieservice** – houdt bewijsmateriaal‑updates in de gaten en triggert her‑evaluatie van getroffen antwoorden.  
   * **Notificatieservice** – stuurt Slack, Teams of e‑mail‑events naar belanghebbenden.  
3. **Event‑bus (Kafka / Pulsar)** – garandeert **at‑least‑once** aflevering van domein‑events (bijv. `BewijsGeüpload`, `AntwoordConcept`).  
4. **Observability‑stack** – OpenTelemetry‑traces over services heen, Prometheus‑metrics en Loki‑logs.  
5. **Policy‑as‑Code Engine** – evalueert compliance‑regels (geschreven in Rego of OPA) voordat een antwoord als “definitief” wordt gemarkeerd.  

Alle services communiceren via **gRPC** (voor lage latency) of **REST** (voor externe integraties). Het ontwerp promoot *dumb pipes, smart endpoints* – de business‑logica woont waar hij hoort, terwijl de bus alleen berichten transporteert.

---

## 3. Datastroom – Van Vraag tot Auditbaar Antwoord

Hieronder staat een Mermaid‑diagram dat een typische levenscyclus van een verzoek visualiseert.

```mermaid
flowchart TD
    subgraph UI["Gebruikersinterface"]
        UI1["\"Web UI\""] -->|Verzend vragenlijst| AG["\"API‑gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Vragenlijstservice\""]
    QMS -->|Haalt sjabloon| AIOS["\"AI‑Orkestratieservice\""]
    AIOS -->|Haalt relevant bewijs| ES["\"Bewijsmateriaalservice\""]
    ES -->|Bewijsobjecten| AIOS
    AIOS -->|Genereert conceptantwoord| RAG["\"RAG‑pijplijn\""]
    RAG -->|LLM‑output| AIOS
    AIOS -->|Slaat concept op| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Detectieservice\""]
    CDS -->|Her‑run indien bewijs gewijzigd| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notificatieservice\""]
    NS -->|Push naar 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
```

**Kernmomenten in de stroom**:

1. **Gebruiker verstuurt** een nieuwe vragenlijst of selecteert een bestaande.  
2. **API‑gateway** valideert JWT, controleert rate limits en stuurt door naar de Vragenlijstservice.  
3. De **Vragenlijstservice** haalt het sjabloon op en publiceert een event naar de AI‑Orkestratieservice.  
4. **AI‑Orkestratieservice** voert een *retrieval‑stap* uit – ze zoekt in de Bewijsmateriaalservice naar alle artefacten die relevant zijn voor de huidige controle (via vector‑similariteit of keyword‑match).  
5. De opgehaalde context, samen met het prompt‑sjabloon, wordt gevoed aan een **RAG‑pipeline** (bijv. `openAI/gpt‑4o‑preview`).  
6. Het concept‑antwoord wordt teruggeslagen in de Vragenlijstservice en gemarkeerd als *“in afwachting van beoordeling.”*  
7. De **Detectieservice** houdt nieuwe bewijsmateriaal‑uploads in de gaten. Indien een beleidsdocument wordt aangepast, triggert ze opnieuw de RAG‑pipeline voor de getroffen antwoorden.  
8. Finale reviewers accepteren of bewerken het concept; bij acceptatie valideert de **Policy‑as‑Code Engine** dat het antwoord aan alle regel‑voorwaarden voldoet voordat het wordt vastgeschreven in een immutable audit‑log.  

---

## 4. Implementatiedetails

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

* **Routing** – `POST /questionnaires/:id/answers` → `vragenlijstservice`.  
* **Beveiliging** – Handhaaf scopes (`questionnaire:write`).  
* **Rate‑limiting** – 100 requests/min per tenant om downstream LLM‑kosten te beschermen.

### 4.2. Vragenlijstservice (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
}
```

* Maakt gebruik van **PostgreSQL** voor relationele data en **EventStoreDB** voor domeinevents.  
* Exposeert gRPC‑methodes `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. Bewijsmateriaalservice (Python + FastAPI)

* Slaat bestanden op in **MinIO** of **AWS S3** met bucket‑niveau encryptie.  
* Indexeert inhoud in **Qdrant** (vector‑DB) voor similarity‑search.  
* Biedt endpoint `POST /search` dat een query accepteert en de top‑k artefact‑IDs teruggeeft.

### 4.4. AI‑Orkestratieservice (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** – Combineert vector‑search met een *system prompt* die het model instrueert bewijs‑IDs te citeren.  
* **Caching** – Opslaan van gegenereerde antwoorden voor 24 uur om dubbele LLM‑calls te vermijden.

### 4.5. Detectieservice (Rust)

* Abonneert zich op `BewijsGeüpload`‑events.  
* Berekent een **hash** van het nieuwe artefact en vergelijkt met bestaande bewijzen gekoppeld aan elke controle.  
* Als de wijziging een drempel overschrijdt, publiceert het `AnswerRequiresRegen`.

### 4.6. Notificatieservice (Node.js)

* Luistert naar `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* Formatteert Slack‑blocks, Teams Adaptive Cards of e‑mail‑templates.  
* Ondersteunt **deduplicatie** – meldt slechts één keer per wijziging per vragenlijst.

---

## 5. Veiligheid & Governance

| Zorg | Mitigatie |
|------|-----------|
| **Datalekken** – LLM‑prompts kunnen gevoelige beleidsinformatie bevatten. | Gebruik **on‑prem LLM‑inference** (bijv. Llama 3.2) binnen een VPC. Maskeer PII voordat je naar externe APIs stuurt. |
| **Ongeautoriseerde toegang tot bewijsmateriaal** | Handhaaf fijne‑granular ACL’s met OPA‑policies in de Bewijsmateriaalservice. |
| **Model‑drift** – Antwoorden verslechteren over tijd. | Plan **periodieke evaluatie** tegen een benchmark‑corpus en hertrain prompt‑templates. |
| **Audit‑baarheid** | Elke status‑verandering wordt vastgelegd in een immutable event‑log opgeslagen op **WORM S3**. |
| **GDPR/CCPA‑naleving** | Implementeer een **right‑to‑be‑forgotten** workflow die gebruikers‑specifiek bewijsmateriaal uit de vector‑DB en object‑store verwijdert ([GDPR](https://gdpr.eu/)). |
| **ISO 27001** | Valideer dat bewijsmateriaalretentie, encryptie en toegangs‑control policies overeenkomen met de ISO 27001‑norm. |
| **HIPAA / SOC 2** | Breid OPA‑regels uit om de vereiste beveiligingsmaatregelen af te dwingen voor gezondheids‑ of SaaS‑providers. |

---

## 6. Schaalstrategieën

1. **Horizontal Pod Autoscaling (HPA)** – Schaal AI‑Orkestratieservice‑pods op basis van GPU‑gebruik (`nvidia.com/gpu`).  
2. **Burst‑bare queues** – Gebruik Kafka‑partities om high‑traffic tenants te isoleren.  
3. **Cold‑start reductie** – Houd een warm pool van containers voor de LLM‑inference server (bijv. met **KEDA** en een custom scaler).  
4. **Kostenbeheersing** – Pas **token‑gebaseerde budgetten** per tenant toe; throttle of factureer over‑gebruik automatisch.

---

## 7. Observability & Continue Verbetering

* **Distributed Tracing** – OpenTelemetry‑spans van UI‑request → API‑gateway → AI‑Orkestratieservice → RAG → Bewijsmateriaalservice.  
* **Metrics** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Log Aggregation** – Gestructureerde JSON‑logs met `request_id` die over services heen wordt doorgegeven.  
* **Feedback‑loop** – Na finalisatie van een antwoord, verzamel reviewer‑commentaren (`review_score`). Gebruik deze signalen in een **reinforcement learning**‑model dat de prompt‑temperature aanpast of alternatieve bewijsmaterialen selecteert.

---

## 8. Stapsgewijze Migratie voor Bestaande Teams

| Fase | Doel | Activiteiten |
|------|------|--------------|
| **0 – Ontdekking** | Huidige vragenlijst‑workflow in kaart brengen. | Identificeer datasources, definieer controle‑taxonomie. |
| **1 – Fundamenten bouwen** | Deploy API‑gateway, authenticatie en basis‑services. | Containeriseer `vragenlijstservice` en `bewijsmateriaalservice`. |
| **2 – AI introduceren** | Run RAG op een pilot‑vragenlijst. | Gebruik een sandbox‑LLM, valideer concept‑antwoorden handmatig. |
| **3 – Event‑gedreven automatisering** | Koppel de Detectieservice aan de pipeline. | Enable auto‑regen bij bewijs‑updates. |
| **4 – Governance aanscherpen** | Voeg OPA‑policies, immutable audit‑logs toe. | Schakel over naar productie‑LLM (on‑prem). |
| **5 – Schalen & optimaliseren** | Auto‑scale GPU‑pods, implementeer kosten‑controles. | Deploy observability‑stack, stel SLO’s in. |

Door de composabele architectuur gefaseerd te adopteren, vermijden teams het risico van een “big‑bang” transitie en kunnen ze vroeg ROI aantonen (meestal een **30‑50 % reductie** in doorlooptijd van vragenlijsten).

---

## 9. Toekomstbestendigheid van de Stack

* **Federated Learning** – Train lichte adapters op de data van elke tenant zonder ruwe bewijsmaterialen te verplaatsen, waardoor antwoord‑relevantie stijgt en data‑sovereignty gerespecteerd wordt.  
* **Zero‑Trust Service Mesh** – Gebruik **Istio** of **Linkerd** met mutual TLS om intra‑service verkeer te beveiligen.  
* **Semantische Governance** – Breid de Policy‑as‑Code engine uit om niet alleen inhoud, maar ook de **semantische gelijkenis** tussen bewijs en controle‑taal te valideren.  
* **Generatieve Traceerbaarheid** – Sla exact de gebruikte LLM‑temperature, top‑p en system‑prompt op naast elk antwoord voor forensisch onderzoek.

---

## 10. Conclusie

Een composabele micro‑services architectuur maakt van beveiligingsvragenlijst‑automatisering geen knellende handmatige klus meer, maar een **schaalbare, auditbare en continu lerende motor**. Door verantwoordelijkheden te desacopleren, LLM's via een stateless RAG‑laag in te zetten en alles te koppelen met een event‑gedreven backbone, kunnen organisaties:

* Leveranciersbeoordelingen in minuten beantwoorden in plaats van dagen.  
* Bewijsmateriaal automatisch actueel houden met verander‑detectie.  
* Regelgevers een helder, immutable audit‑spoor bieden.

Begin klein, iterate snel, en laat de micro‑services‑filosofie u begeleiden naar een toekomst waarin compliance een **feature** is, geen bottleneck.  

---

## Zie ook

- [OPA Policy‑as‑Code voor Micro‑services](https://www.openpolicyagent.org/docs/latest/policy-language/)