Sub-processor Register

Version 1.0. First published 5 August 2026.

This page is Annex IV of the Data Processing Addendum: the general written authorisation for the sub-processors that handle Content Data, and the notice mechanism for changing them. It is a schedule to the Addendum, not a separately accepted document, and this URL is stable: link to it, and check the “Change notices” section at the bottom for history.

It also lists, separately and for transparency, the vendors that process only Account Data, for which we are the controller. Keeping the two apart matters: your authorisation under the Addendum covers the first group; the second group is our own controller responsibility and is disclosed in the Privacy Notice.

1. Sub-processors of Content Data

These providers process your prompts and completions on our behalf. They are what clause 3.5 of the Data Processing Addendum authorises.

2. Processors of Account Data (we are the controller)

These vendors process the account, billing, usage and log data described in the Privacy Notice. We are the controller for that data; these engagements are ours, not processing “on your behalf”.

The contracting entity for each provider is the one identified in that provider’s terms applicable to our account, and each is engaged under that provider’s standard data protection terms. We assess those terms against Annex III of the Data Processing Addendum; where a specific measure differs materially from Annex III, it is recorded on this page. Nothing is recorded under that rule today.

Where inference runs

Inference runs on cyankiwi’s own inference stack, on serverless GPU capacity in the United States provided by RunPod and Modal. We do not offer a per-customer choice of region. This section is the canonical statement of where inference runs; every other page that mentions locality points here.

Each provider operates the underlying infrastructure on which our workloads run. Its handling of that infrastructure is governed by our agreement with it, its data protection terms, and the transfer mechanisms below.

Prompt caching. Our inference engines may hold recently processed prompt content in an in-memory cache to speed up repeated requests. Cached content is never written to a database or to disk. A cache hit is reported in the cached_tokens field of the usage object, and cached input tokens are billed at the cache rate.

Content screening. We do not currently run content screening in the serving path, and no hosting provider screens Content Data on our behalf; clause 5 of the Terms of Service states that position and how it could change.

Transfer mechanisms, per recipient

Clause 4.2 of the Data Processing Addendum explains whose transfers these are (ours, under our vendor agreements).

Our contracting counterparty for the platform (the API, databases, secrets, logs, hosting and authentication) is Google Cloud EMEA Limited (Dublin). Data reaching us from the UK to it is not a restricted transfer, because the UK’s adequacy regulations cover the EEA; what needs a transfer mechanism is the onward leg to Google LLC, its US parent, which it engages as a sub-processor. The inference providers are different: RunPod, Inc. and Modal Labs, Inc. are United States companies we contract with directly, so each of those transfers is a direct restricted transfer from the UK to the United States. The operative mechanism per recipient:

• Google. Google Cloud’s data processing terms apply an alternative transfer solution where Google has adopted one, and the Standard Contractual Clauses otherwise. Google LLC has certified to the UK Extension to the EU-US Data Privacy Framework and adopted it for UK personal data going to and onward from the United States, so that is the operative leg, with the Clauses applying to onward transfers elsewhere. Firebase Hosting sits under Google’s separate Firebase data processing terms, which take the same shape: a transfer solution Google has adopted where available, and Google’s Standard Contractual Clauses otherwise. Google Workspace is governed by its applicable data processing terms and uses Google’s adopted transfer solution where available, with the applicable Standard Contractual Clauses otherwise.
• RunPod. We engage RunPod under its standard data processing agreement. That agreement does not rely on a Data Privacy Framework certification: the operative mechanism it makes applicable is the EU Standard Contractual Clauses (Module Two, governed by the law of Ireland) together with, for UK-origin transfers, the UK International Data Transfer Addendum to the EU Standard Contractual Clauses (version B1.0, governed by the laws of England and Wales). Verified against the published agreement on 3 August 2026.
• Modal. We engage Modal Labs under its data processing addendum. That addendum does not rely on a Data Privacy Framework certification: it incorporates the EU Standard Contractual Clauses, applying the module that matches the parties’ roles (Module Three, processor to processor, where we act as a processor), and governs UK-origin transfers by the Clauses as conformed to UK law under the UK International Data Transfer Addendum. Verified against the published addendum (effective 31 October 2025) on 3 August 2026.
• Stripe: the certified entity is Stripe, LLC, behind Stripe Payments UK Ltd, the UK-facing contracting entity.

We check each certification on the live Data Privacy Framework list rather than assuming it. Google LLC and Stripe, LLC were each verified as actively certified, including under the UK Extension, against the list published on 30 July 2026. RunPod and Modal do not claim a certification and their terms make the Clauses operative, so for them the verification is of the terms themselves, recorded above. We re-verify each mechanism at least every 12 months, and whenever a provider publishes new terms or its certification status changes; the dates above record the most recent verification.

Stripe is dual-role

Stripe acts as our processor for the payment processing it performs on our instructions, and as an independent controller for its own fraud prevention, anti-money-laundering and regulatory compliance. It appears only in the Account Data table above so that nobody reads the Content Data authorisation as covering the processing Stripe does for itself.

Hugging Face

Hugging Face is not a sub-processor: the model registry shown on the site is synchronised FROM our public Hugging Face repositories, and no customer, account or personal data is sent to Hugging Face to process on our behalf. If that ever changes, it joins the tables above under the notice rule below.

Changes to this register

We inform you of an intended new or replacing sub-processor of Content Data before it starts processing personal data. Notice is published as a dated entry in the “Change notices” section at the bottom of this page, stating what is changing and the date it takes effect, and we also write to account holders at their registered email address when we publish one.

Before the stated effective date you may object on reasonable data protection grounds by writing to privacy@cyan.kiwi. We will work with you in good faith to resolve it. If we cannot, you may terminate for that reason; clause 15 of the Terms of Service governs your balance. The governing process is clause 3.5 of the Data Processing Addendum.

Changes to the Account Data tables are disclosed here and in the Privacy Notice when they happen; they are controller disclosures, not authorisation events.

Change notices

None yet. The first dated entry appears here before the change it notices takes effect.