Data Processing Addendum

Version 1.0. First published 5 August 2026.

This Addendum is part of the Terms of Service between you and CYANKIWI LTD (company number 16974010, registered office 64 Nile Street, International House, London N1 7SR). It applies automatically whenever we process personal data on your behalf. You do not sign it, request it or tick a box for it; if you send us personal data, it is already in force between us. It is what UK GDPR Article 28 requires to be in writing before that happens.

It is deliberately short. Most of the obligations below are easy for us to meet because of how the platform is built rather than because of what we promise: we do not store the content of your requests, so most of what a processor agreement normally has to arrange for simply does not arise. Where that is not the whole truth, this document says so rather than rounding up.

If you need this signed as a separate countersigned document, email privacy@cyan.kiwi. Otherwise it binds on the same terms as the rest of the agreement, and no signature is needed.

1. Definitions and roles

Content Data means the prompts, messages, system instructions, tool definitions and files you send to the API, and the completions returned to you: the Customer Content of the Terms as it flows through the Service.

Account Data means the data we hold to run your account: your Firebase user identifier, email address, sign-in method, assent records, API key records, per-request usage metadata, payment records and infrastructure logs.

Applicable Data Protection Law means UK GDPR and the Data Protection Act 2018, and EU GDPR where it applies to your use of the Service.

Roles follow the facts, not the label. Article 28(10) treats a processor that decides the purposes and means of a processing operation as a controller for that operation, so we have allocated the roles by what actually happens:

• For Content Data you are the controller, or you are a processor acting for another controller. We are your processor, or your sub-processor, and we process it only to generate and return the response. If you are a reseller, an aggregator, or otherwise an intermediary, that is the case we mean: we do not assume your counterparty is the controller.
• For Account Data we are a controller in our own right. We decide what to collect, how long to keep it, what security and abuse decisions to take on the strength of it, and what to publish as aggregate service metrics. Calling ourselves a processor for that would be wrong. What we do with Account Data is described in the Privacy Notice, which is a transparency notice rather than part of this Addendum; your rights over Account Data come from Applicable Data Protection Law directly.

This Addendum therefore governs Content Data. It does not turn us into your processor for Account Data, and nothing in the Privacy Notice reduces an obligation this Addendum imposes.

You warrant that you have the lawful basis, notices and rights necessary for us to process the Content Data you send us.

2. Subject matter of the processing

Set out in Annex I.

3. Our obligations as your processor

3.1 We process only on your documented instructions

We process Content Data only on your documented instructions, including as to international transfers. Your instructions are: this Addendum, the Terms of Service, and the API requests you make. We will not process Content Data for any other purpose. If we are required by law to process it otherwise, we will tell you before doing so unless that law prohibits us from telling you.

We will inform you if, in our opinion, an instruction infringes Applicable Data Protection Law.

3.2 We do not retain Content Data, and that is an obligation, not a description

We will not write Content Data to any database, object store, spend record, analytics system or backup that we operate. This is a commitment you can hold us to, not merely a statement about the current build.

Two qualifications, both real:

1. Error text in infrastructure logs. When a request is rejected or fails, the resulting error message is written to our infrastructure logs, which are held for 30 days, and can contain limited request data. We do not put it there deliberately and we do not read those logs for content; anything that lands there is deleted with the logs after 30 days.
2. Our prompt cache. Our inference engines keep an in-memory prompt cache. Cached content is never written to a database or to disk, and a cache hit is visible to you in the cached_tokens field of the usage object and billed at the cache rate.

We will not use Content Data to train, fine-tune, evaluate or improve any model or service, and we do not offer an opt-in that would change that. No sub-processor is permitted to do so either.

3.3 Confidentiality of personnel

Everyone we authorise to process Content Data or Account Data is bound by a duty of confidentiality, whether by contract or by professional obligation, and access is limited to those who need it to run the Service.

3.4 Security

We implement appropriate technical and organisational measures under Article 32. The binding measures are Annex III of this Addendum, below, in this document rather than incorporated from elsewhere. We may improve or change the measures over time provided we do not materially reduce the level of protection below Annex III.

