Intent‑basiertes KI‑Routing‑Engine für Echtzeit‑Zusammenarbeit bei Sicherheitsfragebögen

Sicherheitsfragebögen, Compliance‑Audits und Lieferanten‑Risikobewertungen sind ein anhaltender Schmerzpunkt für SaaS‑Unternehmen. Der traditionelle Workflow — manuelle Triagierung, statische Zuordnungsl Listen und ad‑hoc‑E‑Mail‑Austausch — schafft Latenz, führt zu menschlichen Fehlern und erschwert das Skalieren, wenn das Volumen der Fragebögen steigt.

Was wäre, wenn jede einzelne Frage sofort an die exakt passende Person (oder KI‑Assistent) weitergeleitet werden könnte, die das benötigte Wissen besitzt, und gleichzeitig unterstützende Evidenz aus einem Live‑Knowledge‑Graphen angezeigt würde?

Hier kommt das Intent‑Based AI Routing Engine (IBARE) ins Spiel, ein neues architektonisches Muster, das Echtzeit‑, intent‑gesteuerte Zusammenarbeit in Plattformen wie Procurize ermöglicht. IBARE kombiniert modernste Natural‑Language‑Understanding, einen kontinuierlich angereicherten Knowledge‑Graph und eine leichte Micro‑Service‑Orchestrierungsebene, um zu liefern:

• Sub‑Sekunden‑Frageklassifizierung — das System versteht die zugrundeliegende Absicht einer Frage (z. B. „Verschlüsselung im Ruhezustand“, „Incident‑Response‑Ablauf“, „Daten‑Residency“), anstatt sich allein auf Stichwort‑Matching zu verlassen.
• Dynamische Expertenzuordnung — unter Verwendung von Fähigkeits‑Profilen, Auslastungs‑Metriken und historischer Antwort‑Qualität wählt IBARE den passendsten SME, KI‑Assistenten oder ein Hybrid‑Paar.
• Kontext‑bewusste Evidenz‑Abruf — die Routing‑Entscheidung wird mit relevanten Policy‑Auszügen, Audit‑Artefakten und versionierter Evidenz aus einem föderierten Knowledge‑Graphen angereichert.
• Echtzeit‑Feedback‑Schleife — jede beantwortete Frage fließt zurück in das Modell und verbessert die Intent‑Erkennung sowie die Experten‑Rangliste für zukünftige Fragebögen.

Im Folgenden zerlegen wir die Architektur, gehen durch einen Praxis‑Use‑Case, beleuchten wichtige Implementierungsdetails und quantifizieren die geschäftlichen Auswirkungen.

1. Warum Intent und nicht Stichworte?

Die meisten bestehenden Fragebogen‑Automatisierungstools basieren auf einfachem Stichwort‑ oder regel‑basiertem Routing:

if "encryption" in question → assign to Security Engineer
if "GDPR" in question → assign to Data Privacy Lead

Diese Ansätze brechen zusammen, wenn Fragen mehrdeutig formuliert sind, mehrere Themen enthalten oder fachspezifischen Jargon nutzen.

Intent‑Erkennung geht einen Schritt weiter, indem sie das, was der Fragesteller tatsächlich benötigt, interpretiert:

Durch das Extrahieren des semantischen Intents kann das System die Frage an ein Teammitglied weiterleiten, dessen Expertise mit der Handlung oder dem Konzept übereinstimmt, nicht nur mit einem Oberflächenterm.

2. Hoch‑Level‑Architektur

Unten steht ein Mermaid‑Diagramm, das die primären Komponenten und den Datenfluss von IBARE visualisiert.

  flowchart TD
    subgraph Frontend
        UI[User Interface] -->|Submit Question| API[REST / GraphQL API]
    end

    subgraph Core
        API --> Intent[Intent Detection Service]
        Intent --> KG[Dynamic Knowledge Graph]
        Intent --> Skills[SME Skill‑Profile Service]
        KG --> Evidence[Evidence Retrieval Service]
        Skills --> Ranking[Expert Ranking Engine]
        Evidence --> Ranking
        Ranking --> Router[Routing Engine]
    end

    subgraph Workers
        Router -->|Assign| SME[Subject‑Matter Expert / AI Assistant]
        SME -->|Answer| Feedback[Feedback Collector]
        Feedback --> KI[Knowledge‑Graph Ingestion]
        Feedback --> Model[Model Retraining Loop]
    end

    classDef external fill:#f9f9f9,stroke:#333,stroke-width:1px;
    class UI,API,SME external;

Wichtige Komponenten

3. Detaillierter Durchlauf eines Praxis‑Szenarios

Szenario: Ein Sales‑Engineer erhält von einem potenziellen Unternehmenskunden die Anfrage:

“Können Sie Details dazu liefern, wie Sie Kundendaten in einer Multi‑Tenant‑Umgebung isolieren und welche Verschlüsselungs‑Mechanismen Sie für Daten im Ruhezustand verwenden?”

Schritt 1 – Einreichung

Der Engineer fügt die Frage im Procurize‑Dashboard ein. Das UI sendet einen POST‑Request an die API mit dem Roh‑Text.

