Why location alone is not enough for GDPR
Many assume that simply keeping a language model on‑premises automatically satisfies GDPR, but location alone does not guarantee lawful processing. The regulation demands accountability, transparent records of every personal‑data operation, and the ability to demonstrate data‑minimisation at every step.
GDPR expects organisations to keep a detailed log of who accessed personal data, when, and for what purpose. It also requires that any data that leaves the system be subject to consent, purpose limitation, and that the organisation can delete or amend that data on request. Without a centralised control point, these obligations are hard to meet.
Typical data flow for a self‑hosted model
In many deployments the model runs behind an internal API. Engineers authenticate to the corporate network, then send prompts directly to the model service. The service writes raw request and response payloads to ad‑hoc log files, or to a generic observability platform that does not understand the semantics of personal data. The model itself may emit embeddings that contain traces of user‑provided identifiers.
Because the model endpoint is reached without an intervening policy engine, the following gaps appear:
- No systematic audit of which prompts contain personal data.
- No inline masking of sensitive fields before they are stored or returned.
- No just‑in‑time approval workflow for high‑risk queries.
- No guaranteed replay of a session for a data‑subject access request.
Where the control gap appears
Most organisations already enforce identity with an OIDC or SAML provider. That step decides who a request is, but it does not enforce what the request can do once it reaches the model. The request travels straight to the model’s listening port, bypassing any centralised guardrails. Consequently, the infrastructure cannot produce the evidence that GDPR requires.
Introducing a layer‑7 gateway for GDPR evidence
hoop.dev provides a wire‑protocol gateway that sits between the authenticated identity and the model endpoint. By positioning the gateway on the data path, every prompt and response passes through a single enforcement point. The gateway can:
- Record the full session, including timestamps, user identity, and the exact payload exchanged.
- Apply inline masking to redact personal identifiers before they are logged or returned.
- Require just‑in‑time human approval for queries that match a high‑risk policy.
- Block commands that violate predefined safety rules.
Because hoop.dev is open source, you can host the gateway in the same network segment as the model, keeping the data path short while still gaining the auditability that GDPR demands.
How the gateway creates compliant evidence
The GDPR accountability principle is satisfied when an organisation can demonstrate:
- Purpose‑limited processing: Policies defined in hoop.dev describe which data categories are allowed for a given query type. Any attempt to exceed those categories is rejected before it reaches the model.
- Record‑keeping: hoop.dev records each session with the user’s identity, the exact prompt, and the masked response. These records are searchable and can be supplied to auditors.
- Data‑subject access: When a user requests their data, the recorded session can be replayed or exported, showing exactly what personal data was processed and when.
- Right to erasure: Because the gateway stores only masked logs, you can delete the original personal fields while retaining compliance‑relevant metadata.
All of these capabilities are described in the getting‑started guide and the broader learn section. The documentation explains how to define masking rules, configure approval workflows, and integrate with your existing OIDC identity provider.
FAQ
How does hoop.dev help with data‑subject access requests?
Each session is recorded with the user’s identifier. You can retrieve the masked transcript of any request, providing a clear audit trail that satisfies the GDPR right of access.
Does hoop.dev store personal data itself?
The gateway only stores the masked version of responses. Original personal identifiers are stripped before persistence, reducing the risk of accidental exposure and aligning with the data‑minimisation principle.
Can I keep using my existing IAM solution?
Yes. hoop.dev acts as a relying party for OIDC or SAML tokens. It validates the token, extracts group membership, and then enforces policies based on that identity.
By placing a transparent, policy‑driven layer in front of your self‑hosted model, you gain the audit evidence, control, and data‑privacy safeguards that GDPR expects.
Explore the open‑source repository on GitHub to get started.