The Trust Center describes our current security posture informally. It is informational: where the Trust Center and Annex III differ, Annex III is the commitment, and nothing published there reduces it.

3.5 Sub-processors

You give us general written authorisation to engage sub-processors. The current list, what each one does, what data it receives and in which role is published at the sub-processor register, which is Annex IV of this Addendum: a schedule to it, not a separately accepted document. The register’s URL is stable, and its change history is kept on the page itself.

Changes. We inform you of an intended new or replacing sub-processor for Content Data before it starts processing, by a dated entry in the register’s “Change notices” section stating what is changing and the date it takes effect; we also write to account holders at their registered email address when we publish one. You may object on reasonable data protection grounds by writing to privacy@cyan.kiwi before the stated effective date. We will work with you in good faith to resolve the objection; if we cannot, you may terminate, and clause 15 of the Terms of Service governs your balance.

We impose data protection obligations on each sub-processor by accepting that provider’s data processing terms, and we assess those terms against the measures in Annex III; where a specific measure differs materially, we record it on the register. We remain fully liable to you for each sub-processor’s performance.

3.6 Helping you answer data subjects

Because we do not retain Content Data, there is usually nothing in it for us to search, export, correct or delete on request, and no amount of assistance from us can produce what does not exist. The exception is the error text in clause 3.2, which is searchable while it exists.

For Account Data, we will give you reasonable assistance, taking into account the nature of the processing, to locate, export or delete data we hold. If a data subject contacts us directly about data we process for you, we will not respond substantively; we will tell them to contact you, and tell you promptly.

3.7 Helping you with Articles 32 to 36

We will give you reasonable help with security, breach notification, data protection impact assessments and prior consultation, taking into account the nature of the processing and what we actually know. In practice that means the information in this Addendum, the Privacy Notice and the Trust Center, plus answers to specific questions at privacy@cyan.kiwi.

3.8 Personal data breaches

If we become aware of a personal data breach affecting personal data we process for you, we will notify you without undue delay. That is the statutory standard, it cannot be watered down, and we do not restate it as a fixed number of hours. We become “aware” when we have a reasonable degree of certainty that a security incident has occurred and that it affects personal data. The clock runs from that point, not from the first unconfirmed alert, and the investigation that gets us there is itself run without undue delay.

The notice will describe what we know: the nature of the breach, the categories and approximate number of records affected so far as we can tell, the likely consequences, and the measures taken or proposed. Where we cannot provide everything at once we will provide it in phases without undue further delay. We will cooperate with you and take reasonable steps to contain and remediate.

Notifying you is not an admission of fault by either of us.

3.9 Deletion or return at the end of the Service

At the end of the Service, you choose whether we delete or return the personal data we process for you, and we give effect to your choice without undue delay after your written request. Absent a choice, we delete.

There is little to return: we hold no Content Data (subject to clause 3.2). What exists is Account Data, and it can be exported to you on request.

Four exceptions:

1. Backups. Our database platform keeps automated backups and a short point-in-time-recovery window. Deleted rows persist there until they age out of that cycle. We do not restore backups to recover deleted data.
2. Statutory accounting records. Payment records and the usage records that evidence what you were charged are kept for six years under UK tax and company law. We cannot delete these on request.
3. Legal hold. Where we are required to preserve records by law or by a competent authority’s direction, we keep those records and tell you if we are permitted to.
4. Aggregate figures. Statistics that no longer identify you or your users are not deleted, because they are no longer personal data.

Deletion is performed on request, without undue delay.

3.10 Information and audits

We will make available the information reasonably necessary to demonstrate compliance with Article 28, and allow for and contribute to audits and inspections by you or an auditor you mandate. That right is yours by statute and we do not purport to remove it. We do ask you to exercise it proportionately:

• Ask first. In most cases the published documents plus written answers will settle the question, and we will answer within a reasonable time.
• If they do not, you may audit. Give us 30 days’ written notice, no more than once in any 12 months except following a personal data breach or a regulator’s direction, during business hours, without unreasonable disruption.
• An auditor you mandate must not be our competitor and must be bound by confidentiality.
• Each party bears its own costs.
• An audit cannot extend to another customer’s data, or to a sub-processor’s premises, which we have no right to grant.

