Oronts GmbH, Amtsgericht München HRB 288224 · https://oronts.com/portfolio/oguardai · Version 2026-06-12 · office@oronts.com
Alle Arbeiten
Oronts-Produkte2024Ongoing

OGuardAI

Semantic data protection runtime for AI systems. Policy engine, PII detection and reversible tokenization between your application and any LLM.

Kunde: Oronts GmbH
Sprechen Sie uns anLive-DemoZum Guide

Auf einen Blick

99.7%
PII detection recall on our test corpus
<50ms
Rejection latency target for blocked content
3
Validation layers: policy, PII, tokenization
0
Raw PII values exposed to the model after tokenization

Die Herausforderung

Production LLM systems share a failure class: PII leaking into prompts and outputs, hallucinated data reaching customers, and generated text violating communication policies. Ad-hoc filters solve one incident and break on the next edge case. GDPR makes this an architecture problem, not a patching problem.

Unser Ansatz

OGuardAI runs as a synchronous filter in the LLM request and response path. Three validation layers: content policy classification against hot-reloadable YAML rule sets, PII detection combining pattern matching with named entity recognition, and semantic tokenization that swaps sensitive values for reversible tokens so the model never sees raw data. Restoration happens per output channel policy.

Systemarchitektur

Diagramm wird geladen...

Systemarchitektur: LLM Response, OGuardAI, Policy Check, Pass, Deliver to User, Violation, Content Classifier, PII Found?, Yes, Redact / Tokenize, No, Block + Reason, Upstream Retry

KI-Ebene

OGuardAI ist die KI-Schutzschicht selbst: eine Rust-Laufzeitumgebung, die zwischen einer Anwendung und einem beliebigen LLM sitzt, sensible Daten erkennt, sie durch typisierte semantische Tokens ersetzt, mit denen das Modell weiterhin arbeiten kann, und die Originale in der Antwort gemäß Policy wiederherstellt.

Erkennung

Eine in Rust geschriebene Regex-Basisschicht läuft immer und findet formatbasierte Daten (E-Mail, Telefon, IBAN, Kreditkarte, Reisepass, Steuer- und Sozialversicherungsnummern und mehr) in Texten jeder Sprache. Ein Python-Sidecar ergänzt Named-Entity-Recognition (GLiNER und spaCy) für Personen, Organisationen, Orte und Adressen in etwa zwanzig Sprachen. Überlappende Treffer werden nach Konfidenz zusammengeführt, und wird eine als erforderlich markierte Entität nicht gefunden, schlägt die Anfrage nach dem Fail-Closed-Prinzip fehl.

Semantische Tokenisierung

Erkannte Werte werden durch typisierte semantische Tokens ersetzt: Aus einem Namen wird ein Namens-Token, aus einer IBAN ein IBAN-Token. Das Modell behält den Kontext, den es braucht, statt Lücken zu sehen. Tokens werden dedupliziert und mit Entitäten verknüpft, mit zwei Identitätsschemata (zufällig pro Sitzung oder deterministisch pro Korpus), und nur der sichere, tokenisierte Text wird jemals an das LLM weitergeleitet.

Policy-Engine

Policies sind deklaratives YAML mit Vererbung. Sie entscheiden pro Entitätstyp, ob tokenisiert, geschwärzt, blockiert oder erlaubt wird, und pro Ausgabekanal, wie viel wiederhergestellt wird. Der Kernel löst die effektive Policy bei jeder Anfrage auf, sodass dieselbe Laufzeitumgebung unterschiedliche Regeln für eine Chat-Antwort, eine E-Mail oder ein internes Log durchsetzen kann.

Rehydrierung und Token-Robustheit

Auf dem Rückweg stellt eine dreistufige Token-Reparatur (strikt, Reparatur und Fuzzy) jedes Token über sechs Wiederherstellungsmodi auf sein Original zurück und weist Tokens ab, die das Modell halluziniert hat. Die Wiederherstellung ist deterministisch und idempotent, und jeder widerrufene Wert kommt stets als gelöscht zurück.

Sitzungen, Prompt-Sicherheit und Output-Guard

Sitzungen werden mit AES-256-GCM versiegelt oder über Redis gehalten, mit Replay-Abwehr, mandantenspezifischer Bindung und einer Widerrufstabelle. Ein Prompt-Security-Durchlauf prüft Eingaben auf Extraktionsversuche und injiziert eine gehärtete System-Präambel. Ein optionaler Output-Guard führt einen zweiten Erkennungsdurchlauf auf der Antwort des Modells aus, um personenbezogene Daten abzufangen, die das Modell selbst erzeugt hat.

RAG, Dokumente und Streaming

Derselbe Schutz deckt Retrieval-Augmented Generation ab (Ingest, Query, Kontext und Antwort, mit korpusgebundener Token-Identität und Filterung nach Zugriffsstufe), außerdem Dokumenten-Ingestion mit OCR und visueller Schwärzung für Bilder und PDFs sowie Streaming-Antworten mit Pufferung an Token-Grenzen, damit ein Token nie über Chunk-Grenzen hinweg zerteilt wird.

