Oronts GmbH, Amtsgericht München HRB 288224 · https://oronts.com/portfolio/oguardai · Version 2026-06-12 · office@oronts.com
Tous les travaux
Produits Oronts2024Ongoing

OGuardAI

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

Client: Oronts GmbH
Parlons-enDémo en ligneLire le guide

En bref

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

Le défi

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.

Notre approche

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.

Architecture système

Chargement du diagramme...

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

Couche IA

OGuardAI est la couche de protection IA elle-même : un runtime Rust qui s'intercale entre une application et n'importe quel LLM, détecte les données sensibles, les remplace par des tokens sémantiques typés sur lesquels le modèle peut continuer à raisonner, et restaure les valeurs d'origine dans la réponse selon la politique définie.

Détection

Un socle d'expressions régulières écrit en Rust s'exécute systématiquement et repère les données à format fixe (email, téléphone, IBAN, carte bancaire, passeport, numéros fiscaux et de sécurité sociale, entre autres) dans des textes de n'importe quelle langue. Un sidecar Python ajoute la reconnaissance d'entités nommées (GLiNER et spaCy) pour les personnes, organisations, lieux et adresses dans environ vingt langues. Les correspondances qui se chevauchent sont fusionnées selon leur score de confiance, et une entité requise mais introuvable fait échouer la requête en mode fermé.

Tokenisation sémantique

Les valeurs détectées sont remplacées par des tokens sémantiques typés : un nom devient un token de nom et un IBAN devient un token d'IBAN. Le modèle conserve le contexte dont il a besoin au lieu de voir des champs vides. Les tokens sont dédupliqués et liés aux entités, avec deux schémas d'identité (aléatoire par session ou déterministe par corpus), et seul le texte tokenisé, donc sûr, est transmis au LLM.

Moteur de politiques

Les politiques sont du YAML déclaratif avec héritage. Elles décident, par type d'entité, s'il faut tokeniser, caviarder, bloquer ou autoriser, et, par canal de sortie, dans quelle mesure restaurer. Le noyau résout la politique effective à chaque requête, si bien qu'un même runtime peut appliquer des règles différentes pour une réponse de chat, un email ou un journal interne.

Réhydratation et robustesse des tokens

Au retour, une réparation des tokens en trois étapes (stricte, réparation et floue) restaure chaque token vers sa valeur d'origine à travers six modes de restauration et rejette les tokens hallucinés par le modèle. La restauration est déterministe et idempotente, et toute valeur révoquée revient systématiquement comme supprimée.

Sessions, sécurité des prompts et garde de sortie

Les sessions sont scellées avec AES-256-GCM ou adossées à Redis, avec rejet du rejeu, liaison par tenant et table de révocation. Une passe de sécurité des prompts analyse l'entrée à la recherche de tentatives d'extraction et injecte un préambule système durci, et une garde de sortie optionnelle effectue une seconde passe de détection sur la réponse du modèle afin d'intercepter les données personnelles générées par le modèle lui-même.

RAG, documents et streaming

La même protection couvre la génération augmentée par récupération (ingestion, requête, contexte et réponse, avec identité des tokens limitée au corpus et filtrage par niveau d'accès), l'ingestion de documents avec OCR et caviardage visuel des images et des PDF, ainsi que les réponses en streaming avec mise en tampon aux frontières de tokens, de sorte qu'un token n'est jamais scindé entre deux fragments.

Chargement du diagramme...

Couche IA: 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

Infrastructure et déploiement

OGuardAI est auto-hébergé et neutre vis-à-vis des fournisseurs : les données sensibles ne quittent jamais le périmètre du client. Il est livré sous forme d'images Docker et fonctionne partout, du simple conteneur au cluster multi-répliques.

Runtime et services

Le cœur Rust s'exécute sous forme de serveur HTTP axum, de proxy fournisseur transparent qui se place devant une API LLM existante, et d'outil en ligne de commande oguardai, le tout bâti sur un même noyau de protection. Un service Python distinct sert les modèles NER. Il est distribué sous forme d'images Docker avec une stack Docker Compose complète.

État et montée en charge

Les sessions, le rejet du rejeu et la révocation fonctionnent en mémoire pour une instance unique ou dans un Redis partagé entre répliques, ce qui permet au runtime de monter en charge horizontalement. Les sessions sont chiffrées au repos avec AES-256-GCM, et le TLS se termine au niveau du serveur.

Authentification et accès

L'authentification prend en charge les modes dev, clé API, JWT et OIDC avec application des scopes par route. Le saut entre le serveur et le détecteur est protégé par un secret partagé, et le point de terminaison des métriques exige un scope admin tandis que les sondes de santé restent ouvertes.

Observabilité

Les métriques Prometheus (transformation, réhydratation, détection, entités détectées et bloquées, déclenchements de la garde de sortie et de la sécurité des prompts, et histogrammes de latence) sont sans PII par construction. Le traçage OpenTelemetry corrèle une requête à travers la détection, le LLM et la réhydratation grâce à un identifiant de trace fondé sur une empreinte et sans caractère identifiant.

SDK et intégration

Des SDK clients sont fournis pour TypeScript, Python, Go et Java, aux côtés d'un serveur MCP TypeScript et d'adaptateurs de frameworks, de sorte que les applications adoptent la couche de protection sans toucher au cœur.

Chargement du diagramme...

Infrastructure et déploiement: 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

Décisions d'ingénierie

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.

Technologies

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

Résultats clés

  • 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

Le résultat

Une couche de garde-fous réutilisable et agnostique du framework, qui transforme l'IA conforme au RGPD d'un travail de pompier projet par projet en véritable infrastructure. Un produit propriétaire d'Oronts, auto-hébergé et neutre vis-à-vis des fournisseurs, avec l'architecture documentée dans notre guide sur les fuites de données.

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
Parlons-enTous les travaux