3.11 Aggregate service metrics

We publish per-model performance statistics at a public endpoint. What is published is a whole-service aggregate. Nothing published identifies any individual customer, request or message content.

4. International transfers

CYANKIWI LTD is established in the United Kingdom. Two different transfers happen around this Addendum, and they must not be conflated: your data coming to us, and our onward transfers to the sub-processors in Annex IV. This clause takes them in turn.

4.1 Your data coming to us

If you are in the UK, your sending Content Data to us is not a restricted international transfer at all.

If you are in the EEA, the European Commission renewed its adequacy decisions for the UK on 19 December 2025, running to 27 December 2031, so Content Data can reach us without additional safeguards for as long as that decision stands.

Fallback, agreed now against adequacy lapsing: if and for so long as no adequacy decision covers the transfer, the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated into this Addendum and apply to EEA-origin transfers from you to us, with you as data exporter and CYANKIWI LTD as data importer: Module Two where you are a controller, Module Three where you are a processor; the optional docking clause (Clause 7) included; the Clause 9(a) option being general written authorisation with the notice process in clause 3.5 of this Addendum; the optional redress language in Clause 11 not included; for Clause 17, the law of Ireland; for Clause 18, the courts of Ireland. Annexes I, II and III of the Clauses are completed by Annexes I, III and IV of this Addendum as described in Annex II below. The English governing-law clause in the Terms does not reach the Clauses and does not override those choices. For UK-origin transfers in the same lapsed-adequacy scenario, the UK International Data Transfer Addendum to the EU Standard Contractual Clauses (version B1.0) applies on the same completions, with the tables populated from the same Annexes, and it modifies the governing law and forum in the way that instrument itself provides.

4.2 Our onward transfers to sub-processors

Our onward transfers land in the United States. The inference providers, RunPod, Inc. and Modal Labs, Inc., are United States companies we contract with directly, and our platform provider is contracted through Google Cloud EMEA Limited, which engages its US parent as a sub-processor. These transfers are made under our agreements with those providers. You are not a party to those transfer instruments, and this Addendum does not make you one; what you have instead is clause 3.5: we remain fully liable to you for the sub-processors we choose.

For those transfers we rely on the mechanism each provider’s own data protection terms actually make operative (the Standard Contractual Clauses with the UK Information Commissioner’s International Data Transfer Addendum, or an active certification under the EU-US Data Privacy Framework and the UK Extension), rather than assuming a single mechanism covers them all. The per-recipient mechanism actually in force is recorded on the sub-processor register, and we check each certification on the live Data Privacy Framework list rather than assuming it. For Content Data the recipients are the providers of the serverless GPU infrastructure on which our inference stack runs; the register records where that capacity is located.

The transfer risk assessment for these transfers, which applies the “data protection test” in the Data (Use and Access) Act 2025 for UK-origin data, is ours to carry out and document, and we do.

5. Liability

Nothing in this Addendum limits either party’s obligations under Applicable Data Protection Law, and nothing in any document between us caps what a regulator can fine either party. As between you and us, liability for claims under this Addendum is governed by clause 21 of the Terms of Service: a single statement, kept in one place so the two documents cannot drift apart. That clause carves out of the cap the sums either party becomes liable to pay to a data subject or to a regulator as a direct result of the other party’s breach of this Addendum.

6. Order of precedence

Where this Addendum conflicts with the Terms of Service on the processing of personal data, this Addendum governs. The Privacy Notice is not part of the agreement and cannot conflict with this Addendum; where its description and this Addendum’s commitments differ, the commitments here are what bind us.

Annex I: description of the processing

Subject matter. Provision of a large language model inference API.

Duration. For Content Data, the lifetime of each API request. For Account Data, the periods published in the Privacy Notice.

Nature and purpose. Receiving a request, relaying it to a model served by our own inference stack running on serverless GPU infrastructure from the providers in Annex IV, and returning the response. Recording usage metadata to bill and to operate the Service.

Categories of data subjects. Your personnel who hold accounts and API keys; any individual whose personal data you or your users include in a request.

