Skip to main content
If your LLM app processes EU personal data, three GDPR obligations land on the request path itself: keep personal data to the minimum the model needs (Art. 5), evidence where tool egress sends it (Art. 44), and honour a data-subject’s right to erasure (Art. 17). The GDPR pack turns those into enforced controls you install in one call — no policy authoring from scratch. This page is the gdpr llm landing: what installing the pack actually materialises, one concrete install flow, and how erasure works end to end. For the full content- and action-layer reference, follow the links rather than re-reading them here.

​
1. What the GDPR pack installs

Browsing the catalog is free for any workspace Member; installing is a paid-plan, workspace-Admin action (the same gate as going live — see Plan gating). One install materialises real, editable Guardrail and Firewall rows mapped to GDPR articles:
A PII guardrail that blocks the request when EU identifiers (IBAN, UK NHS number, German Steuer-ID, French NIR) are detected, so regulated data never reaches the upstream provider. It runs on the input stage. See Guardrails for the entity list and per-entity action overrides — you can switch a covered entity from block to mask after install.
A broader PII guardrail that hard-rejects requests containing emails, phone numbers, SSNs, credit-card numbers, or IPs, so special- category and ordinary personal data are caught together.
A logging guardrail that records every guardrail decision as processing evidence — feeding the signed report your auditor reads.
A firewall egress rule that audits the outbound destinations your tools report to the gateway, so a transfer assessment has a real trail of where data went. See Firewall for egress matching.
The pack is a starting point you own, not a black box. Every rule it writes is an ordinary guardrail or firewall row you can edit, reorder, or disable in the console afterward.

​
2. Install the GDPR pack (one concrete flow)

Install from the console under Compliance → Packs, signed in as a workspace Admin on a paid plan. The console drives the management route for you using your session — this is a UserAuth route, never a relay (sk-orca-…) key: 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Before you commit, the catalog tells you exactly which framework you’re mapping to — open it as a Member first: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Install into observe first. The materialised firewall egress rule can run audit-only so you watch real transfer destinations for a week before any of them are denied — see Observe vs enforce.

​
3. PII controls on the request

Data minimisation is the load-bearing GDPR control, and on the gateway it is a PII guardrail. By default the pack blocks the request on the input stage when EU personal data is detected — the request is rejected before the model sees it, so regulated data never reaches the upstream provider. Beyond the bundled EU entities, you can tune the guardrail the pack installed: pick exactly which entities to cover, switch a covered entity from block to mask, and add your own custom entity patterns. The full entity list, the per-entity action overrides, and the custom-entity options live in the Guardrails reference.
If you switch an entity to mask, that masking is live on the input stage but sandbox-evaluated on the output stage — live masking of model responses is on the roadmap. An output block is enforced on both streaming and non-streaming responses. Plan your minimisation around the input stage, where both block and mask are fully live.

​
4. Residency for your gdpr llm evidence

GDPR auditors ask where the evidence lives. OrcaRouter’s data-residency setting stamps every signed compliance report with a region (us / eu / uk / ap / cn / global) and withholds any report whose stamped region no longer matches the workspace. For an EU programme, declare eu before you generate the reports your auditor will rely on: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
Residency governs the report artifact, not where inference runs. It is not geo-pinning model traffic. The dedicated Data residency page covers the distinction and what happens when you change region after reports exist.

​
5. Right to erasure (Art. 17)

A real GDPR app needs a real erasure path, not a promise. On OrcaRouter, account self-deletion runs a grace-then-scrub flow:
StepWhat happens
RequestAccount soft-deleted immediately; login blocked.
GraceA 30-day cancellable window before the irreversible scrub.
ScrubPII scrubbed; cascade purge of request logs, guardrail matches, and firewall events.
The grace window is cancellable — and a user can still export their data during it before the scrub fires (data portability, Art. 20). After the window, the scrub is irreversible and cascades across the records that carry direct identifiers.
Request logs are governed separately from erasure: the default retention is 30 days, server-clamped to a 180-day maximum. Lowering it shrinks the window any personal data sits in logs at all — see Retention.

​
6. Prove it with a signed report

Once the pack is live, generate a compliance report: it is SHA-256 hashed and Ed25519-signed, so an auditor can verify it was produced by OrcaRouter and not altered — publicly, without a login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Anyone can verify the signature against the public key, and you can hand an auditor a scoped, time-boxed share link. The mechanics live in Signed report and Verify a report.

​
7. Where this fits

GDPR is one framework in the broader compliance loop — install a pack, observe it, enforce, declare residency, then ship signed evidence.

Right to erasure

The grace-then-scrub flow and the cascade purge in full.

Data residency

Region-stamped evidence, and why it is not inference geo-pinning.

Compliance overview

The full loop — install, observe, enforce, and ship signed evidence.

Guardrails

The content-layer reference — PII entities, masking, and overrides.
For the boundary between what the gateway guarantees and what stays yours under GDPR — declaring residency, classifying your data, triggering deletions — the Shared responsibility map puts the GDPR pack in context.