Data Processing Agreement

This agreement is between Radiant RX Ltd, trading as Mallard AI, registered in England and Wales, company number 15211321, registered office 45 Chaucer Close, Basingstoke, Hampshire, RG24 9DW, United Kingdom ("we"), and the business using our API ("you"). It applies when you use the API for a business.

It forms part of our Terms of Service and prevails over them on personal data. It applies under UK GDPR, and under EU GDPR where that applies.

For requests that reach us through a router, the data protection terms of our agreement with that router apply first, and this agreement fills any gap.

Questions about this agreement: privacy@mallardai.co.uk.

1. Roles

1. 1.1 You are the controller of the personal data in your requests, or a processor acting for your own customers.
2. 1.2 We are your processor, or your sub-processor where you act for others.
3. 1.3 Where you are a processor, you confirm that your controllers allow you to use us.

2. Subject matter, nature and purpose

1. 2.1 Subject matter and purpose: producing model output from your API requests. We process your data for no other purpose.
2. 2.2 Nature: automated processing in our servers' working memory (RAM), including the graphics cards' working memory, with zero data retention (clause 7). Working memory is the temporary memory a computer uses while it runs a task. It isn't storage: it's cleared as it's reused and when the computer restarts, and nothing in it is saved.

3. Duration

For as long as you use the API, and until clause 15 is complete.

4. Personal data and data subjects

1. 4.1 The personal data: any personal data that you or your users put in prompts, images or files, and the output derived from it. It may include special category or criminal offence data.
2. 4.2 The data subjects: your users, your customers' users, and anyone a request mentions or shows.
3. 4.3 We don't know or choose what is sent.

5. Your rights and duties

1. 5.1 You decide what is sent and why.
2. 5.2 You must have a lawful basis for it and give people any notice the law requires.
3. 5.3 You have the rights this agreement gives you: to instruct us, to object to new sub-processors, to information and to audits.

6. Instructions

1. 6.1 We process personal data only on your documented instructions: these terms and the API requests you send, including clause 11 on where we process it.
2. 6.2 If the law requires us to process it in any other way, we tell you before we do, unless that law forbids it on important grounds of public interest.
3. 6.3 We tell you at once if we think an instruction breaks data protection law.

7. Retention

1. 7.1 Zero data retention (ZDR): we don't store your prompts, images or outputs ("your content").
2. 7.2 Your content is processed only in working memory: on our gateway server while the request runs, and on our GPU server while it is processed. At busy times, a GPU server we rent from Nebius (Annex 2) can process it instead. It is never written to disk or to a database.
3. 7.3 To answer repeated prompts faster, the GPU server reuses its work on recent prompts and images: a prompt cache in the graphics cards' working memory and image caches in RAM. These caches are in working memory only: only the same API key can reuse them, later requests overwrite them, and a restart wipes them. They are never saved.
4. 7.4 If the model server hits an internal error, its error report can include a request's settings, such as its stop sequences or requested output format, and small fragments of its data (a 6 by 6 pixel sample of each image, part of an output), but never the prompt's text. It goes only to the GPU server's own log, which is kept in working memory, limited in size and wiped when the server restarts. Apart from such reports, we write no content to logs.
5. 7.5 Our gateway logs metadata for each request (no content, image links or IP addresses) and keeps it for up to 30 days. For billing, we also keep each API key's daily usage counts: requests and tokens, with no content. We hold both as a controller, under our Privacy Notice.

8. Confidentiality

1. 8.1 Only our director has access to your personal data in our systems. No staff or contractors do.
2. 8.2 The software tools our director uses to run the service, AI assistants included, are never given request content or your personal data.
3. 8.3 Anyone else we allow to process your data will first be bound to confidentiality in writing.

9. Security

We take the measures that Article 32 requires, including those in Annex 1, and won't reduce their overall protection.

10. Sub-processors and other providers

1. 10.1 Annex 2 lists the providers whose services we use to run the API, what each does and whether it has access to your data. Only one has: Nebius, whose GPU servers take requests at busy times.
2. 10.2 You give us general written authorisation to use them.
3. 10.3 We email you 30 days before we add or replace a provider that will handle your data, or start to process your data in a new place. Notices of changes go to the email address on your account or, for a router, to its provider contact.
4. 10.4 You may object on reasonable data protection grounds. If we can't resolve your objection, you may stop using the API without paying for use after the change.
5. 10.5 Before any sub-processor gets access to your personal data, we bind it by a written contract with data protection obligations that meet Article 28 of UK GDPR. We remain fully liable to you for how it meets them.
6. 10.6 Using the providers in Annex 2 doesn't reduce our duties or our liability to you under this agreement.

11. Location and transfers

1. 11.1 We process your data only in the United Kingdom. Our gateway runs on a virtual server in a London data centre, and our GPU server is in England. At busy times, requests may be processed on GPU servers we rent from Nebius in its London region (Annex 2).
2. 11.2 Our gateway server and our GPU server are joined by an encrypted tunnel that runs directly between them. If the direct path ever failed, our network provider's relay servers could carry the encrypted packets, which they can't read (Annex 2).
3. 11.3 We return output to you on your instructions, and make no other transfer: all processing is in the UK.
4. 11.4 We will not process your data outside the UK without notice under clause 10 and a safeguard the law accepts.
5. 11.5 Transfers from the EU to us in the UK rely on the EU's adequacy decision for the UK.

