Startseite
Policy Engine
Policy Engine

Policy als Code, nicht als PDF.

Eine Compliance-Tabelle, die nie ausgeführt wird, ist Theorie. Eine Policy, die bei jedem Event evaluiert wird und ein Decision-Tupel zurückgibt, ist Runtime. Dieser Hub erklärt, wie die Policy Engine in RealSyncDynamics.AI authored, kompiliert und in unter 50ms gegen den Event-Stream evaluiert wird — und warum dieselbe Policy gleichzeitig GDPR, AI Act und ISO 27001 belegen kann.

Zwei Schichten DSL

Policies werden in einer YAML-DSL geschrieben, die für Compliance- und Engineering-Teams gleichermaßen lesbar bleibt. Beim Save kompiliert die Engine das YAML deterministisch nach Rego (OPA), das von einer in-process eingebetteten OPA-Bibliothek evaluiert wird. Reviewer:innen sehen beide Seiten in der PR — YAML für die Intention, Rego für die Ausführung.

YAML-Beispiel

Eine Policy, die Tracking ohne Consent verbietet (TDDDG §25):

  • id: policy.tracker_without_consent
  • applies_to: asset_type [website, page]; environment [production]
  • when: event.event_type = scanner.tracker_added
  • require: exists event.event_type = consent.granted within session, category ∈ analytics, marketing
  • on_violation: severity high, action require_approval, capture page_url + script_src + session_id
  • references: TDDDG_25, GDPR_ART_6, GDPR_ART_7

Eval-Lifecycle

Ein Event durchläuft pro Tenant: Telemetry-Collector → Policy-Eval-Queue → in-process OPA mit Bundle aus Object Storage (Cache 30s, mtime-Reload) → Policy-Decision persistieren →policy.decision.made auf Event-Bus. Downstream konsumiert: Risk-Engine adjustiert Asset-Score, Workflow-Engine startet Approval bei require_approval, Notification routet Alerts, Evidence Engine sealed Decision + Event zusammen.

Latenzen: p50 4ms, p99 35ms. Inline-Mode (synchron für AI-Runtime-SDK) bleibt unter 50ms p99 als hartes SLO.

Policy-Inheritance

Policies erben in vier Schichten:

  • RSD-shipped Default Policies (Plattform-Floor)
  • Industry-Pack-Policies (Healthcare, FinTech, HR — Tenant opt-in)
  • Tenant-Custom-Policies (im Produkt oder via Git-PR)
  • Environment-Overrides (Production strenger als Staging)

Höhere Schichten dürfen niedrigere verschärfen (Severity rauf, Allow-Conditions enger), aber nicht abschwächen. Der Compiler weigert sich, ein Bundle zu emittieren, das diese Invariante verletzt.

Eine Policy belegt vier Frameworks

Ein Hochrisiko-AI-System wird ohne abgeschlossene DPIA deployed. Das eine Event triggert vier Frameworks:

  • GDPR Art. 35policy.dpia_required_before_deploy, Action: block.
  • EU AI Act Art. 9 + 11policy.ai_act_high_risk_obligations, Action: block.
  • ISO 27001 A.5.34policy.iso_privacy_assessment, Action: require_approval.
  • SOC2 CC9.1policy.soc2_change_management, Action: warn.

Strictest action wins: block. Der Evidence-Record verlinkt auf alle vier matched Policies — ein gemeinsames Deployment-Blocked-Event belegt vier Frameworks gleichzeitig.

Observe-Mode vs Inline-Mode

Default ist Observe: Policy evaluiert async auf dem Event-Bus, Decision wird geschrieben, kein In-line-Block. Für AI-Runtime-Calls mit hartem Compliance-Anspruch (z. B. Modell-Calls, die personenbezogene Daten als Prompt mitschicken könnten) kann der SDK auf den synchronen Endpoint /policy/decide wechseln und auf die Decision warten. Das SLO bleibt strikt: p99 <50ms.

Weiterlesen

Live ausprobieren

Beispiel-Workspace mit Seed-Daten oder Compliance-Check für die eigene Domain.