:::info Document status Version v1.0, effective 2026-08-31. The official language of the Terms is English; any translation is provided for convenience only. :::
KOMASHI — MODULE D(2) · ANNEX 3 (AUTHORIZED SUB-PROCESSORS)
Parent agreement. This Annex forms part of the Komashi Data Processing Agreement (Module D(2)) and is maintained separately from Annexes 1–2 (module-d2-annexes.md) so the sub-processor list can be re-issued on its own cadence. Capitalized terms not defined here have the meanings given in the DPA, Module 0, or the GDPR.
Annex 3 version: v1.0 Annex 3 effective date: 2026-08-31 Also published at: https://komashi.com/legal/subprocessors
Maintenance / amendment. This Annex is maintained under the general authorization in DPA §4.1. The authorization covers the named recipients, provider groups and downstream-provider pools below. Selection or switching within an already listed pool does not require separate notice. Komashi gives notice and a reasonable opportunity to object before engaging a recipient or provider category not already covered by this Annex, as set out in DPA §4.2. Each published change carries a new version number and effective date, and superseded versions are retained and available on request under Section 4.5 of Module 0.
SCC linkage. This Annex is the agreed sub-processor list for the general-written-authorization option in SCC Clause 9(a). Where a particular transfer uses specific authorization and requires SCC Annex III, the relevant entries below supply the information for that annex. The EU Standard Contractual Clauses under DPA §5.2a are operative, not contingent: Sections B and C cover recipients that may be established in, owned from, or process data in third countries. A transfer impact assessment and an applicable transfer mechanism are required before Controller Data is routed to such a recipient. A recipient or provider category not already covered by this Annex is subject to the §4.2 notice-and-objection process before engagement.
Annex 3 — Authorized Sub-processors
General authorization under DPA Section 4.1. Current list maintained at https://komashi.com/legal/subprocessors.
A. Infrastructure
There is no sub-processor in the infrastructure layer at all. Komashi runs the Platform's application, database, storage and log indexing on equipment it owns, at its own premises in the EU/EEA. It rents no compute, hosting, database, or log-analytics service from any provider, and the equipment is not housed in a third-party data centre, so no facility operator has physical access to the machines either. Outbound transactional email is sent from Komashi's own mail servers, so no delivery provider receives recipient names or addresses.
The practical consequences for the Controller are:
(a) no third party holds any account over the Platform's database, logs, or mail — logical or physical;
(b) the logging layer, usually the least-controlled place personal data ends up, does not leave Komashi's own systems; and
(c) the security assurance for this layer is entirely Komashi's own. There is no facility operator's certification to inherit and no hosting provider's audit report to point at, which is why Annex 2 carries the physical-security commitments directly and why DPA Section 3.9(a) is drafted around a documented response rather than a certification. This cuts both ways, and the Controller should read it that way: the CLOUD Act and third-party-access exposure that a rented facility would carry does not arise, but nor is there an external auditor standing behind the physical controls. Annex 2 therefore states those controls directly — including the one that is not in place, so that the position can be assessed rather than assumed.
The sub-processors in Section B are therefore application-level services only — invoicing, AI, sign-in and analytics, and payment-side verification. None of them holds Controller Data at rest on Komashi's behalf as a matter of infrastructure.
B. Sub-processors
The "Controller Data" column states what actually leaves Komashi's own systems. Nothing beyond the categories listed reaches the recipient.
| # | Sub-processor (legal name) | Service | Controller Data received | Processing location | Owner / parent jurisdiction | Transfer mechanism |
|---|---|---|---|---|---|---|
| 1 | Billingo Technologies Zrt. (Hungary) | Issuance and delivery of invoices through the Platform | Billing name, address, tax identifier, email address, invoice line items and the other data required to issue the invoice | Hungary | EU | None — EU/EEA-located |
| 2 | KBOSS.hu Kft. ("Számlázz.hu", Hungary) | Issuance and delivery of invoices through the Platform | Billing name, address, tax identifier, email address, invoice line items and the other data required to issue the invoice | Hungary | EU | None — EU/EEA-located |
| 3 | OpenRouter, Inc., its applicable affiliates, and the downstream model and inference providers in Section C | Routing and processing of requests where an AI feature is enabled. A request or workflow may use one or more downstream models and inference providers, including multiple providers in parallel or in sequence | Service names and descriptions, support questions, support-ticket content and other free text submitted to an AI feature; request and response content; model, routing, usage and security metadata. Free text may contain End User personal data | United States, EU/EEA, and other locations identified for the participating providers in Section C or the provider directory referenced there | United States | Varies by route; SCCs, adequacy decision or another lawful mechanism, as applicable (Section E) |
| 4 | Google Ireland Limited / Google LLC | (i) Google Sign-In where a user chooses it; (ii) web analytics operated on Komashi's own account | (i) Name, email address, Google account identifier; (ii) IP address, device and browser data, usage and event data | Ireland; United States | United States | SCCs or an applicable adequacy decision (Section E) |
| 5 | Stripe Payments Europe, Limited / Stripe, Inc. — only to the extent Stripe acts as processor | Provider onboarding and verification carried out on Komashi's instruction. For the payment transaction itself Stripe is an independent controller — see Section D | Name, email address, billing data and the personal data required for Provider verification / KYC | Ireland; United States | United States | SCCs or an applicable adequacy decision (Section E) |
Sections B and C together describe the authorized recipient set. A listed provider does not necessarily receive Controller Data: it receives data only if the relevant integration, model, route or fallback is selected. There is no hosting, data-centre or email-delivery entry because those functions are performed by Komashi on its own equipment (Section A).
C. Authorized AI model and inference provider pool
Where an AI feature is enabled, Komashi may route a request through the routing service listed below to one or more model operators, cloud AI services or inference providers in the pool below. A feature or workflow is not limited to a single model: it may use multiple models or providers at the same time or in sequence, including for routing, classification, generation, verification, fallback or quality comparison. This may involve two or three providers in the same workflow, but no fixed number is promised or required. Only providers that participate in the relevant request or workflow receive its data. Other providers in the pool receive nothing merely because they are listed.
The authorization covers the provider group and the affiliate, regional contracting entity, cloud platform or infrastructure operator through which that provider makes the relevant model or endpoint available. Depending on the route, the provider may process the Controller Data categories stated in Section B, row 3, in the EU/EEA, the United States, the United Kingdom, Canada, France, Singapore or another region disclosed for that endpoint, excluding the United Arab Emirates unless this Annex and DPA Section 5.2 are first amended. For a third-country route, Komashi applies the mechanism and assessment described in DPA Section 5.2a.
Authorized model families
The following model families, including their current, renamed, updated and successor versions made available through an authorized provider, may be used. Listing a family authorizes its use but does not mean that every model in it is active.
| Model developer | Authorized model families |
|---|---|
| OpenAI | GPT models and related reasoning, multimodal, embedding, transcription and image models |
| Anthropic | Claude models |
| Gemini models and related Google embedding or multimodal models | |
| Mistral AI | Mistral, Mixtral, Codestral and related models |
| Cohere | Command, Embed, Rerank and related models |
| xAI | Grok models |
| Meta | Llama models and related Meta AI models |
| DeepSeek | DeepSeek chat, reasoning, coding, Pro, Flash and related models |
| Alibaba Cloud | Qwen models and related Alibaba Cloud AI models |
| NVIDIA | Nemotron and related NVIDIA AI models |
| Other authorized developers in this Section | Models identified under that developer or provider in the routing service's then-current model directory, provided the route satisfies the controls in DPA Section 5.2a |
Komashi may also use automatic routing or equivalent routing logic to select one or several authorized models for a request or workflow. A change between versions within an authorized model family, or the addition of a successor version within that family, is not a new sub-processor addition.
Authorized routing and inference providers
| Authorized provider group or service | Role in the routing chain |
|---|---|
| OpenRouter | Routing service |
| OpenAI | Model operator or API endpoint provider |
| Anthropic | Model operator or API endpoint provider |
| Google AI / Google Cloud Vertex AI | Model operator, cloud AI service or endpoint provider |
| Microsoft Azure AI | Cloud AI service or endpoint provider |
| Amazon Web Services / Amazon Bedrock | Cloud AI service or endpoint provider |
| Mistral AI | Model operator or API endpoint provider |
| Cohere | Model operator or API endpoint provider |
| xAI | Model operator or API endpoint provider |
| Meta | Model operator or first-party model endpoint provider |
| DeepSeek | Model operator or API endpoint provider |
| Alibaba Cloud | Cloud AI service or endpoint provider |
| NVIDIA | Model or inference endpoint provider |
| Together AI | Model hosting or inference provider |
| Fireworks AI | Model hosting or inference provider |
| Groq | Model hosting or inference provider |
| Cloudflare Workers AI | Model hosting, network or inference provider |
| Baseten, DeepInfra, Nebius AI, Novita AI, Parasail, SambaNova, Venice and other named inference providers made available through the routing service | Alternative capacity, hosting or inference endpoint for a selected model |
The routing service's current model directory, provider directory and the policy attached to each participating endpoint further identify available models, providers, processing regions and data-handling characteristics. Komashi may use routing controls, provider allowlists, region controls, zero-retention settings and data-collection restrictions where appropriate for the feature. A model developer or provider outside the groups and services covered above is treated as a new provider category under DPA Section 4.2.
D. Parties that are not sub-processors, and why
Listing these is deliberate: a Controller's counsel will look for them, and each is excluded for a stated reason rather than by omission.
| Party | Why it is not a sub-processor of Controller Data |
|---|---|
| Barion Payment Zrt. · Mollie B.V. · Stripe (payment leg) | Each acts as an independent controller for the payment data it processes, determining its own purposes and means under its own licence and regulatory obligations (Privacy Policy Section 5.1(c)). They are not engaged by Komashi to process Controller Data on its instructions, are not subject to the Section 4.2 objection right, and Komashi receives no End User funds, card numbers, or payment credentials (Provider Terms Section 4.1a). Stripe additionally appears in Section B for the separate onboarding and verification processing it carries out on Komashi's instruction — the two roles are distinct and are not interchangeable |
| Web analytics a Provider configures on its own account | Where the Provider switches on Google Analytics or Microsoft Clarity for its own presence, on its own account and under its own legal basis and consent collection (Provider Terms Section 6.7), that processing is the Provider's, not Komashi's. This is separate from the analytics Komashi operates on its own account, which is in Section B, row 4(ii) |
| Exchange-rate data source | Provides reference rates only. No personal data is transmitted to it (Module F Section 4.2) |
E. Third-country transfers
Some recipients in Sections B and C are established in, owned from, or may process data in a third country. Where Controller Data is routed to such a recipient, the transfer is made under the EU Standard Contractual Clauses, an applicable adequacy decision or another lawful mechanism stated for the route, on the terms set out in DPA Section 5.2a, and is covered by the transfer impact assessment required by DPA Section 5.2a(b).
(a) Why the SCCs and not an adequacy decision. Some of these recipients are, or may become, certified under the EU–US Data Privacy Framework. Komashi nevertheless relies on the SCCs as the primary mechanism for every US transfer. The reason is resilience rather than caution: an adequacy decision can be annulled or suspended, and a package that depended on one would lose its transfer basis overnight. Where a recipient is DPF-certified, that certification operates as an additional safeguard, not as the basis relied on.
(b) Data minimisation as a supplementary measure. The "Controller Data received" column in Section B is a limit. Only the categories stated there may leave the EU/EEA, and only where the relevant integration, model, route or fallback is used.
(c) Adding a sub-processor. A recipient or provider category not already covered by Sections B and C requires the transfer impact assessment in DPA Section 5.2a(b) where applicable and the notice-and-objection process in DPA Section 4.2 before the addition takes effect. Selection or switching within the authorized pool does not require a separate notice.
(d) Onward transfer in the AI routing chain. The routing service may pass a request to one or more providers in the authorized pool in Section C, and those providers may use identified cloud or inference endpoints to process it. Komashi may change or combine models, providers, regions and fallbacks within that pool without separate notice. Each provider participating in the workflow may receive the Controller Data needed for its assigned processing step. Komashi uses the contractual terms and technical controls reasonably available for the participating routes to limit retention and prevent use of Controller Data for a recipient's own purposes, including model training, unless the Controller has separately instructed or authorized that use. Retention and routing characteristics may vary by endpoint and are assessed for the participating routes.
(e) No UAE transfer. No Controller Data is transferred to, stored in, or accessible from the United Arab Emirates, notwithstanding Komashi's registration there (DPA Section 5.2).