Data and privacy

This page is a readable summary of what the service stores, for how long, who else sees it, and what erasure reaches. It is a map into the legal documents, not a replacement for them.

The legal documents govern. Where anything here differs from them, they win. Nothing on this page creates a right they do not create.

Consent is recorded against a specific version of each document. Accepting one version is not acceptance of the next — when a new version is published, we ask again (Terms §22, Privacy §13).

The short version

• Your tier decides what we keep. It is the thing the tiers are actually selling (Terms §6).
• On shared_anon and private, your prompt text is never written to the call record — with one qualification for batch traffic, which holds a working copy for an operational window (see below). On free it is retained verbatim and reused for our own purposes.
• We store the model’s output on every tier, including private. There is no tier on which we do not. See below — this is the one most people get wrong.
• A judge model sees some of your outputs. Most calls are not evaluated, but some are (Terms §11).
• Erasure is real and covers output on every tier — but it does not reach your templates, which are retained verbatim on every tier including private.
• Pooled statistics survive erasure. We can delete your content; we cannot un-derive an average.
• We do not currently offer the service for personal data subject to the EU or UK GDPR (Privacy §10, DPA §12.5).

Your tier decides what we keep

The following restates the grant table in Terms §6.1. It is described there as a rendering of a single retention matrix in the service’s code, applied at one write chokepoint.

Four consequences worth reading twice:

• An unknown or unreadable tier is treated as private — the most restrictive setting, never as free (Terms §6.3).
• The table applies from the moment a tier takes effect, not from the moment you accept the matching data-grant document (Terms §6.1).
• Tier changes are forward-only. Moving to private does not re-classify data already written and does not withdraw verdicts already pooled (Terms §6.4, §8.2).
• Cancelling a paid tier moves you to the free tier’s grant at the same time as its limits, so from that point your future traffic is pooled traffic (Terms §14).

What free costs you instead of money

On free and only on free, we retain your prompt text and use it for our own purposes: re-executing it against newly introduced models to measure them (“model-introduction replay”), and developing the canonical taxonomy. That reuse is the consideration for the tier (Terms §6.5).

That replay runs on our provider credentials against a roster we choose, returns you nothing, and is not billed to you. On that path the model providers are our subprocessors. If you do not want your content to travel that path, do not use free.

Because that prompt text is used for our own purposes, we are not acting as a “service provider” under the CCPA in respect of it. The same is true of template content on free and shared_anon, used for taxonomy. We still do not sell or share either. If you need service-provider treatment for everything you send, use private (Terms §6.5, DPA §6.4).

Common-capability adoption — the widest grant on free and shared_anon

On free and shared_anon, if we determine that a capability you defined is suitable to become part of the canonical library, you grant us a right to reproduce, publish and redistribute that capability’s template text verbatim — including serving it, unmodified, to any other customer whose calls route to that canonical capability. We decide, at our discretion; you get no notice, credit or compensation. To the extent it is published under that licence, it is no longer confidential (Terms §9).

If your template text is commercially sensitive, do not put it on free or shared_anon. On private, no republication licence applies and template text is not used for taxonomy at all.

Model output: written on every tier, deleted once you have it on the paid tiers

The intuitive reading of “private” is that nothing is stored, and it is wrong in one respect: an output has to be written, on every tier, for the time it takes to deliver it (Terms §7, Privacy §5). Three paths rebuild your own deliverable from stored output after the call has finished:

1. Webhooks. Delivery records are deliberately content-free; the payload we sign and POST is rebuilt from stored output at send time.
2. Batch output files. The output file is rendered from stored outputs when the batch finalizes.
3. Your own retrieval. You can ask for a past call and get its output back, for as long as we still hold it — which is also the recovery path when a webhook delivery is lost.

Beyond those three, stored output is used for the evaluation and judging you instruct, and — on free only — as a comparison baseline in model-introduction replay. For nothing else.

On shared_anon and private, retention is bound to delivery (Terms §7.1). We delete the output of a call promptly — typically within minutes — once it has been delivered to you and any evaluation of it has finished. An output we could not deliver is held for you to retrieve for at most 72 hours, then deleted. What that means in practice:

