Whitepaper


A public architecture summary explaining how DataSitr detects, transforms, and routes personal data today without widening the claim boundary beyond what the repo and current artifacts prove.

Current reference · 2026-04-29T14:40:52Z

1. Architectural purpose

DataSitr sits between customer applications and AI providers as a privacy gateway. Its purpose is to reduce uncontrolled raw-data transfer, not to replace legal review or to claim automatic regulator approval.

2. Detection layer

Detection is not regex-only. The runtime combines Presidio analyzers, spaCy for English text, Saudi-specific structural recognizers, and a configurable local Arabic NER backend for semantic entities such as person, organization, and location. Benchmark-gated alternatives such as official Presidio backends and GLiNER-assisted paths exist, but they are not public default-production claims unless the current benchmark artifacts justify them.

3. Transformation layer

4. Routing model

The policy engine chooses green, amber, red, or block based on identifiability, confidence, sensitivity, tenant policy, and the configured provider path. If the system cannot establish an acceptable route, it fails closed instead of silently downgrading controls.

5. Vault and rehydration

The vault is stateful, tenant-scoped, and encrypted at rest with AES-256-GCM. Rehydration only restores known tokens for the requesting tenant and request context, and it fails closed if unresolved placeholders remain.

6. Claim boundary

This paper describes how the product works today. It does not claim blanket HA, automatic failover, external certification, SDAIA approval, or final governance completeness. Use the trust page for the current proof boundary and the benchmark page for the current detector snapshot.