Sub-processors
The third parties that may process your data, or your customers' data, on our behalf when we build and run an agent for you. This page is the list. It is deliberately incomplete where we have not yet confirmed a vendor, and every unconfirmed value is marked.
Draft, not yet reviewed by a lawyer. These documents were prepared as a structured starting point. Every highlighted value still needs to be supplied, and the whole set needs review by qualified counsel in India before it is relied on.
What a sub-processor is
A Sub-processor is a third party we use that may process Client Data or End Customer Data on our behalf.
Those two terms mean specific things across our documents. Client Data is data belonging to or controlled by you that an agent reads or writes. End Customer Data is personal data about an individual who deals with you, for example a shopper or a lead, that an agent reads or writes on your systems. An Agent is software we build that is given a goal and a set of tools, and that decides which tools to call and in what order to reach it.
For End Customer Data that an agent reads or writes on your systems, you are the controller and we are the processor. A sub-processor sits one step further down: it is a party we bring in to do part of that processing. Because you are the controller, the list below is your business, and you are entitled to know who is on it before your data reaches them.
The current list
This is the full set of categories in which a sub-processor may handle your data. Most of the vendor names are not yet fixed. Where a cell reads TODO, no vendor has been confirmed and we are not going to guess one on a legal page. Where a cell reads VERIFY, the vendor is confirmed but the stated fact has not been checked against that vendor's current documentation.
A row with an unfilled name means we have not committed to a vendor for that function. It does not mean the function is absent. Before an engagement starts, ask us for the filled version of this table for your project, and it will be attached to your data processing addendum.
| Sub-processor | What it is used for | Data it may process | Processing location | DPA | Training opt-out |
|---|---|---|---|---|---|
| {{TODO: model provider(s)}} | LLM inference for agent reasoning | Prompts and outputs, which may contain client and end-customer data | {{TODO: processing location for the model provider}} | {{TODO: model provider DPA URL}} | {{TODO: is training on your data disabled}} |
| {{TODO: hosting provider for agent runtimes}} | Compute and storage | {{TODO: what agent runtime data this provider holds}} | {{TODO: processing location for the runtime host}} | {{TODO: runtime host DPA URL}} | Not applicable |
| {{TODO: transactional email provider, if any}} | Notifications and approval emails | {{TODO: what an approval email contains}} | {{TODO: processing location for the email provider}} | {{TODO: email provider DPA URL}} | Not applicable |
| {{TODO: error tracking / observability vendor, if any}} | Tracing and error reporting | {{TODO: what a trace or error report carries}} | {{TODO: processing location for the observability vendor}} | {{TODO: observability vendor DPA URL}} | Not applicable |
| Hostinger (web hosting) | Serving aispeedforce.com | Server access logs containing IP address and user agent | {{VERIFY: confirm the data centre region for this account}} | {{TODO: Hostinger DPA URL}} | Not applicable |
Hostinger is the one row we can state as fact today. It hosts this website. It sees the server access logs described in our cookie policy, and it does not touch agent data, because no agent runs on this website. Its data centre region for this account still has to be confirmed, so it is marked rather than asserted.
This site itself sets no cookies, runs no analytics and loads no third-party scripts or fonts as of 23 August 2026. Nothing on aispeedforce.com sends your visit to a fifth party.
Why the model provider row matters most
Read that first row again. It is the one that carries real risk, and it is the reason this page exists.
An agent reasons by sending a prompt to a language model and reading the output back. That prompt is not an abstract instruction. It contains whatever the agent needed to make its decision: the order it just fetched, the ticket text a shopper wrote, the email address on the account, the note a staff member left. Prompts and outputs sent for inference may contain Client Data and End Customer Data. That is not an edge case. On a support triage agent it is every single run.
So the questions on that row are the questions that actually matter. Which provider receives the prompt. In which country it is processed. Whether there is a data processing agreement behind it. Whether the provider trains on what we send, and whether that is switched off. None of those four are answered yet, which is precisely why they are marked and not filled.
How we minimize what goes into a prompt, what we do with run traces, and the position we take on training are set out in full on AI and your data. Read that page alongside this one. This page tells you who is in the chain. That page tells you what is sent to them and why.
How we choose them and what we require
We keep the list short. A sub-processor is added when a function genuinely cannot be done without one, not because it is convenient. Fewer parties in the chain means fewer places your data can sit and fewer contracts you have to trust.
Before a vendor handles Client Data or End Customer Data on our behalf, we require three things.
- A data processing agreement. A signed or accepted DPA that binds the vendor to process data only on documented instructions, to keep it confidential, to support deletion and return, and to flow the same obligations down to anyone it uses in turn. The DPA URL for each vendor goes in the table above.
- Security appropriate to the data. Encryption in transit, access control on the vendor's side, and a published incident process. We state what is true and we do not claim certifications. We hold none, and neither claiming nor implying one is acceptable on this page. What we look for in a vendor is described on our security page.
- For a model provider, an explicit position on training. Not an assumption, not a default we hope is right. A written statement, from the provider, on whether prompts and outputs sent through the account we use are used to train or improve their models, and where that setting lives. If training cannot be disabled on the plan we would use, that provider does not get client data.
We also prefer a vendor that lets us pick a processing region, because that determines whether your data leaves your jurisdiction. Our international transfer mechanism is {{TODO: confirm which transfer mechanism is in place, and with which sub-processors}}.
Platforms are not sub-processors in the usual sense
This is the part people get wrong, and it is the part reviewers ask about, so here it is plainly.
A Platform is Shopify, Wix, WordPress, Ecwid, HighLevel, BigCommerce, or another system an agent connects to. When we build you an agent that reads your store, that agent connects to a Platform account that is already yours. You signed up for it. You agreed to its terms. Your data was already sitting in it before we arrived.
So when an agent reads a merchant's Shopify store, Shopify is the merchant's own processor under the merchant's agreement with Shopify. It is not ours. We did not put your data there and we do not send your data to it. The agent reaches it using credentials you grant, at a scope you set, and you can revoke those credentials at any time. The relationship, the contract and the responsibility for that Platform are between you and the Platform.
A sub-processor is different. A sub-processor is a party we bring into the chain to do part of our processing, one your data would not otherwise reach. A model provider is the clearest example: without us, your order data was never going to be sent to an inference endpoint. That is a party we added, so it belongs on the list above and it is ours to justify.
The practical test is who introduced the party. If you already had the relationship, it is your processor and it sits in your own vendor register. If we introduced it to deliver our service, it is our sub-processor and it belongs on this page. Platforms fall on your side of that line. Model providers, agent runtime hosts and our own tooling fall on ours.
One qualification. If we build and publish an app that runs on a Platform's marketplace, the app itself is our software and our processing obligations apply to it. The Platform is still the Platform. Where those two overlap is set out in the relevant app policy under app policies.
Notice of a change, and how to object
The list will change. Vendors get added, replaced and dropped. When that happens, this is what we do.
We update the table on this page and add a row to the version history at the foot of it, so the change is on the public record with a date. This page is the canonical list, and it is reachable without signing in so you can check it whenever you want.
We also notify clients with an active engagement directly, by {{TODO: the notification method for a sub-processor change: email to the named contact, in-product notice, or both}}, before the new sub-processor starts processing your data. Notice goes out ahead of the change, not after it.
You may object to a new sub-processor. The window for raising an objection after we give notice is {{TODO: COMMERCIAL TERM. The objection window, in days, after notice of a new sub-processor. Set this with counsel before publishing}}. It is a commercial term and it has not been set, so we are not writing a number here that we would then have to walk back.
If you object on reasonable data protection grounds, we will work with you to find an alternative for your engagement. If there is no workable alternative, the consequences for the engagement, including termination and any refund, are governed by {{TODO: COMMERCIAL TERM. What happens to the engagement if an objection cannot be resolved}} and by our data processing addendum.
Changes to this document
We may update this document. When we do, we change the "Last updated" date and add a row to the version history at the foot of the page. Section anchors are stable and we do not rename them, so a link to a section keeps working.
A change to the table itself is a change to this document, and it gets a version history row of its own naming the sub-processor added or removed.
Ask a question about this list
If you want to know who sits behind a row before you sign anything, ask. We would rather answer a direct question than have you assume.
Questions about this list, and objections to a new sub-processor, go to {{TODO: privacy@aispeedforce.com, confirm the mailbox exists}}. Until that mailbox is confirmed, use hello@aispeedforce.com, which is monitored. You can also use the contact form.
Useful things to include: which engagement or app you are asking about, whether you need the answer for a vendor review or a records of processing entry, and whether you need it in writing on our letterhead.
Related documents: AI and your data, data processing addendum, privacy policy and security.
Version history
| Version | Date | Change |
|---|---|---|
| 0.1-draft | {{TODO: effective_date}} | First published draft. Not yet reviewed by counsel. |