• Keep what you fetch. A synchronous response is delivered when it is written to you; a webhook result when your endpoint acknowledges it; a batch result when you fetch its output file. There is no retrieval of a past output after that. A retrieval of a deleted output returns the call’s record with output_purged: true and no parsed field.
• Batch output files are fetched-once-then-gone. A file stays fetchable for a short grace after your first fetch, so a download broken in transit can be retried; then the blob goes. The batch’s input file (your prompts) is deleted as soon as every line has finished.
• Evaluation finishes first. A call selected for evaluation keeps its output until the judge has produced its verdict — ordinarily seconds, at most a day. The verdict survives; the output does not.
• The one exception is yours. A task model you judge on your own criteria keeps a copy of each evaluated exchange for the review window you set (Terms §11; see Evaluation review below).

On free, output is retained until erasure or account closure — it is the replay baseline that pays for the tier. Once delivery is complete we may also delete it at our discretion to manage storage.

This is a schedule we enforce with a continuous sweep and monitor, not an intention. If it ever lengthens, that is a new version of the Terms; shortening it is not.

Evaluation review, and your prompt template

Your own evaluation criteria. When you write your own evaluation criteria for a task model, its verdicts stop pooling with other workspaces and stay yours. So that you can improve those criteria, we keep a copy of each evaluated exchange on that task model — what the judge was shown, the candidate outputs and the verdicts — for a review window you control, up to the maximum shown in the console, and delete it when the window closes. It opens automatically the first time you set your own criteria; you can shorten it, including to nothing, and you cannot lengthen it past the maximum. On shared_anon and private a judge grading a single answer is not shown your prompt, so that copy carries no request text; a comparison of several candidate answers is, and the copy carries what the judge saw. The console’s task-model page shows the exchanges; GET /management/capabilities/{slug}/evaluations returns them.

Your prompt template. On free and shared_anon your template is compared with the canonical task library once, within a bounded period of the task model’s creation, to map it and decide whether to adopt it (Terms §9). When that is done, everything we kept for the comparison is deleted and the template text becomes yours to delete — from the task-model page or DELETE /management/capabilities/{slug}/template. On private there is no evaluation and you can delete the text at any time. Deleting the text does not delete the content-free record of which version ran a call, it does not un-adopt a template already adopted into the library, and it switches the task model off until you register a new prompt. Erasure blanks template text too.

What “never stored” does and does not mean

On shared_anon and private, prompt variables are dropped at the moment the call record is written — not written and later deleted. It does not mean the prompt never exists in our systems. Three real qualifications (Terms §6.2, Privacy §4.3):

• Worker memory. Your prompt is necessarily in memory while the call is served, including when we retry or fail over to a second model within the same request.
• Batched calls hold a working copy. A batch submission has to keep its rendered request — the provider submission reads it back and a retry needs it again. That working copy lives on the call record’s operational metadata on every tier including private, is stripped when the batch finalizes, and is stripped again by a daily sweep that catches anything left behind and anything still in flight after 72 hours. A batch also carries a hard 24-hour expiry backstop. For batch traffic, “never stored” means “not stored beyond the operational window” — hours to a couple of days.
• shared_anon retains a routing embedding, for a bounded purpose. An embedding is partially invertible, so it is treated as content rather than metadata — which is why erasure hard-deletes it rather than blanking it. It is kept only as material for the one-time library evaluation of the capability it was routed to, and deleted when that evaluation is done. private retains no embedding.

Two further things are retained regardless of tier:

• Benchmark (“golden”) sets you upload are exempt from tier retention limits, on every tier including private, because re-running them is the point. Uploading requires an explicit acknowledgement of that exemption, recorded with who gave it and when, and a run whose set carries no acknowledgement is refused (Terms §6.2, Privacy §7.2A).
• A capability’s own definition — slug, display name, description — is indexed for routing on every tier including private. It is configuration you author to declare what a capability is, and the routing index cannot function without it (Terms §9, Privacy §6).

How long we keep things

Who else sees your data

Model providers — which mode served the call decides everything

Every capability declares its access mode, and the mode is visible to you on the capability (Terms §5).

Two things you have to act on yourself in bring-your-own-key mode:

