Beta terms, privacy, and data posture
Paid beta access requires acceptance of the Keiro beta terms and privacy notice through the invite workflow. If those documents are not available for a user or organization, do not start paid traffic for that organization.
On this page 1 of 5
Data use#
Keiro processes prompts, responses, tool inputs, metadata, and usage records to provide the API, route requests, debug failures, enforce plans and limits, and support billing and abuse prevention.
Do not send regulated, highly sensitive, or contract-restricted data unless your beta agreement explicitly allows that use.
Providers and subprocessors#
Keiro may route requests to upstream model providers or infrastructure vendors needed to provide the API. The beta terms or support channel must identify the active subprocessors for each organization before paid use.
See Subprocessors and data routing for the current public beta posture and DPA process.
Provider data-use terms can vary by provider and by account mode. During paid beta, Keiro support should confirm whether a request path uses Keiro-managed provider capacity or a customer-approved provider arrangement before sensitive workloads are enabled.
Data retention#
Keiro may retain API request metadata, usage records, billing records, abuse and security logs, and operational traces for reliability, billing, security, and support. See Data retention and erasure for the current paid beta retention posture. Customer-facing docs should not promise deletion or retention periods that are not present in the accepted beta terms.
Beta users may request an export or deletion review through the support channel. Export and deletion are subject to security, abuse-prevention, accounting, dispute, and legal retention requirements. Keiro exports only supported customer-facing records and excludes credentials, sensitive operational details, and non-public account data.
Support, escalation, and incident status ownership#
Use the beta support channel for key issues, billing questions, security concerns, and data-handling questions. Include timestamps, endpoint paths, model IDs, HTTP status, whether the request streamed, and request IDs when available.
See Beta SLA and support posture for availability, maintenance, incident-update, and support expectations during the beta.
Do not send API keys, external service credentials, private datasets, or full logs that may contain secrets in support tickets.
The incident commander owns customer status updates during paid beta. The support owner confirms customer impact, and the on-call platform owner confirms API recovery before an incident is marked resolved.