Our Approach To Privacy
Model Pond is a direct response to the problem of benefiting from AI without worrying about our data. We approach any retained information as a potential hazard both to us and to you, and go to extreme lengths to eliminate the risk of retention wherever possible.
Zero retention is central to the service and also a hard requirement for every listed provider.
What we keep
Requests are served and let go. A prompt and its response live for as long as it takes to answer them, and the service is built so that this is a property of the design rather than a promise about behaviour.
What we keep is what it takes to bill you: counters and amounts attributed to an API key and a target model, held against a billing period rather than with the time of an individual request. That is the whole of the record, worked back from the purpose it serves. The full list is on the gateway page.
The figures kept are those that calculate usage, at the level of totals for a billing period.
Cookies and accounts
Every item below is held because the service needs it to work. Minimisation is the design rule — narrow the purpose, and less has to be held — so each element answers to a purpose that requires it.
| Item | Detail | Held because |
|---|---|---|
| Cookie | A single cookie is used to track your login session. | A session has to persist between requests |
| Requests | Served and answered; the counters above are the record kept | Billing counts usage |
| Account | A username and a password | Sign-in needs a credential to check |
| Email address | You can register with a username instead of an email address. | A username carries the account, so contact details stay yours to give |
| Payment | A balance topped up by bank transfer | The balance has to be settled |
| Billing records | A payment is recorded against the balance it settles, kept apart from the account it tops up | Settling a balance needs the amount it carries |
The result is an account that signs in with a username and a password, settles a balance by transfer, and gives a name or an email address only if its holder chooses to. Personal data is collected where a stated purpose requires it; the purpose here is running an account and billing for usage, which a username, a credential, a balance and a set of counters cover between them.
That is a data-minimised design, and it is compatible with GDPR as it applies across the EU and EEA. Data minimisation is a requirement of the regulation, privacy by design and pseudonymous accounts are established practice under it, and it places no general requirement on an ordinary online service to hold a real name or an email address.
Zero retention as the default
Most gateways offer zero data retention as an opt-in filter. It is switched on per model group and, once enabled, it narrows the endpoints available to you.
Here the service runs in that state always. Retention terms are agreed with each provider before it begins serving, and every provider carried has met them, so the terms apply to each request by construction. Collection and retention are the same rule applied at two points: hold what the purpose needs, and hold it for as long as the purpose lasts.
| Retention | Model Pond | Typical gateway |
|---|---|---|
| Status | Required, always on | Conditional, opt-in |
| Granularity | A condition of serving any request | Set per model group |
| Verification | Checked before a provider serves | Carried on the assumption of retention |
Provider criteria
Every provider meets all of these before a request is routed to it. The criteria cover where the company sits, where the hardware runs, and what interest the company has in the traffic.
| Criterion | Why it matters |
|---|---|
| European-owned | The company serving the request answers to European law |
| European-domiciled | Its obligations sit with a company inside Europe |
| Infrastructure in Europe | Processing happens where those terms apply |
| European path end to end | The route to the provider keeps proxy and CDN layers inside Europe |
| Published retention policy | Explicit, public terms for what is kept and for how long |
| Runtime IP and ASN checks | Their public interfaces are checked as they are reached |
| Infrastructure businesses | Companies that earn their revenue from serving traffic |
The last of these is the narrowest filter. A provider whose revenue comes from serving traffic has that as its interest in a request; a company with models of its own has an interest in what the request contains.
Providers applying these terms implement GDPR
Our Infrastructure
We run our software on physical hardware with no third party hypervisors running underneath. These computers are configured to use Secure Boot using signing keys we control, into an operating system image and serving software we build. Every step is measured using the hardware Trusted Platform Module, and can be verified in the response headers of every request you make.
Our approach to third party networking infrastructure is identical: the first computer decrypting your request is ours. We do not use third party content distribution networks or load balancers.
Our Software
The data plane software and its build process is open to public inspection. A narrow interface exists allowing authentication, billing and abuse prevention to occur in a separate module we do not publish, but that module verifiably has no access to the user traffic or data.
Attestation
Attestation makes any change to the service visible. A change that went unpublished would show up as a mismatch between what runs and what is published, and anyone can see it.
Every copy of our software we run is also publicly released, along with the OS image each copy booted on. Both are public, so a third party can build the same thing from the same sources and check that what we operate is identical. The comparison is against a build someone else produced.
Attestation is anchored in hardware. The list of TPM keys belonging to the hardware we operate is published, and each response from the API carries a header containing a temporary key recently signed by the TPM, together with a signature over your request.
- The TPM keys of the hardware in service are published.
- Every API response carries a temporary key signed by the TPM.
- The same response carries a signature over the request it answers.
- The software and the OS image it booted on are public, so the running version can be compared with a build made elsewhere.
A signature over the request is what lets you tell a response from the service apart from one manufactured by something sitting in front of it.
Bulk requests
Batch jobs involve a file of requests large enough to be worth writing to disk. Such a file is encrypted under a key generated for that job and held only in memory. The file is readable for as long as that key lives: a restart clears the key, and the file on disk stays encrypted. Protection and disposal are the same mechanism.
Turnaround, billing and provider support for bulk work are described on the batch page.
Web search
Search is a request to a third party rather than to a model provider on this service. When it is used, the query text is sent to the search engine and the results needed to answer it are retrieved and passed to the model alongside your message.
Search therefore sits outside the provider terms that cover model inference. Treat search text as you would any query typed into a search engine.
The search provider and the terms it applies are still being settled; this section will name them once that is confirmed.
What to read next
The parts of the platform people usually read after this page.