• Unpaid provider tiers. At least one provider — Google’s Gemini API — applies materially different data-use terms to unpaid projects, under which it uses submitted content and generated responses to improve its products and human reviewers may read, annotate and process API input and output. The service does not detect the billing status of a credential and cannot warn you. Choosing a paid provider project is your responsibility (Terms §5.1).
• Regional restrictions. Some providers restrict which of their tiers may serve users in particular regions. Complying is your responsibility.

The registered provider set is Anthropic, OpenAI, Google (Gemini), Groq, Meta, xAI, Perplexity, OpenRouter, DeepSeek, Moonshot AI, Z.AI, MiniMax and Alibaba Cloud (DashScope). Which of them are enabled for your account is your choice in bring-your-own-key mode.

The service also supports a zero-custody mode, in which a provider credential is supplied on a per-request header, used for that request only, and never written to storage. It cannot be combined with a vaulted credential on the same account (Terms §5.1).

Judge models

When a call is evaluated, the output is sent to a judge model — another model — which scores it. Most calls are not evaluated; the rate depends on how much evidence we already have about the models eligible for that capability, and it is controlled by policy rather than configured per call (Terms §11).

We do not evaluate your output in the same judge request as another customer’s, on any tier, today. On private that is unconditionally forbidden. On free and shared_anon, the DPA’s shared-judging exception already permits it — a standing legal permission, not a description of current behaviour — and the Terms state the reservation to enable it on those two tiers only, never on private. If we do, the judge sees outputs and not your identity (Terms §11, DPA §4.2(c)).

Infrastructure subprocessors

All of our own infrastructure and all of our infrastructure subprocessors are in the United States (Privacy §7.3 and §10, Subprocessor Register ). Model providers are a separate case — see above, and see the transfers section at the end of this page.

We give at least 30 days’ notice before adding or replacing a subprocessor, by email to the account address and by updating the register. You may object on reasonable data protection grounds within that period; if we cannot resolve the objection, you may terminate the affected service without penalty.

Stripe is not our subprocessor. Billing contact and payment data are collected by Stripe through a Stripe-hosted checkout; card and bank details never reach our systems. For that data Stripe acts as an independent controller under its own terms (Privacy §7.3).

The public benchmark site

The public rankings are generated from an immutable snapshot of aggregate statistics. The published artifact contains no customer prompt or output text — judge-derived scores are numbers. Published rankings name providers’ models; that is comparative commentary about third-party products, not a disclosure about any customer (Privacy §12).

What you must not send us

You are responsible for what you submit, and we have no technical means of detecting a breach of these — the service imposes no schema on prompt content (Terms §4, DPA §3.4):

• Any personal data at all on the free tier.
• Personal data of any kind inside a template, on any tier including private — because template text is not reached by the automated erasure.
• On any tier, unless we have agreed in a signed written amendment: HIPAA-regulated health information, PCI cardholder data, GLBA-regulated information, government-issued identification numbers, biometric identifiers, or the personal data of children under 13. That amendment is available only where the DPA has been executed by signature on the private tier.

Deletion

On a verified request, or on account closure, we erase the content we hold for you. Erasure completes within 30 days (Terms §12.1, Privacy §8.1, DPA §8.2). On request we provide a report of what was erased and what was retained.

What erasure covers

• Every call record’s prompt text, content-bearing metadata (including batch working copies) and model output — the last of these on every tier, because the retention matrix governs what we keep by default while erasure is you overriding it. Where a payload has been archived to object storage, the blob itself is deleted, not just the reference;
• evaluation dispatch input and output excerpts, and fan-out judge candidate and winner payloads;
• routing embeddings — hard-deleted, not blanked, because an embedding is partially invertible;
• batch API content at rest: uploaded input blobs and rendered output and error files deleted, rows tombstoned, per-line request bodies blanked;
• vaulted provider credentials — the encrypted secret and its wrapped data key are destroyed, so there is nothing left to decrypt;
• the incidental metadata (IP address, user agent) attached to your consent records and to your signup registration record.

Because several of these tables are append-only by design, erasure overwrites fields rather than deleting rows. The procedure defaults to a dry run and refuses to run against our own operator account.

What erasure does not reach

These are listed because the alternative is a promise that would be broken. No warranty is made that your content is absent from them (Terms §12.2, Privacy §8.2, DPA §8.3):

If you need any of these erased, contact us and it will be treated as a specific request rather than declined — but it is not represented as automatic.