Schritt 2 – Intent‑Extraktion

Der Intent Detection Service leitet den Text durch einen feinabgestimmten Transformer, der eine Wahrscheinlichkeits‑Verteilung über eine Taxonomie von 120 Intents ausgibt. Für diese Frage sind die Top‑Drei‑Intents:

1. Tenant Isolation – 0.71
2. Encryption‑at‑Rest – 0.65
3. Data Residency – 0.22

Diese Intents werden als Multi‑Label‑Vektor am Frage‑Datensatz angehängt.

Schritt 3 – Knowledge‑Graph‑Abfrage

Der KG erhält den Intent‑Vektor und führt eine semantische Ähnlichkeitssuche (unter Nutzung von Vektor‑Einbettungen von Policy‑Klauseln) aus. Er liefert:

Die relevantesten Artefakte werden als Evidenz‑Pakete zusammengefasst.

Schritt 4 – Skill‑Profile‑Matching

Der Skills Service sucht alle Experten, die mit Cloud Architecture, Security Engineering und Compliance getaggt sind. Jeder Experte erhält ein Skill‑Embedding, das mit dem Intent‑Vektor verglichen wird. Gleichzeitig werden berücksichtigt:

• Aktuelle Auslastung (offene Aufgaben, Warteschlangenlänge)
• Qualitäts‑Score (Durchschnitt aus früheren Fragebogen‑Antworten)
• Zeitzonen‑Nähe (zur Reduktion der Latenz)

Der bestplatzierte Kandidat ist Alex Patel (Senior Cloud Security Engineer) mit einem zusammengesetzten Score von 0.92. Ein KI‑Assistent für Kryptografie (namens CryptoBot) wird ebenfalls mit einem Score von 0.87 vorgeschlagen.

Schritt 5 – Routing & Benachrichtigung

Die Routing Engine erzeugt eine Kollaborations‑Aufgabe, die enthält:

• Die Original‑Frage
• Die erkannten Intents
• Das Evidenz‑Paket (Download‑Links)
• Den vorgeschlagenen KI‑Assistenten (optional)

Alex erhält eine Push‑Benachrichtigung in Slack und im Procurize‑UI, während CryptoBot als Hintergrund‑Micro‑Service bereitsteht, um die Antwort zu ergänzen.

Schritt 6 – Antwort‑Zusammenstellung

Alex prüft die Evidenz, fügt zusätzlichen Kontext zu den letzten Plattform‑Updates hinzu und ruft CryptoBot auf, um automatisch einen prägnanten Absatz zur Verschlüsselungs‑Algorithmen (AES‑256‑GCM) zu erzeugen. Der zusammengeführte Text wird editiert, freigegeben und eingereicht.

Schritt 7 – Feedback‑Schleife

Der Kunde markiert die Antwort als „vollständig zufriedenstellend“. Der Feedback Collector protokolliert:

• Antwort‑Text
• Verknüpfte Evidenz‑IDs
• Zufriedenheits‑Rating (5/5)

Der Knowledge‑Graph‑Ingestion‑Service fügt einen neuen Knoten „Answer‑2025‑10‑21‑001“ hinzu, der mit der ursprünglichen Frage, der Evidenz und den Intents verknüpft ist. Dieser Knoten wird künftig Teil von Ähnlichkeits‑Suchanfragen.

Schritt 8 – Modell‑Update

Die neu gelabelten Daten (Frage + bestätigte Intents + Antwort) werden in die Training‑Pipeline eingespeist. Nach dem Sammeln von 1.000 solchen Interaktionen wird das Intent‑Modell neu trainiert, wodurch es Feinheiten wie „Tenant‑Level‑Key‑Management“ besser erkennt.

4. Kern‑Technische Bausteine

4.1 Intent‑Detection‑Modell

• Architektur: RoBERTa‑large, feinabgestimmt auf einem proprietären Datensatz von 50 k annotierten Fragebogen‑Sätzen.
• Loss‑Funktion: Binary Cross‑Entropy für Multi‑Label‑Klassifikation.
• Training‑Augmentation: Back‑Translation für Mehrsprachigkeit (Englisch, Deutsch, Japanisch, Spanisch).
• Performance: Macro‑F1 = 0.91 auf Validierungs‑Set; durchschnittliche Latenz ≈ 180 ms pro Request.

4.2 Knowledge‑Graph‑Plattform

• Engine: Neo4j 5.x mit integrierten Vektor‑Similarity‑Indizes (via Neo4j Graph Data Science).
• Schema‑Highlights:
  • Entitätstypen: Policy, Control, Evidence, Question, Answer, Expert.
  • Beziehungen: VALIDATES, EVIDENCES, AUTHORED_BY, RELATED_TO.
• Versionierung: Jedes Artefakt besitzt ein version‑Attribut und einen valid_from‑Zeitstempel, wodurch audit‑fähige Zeitreisen möglich sind.

4.3 Skill‑Profile‑Service

• Datenquellen: HR‑Verzeichnis (Skills, Zertifikate), internes Ticket‑System (Aufgaben‑Abschlüsse) und ein Qualitäts‑Score, der aus Nach‑Antwort‑Umfragen abgeleitet wird.
• Embedding‑Erzeugung: FastText‑Einbettungen von Skill‑Phrasen, kombiniert mit einem dichten Auslastungs‑Vektor.
• Ranking‑Formel:

