Composable AI Micro‑services Architektur für skalierbare Automatisierung von Sicherheitsfragebögen

Unternehmen ersticken in einer ständig wachsenden Flut von Sicherheitsfragebögen, Lieferantenbewertungen und Compliance‑Audits. Traditionelle monolithische Werkzeuge können nicht mithalten, insbesondere wenn sie in unterschiedliche Produkt‑Ökosysteme integrieren, mehrsprachige Anfragen unterstützen und Echtzeit‑Audit‑Logs bereitstellen müssen.

Eine zusammensetzbare Micro‑services‑Architektur, gebaut um große Sprachmodelle (LLMs) und Retrieval‑Augmented Generation (RAG), bietet einen Weg, die Automatisierung zu skalieren und gleichzeitig die Flexibilität und Governance zu bewahren, die regulierte Branchen verlangen. In diesem Leitfaden werden wir:

• Die Kern‑Designprinzipien skizzieren, die das System sicher, auditierbar und erweiterbar halten.
• Eine Referenzimplementierung anhand eines Mermaid‑Diagramms durchgehen.
• Zeigen, wie jeder Service unabhängig auf Kubernetes, serverlosen FaaS‑Umgebungen oder Edge‑Runtimes bereitgestellt werden kann.
• Konkrete Best‑Practice‑Empfehlungen zu Daten‑Governance, Observability und kontinuierlicher Verbesserung geben.

TL;DR: Zerlegen Sie die Plattform zur Automatisierung von Fragebögen in kleine, klar definierte Services, lassen Sie LLMs hinter einer zustandslosen Inferenz‑Schicht arbeiten und nutzen Sie ereignisgesteuerte Pipelines, um eine einzige Quelle der Wahrheit für Evidenz und Versionskontrolle zu erhalten.

1. Warum komponieren statt einen riesigen Monolith bauen?

Das Composable‑Modell verkörpert die Philosophie „Baue nur, was du brauchst, und ersetze, was du nicht mehr willst“. Es passt zur dynamischen Natur von Sicherheitsfragebögen, bei denen regelmäßig neue Kontroll‑Frameworks (z. B. ISO 27001 Rev 2) auftauchen und Teams schnell reagieren müssen.

2. Kernarchitektur‑Säulen

1. Zustandsloses API‑Gateway – Einstiegspunkt für UI, SaaS‑Connectors und externe Tools. Handhabt Authentifizierung, Anfrage‑Validierung und Throttling.
2. Domänenspezifische Micro‑services – Jeder kapselt einen abgegrenzten Kontext:
   • Questionnaire Service – speichert Metadaten zu Fragebögen, Versionierung und Aufgaben‑Zuweisungen.
   • Evidence Service – verwaltet Artefakte (Richtlinien, Screenshots, Audit‑Logs) in einem unveränderlichen Object‑Store.
   • AI Orchestration Service – komponiert Prompts, führt RAG‑Pipelines aus und liefert Antwort‑Entwürfe.
   • Change‑Detection Service – überwacht Evidenz‑Updates und löst Neuberechnungen betroffener Antworten aus.
   • Notification Service – pusht Slack-, Teams‑ oder Email‑Events an Stakeholder.
3. Event‑Bus (Kafka / Pulsar) – garantiert mindestens‑einmal‑Zustellung von Domain‑Events (z. B. EvidenceUploaded, AnswerDrafted).
4. Observability‑Stack – OpenTelemetry‑Traces über alle Services, Prometheus‑Metriken und Loki‑Logs.
5. Policy‑as‑Code‑Engine – evaluiert Compliance‑Regeln (geschrieben in Rego oder OPA), bevor eine Antwort als „final“ markiert wird.

Alle Services kommunizieren via gRPC (für niedrige Latenz) oder REST (für externe Integrationen). Das Design fördert dumme Pipes, kluge Endpunkte – die Business‑Logik lebt dort, wo sie hingehört, während der Bus lediglich Nachrichten transportiert.

3. Datenfluss – Von der Frage zur auditierbaren Antwort