What survives, and why

We can delete your content. We cannot un-derive an aggregate. That asymmetry is stated identically in the Terms and the Privacy Policy, and it is a structural property, not a hedge (Terms §12.3, Privacy §8.3).

• Verdicts and the aggregates computed from them. A verdict is a fact about a model — “model X scored 0.72 on capability Y” — computed across many contributors. Once pooled, the aggregate cannot be un-derived: we can recompute the average without your verdicts, and will where erasure requires it, but the recomputed number is a new number. It does not undo routing decisions already made, models already retired, or rankings already published. The erasure report counts these rows explicitly.
• Aggregate usage and billing records, for the period required by tax and accounting law. The metered counts that are the evidence for invoices already issued are integers and rates, never content, and erasure deliberately does not reach them.
• Access and audit records, including the append-only record of every time one of your provider credentials was decrypted and by which subsystem.
• Consent records — the fact that you accepted a specific version on a specific date is the basis on which we processed your data. On erasure the incidental metadata attached to them (IP address, user agent) is purged and the fact of acceptance is kept.

Get your data out first

Following termination you get at least 7 days’ written notice before erasure begins. On written request made before then, we will provide within 14 days a copy of your retained prompt text, model outputs, batch API input files, benchmark sets and templates in a structured, machine-readable format. While such a request is outstanding, erasure does not begin and the 30-day period is extended. Provider credentials and webhook signing secrets are not exported (Terms §12.1, DPA §8.1).

Pooling is irreversible

If your account is on free or shared_anon, the verdicts produced when your calls are evaluated are contributed to a cross-customer pool. That pool decides which models the service routes work to, and it is the basis of the public rankings.

A pooled verdict contributes only the judged model, the capability and the score. The judge’s rationale is not pooled. It carries neither your identity nor your content (Terms §8.1).

A verdict pools only if all four of these hold at the moment it is written:

1. your account’s statistics scope is global — that is, free or shared_anon;
2. the capability exists and is active;
3. the capability maps to a confirmed canonical capability (raw, unmapped capability names never pool);
4. the judging panel is your account’s ordinary production panel (shadow and experimental panels never pool).

Anything else, and the verdict stays in your account.

Verdicts already contributed will not be un-pooled. Changing your tier, or leaving, changes what happens to future verdicts. This is a commitment about what we will do, not a claim about what is technically possible: un-pooling is mechanically possible, it is reserved for repairs and for honouring erasure requests where we determine it is required, and it is not offered as a customer-triggered right (Terms §8.2).

If you do not want to contribute, that is exactly what private is for.

Security, and what we do not claim

Each of these is a description of the running system (Terms §13, Privacy §9, DPA §9):

• Tenant isolation enforced at the data-access layer; every deliberate cross-account read must appear in a reviewed allowlist that an automated test enforces — both new entries and stale ones fail the test suite.
• Provider credentials at rest: a fresh 256-bit data key per credential, AES-256-GCM over the secret, and the data key wrapped by your account’s own key-encryption key in Azure Key Vault. The key-encryption key never leaves the vault, no plaintext is stored, and decryption fails closed — a vault outage fails the call rather than falling back to any other key. Only the last four characters are stored for display. Every materialization of plaintext writes an append-only audit record naming purpose, provider and capability, never key material.
• API keys at rest: a SHA-256 digest only, plus a short display hint. A key is displayed once at creation and cannot be recovered — only revoked and replaced.
• Webhook destinations validated at registration as HTTPS-only and public-IP-resolving, as a server-side request forgery guard. Signing secrets are vaulted and shown once; the endpoint record holds a pointer, never the value.
• Error reporting runs with default personal-data capture disabled. Two composed scrubbing layers then redact secret-bearing field names and provider-key, authorization and cookie headers, and scrubbing fails closed — a failure destroys the carrying fields, and failing that the event is dropped.
• Retention decisions enforced at one write chokepoint that fails closed on an unknown or unreadable tier.
• Content is not logged — prompt variables, batch messages and content snippets are excluded from application logging by policy. That is a policy, not a mechanically enforced invariant, and it is not warranted that content can never appear inside an exception message produced by an upstream component.

Security incidents. We notify you at your account email address within 72 hours of becoming aware of a breach affecting your content. Detection is alert-driven rather than a continuously monitored security operations function, so the 72 hours run from actual awareness.

