SUBPROCESSORS.md

Rama main · réplica de lectura del repositorio original.

# lynox Sub-processors

**Last reviewed: 2026-08-11**

This file is the canonical, repo-checked-in list of sub-processors engaged for the **lynox Managed Hosting** service (`engine.lynox.cloud` / `*.lynox.cloud` tenant instances).

This list applies only to lynox AI's managed offering. The **self-hosted lynox software** (`@lynox-ai/core` and `@lynox-ai/web-ui`) is a different case: what it connects to is **not limited to** the LLM provider whose API key you configure. It follows from how you configure the deployment and what you ask the agent to do — a default install reaches a web-search backend, and connected accounts, third-party APIs and addresses the agent is asked to fetch are contacted by your deployment directly.

Whether any of those third parties is a sub-processor, a recipient, or neither depends on your deployment and your own role as controller. This document does not answer that question, and does not need to: it lists the sub-processors **lynox AI** engages for the managed service. For processing lynox AI carries out for you, the binding text is the Data Processing Agreement.

The website page <https://lynox.ai/subprocessors> and this file mirror the customer-facing list. The contractually binding list lives in the **Data Processing Agreement** at <https://lynox.ai/dpa>. If any version diverges, the DPA prevails.

| Sub-processor | Purpose | Location | Transfer mechanism |
|---|---|---|---|
| Anthropic, PBC | Primary LLM inference (Claude family, direct API) — the default for every managed instance. | United States | SCCs (**Module 2 and Module 3**, 2021/914; Irish law) per Anthropic's DPA §I.1 — **not** the EU-US Data Privacy Framework: Anthropic is not a certified participant (US Dept. of Commerce register, checked 2026-08-11), and its own privacy policy names only adequacy decisions and SCCs. **Retention: inputs and outputs are deleted within 30 days of receipt or generation**, which is Anthropic's API default; lynox holds no zero-retention agreement, and zero retention is available from Anthropic only under one. Longer retention applies where a request is flagged under Anthropic's Usage Policy. No training on inputs under its Commercial Terms. |
| Mistral AI SAS | Inference and voice in the default managed setup: the background worker profile (`ministral-14b-2512`), the fallback profile used for named sub-agent spawns (`mistral-medium-2604`), **speech-to-text** (`voxtral-mini-2602`) and **text-to-speech** (Voxtral). Text-to-speech has no alternative implementation — spoken output always goes to Mistral. On a managed instance neither can be switched away: `transcription_provider` is not tenant-writable (the managed config gate 403s it) and `LYNOX_TRANSCRIBE_PROVIDER` is self-host-only, so the local whisper.cpp fallback that ships in the image is unreachable there. Mail-triage classification does **not** run here by default: it follows the instance's main provider, which is Anthropic unless the customer changes it. Any customer may also select Mistral as their main inference provider, so that primary inference runs with a provider hosted in the EU. | EU (seat: France) | EU — hosted in the EU by default (endpoint api.mistral.ai). Mistral may transfer data to its own sub-processors outside the EU, on the basis of adequacy decisions or appropriate safeguards (Mistral DPA §8.1); Mistral lists them in its Trust Center. **Retention is not zero by default:** Mistral keeps API inputs and outputs "for the period necessary to generate the Output and then for thirty (30) rolling days to monitor abuse" (Mistral Privacy Policy §5, effective 2026-07-27), the default for the stateless endpoints lynox uses. Zero Data Retention is **opt-in** — Scale plan only, stateless endpoints only, granted on request at Mistral's discretion — and lynox does not hold it (account on Pay-as-you-go, checked 2026-08-11). Mistral's Data Processing Addendum carries **no** zero-retention commitment; its §2.3 merely carves abuse monitoring out "when zero data retention has been activated". **No training on API inputs or outputs** — this is contractual (Commercial Terms of Service §4.2, effective 2026-08-05); separately, lynox has not enabled training in its Mistral organisation settings, an account configuration rather than a contractual term (checked 2026-08-11). The remaining carve-outs are thumbs-up/down Feedback and Labs/Preview models, neither of which lynox uses. |
| Fireworks AI, Inc. | LLM inference for the opt-in "Efficient" and "Balanced" model strategies — engaged for a managed instance by one of two routes: the instance selects one of those presets (or a Fireworks model) in its own model settings, or lynox pins a preset for that instance from the control plane. A pin takes effect only where the instance has not chosen a strategy itself. The option is enabled platform-wide, but neither route is the default: an instance with no selection and no pin routes to Anthropic and Mistral only, and no data is transmitted to Fireworks until one of the two routes applies. Where a preset is selected, **all three** model tiers (fast / balanced / deep) run on Fireworks' serverless inference on open-weight models; those in use today come from Chinese developers. Which model a tier currently uses, with its origin and processing location, is shown in the instance under Settings → Configuration. The weights are open; the inference runs on Fireworks' own infrastructure. None of the sub-processors listed in Schedule 4 of its DPA is a Chinese entity. The processing locations named there include the United States, Germany, the United Kingdom, Japan and Iceland; one row, a content-delivery provider, is listed with no fixed country at all. Schedule 4 is Fireworks' list and can change — it is the list as we read it on 2026-08-11, and Fireworks owes 30 days' notice of changes to it (Fireworks DPA, Schedule 4). Fireworks does not retain prompt inputs or model outputs beyond the lifecycle of a request (Zero Data Retention — Fireworks' default for open models, which we have not opted out of by enabling prompt logging, and a contractual obligation under §4.5 of its DPA), and is contractually prohibited from using the data to train, fine-tune or otherwise improve any shared or foundational model (§4.3(f)). | United States | SCCs (Module 2, 2021/914; Irish law, Irish DPC); Zero Data Retention and the no-training commitment as additional safeguards; SOC 2 Type II, ISO 27001 / 27701 / 42001 |
| Stripe, LLC (US) / Stripe Payments Europe, Limited (Ireland) | Payment processing and subscription billing | Ireland (EU) — as a customer outside North and South America, lynox's contracting entity is **Stripe Payments Europe, Limited** (Stripe DPA); the transfer to **Stripe, LLC** in the United States is an onward transfer inside the Stripe group. | For lynox's own leg: EU — no third-country transfer, our counterparty being Stripe Payments Europe, Limited (Ireland). For Stripe's onward transfer to Stripe, LLC (US): eU-US and Swiss-US Data Privacy Framework — Stripe, LLC is an active DPF participant (US Dept. of Commerce register, checked 2026-08-11). Stripe's Data Transfers Addendum §2 makes the mechanisms **mutually exclusive**: "the transfer will be subject to one Data Transfer Mechanism only, according to the following order of precedence: (a) the Data Privacy Framework; (b) the EEA SCCs or the UK International Data Transfer Addendum". The SCCs are therefore a **fallback** that activates only if the DPF ceases to apply — **not** a second mechanism running alongside it. |
| Hetzner Online GmbH | Server infrastructure — shared tenant hosts (isolated container per customer); dedicated VPS available as Enterprise upgrade | Germany (EU) | EU |
| Brevo (Sendinblue SAS) | Transactional email delivery (SMTP relay) and contact list management | EU (France/Germany) | EU |
| Cloudflare, Inc. | DNS, CDN, DDoS protection, tunnel relay | United States / EU (edge network) | EU-US and Swiss-US Data Privacy Framework. Cloudflare's DPA sequences the mechanisms rather than stacking them: a transfer made under the Data Privacy Framework is defined as **not** a Restricted Transfer (cl. 6.4), so the standard contractual clauses in cl. 6.2 do not engage. If the certification lapses or is invalidated, the same clause deems the transfer Restricted immediately and cl. 6.2 applies, with Cloudflare undertaking to notify. The SCCs are the contractual **fallback**, not a second mechanism running alongside. |
| Plausible Insights OÜ | Anonymous website analytics (no personal data) | EU (Estonia) | EU |
| Google Ireland Limited (Gordon House, Barrow Street, Dublin 4, Ireland) — for the marketing measurement; see mechanism for search queries | Marketing measurement on lynox.ai only — Google Analytics 4 + Google Tag Manager (Consent Mode v2; fires only with marketing consent via Klaro). A Managed Hosting instance also runs its own search service, which queries public search engines on the customer's behalf. Where Google is among them, what reaches Google is the search text together with ordinary HTTP request headers; no account, tenant or user identifier is sent, and the request carries no identifier of the instance beyond its network address. Instances created under the current provisioning configuration do not query Google; instances created earlier do, until their search configuration is regenerated. | EEA (Ireland); onward transfer to Google LLC (United States) | Our contracting party for the website measurement is Google Ireland Limited: the Analytics terms accepted for the account and the Google Ads invoices name it (read 2026-10-02). Google also processes this data in the United States as its own onward transfer. Google LLC is listed in the US Department of Commerce register with the EU-U.S. framework, the UK Extension and the Swiss-U.S. framework each *Active* (retrieved 2026-10-01; next certification due 2027-09-13 — a re-certification deadline rather than an expiry date; the listing covers Google LLC and its wholly-owned US subsidiaries); which mechanism carries that onward leg is set by Google's terms, and we have checked Google LLC's certification as stated. For search queries from Managed Hosting instances there is no contract between lynox and Google. |
| Self-hosted (Bugsink) | Error reporting (always active for managed instances) | EU (self-hosted on lynox infrastructure) | No third-party transfer |

## Notes

- **Customer-configured endpoints (BYOK).** If a customer connects their own LLM provider via Settings → Configuration with their own key — for example OpenAI, an OpenAI-compatible endpoint, Google Vertex AI, or a self-hosted model — that provider is engaged by the customer under their own agreement with it. It is the customer's own controller relationship, not a lynox sub-processor, and is therefore not listed above. The default managed setup uses Anthropic + Mistral only.
- **Prompt caching.** Prompt prefixes are cached to cut latency and cost: on Anthropic we set explicit cache breakpoints, while Mistral and Fireworks apply their own automatic prefix caching. Cached data is short-lived and expires on its own: our Anthropic cache breakpoints carry a one-hour time-to-live, and for Fireworks its documentation states the data stays in volatile memory and is never written to persistent storage. Caching is the one carve-out from the Fireworks zero-retention commitment cited in the table (its DPA §4.5). It does not bear on Anthropic or Mistral, whose 30-day retention windows already cover anything cached.
- **Google Ireland Limited** is our contracting party for `lynox.ai` marketing measurement (GA4 + Tag Manager, gated by Klaro Consent Mode v2); Google processes that data in the United States as its own onward transfer (Google LLC, EU-U.S. and Swiss-U.S. DPF Active). Google also receives search queries from Managed Hosting, with no contract between lynox and Google on that leg: an instance runs its own search service which queries public search engines on the customer's behalf, and where Google is among them it receives the search text and ordinary HTTP request headers, with no account, tenant or user identifier. Instances created under the current provisioning configuration do not query Google; instances created earlier do, until their search configuration is regenerated. Beyond those two, tenant data reaches Google only where the customer separately enables a Google integration (Calendar OAuth, BYOK Gemini); those are customer-controlled and disclosed inline in the Privacy Policy where applicable.
- All sub-processor changes are notified to managed customers at least 30 days in advance per the DPA.

## Where this list is duplicated

The same sub-processor inventory appears on the lynox website in two places:

- <https://lynox.ai/privacy> — section 5 (third-party services)
- <https://lynox.ai/dpa> — section 9 (sub-processors)

The DE counterparts (`/de/datenschutz/`, `/de/avv/`) mirror these.

This `SUBPROCESSORS.md` file is the engineering-visible source of truth; the web pages are updated in the same change.

## Contact

For questions about sub-processors or to object to a sub-processor change:
<privacy@lynox.ai>