A single unauthorized inference request can expose personal data and trigger massive GDPR fines.
What GDPR expects from AI inference services
GDPR treats every operation that processes personal data as a "processing activity" that must be documented, justified, and secured. Article 5 demands purpose limitation, data‑minimisation, and storage‑restriction. Articles 30 and 32 require a detailed record of who accessed data, when, and under what legal basis, plus technical and organisational safeguards. When a data‑subject exercises their rights, access, rectification, erasure, or restriction, the controller must be able to locate the relevant processing records quickly (Article 12). Failure to produce this evidence can lead to fines of up to 4 % of global turnover.
Why inference workloads are a compliance hot‑spot
Inference services accept input (prompts, feature vectors) and return model outputs. If the input contains identifiers, health information, or any other personal data, the request itself becomes processing under GDPR. The output can also re‑expose that data, especially when the model is prompted to repeat or transform it. Because inference often runs behind autoscaling APIs, requests travel across multiple containers, and the underlying model may not retain data, many organisations assume they have no audit trail. That assumption is dangerous: auditors will still ask for a record of every request that touched personal data, regardless of whether the model persisted it.
The evidence GDPR auditors look for
- Proof of lawful basis for each request (consent, contract, legitimate interest, etc.).
- A log that ties the request to a specific identity, timestamp, and purpose.
- Details of any transformation or masking applied to the data before it left the system.
- Records of any human approval required for high‑risk queries.
- Storage of the log so it cannot be altered after the fact.
These items form the “record of processing activities” that GDPR mandates. Without a single point that captures them, each microservice would need to implement its own logging, masking, and approval logic, a costly, error‑prone approach.
What a compliant architecture must provide
The most reliable way to meet the GDPR evidence requirement is to place a unified, protocol‑aware gateway in front of every inference endpoint. That gateway must be able to:
- Authenticate the caller via OIDC or SAML and map group membership to a purpose.
- Enforce just‑in‑time (JIT) approvals for requests that exceed a risk threshold.
- Mask or redact personal identifiers in responses before they reach the client.
- Record the full request and response payload, the identity that issued it, and the outcome of any approval workflow.
- Persist the audit record outside the inference service so it survives scaling events and restarts.
When these capabilities sit on the data path, the gateway becomes the single source of truth for GDPR evidence.
How hoop.dev satisfies the GDPR evidence requirement
hoop.dev is an open‑source layer‑7 gateway that proxies connections to any supported target, including custom inference APIs. By sitting in the data path, hoop.dev becomes the only place where enforcement can happen. It provides the exact controls listed above:
- Identity‑driven access. hoop.dev validates OIDC/SAML tokens, extracts the user’s groups, and decides whether the request can proceed.
- Just‑in‑time approval. For queries flagged as high‑risk, hoop.dev routes the request to a human approver before it reaches the model, ensuring a documented lawful basis.
- Inline data masking. Sensitive fields identified in the response are redacted in real time, supporting GDPR’s data‑minimisation principle.
- Session recording. Every inference request and its corresponding response are captured, timestamped, and stored by hoop.dev for audit purposes.
- Audit trail for compliance. The recorded sessions are stored for audit purposes, giving auditors the evidence they need under GDPR.
Because hoop.dev handles these functions centrally, organisations no longer need to instrument each inference microservice individually. The gateway’s logs can be exported to a SIEM, a data‑retention store, or any compliance‑reporting tool, providing the evidence auditors demand.
Getting started with hoop.dev for inference compliance
To adopt hoop.dev for your inference workloads, follow the high‑level steps below. Detailed instructions are in the official documentation.
- Deploy the hoop.dev gateway using the Docker‑Compose quick‑start or your preferred orchestration platform.
- Configure an "inference" connection that points to your model serving endpoint. The gateway stores the service credentials; clients never see them.
- Enable OIDC authentication so that every request carries a verified identity token.
- Define masking rules for any personal identifiers that may appear in model responses.
- Set up JIT approval policies for high‑risk queries, linking them to a Slack or email approver group.
- Verify that session logs are being persisted and that they include the required GDPR fields.
For a walkthrough of the deployment process, see the getting‑started guide. For deeper information on masking, approvals, and audit‑log configuration, explore the learn section of the documentation.
Call to action
Visit the open‑source repository on GitHub to get the code, read the full docs, and contribute.
FAQ
Does hoop.dev make my inference service GDPR‑compliant?
hoop.dev provides the technical controls that generate the audit evidence GDPR requires. Compliance also depends on organisational policies, lawful bases, and how you use the data. hoop.dev is a strong building block, but you must still define the legal basis for each inference request.
Can hoop.dev mask data that the model returns?
Yes. hoop.dev can apply inline masking rules to response payloads, ensuring that personal identifiers are redacted before they leave the gateway.
Where are the audit logs stored?
hoop.dev persists logs in a location you configure outside the inference service, guaranteeing that the records survive scaling events and remain available for audit purposes.