Unten ist ein Mermaid‑Diagramm, das einen typischen Request‑Lebenszyklus visualisiert.

  flowchart TD
    subgraph UI["Benutzeroberfläche"]
        UI1["\"Web UI\""] -->|Fragebogen einreichen| AG["\"API Gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Questionnaire Service\""]
    QMS -->|Template holen| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Relevante Evidenz holen| ES["\"Evidence Service\""]
    ES -->|Evidenz‑Objekte| AIOS
    AIOS -->|Entwurf generieren| RAG["\"RAG Pipeline\""]
    RAG -->|LLM‑Ausgabe| AIOS
    AIOS -->|Entwurf speichern| QMS
    QMS -->|Event AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Change‑Detection Service\""]
    CDS -->|Neu ausführen bei Evidenz‑Änderung| AIOS
    CDS -->|Event AnswerUpdated| EB
    EB -->|Benachrichtigen| NS["\"Notification Service\""]
    NS -->|Push zu 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

Wichtige Momente im Fluss:

1. Benutzer übermittelt einen neuen Fragebogen oder wählt einen bestehenden aus.
2. API‑Gateway prüft das JWT, kontrolliert Rate‑Limits und leitet an den Questionnaire Service weiter.
3. Der Questionnaire Service holt das Fragebogen‑Template und postet ein Event an den AI Orchestration Service.
4. AI Orchestration führt einen Retrieval‑Schritt aus – sie fragt den Evidence Service nach allen Artefakten ab, die zur aktuellen Kontrolle passen (vektorbasierte Ähnlichkeit oder Stichwort‑Suche).
5. Die abgerufenen Kontexte zusammen mit dem Prompt‑Template speisen eine RAG‑Pipeline (z. B. openAI/gpt‑4o‑preview).
6. Der Entwurf wird zurück im Questionnaire Service gespeichert und als „ausstehende Prüfung“ markiert.
7. Der Change‑Detection Service beobachtet neue Evidenz‑Uploads. Wird eine Richtlinie aktualisiert, löst er die RAG‑Pipeline für betroffene Antworten erneut aus.
8. End‑Reviewer akzeptieren oder editieren den Entwurf; nach Akzeptanz prüft die Policy‑as‑Code‑Engine, ob die Antwort alle Regel‑Constraints erfüllt, bevor sie in ein unveränderliches Audit‑Log geschrieben wird.

4. Implementierungsdetails

4.1. API‑Gateway (Envoy + OIDC)

• Routing – POST /questionnaires/:id/answers → questionnaire-service.
• Sicherheit – Durchsetzung von Scopes (questionnaire:write).
• Rate‑Limiting – 100 Requests/Minute pro Mandant, um LLM‑Kosten zu schützen.

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
}

• Nutzt PostgreSQL für relationale Daten, EventStoreDB für Domain‑Events.
• Exponiert gRPC‑Methoden GetTemplate, SaveDraft, FinalizeAnswer.

4.3. Evidence Service (Python + FastAPI)

• Speichert Dateien in MinIO oder AWS S3 mit Bucket‑verschlüsselung.
• Indexiert Inhalte in Qdrant (Vektor‑DB) für Ähnlichkeitssuche.
• Stellt einen Endpoint POST /search bereit, der eine Anfrage entgegennimmt und die Top‑k Artefakt‑IDs zurückgibt.

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 – Kombiniert Vektorsuche mit einem System‑Prompt, der das Modell anweist, Evidenz‑IDs zu zitieren.
• Caching – Speichert generierte Antworten für 24 h, um doppelte LLM‑Aufrufe zu vermeiden.

4.5. Change‑Detection Service (Rust)

• Abonniert EvidenceUploaded‑Events.
• Berechnet einen Hash des neuen Artefakts und führt einen Diff gegenüber bestehender Evidenz zu jeder Kontrolle durch.
• Überschreitet der Unterschied einen konfigurierbaren Schwellenwert, veröffentlicht er AnswerRequiresRegen.

