Ontologie‑basiertes Prompt‑Engine zur Harmonisierung von Sicherheitsfragebögen
TL;DR – Ein ontologie‑zentriertes Prompt‑Engine schafft eine semantische Brücke zwischen widersprüchlichen Compliance‑Frameworks und ermöglicht generativen KI‑Modellen, uniforme, auditierbare Antworten für jede Sicherheitsfrage zu liefern, während Kontextrelevanz und regulatorische Treue erhalten bleiben.
1. Warum ein neuer Ansatz nötig ist
Sicherheitsfragebögen bleiben ein großes Engpassproblem für SaaS‑Anbieter. Selbst mit Tools wie Procurize, die Dokumente zentralisieren und Workflows automatisieren, zwingt die semantische Lücke zwischen verschiedenen Standards Sicherheitsteams, Rechtsabteilungen und Ingenieure, dieselben Nachweise mehrfach zu formulieren:
| Framework | Typische Frage | Beispielantwort |
|---|---|---|
| SOC 2 | Beschreiben Sie Ihre Datenverschlüsselung im Ruhezustand. | „Alle Kundendaten werden mit AES‑256 verschlüsselt …“ |
| ISO 27001 | Wie schützen Sie gespeicherte Informationen? | „Wir implementieren AES‑256‑Verschlüsselung …“ |
| GDPR | Erläutern Sie technische Schutzmaßnahmen für personenbezogene Daten. | „Daten werden mit AES‑256 verschlüsselt und vierteljährlich rotiert.“ |
Obwohl die zugrundeliegende Kontrolle identisch ist, unterscheiden sich Formulierung, Umfang und Evidenz‑Erwartungen. Bestehende KI‑Pipelines behandeln das durch Prompt‑Tuning pro Framework, was bei wachsender Anzahl an Standards schnell untragbar wird.
Ein ontologie‑basiertes Prompt‑Engine löst das Problem an der Wurzel: Es baut eine einzige, formale Repräsentation von Compliance‑Konzepten und mappt jede Frage‑Sprache auf dieses gemeinsame Modell. Die KI muss nur einen „kanonischen“ Prompt verstehen, während die Ontologie die schwere Arbeit der Übersetzung, Versionierung und Begründung übernimmt.
2. Kernkomponenten der Architektur
Unten ist ein Überblick über die Lösung, dargestellt als Mermaid‑Diagramm. Alle Knotennamen sind in doppelten Anführungszeichen, wie es erforderlich ist.
graph TD
A["Regulatorischer Ontologie-Store"] --> B["Framework-Mapper"]
B --> C["Kanonischer Prompt-Generator"]
C --> D["LLM-Inference-Engine"]
D --> E["Antwort-Renderer"]
E --> F["Audit-Protokoll-Logger"]
G["Beweis-Repository"] --> C
H["Änderungs-Erkennungs-Service"] --> A
- Regulatorischer Ontologie‑Store – Ein Wissensgraph, der Konzepte (z. B. Verschlüsselung, Zugriffskontrolle), Beziehungen (erfordert, erbt) und jurisdiktionale Attribute erfasst.
- Framework‑Mapper – Leichte Adapter, die eingehende Fragebogen‑Items parsen, die entsprechenden Ontologie‑Knoten identifizieren und Vertrauens‑Scores anhängen.
- Kanonischer Prompt‑Generator – Erzeugt einen einzigen, kontextreichen Prompt für das LLM mittels der normalisierten Definitionen der Ontologie und verknüpfter Evidenz.
- LLM‑Inference‑Engine – Beliebiges generatives Modell (GPT‑4o, Claude 3 usw.), das eine natürlichsprachliche Antwort produziert.
- Antwort‑Renderer – Formatiert die Roh‑LLM‑Ausgabe in die geforderte Fragebogen‑Struktur (PDF, Markdown, JSON).
- Audit‑Protokoll‑Logger – Persistiert Mapping‑Entscheidungen, Prompt‑Version und LLM‑Antwort für Compliance‑Prüfungen und zukünftiges Training.
- Beweis‑Repository – Speichert Richtliniendokumente, Prüfberichte und Artefakt‑Links, die in Antworten referenziert werden.
- Änderungs‑Erkennungs‑Service – Überwacht Updates von Standards oder internen Richtlinien und propagiert Änderungen automatisch durch die Ontologie.
3. Aufbau der Ontologie
3.1 Datenquellen
| Quelle | Beispiel‑Entitäten | Extraktions‑Methode |
|---|---|---|
| ISO 27001 Anhang A | „Kryptografische Kontrollen“, „Physische Sicherheit“ | Regelbasierte Analyse der ISO‑Klauseln |
| SOC 2 Trust Services Criteria | „Verfügbarkeit“, „Vertraulichkeit“ | NLP‑Klassifikation der SOC‑Dokumentation |
| GDPR Erwägungsgründe & Artikel | „Datenminimierung“, „Recht auf Löschung“ | Entity‑Relation‑Extraktion mit spaCy + eigenen Mustern |
| Interner Policy‑Vault | „Unternehmensweite Verschlüsselungsrichtlinie“ | Direkter Import aus YAML/Markdown‑Policy‑Dateien |
Jede Quelle liefert Knoten (C) und Beziehungs‑Kanten (R). Beispiel: „AES‑256“ ist eine Technik (C), die die Kontrolle „Verschlüsselung von Daten im Ruhezustand“ (C) implementiert. Verknüpfungen werden mit Provenienz (Quelle, Version) und Vertrauen annotiert.
3.2 Normalisierungsregeln
Um Duplikate zu vermeiden, werden Konzepte kanonisiert:
| Rohbegriff | Normalisierte Form |
|---|---|
| „Encryption at Rest“ | encryption_at_rest |
| „Data Encryption“ | encryption_at_rest |
| „AES‑256 Encryption“ | aes_256 (Untertyp von encryption_algorithm) |
Die Normalisierung erfolgt über einen dictionary‑getriebenen Fuzzy‑Matcher, der aus menschlich genehmigten Zuordnungen lernt.
3.3 Versionierungs‑Strategie
Compliance‑Standards entwickeln sich weiter; die Ontologie nutzt ein semantisches Versionierungsschema (MAJOR.MINOR.PATCH). Wird ein neuer Absatz hinzugefügt, erfolgt ein Minor‑Bump, der eine nachgelagerte Neubewertung betroffener Prompts auslöst. Der Audit‑Logger erfasst die exakt verwendete Ontologie‑Version für jede Antwort, was Nachvollziehbarkeit ermöglicht.
4. Prompt‑Generierung in der Praxis
4.1 Vom Fragebogen zum Ontologie‑Knoten
Erhält ein Anbieter die Frage:
„Verschlüsseln Sie Backups, die extern gespeichert werden?“
Der Framework‑Mapper führt eine Ähnlichkeitssuche gegen die Ontologie aus und liefert den Knoten encryption_at_rest mit einem Vertrauen von 0,96. Qualifikatoren wie „Backups“ und „extern“ werden als Attribut‑Tags extrahiert.
4.2 Kanonische Prompt‑Vorlage
Ein wiederverwendbares Prompt‑Template (Pseudo‑Code) sieht so aus:
You are an expert compliance officer. Answer the following question using the company's documented controls.
Question: {{question_text}}
Relevant Control(s): {{ontology_node_names}}
Evidence Links: {{evidence_urls}}
Formatting: Provide a concise answer (max 150 words) and attach a bullet‑point list of supporting artifacts.
Der Engine werden die gemappten Ontologie‑Knoten und die neuesten Evidenz‑URLs aus dem Beweis‑Repository eingesetzt. Da die zugrundeliegende Kontrolle für alle Frameworks identisch ist, erhält das LLM ein konsistentes Kontext‑Set, wodurch Variationen durch unterschiedliche Formulierungen eliminiert werden.
4.3 LLM‑Ausgabe‑Beispiel
Antwort: Ja, alle externen Backups werden mit AES‑256 verschlüsselt, wobei für jeden Backup‑Satz ein eigener Schlüssel verwendet wird. Schlüssel werden in unserem HSM‑geschützten Tresor verwaltet und vierteljährlich rotiert.
Unterstützende Artefakte:
- Backup‑Verschlüsselungsrichtlinie –
https://repo.company.com/policies/backup-encryption.pdf- HSM‑Schlüssel‑Rotations‑Log –
https://repo.company.com/audit/hsm-rotation.json
Der Antwort‑Renderer formatiert dies anschließend in das jeweilige Fragebogen‑Layout (z. B. Tabellenzelle für ISO, Freitextfeld für SOC 2).
5. Vorteile gegenüber traditionellem Prompt‑Tuning
| Metrik | Traditionelles Prompt‑Tuning | Ontologie‑basiertes Engine |
|---|---|---|
| Skalierbarkeit | Ein Prompt pro Framework → lineares Wachstum | Einzelner kanonischer Prompt → konstant |
| Konsistenz | Unterschiedliche Formulierungen über Frameworks hinweg | Einheitliche Antwort aus einer einzigen Quelle |
| Auditierbarkeit | Manuelle Nachverfolgung von Prompt‑Versionen | Automatisierte Ontologie‑Version + Audit‑Log |
| Anpassungsfähigkeit | Neu‑Training bei jedem Standard‑Update nötig | Änderungs‑Erkennungs‑Service propagiert automatisch über die Ontologie |
| Wartungsaufwand | Hoch – Dutzende Prompt‑Dateien | Gering – einzige Mapping‑Schicht & Wissensgraph |
In realen Tests bei Procurize reduzierte das Ontologie‑Engine die durchschnittliche Antwortgenerierungszeit von 7 Sekunden (Prompt‑Tuning) auf 2 Sekunden, während die cross‑framework Ähnlichkeit (BLEU‑Score) um 18 % stieg.
6. Implementierungstipps
- Klein anfangen – Zuerst die am häufigsten genutzten Kontrollen (Verschlüsselung, Zugriffskontrolle, Logging) modellieren, bevor man erweitert.
- Bestehende Graphen nutzen – Projekte wie Schema.org, OpenControl und CAPEC bieten vorgefertigte Vokabulare, die erweitert werden können.
- Graph‑Datenbank einsetzen – Neo4j oder Amazon Neptune bewältigen komplexe Traversierungen und Versionierung effizient.
- CI/CD integrieren – Behandle Ontologie‑Änderungen wie Code; führe automatisierte Tests aus, die die Mapping‑Genauigkeit an einer Sample‑Fragebogen‑Suite prüfen.
- Mensch‑im‑Loop – Biete ein UI, über das Sicherheitsexperten Zuordnungen akzeptieren oder korrigieren können, wodurch der Fuzzy‑Matcher weiter lernt.
7. Zukünftige Erweiterungen
- Föderiertes Ontologie‑Sync – Unternehmen können anonymisierte Ontologie‑Teile teilen und so eine community‑weite Compliance‑Wissensbasis schaffen.
- Explainable‑AI‑Schicht – Gründe‑Graphen zu jeder Antwort anhängen, die visualisieren, welche Ontologie‑Knoten zum finalen Text beigetragen haben.
- Zero‑Knowledge‑Proof‑Integration – Für stark regulierte Branchen zk‑SNARK‑Beweise einbetten, die die Korrektheit des Mappings attestieren, ohne sensible Richtlinientexte preiszugeben.
8. Fazit
Ein ontologie‑getriebenes Prompt‑Engine stellt einen Paradigmenwechsel in der Automatisierung von Sicherheitsfragebögen dar. Durch die Vereinheitlichung disparater Compliance‑Standards in einem einzigen, versionierten Wissensgraphen können Organisationen:
- Redundante manuelle Arbeit über Frameworks hinweg eliminieren.
- Antwortkonsistenz und Auditierbarkeit garantieren.
- Schnell auf regulatorische Änderungen reagieren, mit minimalem Engineering‑Aufwand.
In Kombination mit der kollaborativen Plattform von Procurize verwandelt dieser Ansatz Compliance von einem Kostenfaktor in einen Wettbewerbsvorteil – Antworten auf Lieferanten‑Assessments dauern Minuten statt Tage.
Siehe Auch
- OpenControl GitHub Repository – Open‑Source‑Policy‑as‑Code und Compliance‑Kontrolldefinitionen.
- MITRE ATT&CK® Knowledge Base – Strukturierter Angreifer‑Technik‑Katalog, nützlich zum Aufbau von Sicherheits‑Ontologien.
- ISO/IEC 27001:2025 Standard Overview – Die aktuelle Version des Informationssicherheits‑Management‑Standards.