GDPR Compliance

Audience: Data Protection Officers, Legal Counsel, Compliance Teams

1. What Is OGuardAI's Role Under the GDPR?

OGuardAI is self-hosted software, not itself a GDPR actor. Controller and processor roles under the GDPR attach to an organization or other body that determines the purposes and means of processing, or that processes personal data on another party's behalf. They do not attach to a piece of software. The deploying organization determines OGuardAI's place in its architecture. When you run OGuardAI inside your own infrastructure, the software is a technical tool operating under your control as controller: it introduces no new party that determines purposes or means. Oronts does not become a processor merely by licensing the software, because in a self-hosted deployment Oronts does not process any personal data on your behalf. A separately engaged operator, for example a managed-hosting provider you contract to run OGuardAI, may be a processor depending on the actual arrangement, in which case an Article 28 contract with that operator applies.

2. Does OGuardAI Store Personal Data?

No persistent storage of raw personal data occurs.

• During request processing, raw values exist transiently in server process memory. They live inside the request and session objects and are dropped when those objects leave scope as the request completes. The runtime does not guarantee immediate memory zeroization: dropped values may remain in freed allocator pages until overwritten, and the operating system, not OGuardAI, governs when physical pages are reclaimed. Two configuration-specific exceptions widen where raw values transiently exist. If OCR is used, the runtime writes the raw image bytes and the extracted OCR text to short-lived temporary files on the local disk of the same host, so raw content touches disk (not RAM only) for the duration of that OCR call. Their removal is best-effort: the temporary input and output files are dropped at the end of the run, but deletion of the extracted TSV text file can be skipped on the read-failure and process-wait branches or fail outright, so an exceptional failure can leave a temporary TSV artifact on disk. If the optional Python NER sidecar is deployed, the raw text is sent to that separate process and held in its memory during detection; it runs inside the controller's own infrastructure and within the same trust zone, but it is not the server process.
• The sealed session blob (an AES-256-GCM encrypted mapping of tokens to original values) is returned to the calling application. With the default sealed (stateless) backend the server retains nothing after the response. The optional in-memory backend (development and testing) holds the raw token-to-value mapping in RAM only (it does not encrypt at rest). An expired entry becomes inaccessible at its TTL (a load returns nothing and evicts that entry) and is physically removed on the next access of the same session id or on a periodic sweep amortized across writes; absent either event it can linger in memory past expiry while remaining unreachable through normal loads. The optional Redis backend persists only AES-256-GCM ciphertext plus non-PII routing metadata (tenant, policy, and session ids, timestamps, language), never raw personal data, encrypted at rest. No backend writes raw personal data to disk.
• The entity revocation table stores only HMAC-SHA-256 hashes of revoked values. No raw personal data is stored in the revocation table.
• Audit logs record entity types, counts, and policy names. Raw personal data values never appear in logs. The audit event schema also reserves optional Art. 30 record-of-processing fields (purpose, legal_basis, data_category) as PII-free controlled labels, never derived from request content; the runtime does not currently populate them (there is no policy/config wiring to set them yet), so today they are absent from every event.

See Data Retention for the complete data lifecycle matrix.

3. Where Does Personal Data Flow?

Your Application (controller)
    |
    v
