GDPR & UK GDPR
Summary
Under the EU GDPR and the UK GDPR, Infer acts as a processor, in practice a sub-processor, since inference requests reach us through our routing partner rather than from end users directly. We act only on instructions carried by the request itself, and we handle the content of a prompt for exactly one purpose: to return an inference response. This page is part of Infer's compliance program.
The unusual part is what happens next: nothing. Prompts and completions exist only in volatile memory for the life of a request and its transient session cache. They are never written to durable storage, never logged, never used for training, and never shared. Two GDPR principles that most vendors satisfy through policy and retention schedules, data minimisation and storage limitation, are satisfied here structurally, by an architecture that has nowhere to put the data, not by an aspiration to delete it later.
Infer is pre-launch and serves no production traffic yet. Figures and controls described across this site are design commitments until measured in operation.
How the architecture maps to GDPR principles
Article 5 sets the principles a processor's design has to survive. Below is what each one means at Infer, stated as the system behaves by construction:
| Principle | How Infer satisfies it |
|---|---|
| Purpose limitation | Request content is used solely to generate the response returned to the caller. There is no analytics path, no evaluation pipeline, and no product feature that consumes it for anything else. |
| Data minimisation | Infer receives only what the request carries. Nothing is enriched, joined, or copied out of the request, and no profile is built from it. Operational records keep metadata only. |
| Storage limitation | Content is never written to durable storage. Volatile state lives in GPU and host memory for the request and its session cache, and does not survive a replica restart. Metadata-only logs (timestamps, token counts, status codes, latency, hashed identifiers) are retained 30 days. |
| Security of processing (Art. 32) | TLS at the external edge; an encrypted overlay network between gateway and compute. A single authorized upstream API caller, credentialed and optionally IP-allowlisted. No internal tool, console, or export path surfaces content to personnel; debugging uses synthetic traffic only. |
| No secondary use or training | Content is never used to train, fine-tune, or evaluate models, and is never shared with a third party for their own purposes. |
| Transparency | Our handling is described in a published privacy policy and a published security overview, so a controller can describe our processing accurately in their own notices and records. |
International transfers
Processing occurs in the United States. A controller in the EEA or the UK therefore needs a valid transfer mechanism to send personal data through us.
A data processing agreement incorporating the European Commission's Standard Contractual Clauses, together with the UK addendum for UK GDPR transfers, is in legal preparation. The engagement covers module selection for our sub-processor position, the Art. 28 processing terms, and the technical and organisational measures annex, which is largely a restatement of the table above, since our measures are properties of the architecture rather than procedures layered on top of it.
Until that agreement is executed and available, controllers should treat Infer as pre-launch for regulated EU or UK personal data and contact us before routing it.
Data subject rights under zero retention
Zero retention changes what a rights request can meaningfully return, and we would rather state that plainly than imply capabilities we do not have.
A processor's job under Articles 12–23 is to assist the controller in responding to data subjects. Where a request concerns the content of a prompt or completion, after the response has been returned there is no content left to access, rectify, erase, port, or restrict: it was never written down. We answer such requests by explaining exactly that, in writing, so the controller can pass a truthful account to the data subject and close the request.
The records that do persist are operational metadata: timestamps, token counts, status codes, latency figures, and hashed identifiers, held 30 days. They contain no prompt or completion content and are not structured to identify a data subject, so they do not give us a way to locate an individual's data on request. Where a controller needs that stated formally for their own records, we will state it.
Rights requests about the account relationship itself (the routing partner's contact and billing data, for example) are handled by the controller who holds that relationship, and we assist as our agreement provides.
Status
Infer's processor readiness is underway. Three workstreams are in motion:
- DPA and Standard Contractual Clauses. Preparation with counsel is underway, covering the Art. 28 terms, the correct SCC module for our sub-processor position, the UK addendum, and the measures annex.
- Representative determination. Whether Infer requires an EU representative under Art. 27, a UK representative, or neither depends on whether we actively offer services to data subjects in those jurisdictions. That analysis is in progress and will be resolved before launch; where a representative is required, the appointment and its published contact details follow.
- Records and sub-processor disclosure. Our Art. 30(2) record of processing activities is being written alongside the sub-processor evaluation described in the security overview.
This page is updated as each of those completes, with the status line above changed at the same time.
Contact
For the data processing agreement, transfer documentation, or a controller-side questionnaire about our processing:
contact@infer.industries
Please include the jurisdiction and the role you act in, so we can answer against the right framework.