4.6. Notification Service (Node.js)

• Lauscht auf AnswerDrafted, AnswerFinalized, AnswerRequiresRegen.
• Formatiert Slack‑Blocks, Teams‑Adaptive‑Cards oder E‑Mail‑Templates.
• Unterstützt Deduplication – benachrichtigt pro Änderung nur einmal pro Fragebogen.

5. Sicherheit & Governance

6. Skalierungsstrategien

1. Horizontal Pod Autoscaling (HPA) – Skalierung der AI Orchestration‑Pods basierend auf GPU‑Auslastung (nvidia.com/gpu).
2. Burst‑fähige Queues – Kafka‑Partitionierung nutzen, um Hoch‑Traffic‑Mandanten zu isolieren.
3. Cold‑Start‑Reduktion – Warm‑Pool von Containern für den LLM‑Inference‑Server (z. B. mit KEDA und einem eigenen Scaler) bereithalten.
4. Kostenkontrolle – Token‑basiertes Budget pro Mandant anwenden; Über‑Nutzung automatisch drosseln oder in Rechnung stellen.

7. Observability & Kontinuierliche Verbesserung

• Distributed Tracing – OpenTelemetry‑Spans von UI‑Request → API‑Gateway → AI Orchestration → RAG → Evidence Service.
• Metriken – answer_draft_latency_seconds, evidence_upload_bytes, llm_token_usage.
• Log‑Aggregation – Strukturierte JSON‑Logs mit durchgängiger request_id über alle Services hinweg.
• Feedback‑Loop – Nach Finalisierung einer Antwort Reviewer‑Kommentare (review_score) erfassen. Diese in ein Reinforcement‑Learning‑Modell einfließen lassen, das Prompt‑Temperatur oder alternative Evidenz‑Quellen anpasst.

8. Schritt‑für‑Schritt Migrationspfad für bestehende Teams

Durch die inkrementelle Einführung der composable Architektur vermeiden Teams das Risiko eines Big‑Bang-Umstiegs und können frühen ROI demonstrieren (oft 30‑50 % Reduktion der Durchlaufzeit für Fragebögen).

9. Zukunftssichere Erweiterungen

• Federated Learning – Leichtgewichtige Adapter auf den Daten jedes Mandanten trainieren, ohne Roh‑Evidenz zu entfernen, um die Antwort‑Relevanz zu erhöhen und gleichzeitig Datensouveränität zu wahren.
• Zero‑Trust Service Mesh – Einsatz von Istio oder Linkerd mit Mutual TLS zur Absicherung des intra‑Service‑Traffic.
• Semantische Governance – Erweiterung der Policy‑as‑Code‑Engine, um nicht nur den Antwort‑Inhalt, sondern auch die semantische Ähnlichkeit zwischen Evidenz und Kontroll‑Formulierung zu prüfen.
• Generative Traceability – Für jede Antwort exakt das verwendete LLM‑Temperature, Top‑p und System‑Prompt neben dem Ergebnis speichern, um forensische Prüfungen zu ermöglichen.

10. Fazit

Eine composable Micro‑services‑Architektur verwandelt die Automatisierung von Sicherheitsfragebögen von einer schmerzhaften manuellen Aufgabe in ein skalierbares, auditierbares und kontinuierlich verbesserndes System. Durch die Entkopplung von Verantwortlichkeiten, die Nutzung von LLMs über eine zustandslose RAG‑Schicht und das Verknüpfen aller Komponenten über ein ereignisgesteuertes Rückgrat können Unternehmen:

• Vendor‑Assessments in Minuten statt Tagen beantworten.
• Evidenz stets aktuell halten dank automatischer Change‑Detection.
• Regulierungsbehörden eine klare, unveränderliche Audit‑Spur vorlegen.

Klein starten, schnell iterieren und die Prinzipien der Micro‑services‑Philosophie nutzen, um Compliance zu einer Funktion, nicht zu einem Engpass, zu machen.

Siehe auch

• OPA Policy‑as‑Code für Micro‑services