Categories of personal data. Whatever you choose to send. We do not restrict or inspect the content of requests, so we cannot enumerate this for you; you determine it. On our side, account identifiers, email addresses, assent records, API key records, per-request usage metadata, payment records and infrastructure logs.

Special category data. Not requested, not required, and not something the Service is designed for. The Terms of Service prohibit sending protected health information and payment card data. We do not offer a business associate agreement and we have no PCI assessment.

Frequency. Continuous, for as long as you use the API.

Annex II: transfer mechanisms

Clause 4 identifies the two transfer legs and the mechanism for each.

For the clause 4.1 fallback Clauses (you to us, only while no adequacy decision covers the transfer): the data exporter is you and the data importer is CYANKIWI LTD; the module, governing law and forum selections are those made in clause 4.1. Annex I of the Clauses (the description of the transfer) is completed by Annex I above; Annex II of the Clauses (technical and organisational measures) by Annex III below; Annex III of the Clauses (the list of sub-processors) by Annex IV below.

For our onward transfers (us to each sub-processor): the exporter is CYANKIWI LTD and the importer is the provider entity named on the sub-processor register; the operative mechanism per recipient is recorded there and executed in our agreement with that provider, per clause 4.2.

Annex III: technical and organisational measures

The binding Article 32 measures. Stated as commitments; the Trust Center describes the same system informally, and nothing there reduces this Annex.

Encryption in transit. All customer traffic to api.cyan.kiwi and cyan.kiwi is encrypted with TLS. Traffic between our own services runs inside Google Cloud’s network, and traffic from our platform to the inference machines is encrypted in transit.

Encryption at rest. All customer data at rest in our systems (databases, secrets, logs) is encrypted with provider-managed keys. Content Data is not written to the inference machines’ storage at all (clause 3.2), and the storage those machines do have is encrypted under the host provider’s platform encryption.

Inference hosts. Inference runs on serverless GPU infrastructure from the providers in Annex IV. We operate our own inference stack on that infrastructure; each provider’s handling of it is governed by our agreement with that provider and the transfer mechanisms in clause 4.2.

Content minimisation by architecture. Prompts and completions are not written to any datastore we operate (clause 3.2, including its two stated exceptions: error text in logs and the in-memory prompt cache). No request or response content is written to the spend record. End-user identifiers offered by client libraries are not captured. Privacy-critical serving configuration is verified as part of our release process.

Credential handling. Customer API keys are stored only as hashes; plaintext is shown once at creation and cannot be recovered. Dashboard authentication is delegated to a managed identity provider; we hold no password material. Service credentials are held in a managed secret store and are never committed to source control. The inference engines’ endpoints require key authentication.

Access control. Access to production systems, including the inference machines, is limited to personnel who need it to run the Service, under the confidentiality duty in clause 3.3. Services run under dedicated service accounts rather than default identities. Administrative access is scoped to the minimum necessary.

Release gates for inference engines. An inference engine configuration reaches customer traffic only after passing documented internal release gates.

Change management. Changes reach production through a controlled, scripted release process, and privacy-critical configuration is re-checked before release.

Logging and retention. Infrastructure logs (source IP, user agent, path, status, timing and error messages; no request or response bodies) are retained for 30 days. Per-request usage metadata is deleted automatically after 400 days. Payment and accounting records are kept six years.

Backups and recovery. The customer database is backed up automatically with point-in-time recovery. Backups are not restored to recover deleted data.

Availability. Continuous availability monitoring with automated probes, operated for our own operations (no contractual service level; clause 7 of the Terms).

Incident response. Security incidents affecting customer data are investigated, contained and notified per clause 3.8 (without undue delay), and to the Information Commissioner’s Office within 72 hours where we are the controller and the threshold is met.

Vulnerability reports. security@cyan.kiwi is published, with rules of engagement, at the Trust Center.

Personnel. Personnel authorised to process data are bound by confidentiality and access is need-based (clause 3.3).

Annex IV: authorised sub-processors

The sub-processor register, as amended under clause 3.5. The register separates the providers that process Content Data on your behalf from the vendors that process only Account Data, for which we are the controller; your general written authorisation under clause 3.5, and this Annex, cover the former.