OGuardAI Runtime (self-hosted, under controller's control)
    |--- Raw PII exists ONLY here, transiently in RAM
    |
    +---> Tokenized text (no raw PII) ---> LLM Provider
    +---> Encrypted session blob ---------> Your Application
    +---> Audit event (no raw PII) -------> Your Log Infrastructure

Detected personal data that the policy does not whitelist does not cross the trust boundary to the LLM provider. The LLM receives only semantic tokens (e.g., {{email:e_001:2f8c1d64ab09}}) and safe metadata (entity type, language, formality, never actual values). Two scoping notes apply: a value the operator explicitly lists in a policy whitelist passes through unchanged (a deliberate configuration decision; the shipped strict policies have an empty whitelist), and a value no detector matches is not protected (see Guarantees and Non-Guarantees on detection completeness). If the optional Python NER sidecar is deployed, it also receives the raw text for detection; it runs inside the controller's own infrastructure and belongs on an internal network within the same trust zone.

4. Right to Erasure (Art. 17)

OGuardAI supports erasure through three mechanisms:

1. Session expiry. Sealed session blobs carry a configurable TTL (default: 1 hour), bound into the authenticated envelope. Once the expiry timestamp has passed, the runtime refuses to unseal the blob and returns a clean GUARDAI_SESSION_EXPIRED error, so the tokens can no longer be restored. Note this is a runtime enforcement check, not a cryptographic invalidation: the sealing key stays in the keyring, so if durable unrecoverability is the goal, combine expiry with key retirement (mechanism 3).
2. Entity revocation. Calling the revocation API marks a specific (entity_type, value) pair as permanently non-restorable within the caller's scope. Future rehydration requests return [DELETED] for that value. Relationship traversal is bounded to one within-session cascade: when rehydrate encounters a person previously revoked through the revocation API, the runtime also deletes the tokens in that same session whose metadata carries a belongs_to link to the revoked person's token (for example the email, phone, or address detected as belonging to that person). The cascade operates only over the token map of the session being rehydrated and only across explicit belongs_to links, so it does not reach values that were never linked to the person, nor the same person's values tokenized in a different session. Those unlinked and cross-session values still require explicit revocation. The bulk endpoint (POST /v1/revoke/bulk) does this in one call by taking the full list of values to erase.
3. Key retirement. The session keyring holds keys by ID and seals new blobs under the current key. Once a deployment stops serving a retired key ID, any blob sealed under it fails to unseal and returns GUARDAI_SESSION_EXPIRED, so those values can no longer be restored through the runtime. This is enforcement by key availability, not cryptographic destruction: the keyring is a plain in-memory map with no secure-erase guarantee, a configuration change takes effect when the process reloads its key set rather than intrinsically at the instant of the edit, and re-adding the same key material under the same ID restores decryptability. Durable unrecoverability therefore requires securely destroying every copy and backup of the retired key. A graceful rotation that keeps the old key in the ring instead lets in-flight sessions stay valid until their TTL expires, so retire and destroy the key, not merely rotate, when erasure is the goal.

The controller remains responsible for deleting personal data held in its own systems (databases, vector stores, application caches).

See Data Retention Section "Forget User X" for the step-by-step procedure.

5. Data Portability (Art. 20)

• Tokenization is deterministic within a session: the same value always produces the same token.
• Sealed session blobs are portable: they can be transferred between application instances that share the same encryption key.
• The transform API returns the tokenized text, per-entity metadata (token, entity type, confidence), and the sealed session_state blob. It does not return raw token-to-value mappings; original values are recovered only through the rehydrate API, gated by policy and output channel. Because OGuardAI keeps no extractable copy of the data, the controller fulfills Art. 20 portability requests from its own source systems.

6. Data Processing Agreement (DPA) Considerations

Because OGuardAI is self-hosted, the standard DPA landscape is simplified:

• No third-party sub-processors are introduced by OGuardAI in its default (sealed session, built-in detectors) configuration.
• If the optional Python NER sidecar is deployed, it runs within the controller's own infrastructure as a co-located service, not as an external sub-processor.
• The LLM provider (OpenAI, Anthropic, etc.) may be the controller's own sub-processor, depending on the actual arrangement and the provider's terms; the software cannot determine that legal role, so assess it per engagement. For the personal data OGuardAI detects and the policy does not whitelist, the runtime sends the provider only tokenized text, not raw values. That guarantee is scoped: values an operator whitelists pass through unchanged, values no detector matches are not protected, and if the proxy's remote-image-URL opt-in is enabled the pixels behind a remote image are forwarded without an OCR scan. Assess those configured paths when relying on this control.
• Standard Art. 28 DPA clauses (purpose limitation, confidentiality, assistance to the controller, deletion on termination, audit rights) are contractual and organizational duties, not properties that self-hosting by itself satisfies. An Article 28 contract is required only where a distinct processor is actually engaged. The technical controls OGuardAI provides (policy-driven data minimization, key and session lifecycle, PII-free audit events, access control) can support an organization's Article 28 obligations where such obligations apply, but they neither create nor discharge a DPA. Whether a DPA is required depends on the parties and the operating arrangement.

7. Data Protection Impact Assessment (Art. 35)

When conducting a DPIA for AI systems that process personal data, OGuardAI provides the following controls:

OGuardAI also supports shadow mode (dry-run), allowing the DPIA team to evaluate the system's detection and tokenization behavior on representative data before enabling active protection. Shadow mode returns a redacted comparison (a fingerprint hash plus length and entity-count deltas), not raw PII, and it is a dev-only diagnostic that the runtime rejects in production as a fatal validation error. It is a staging-only evaluation aid, not a production compliance control.

8. Summary for DPO Review

9. Related Documentation

• Compliance Controls Mapping: GDPR, HIPAA, SOC 2, PCI DSS article-by-article mapping
• Data Retention and Privacy: Complete data lifecycle, deletion procedures, retention policies
• Guarantees and Non-Guarantees: Explicit statements of what OGuardAI does and does not guarantee
• Security Whitepaper: Trust boundary model, encryption, authentication, tenant isolation