Subprocessors and data routing
This page describes the paid beta subprocessor and data-routing posture for Keiro eb1. It is a customer-facing summary, not a substitute for the signed beta agreement, privacy notice, or DPA.
On this page 1 of 7
Version#
Current paid beta posture version: subprocessors-2026-07-10.
This version supersedes subprocessors-2026-06-16.
Keiro may update this page as the beta environment changes. Material changes to customer data routing are communicated through the support channel or agreement process before sensitive workloads are enabled.
Data routing categories#
| Category | Purpose | Data that may be processed |
|---|---|---|
| Keiro API and control plane | API serving, authentication, routing, usage accounting, limits, audit, billing, and support | Prompts, responses, tool inputs, request metadata, API-key metadata, organization metadata, usage and billing records |
| Authenticated console and docs | Organization administration, key management, usage and billing views, documentation access | Account identity, console session metadata, organization records, and page requests |
| Public site, status, and access intake | Public website, availability updates, early-access form, and access follow-up | Public page requests, contact details, and access-request text submitted by the user |
| Business email and support | Beta communication and support follow-up | Contact details, support messages, issue metadata, and customer-provided context |
| Approved model providers | Model inference for customer-approved routes | Prompts, responses, tool inputs, images, and request metadata needed to provide the response |
| Infrastructure and monitoring providers | Hosting, networking, logging, alerting, backup, and operational monitoring | Request metadata, operational traces, security logs, and limited payload artifacts when explicitly enabled by policy |
Current paid beta providers#
The paid beta may use:
The authenticated docs experience is served through Keiro-operated services; it is not part of Netlify's public-site hosting purpose above.
The active model-provider and infrastructure list can differ by customer, route, region, and billing mode. The signed agreement and support confirmation for an organization are authoritative before sensitive workloads are enabled.
- Keiro-operated API, console, billing, routing, and authenticated docs services
- Netlify (Netlify, Inc., USA) for the public website, early-access intake, and published status artifact
- Google Workspace for business email and support routing
- upstream model providers approved for the customer's beta path
- infrastructure, observability, backup, and security services needed to operate the API
BYOK, resell, and passthrough#
Keiro supports several approved arrangements:
Do not infer an arrangement from a public model ID. Confirm the active data-use, retention, region, and billing posture through the beta agreement or support channel before sending sensitive data.
resell: Keiro-managed provider capacity is used for the request.byok: a customer-approved external provider arrangement may be used.passthrough: a customer-approved provider arrangement may govern the upstream path.direct: a direct Keiro-operated serving path may be used where applicable.
DPA posture#
During beta, a DPA or equivalent data-processing addendum is handled through the agreement process. If your organization requires a DPA, subprocessor notice, data-retention commitment, region restriction, or deletion commitment, complete that process before production-style use.
Keiro does not ask users to send external service credentials, API keys, private datasets, regulated data, or full prompt/response logs through the public access form or first support message.
Change notice#
For beta customers with sensitive-workload approval, Keiro communicates material subprocessor or data-routing changes through the support channel, agreement process, or customer status-update path.