Data processing policy

1. Roles

For account, billing, website, security, and business operations, Standard Thinking generally acts as a controller or business. For personal data contained in Customer Content that a business customer submits for inference or customer-enabled storage features, Standard Thinking generally acts as that customer’s processor or service provider and processes the data on documented instructions.

The customer determines the lawfulness, purpose, and content of its Inputs and is responsible for notices, consents, and instructions to its own users and data subjects.

2. Data categories

• Inputs: prompts, messages, code, files, embeddings, media, model artifacts, retrieval data, or other material submitted by the customer.
• Outputs: tokens, text, code, media, classifications, embeddings, or other results generated in response to Inputs.
• Account data: users, organization, permissions, projects, billing contacts, authentication, and support records.
• Service metadata: model identifier, token counts, request time, latency, region, route, status and error codes, and project identifiers.

3. Processing purposes

We use authentication credentials and relevant account data to authenticate requests and control access. We process Inputs and Outputs to run the requested model or deployment, route traffic, return results, provide customer-enabled features, protect the platform, and deliver requested support, subject to the processing and retention limits in Section 4.

We process Customer Content on your behalf to provide, operate, secure, and support the Services you request, and as required by applicable law. We do not use Customer Content for our independent purposes unless the customer separately and expressly authorizes that use or that use is expressly permitted under Section 5.3 of the Terms of Service. Any separately authorized use remains subject to its express terms.

We process account data and service metadata for metering, billing, reliability, capacity planning, incident investigation, abuse prevention, and legal compliance.

We do not use Inputs or Outputs to train public or shared models unless the customer gives a separate, explicit opt-in or that use is expressly permitted under Section 5.3 of the Terms of Service. De-identified operational statistics and content-free service metadata may be used to improve platform reliability, routing, and performance.

4. Processing, caching, and retention

4.1 Temporary processing and caching

We may temporarily hold Customer Content and derived processing data in buffers, queues, caches, and other intermediate systems as reasonably necessary to provide, operate, secure, and support the Services you request. This may include prompt caching, KV caching, and reuse of intermediate results across requests to improve processing efficiency. The method and duration may vary with the service, configuration, workload, and technical requirements, subject to applicable law and any specific retention commitment.

Temporary processing data is kept only for as long as reasonably necessary for the applicable function and is then cleared through the relevant expiration, eviction, or deletion processes. This policy does not promise a fixed cache lifetime or immediate deletion of all processing data when an individual request ends. Temporary processing does not authorize independent use of Customer Content.

4.2 Services with a ZDR commitment

Where the applicable product description, service documentation, or customer agreement expressly identifies a service or configuration as ZDR, we do not retain Inputs or Outputs handled by that inference service as content logs, histories, backups, or other persistent content records. The applicable ZDR terms identify any permitted temporary inference caching and its scope. Such caching is treated as part of inference processing only within those terms; features that retain retrievable content or stored responses outside that scope are subject to separate retention terms.

A ZDR commitment applies to the identified inference service and configuration. It does not extend to separately enabled storage features, material you voluntarily provide for support or feedback, or copies kept by your application or other services you use. Content-free account and service metadata is handled separately. This policy does not establish a ZDR commitment for every service or configuration.

4.3 Customer-directed storage

Storage through the Product Plan data platform is optional. When you enable it, we retain the data you designate to provide that feature on your behalf. That stored data is outside the scope of inference ZDR. The same principle applies to other customer-enabled features that require retained content, such as history, response caching, batch processing, retrieval, evaluations, fine-tuning, and stored model assets. Enabling one such feature does not remove a ZDR commitment from separately covered inference processing.

Retention periods, access and deletion controls, and the effect of disabling a storage feature are described in the product, documentation, or customer agreement. Disabling a feature does not by itself require immediate deletion of previously stored data or its backups. Enabling storage does not by itself authorize training on your content for public or shared models. That use requires a separate, explicit opt-in or express permission under Section 5.3 of the Terms of Service.

4.4 Deletion, metadata, and legal preservation

Unless a specific period is stated, retained Customer Content is kept only as long as reasonably needed for the customer-directed function, requested support, or applicable legal obligations. Retention for model-training use permitted under Section 5.3 of the Terms of Service is governed by the applicable Service-Specific Terms, subject to that Section’s exclusions and this Policy’s restrictions on backup use and legal preservation. When the applicable period ends, data is deleted or returned through the relevant service processes. Deletion may take a reasonable period to propagate through systems, and backup copies may remain until the applicable replacement or deletion cycle, subject to law and contractual commitments. Remaining copies are restricted to recovery, security, or legal preservation purposes and are not used for independent purposes.

We may retain content-free service metadata, such as model identifiers, token counts, timestamps, latency, region, route, status and error codes, non-reversible safety signals, and account or project identifiers, for billing, reliability, security, and service operations. This metadata does not include the substance of Inputs or Outputs.

Legal preservation requirements may apply to information already in our possession. These provisions do not authorize collecting content records that an applicable ZDR commitment prohibits or overriding a stricter signed agreement.

5. Infrastructure, model services, and subprocessors

We may engage cloud infrastructure, networking, model execution, observability, authentication, support, and other service providers to process data on our behalf. Subprocessors must follow the processing and retention restrictions applicable to the relevant service. Where a service or configuration carries a ZDR commitment, subprocessors handling its covered inference content must follow materially equivalent restrictions.

A customer-selected model may be subject to model-specific terms or processing constraints. Where an enterprise agreement provides a subprocessor list or notice mechanism, we will follow that agreement.

6. Location and transfers

Data may be processed in the United States and other locations where we or our providers operate. If applicable law requires a transfer mechanism, the parties may enter into a DPA incorporating standard contractual clauses or another recognized safeguard. Regional or dedicated processing is available only when expressly included in an order.

7. Security and confidentiality

We use technical and organizational measures designed to protect data against unauthorized or unlawful access, use, alteration, and loss. Measures are selected based on the service, sensitivity, and risk and may include encryption, access controls, content-free operational logging, monitoring, environment separation, and incident response. Personnel and providers with access to information eligible for storage are subject to confidentiality obligations.

See our Security Policy for the public overview. Specific enterprise controls belong in the applicable security exhibit or order.

8. Data subject requests and legal demands

When we act as a processor, we will provide reasonable assistance for a customer’s verified data subject request as required by the applicable DPA and law. We may direct an individual to the customer that controls the data.

We review government and legal demands for validity and scope. Where legally permitted, we notify the affected customer before disclosing Customer Content and seek to limit disclosure to what is required.

9. Restricted data

Do not submit payment-card data, protected health information, government-classified information, export-controlled technical data, biometric identifiers used for identification, or other specially regulated data unless Standard Thinking has expressly agreed in writing to support that data type and the required safeguards are enabled.

10. Enterprise requests

To request a DPA, discuss regional processing or retention controls, or ask a data-processing question, contact contact@standardthinking.ai.