12. Data subjects' rights

1. 12.1 We don't store your content (clauses 7.1 to 7.4), so we usually have nothing to search.
2. 12.2 We pass any request we receive about your data to you within 5 working days, and help you answer it with the information we have.

13. Help with your other duties

We help you, with the information we have, to meet your duties on security, personal data breaches, data protection impact assessments and prior consultation with a supervisory authority.

14. Breaches

1. 14.1 We tell you about a personal data breach affecting your data without undue delay, and within 48 hours of becoming aware of it, with what we know then.
2. 14.2 We send updates as we learn more.

15. End

1. 15.1 When you stop using the API, we delete or return your personal data, at your choice, unless the law requires us to keep it.
2. 15.2 We don't store your content (clauses 7.1 to 7.4). Anything left in the caches is overwritten in normal use, or wiped when the server restarts.

16. Information and audits

1. 16.1 We give you the information you need to show that we meet Article 28.
2. 16.2 We allow and contribute to audits, including inspections, by you or by an auditor you appoint who is bound by confidentiality.
3. 16.3 Give us 30 days' notice of an audit. Audits take place no more than once a year, unless after a breach or when a regulator requires it.
4. 16.4 Audits are at your cost, and start with documents.
5. 16.5 Audits of any sub-processor we add follow its contract with us.

17. (Not used.)

18. Law

1. 18.1 English law governs this agreement, and the courts of England and Wales have jurisdiction.
2. 18.2 Where EU GDPR applies to your use of the API and requires this agreement to be governed by the law of an EU or EEA state, Irish law governs it for that purpose.

Annex 1: security measures

Zero data retention (clause 7): request content, any image we fetch and the caches exist only in working memory. We write no content to disk.

Connections

Callers connect over HTTPS (TLS 1.2 or 1.3) to our gateway server, where our own web server ends the encrypted connection. No third party ends it. The gateway passes each request to the GPU server through an encrypted WireGuard tunnel that runs directly between the two machines. The tunnel's network holds only these servers and the standby GPU servers (Annex 2).

API keys

API keys are stored as SHA-256 hashes, never the keys themselves. Each API key is shown to its customer once, when it is created, and its hash, first 8 characters and label are kept in our account database (Supabase, London). The gateway's own key hashes and secrets are in a file on the gateway server that only the root account can read, with a separate admin key.

Access

One operator, our director, runs our systems. No staff or contractors have access. The software tools our director uses, AI assistants included, are never given request content or customers' personal data. They may read our request metadata, which holds no content. Two-factor authentication protects every account we run the service with.

Gateway server

• Working memory: a request's content, while the request runs.
• Disk: the system, the gateway's code, its secrets and the metadata log. The server has no swap, and core dumps are disabled for the gateway and for our web server, so their working memory is never written to disk.
• Access: SSH by key only. A firewall allows only SSH, web traffic (ports 80 and 443) and the tunnel.
• Software: security updates install automatically. The gateway runs as an unprivileged user, sandboxed by systemd, with a cap on the working memory it can use. It can't reach private or internal network addresses, except its own machine and the GPU servers' tunnel addresses.

GPU server

• Where: our own server, in England. Physical access is limited to our director.
• Working memory: a request's content while it is processed, in the computer's RAM and the graphics cards' working memory. After the response, the caches below.
• Disk: its system disk is encrypted, and holds no request content. The server swaps only to compressed RAM, never to disk, and core dumps are disabled for the model server.
• Network: the model server accepts connections only on the tunnel address, so only our gateway server can reach it over the network.
• Updates: security updates are applied daily, except the kernel and the graphics driver, which we update by hand.

Caches

To answer repeated prompts faster, the GPU server reuses its work on recent prompts and images: a prompt cache in the graphics cards' working memory and image caches in RAM. They are never saved, and stay until later requests overwrite them or the server restarts. They are kept apart per API key, and per end user or session where the caller names one. Callers can't set their own image cache keys.

Logs

The gateway logs one line of metadata per request: the time, request ID, path, model, status, whether streamed, timings, token counts, the first 8 hex digits of the API key's hash, which cache scope applied and how many images it fetched. These lines are kept in the gateway server's system log for up to 30 days, and the last 500 also in the gateway's working memory. Our web server logs nothing about requests.

No prompt, output, image or image link is ever logged, and no caller's IP address. The model server's request logging is off. Its own log is kept in working memory only, limited in size and wiped at restart. Its error reports are the one exception to no content in logs: they can hold a request's settings and small fragments of its data, but never the prompt's text (clause 7.4).

Images sent as web links

Our gateway fetches them on the gateway server, never on the GPU server, and passes them on with the request. It fetches only from public addresses, on ports 80 and 443, at most 4 images a request and 10 MB each. The link is never logged.

Testing

We test zero data retention by sending marked test requests and searching every log and disk we control for the marker, before launch and after each change to the serving software.

Annex 2: sub-processors and other providers

One sub-processor, Nebius, takes requests at busy times. The other providers' services carry or support the API without access to your data.

These providers never receive request data:

• Namecheap: DNS for our domains.
• Let's Encrypt: our certificates.
• Google Workspace: our email, including support and privacy requests.
• Supabase: our account database, in London.
• Stripe: payments.
• Onelink: payments from outside the UK, the Channel Islands or the Isle of Man.
• Resend: our emails.

Supabase, Stripe, Onelink and Resend handle account and billing details under our Privacy Notice.