What we do not have, and do not claim. No SOC 2 Type II and no ISO 27001 certification. No representation that we conduct third-party penetration testing, formal business-continuity or disaster-recovery testing, or that we maintain documented recovery point or recovery time objectives. We have not verified whether database-volume encryption at rest is enabled by our hosting provider — the encryption described above protects provider credentials specifically, not the datastore as a whole. Any of this will be published when it changes.

Audit. On written request you get our then-current architecture and security documentation, the subprocessor register, and — for your own account — a report of what was erased and what was retained. On 30 days’ notice, and no more than once in any 12-month period, you may assess our compliance with the DPA at your own expense; more often following a security incident affecting your content, or where you have a reasonable and documented belief that we are not complying (Terms §13, DPA §13).

Where your data is, and the GDPR position

All of our own infrastructure and all of our infrastructure subprocessors are in the United States (Azure Central US; error monitoring in Iowa). Model providers are the separate case set out below.

We do not currently offer the service for personal data subject to the EU or UK GDPR. The DPA does not incorporate the Standard Contractual Clauses or the UK International Data Transfer Addendum, and such processing requires the applicable instrument to be executed as an addendum first. Contact us before sending such data through the service (Privacy §10, DPA §12.5).

Model providers: establishment and serving location are different questions.

• Establishment is the domicile of the contracting entity, and determines which legal system can compel it to disclose data regardless of where the data sits. The providers established in the People’s Republic of China are DeepSeek, Moonshot AI, Z.AI, MiniMax and Alibaba Cloud. The remainder are established in the United States or the European Union.
• Serving location is where inference actually runs, and does not follow from establishment. Several providers, including PRC-established ones, operate region-scoped endpoints elsewhere.
• A provider established in one jurisdiction and serving from another may remain subject to the laws of the jurisdiction where it is established. Choosing a non-PRC endpoint of a PRC-established provider addresses where the data sits; it does not by itself address the reach of PRC law over the provider.

Who chooses. In bring-your-own-key mode the credential you supply is bound to a specific regional endpoint, so you select both the provider and the serving region, and the transfer is made under your own agreement with that provider. On the operator-supplied path and on free-tier replay, we are the exporter and we choose the endpoint.

We surface the serving region for each provider and model where the provider makes it determinable, and indicate where it does not. That comes from the provider’s own documentation and endpoint configuration; we do not independently verify it (Privacy §10, DPA §12.3).

Exercising your rights

Write to privacy@kapualabs.com . For data we hold as controller we respond within 30 days, extendable by a further 45 days where a request is complex; we will tell you if we extend. We will ask you to verify your identity, typically by confirming control of the account email address, and may decline a request we cannot verify. An authorized agent may act for you on written proof of authority.

We do not sell personal information and we do not share it for cross-context behavioral advertising (Privacy §8.4).

Two practical limits, stated plainly:

1. For call content we act as a processor on our customer’s instructions. If your data reached us inside a customer’s prompt, that customer is the controller and the request belongs to them. We will assist them, and we will forward a request we receive directly.
2. Prompt content is unstructured and we apply no schema to it, so we cannot search a tenant for the records relating to a particular individual. What we can do is erase a whole tenant, erase or amend a record identified to us by identifier, and provide the compliance information in DPA §13. If your own obligations require record-level mapping, you have to maintain it (DPA §4.4).

You can also retrieve your own call records through the API, which covers much of access and portability in practice, and export your content before erasure.

Contacts. Privacy and data requests: privacy@kapualabs.com · General and legal notices: llmbench@kapualabs.com · Support: support@kapualabs.com . The support table and the uptime target are in Terms of Service §15 ; read the figures there rather than relying on a summary.

Versions and changes

Each legal document is versioned by date, and exactly one version of each kind is current at any time. Where consent is the basis for processing, it is recorded against a specific version: accepting one version does not carry to the next, and we re-prompt and record a fresh acceptance on a version change.

We give at least 30 days’ notice of a material change by email to account owners and by notice in the console, except where a change is required by law or addresses a security issue. The DPA is amended differently — see Terms §22 and DPA §14.4.

Check the documents themselves for the current version. This page is a summary and may lag them.