Data Privacy (GDPR)

Data Privacy gives a Data Protection Officer (DPO) the tools to satisfy GDPR subject-rights requests against a memory bank: erase a data subject, export everything Hindsight holds about them, set automatic retention limits, and keep an auditable record of every privacy action. EU personally identifiable information can also be redacted at write time so it never lands in a memory in the first place.

Enterprise feature

Data Privacy is available on Enterprise plans. If you don't see the Data Privacy tab on a bank, or the Privacy Events page in your organization, book a call or contact your Hindsight representative to enable it for your organization. Until it is enabled the surface renders in a locked / contact-sales state.

Where it lives

• Data Privacy tab — per bank, under the bank's profile. Organization owners manage erasure, retention rules, and exports here.
• Privacy Events — an organization-wide ledger of every privacy action (erasure, export, retention run) with its actor, reason, timestamp, and counts. Receipts are retained indefinitely as your compliance record — they survive the memories they describe.

Identifying a data subject

Hindsight does not parse names or emails out of memory content. A "subject" is whoever you tag as one. Tag every memory about a person with a stable subject tag, for example:

gdpr:subject:user:alice-12345

Erasure, export, and retention all operate on these tags, so consistent tagging at retain time is what makes subject rights work later. The gdpr:* tag namespace section below covers the optional lawful-basis and category tags that enrich a DSAR export.

Right to erasure (Art. 17)

Erasure is a two-step, DPO-safe flow so a destructive delete is never one click:

1. Preview (dry run). Runs the erasure against the subject's tags without deleting anything and returns the counts it would remove plus a short-lived preview token.
2. Execute. Re-submit with the preview token to confirm. Hindsight verifies the request matches the preview, consumes the token (single use), performs the delete, and writes an erasure receipt to Privacy Events.

Erasure removes the subject's memories and cascades to the derived data that referenced them (stale observations are swept, affected mental models are handled per your policy). A repeat of the same erasure within a 24-hour window returns the original receipt instead of re-running — so an accidental double-submit is safe.

Retention policies

Retention rules automatically age out data you no longer have a basis to keep. Rules are written in a sentence-shaped editor on the Data Privacy tab; each rule has:

• a scope — which memories it applies to (by tag), e.g. all gdpr:subject:user:*;
• a trigger — either no activity (not recalled within N days) or age (created more than N days ago);
• an action — erase the matching memories when the trigger fires.

Hindsight evaluates active rules on a recurring schedule and records each run in Privacy Events, so you have proof that a retention limit is actually being enforced. Rules ship disabled; nothing is erased until you enable retention on the bank.

Data subject access requests (Art. 15)

A DSAR export returns everything Hindsight holds for a subject as a signed envelope:

• the subject's memories (optionally including invalidated ones);
• observations derived from them;
• a mental-model snapshot;
• processing context — the lawful bases, categories, and purposes aggregated from the subject's gdpr:* tags;
• honest disclosure notes (e.g. that missions and policies shown are those active at export time), so the envelope is safe to hand to a regulator.

Small subjects return the envelope inline as JSON. Large subjects return a 202 and a job you poll until it completes, at which point you get a download link. Every export writes a receipt to Privacy Events.

EU PII redaction

The EU PII detector pack redacts European personal identifiers at retain time, before content is stored — so the plaintext identifier never enters the memory bank. It covers 12 checksum-validated identifiers, including IBAN, UK NHS number and National Insurance number, EU VAT, German Personalausweis, French NIR, Dutch BSN, Spanish DNI/NIE, Italian Codice Fiscale, E.164 phone numbers, and ICAO 9303 machine-readable-zone passport data.

It is enabled per bank as a Memory Defense rule (on: eu_pii, action: redact) and gated on the memory_defense.eu_pii entitlement. See Redaction and Other Detectors for how Memory Defense rules and redaction work in general.

The gdpr:* tag namespace

Beyond the subject tag, an optional closed-vocabulary namespace lets you record the lawful basis and data categories on each memory, which the DSAR export then aggregates into the envelope's processing context:

Tag	Meaning (GDPR article)
gdpr:subject:<id>	The data subject the memory concerns
gdpr:basis:<basis>	Lawful basis for processing (Art. 6) — e.g. contract, consent, legitimate_interest
gdpr:purpose:<purpose>	Purpose of processing (Art. 5(1)(b))
gdpr:category:<category>	Special-category data (Art. 9), when applicable

Tag validation can run in warn-only or strict mode per bank; in strict mode a retain with an unknown vocabulary value is rejected so tag hygiene stays clean.

Audit trail

Every action above — preview, erasure, retention run, and export — writes a row to Privacy Events with the actor (the authenticated user's email, or the API key name for programmatic calls), the reason, the counts, and a checksum. This is the DPO's evidence that a request was handled, and it outlives the data it describes.