Diagramm wird geladen...

KI-Ebene: App request, Detect: regex floor + NER sidecar, Policy per entity, block or required missing, Fail closed, tokenize, Semantic tokens, safe text, Any LLM provider, Token repair: strict, repair, fuzzy, Rehydrate under output-channel policy, Output guard: catch model-generated PII, App response, PII-safe audit and metrics

Infrastruktur und Deployment

OGuardAI ist self-hosted und anbieterneutral, sensible Daten verlassen die Kundenumgebung also nie. Es wird als Docker-Images ausgeliefert und läuft überall, vom einzelnen Container bis zum Cluster mit mehreren Replikas.

Laufzeit und Dienste

Der Rust-Kern läuft als axum-HTTP-Server, als transparenter Provider-Proxy, der sich vor eine bestehende LLM-API setzt, und als Kommandozeilenwerkzeug oguardai, alles auf einem gemeinsamen Schutz-Kernel aufgebaut. Ein separater Python-Dienst stellt die NER-Modelle bereit. Es wird als Docker-Images mit einem vollständigen Docker-Compose-Stack ausgeliefert.

State und Skalierung

Sitzungen, Replay-Abwehr und Widerruf laufen bei einer einzelnen Instanz im Speicher oder über Replikas hinweg in einem gemeinsamen Redis, die Laufzeitumgebung skaliert also horizontal. Sitzungen werden im Ruhezustand mit AES-256-GCM verschlüsselt, und TLS terminiert am Server.

Authentifizierung und Zugriff

Die Authentifizierung unterstützt die Modi Dev, API-Key, JWT und OIDC mit Scope-Durchsetzung pro Route. Der Hop vom Server zum Detektor ist durch ein Shared Secret geschützt, und der Metrics-Endpunkt verlangt einen Admin-Scope, während die Health-Probes offen bleiben.

Observability

Prometheus-Metriken (Transform, Rehydrate, Detect, erkannte und blockierte Entitäten, Output-Guard- und Prompt-Security-Auslöser sowie Latenz-Histogramme) sind per Konstruktion frei von PII. OpenTelemetry-Tracing korreliert eine Anfrage über Detect, LLM und Rehydrate hinweg mit einer per Fingerprint gebildeten, nicht identifizierenden Trace-ID.

SDKs und Integration

Client-SDKs gibt es für TypeScript, Python, Go und Java, dazu ein MCP-Server in TypeScript und Framework-Adapter, sodass Anwendungen die Schutzschicht übernehmen, ohne den Kern anzufassen.

Diagramm wird geladen...

Infrastruktur und Deployment: Client SDKs: TS, Python, Go, Java, Rust server or proxy, MCP server, Python NER sidecar: GLiNER + spaCy, Redis: sessions, replay, revocation, Any LLM provider, Prometheus + OpenTelemetry

Engineering-Entscheidungen

A synchronous filter in the request and response path

Guardrails only work if they run before the model sees data and before output reaches a user. OGuardAI sits inline rather than as an after-the-fact audit, accepting a small, bounded latency cost for enforcement that cannot be skipped.

Reversible tokenization over blunt redaction

Redaction destroys the context a model needs to answer well. OGuardAI swaps sensitive values for structure-preserving tokens, so the model reasons over coherent text and never sees raw data. Restoration happens per output-channel policy, which makes the token vault the asset to secure.

Hot-reloadable YAML policies

Communication and data rules change faster than release cycles. Policies are YAML that reloads without a restart, so operations can tighten or relax rules live instead of waiting for a deploy.

Pattern matching and NER together

Regular expressions catch known formats; named-entity recognition catches contextual PII a pattern misses. Running both raises detection recall instead of betting on one technique.

Technologie

Backend
RustaxumPythonFastAPITypeScript
Infrastruktur
DockerRedisPrometheusGitHub Actions
KI / ML
PII detectionNER (GLiNER + spaCy)Semantic tokenizationPolicy engine
Frontend
Next.js

Kernergebnisse

  • GDPR-aware AI architecture by design, not by patching
  • Hot-reloadable YAML policies without restarts or redeployments
  • Reversible tokenization keeps LLM output quality while protecting data
  • The pattern is documented publicly in our engineering guides

Das Ergebnis

Eine wiederverwendbare, Framework-unabhängige Guardrail-Schicht, die DSGVO-gerechte KI von projektweiser Feuerwehrarbeit in Infrastruktur verwandelt. Ein proprietäres Oronts-Produkt, self-hosted und anbieterneutral, mit einer Architektur, die in unserem Data-Leakage-Guide dokumentiert ist.

What an OGuardAI deployment looks like

OGuardAI drops into a client's AI stack as the layer between the application and any model provider.

  • It sits between your application and any LLM, inside your infrastructure
  • Your content and data rules live as YAML that you control
  • EU or private hosting keeps data in your tenancy; the model never sees raw PII
  • Reversible tokens preserve output quality while protecting sensitive values
  • We integrate it into your pipeline and hand over a layer your team operates
Sprechen Sie uns anAlle Arbeiten