score = α * intent_similarity
      + β * expertise_match
      + γ * availability
      + δ * historical_quality

wobei α = 0.4, β = 0.35, γ = 0.15, δ = 0.10 (via Bayesian‑Optimierung).

4.4 Orchestrierung & Micro‑Services

Alle Services laufen containerisiert (Docker) und werden über Kubernetes mit Istio Service‑Mesh koordiniert. Asynchrone Kommunikation nutzt NATS JetStream für latenz‑geringen Event‑Stream.

4.5 Sicherheits‑ & Datenschutz‑Überlegungen

• Zero‑Knowledge‑Proofs (ZKP): Für besonders sensible Evidenz (z. B. interne Pen‑Test‑Berichte) speichert der KG nur ZKP‑Commitments; die eigentliche Datei bleibt verschlüsselt in einem externen Tresor (AWS KMS) und wird nur bei Bedarf für den zugewiesenen Experten entschlüsselt.
• Differential Privacy: Der Intent‑Modell‑Training‑Pipeline werden kalibrierte Laplace‑Rauschwerte zu aggregierten Gradienten‑Updates hinzugefügt, um das Inhalts‑Schutz‑Level einzelner Fragebögen zu wahren.
• Audit‑Trail: Jede Routing‑Entscheidung, Evidenz‑Abruf und Antwort‑Edit wird in einem unveränderlichen Append‑Only‑Ledger (Hyperledger Fabric) protokolliert und erfüllt SOC 2‑Nachvollziehbarkeits‑Anforderungen.

5. Messbare Geschäftsauswirkungen

Ein Pilot mit drei Enterprise‑SaaS‑Kunden über sechs Monate zeigte einen netto ROI von 4,3×, vor allem bedingt durch verkürzte Verkaufszyklen und geringere juristische Aufwände.

6. Implementierungs‑Checkliste für Teams

1. Intent‑Taxonomie definieren – gemeinsam mit Security, Legal und Product eine Liste von 100‑150 High‑Level‑Intents erarbeiten.
2. ** Trainingsdaten kuratieren** – mindestens 10 k historische Fragebogen‑Sätze mit Intent‑Labels annotieren.
3. ** Skill‑Profile aufbauen** – Daten aus HR, Jira und internen Umfragen zusammenführen, Fähigkeits‑Beschreibungen normalisieren.
4. ** Knowledge‑Graph bereitstellen** – vorhandene Policy‑Dokumente, Evidenz‑Artefakte und Versions‑Historie importieren.
5. ** Integration in Kollaborations‑Hub** – Routing‑Engine mit Slack, Teams oder einer eigenen UI verbinden.
6. ** Feedback‑Schleife etablieren** – Zufriedenheits‑Ratings erfassen und in den Retraining‑Pipeline einfließen lassen.
7. ** KPIs überwachen** – Grafana‑Dashboards für Latenz, Routing‑Erfolg und Model‑Drift einrichten.

7. Zukunftsperspektiven

7.1 Multi‑Modal‑Intent‑Erkennung

Einbindung von Dokument‑Bildern (z. B. gescannte Verträge) und Audio‑Clips (Sprach‑Briefings) über CLIP‑artige Multi‑Modal‑Modelle, um das Routing über reinen Text hinaus zu erweitern.

7.2 Föderierte Knowledge‑Graphs

Ermöglichen von Cross‑Organisation‑Graph‑Federation, bei der Partnerunternehmen anonymisierte Policy‑Ausschnitte teilen, um die Intent‑Abdeckung zu verbessern, ohne proprietäre Daten preiszugeben.

7.3 Auto‑generierte Experten‑Profile

Große Sprachmodelle (LLMs) nutzen, um aus Lebensläufen automatisch ein Draft‑Skill‑Profile für neue Mitarbeitende zu erstellen und damit den Onboarding‑Aufwand zu reduzieren.

8. Fazit

Das Intent‑Based AI Routing Engine (IBARE) revolutioniert den Workflow von Sicherheitsfragebögen. Durch das Verstehen der wahren Intention hinter jeder Frage, die dynamische Zuordnung zum passenden Menschen oder KI‑Assistenten und die Verankerung von Antworten in einem lebendigen Knowledge‑Graph können Unternehmen:

• Antwortzeiten von Wochen auf Stunden reduzieren,
• Antwortqualität durch kontext‑basierte Evidenz erhöhen,
• Skalierbare Zusammenarbeit über verteilte Teams hinweg ermöglichen und
• Audit‑fähige, konforme Prozesse beibehalten, die sowohl Aufsichtsbehörden als auch Kunden zufriedenstellen.

Für SaaS‑Unternehmen, die ihr Vendor‑Risk‑Management zukunftssicher machen wollen, liefert IBARE ein greifbares, erweiterbares Blueprint — ein Ansatz, der schrittweise übernommen und kontinuierlich verfeinert werden kann, während sich das regulatorische Umfeld weiterentwickelt.