Data Handling

This page covers what AI Setu stores about your requests, for how long, and where. It describes the current, verified behavior of the platform — not a final, binding legal document. See your Data Processing Agreement for the contractual terms.

What's logged for billing and observability

Per-request operational logs and the usage ledger record ids, provider and model, status, latency, token counts, cost, cache outcome, and the metadata tags you send (an allow-listed set of short key/value pairs) — not your prompt or response text. Error messages returned to you never echo raw prompt or response content either.

You can browse, filter and export these records for each workspace, and the retention window is documented in Request Log, Export and Retention.

What's cached, and for how long

Enabling response caching does store response content temporarily:

• Exact-match cache — the full response body, keyed by a hash of your request (not the raw text), default TTL 600 seconds, capped at 24 hours.
• Semantic cache (opt-in) — the full response body plus an embedding vector of your prompt (not the prompt text itself), default TTL 10 minutes.

Both are scoped to your workspace and never served across workspaces or namespaces. Set x-ai-setu-cache: off on a request to skip caching entirely, or purge a workspace's cache on demand (see Caching).

When content leaves AI Setu's infrastructure

Two guardrail features you explicitly opt into and configure send content onward:

• Webhook guardrail check — if you configure one, the gateway posts the flagged text and request body to the URL you specify. AI Setu strips its own internal auth headers before forwarding, but your endpoint does receive the content.
• LLM-judge guardrail check — if enabled, flagged content is sent to another model through AI Setu's own normal provider routing (billed like any other request) to get a classification verdict — not a third-party leak, but content does make a second trip to an LLM provider.

Outside of these opt-in checks and the caching behavior above, your request and response content is used only to serve that one call and is not otherwise persisted by AI Setu.

PII and secrets

If you enable the PII or secrets guardrail checks, matched values (emails, credit card numbers, API keys, etc.) are redacted with an opaque token before being logged or returned — the raw matched value itself is never stored or echoed back, only the category and count.

Region

Production infrastructure runs in AWS us-east-1 (N. Virginia, USA). A key or ephemeral token minted for one gateway region is rejected with 421 (wesence.misdirected_region) if it reaches a different region's gateway — see Errors. Upstream providers (OpenAI, Anthropic) are called at their own standard public endpoints, which are US-hosted and so co-located with the platform; where a provider offers an in-region option (such as AWS Bedrock in us-east-1), routing to it depends on your BYOK and routing configuration — see Providers.

Deletion requests

AI Setu supports per-user erasure requests (relevant under India's DPDP Act and comparable regimes elsewhere): an erasure request immediately revokes the affected user's API keys within their own workspaces, then anonymizes their account and removes their workspace memberships on a scheduled follow-up pass. Contact your workspace admin or support to request one.

Deleting a workspace

Deleting a workspace is two steps, so a mistake is recoverable until you make it final:

1. deleteWorkspace (console, SDK or API) soft-deletes it: its API keys and every ephemeral client token (tt_ev_) minted from them stop authenticating at the gateway, no new ephemeral tokens can be minted from its keys, and its response caches are erased, but its rows stay for review. Metering rows (usage_events: tokens, cost, latency, your metadata tags; never message text) and request-log export files are kept.
2. purgeWorkspaceData(id, confirm) (GraphQL mutation; confirm must repeat id) permanently removes the deleted workspace's usage_events, its export rows and files, and its workspace- and tag-level budgets, and writes a workspace.purged audit event with the counts. The admin SDK's workspaces.purgeData(id) sends both for you.

Both steps follow the same permission rule. workspace:delete works on any workspace in the organisation; workspace:delete_own works only on workspaces created by the calling personal access token (the ownership-scoped grant meant for a runtime token that provisions one workspace per end tenant). A call that fails this check returns 403 before anything is deleted and writes no audit event.

How a purge call behaves:

• It refuses a workspace that is not deleted yet, and refuses (conflict) while a request-log export of the workspace is still pending or running: wait for in-flight exports to finish, then call again.
• Each call works for about 20 seconds at most. When rows remain (a very large workspace, or a concurrent purge), the result's truncated flag is true: call it again until it is false. Repeating a call is always safe.
• Export rows are removed only after object storage confirms their files are gone. If storage refuses a delete, the call fails with an external-service error, keeps the export rows, and is safe to retry.
• Every call that starts deleting writes one workspace.purged audit event, including a call that fails part-way (with the counts so far and the error).

What a purge does not remove yet (follow-up):

• Evals: datasets and rows (eval_rows.input, which can hold prompt text) and runs and results (eval_results.output, model output text).
• Prompt templates of the workspace (prompt_templates, their versions and folders), which hold prompt text.

If they hold end-user data, delete them with their own mutations (deleteEvalDataset, deletePromptTemplate, deletePromptFolder) before you call deleteWorkspace. Credit ledger entries and invoices are the organisation's settled money, not end-user data, and stay.

Use the pair to complete a tenant-level erasure of usage and request-log data when you run one workspace per end tenant. Without a purge, usage rows age out under the usage retention window instead.

Deeper reading

For the contractual retention, sub-processor, and jurisdiction-specific terms, see your organization's Data Processing Agreement and AI Setu's published privacy policy, both linked from the console's billing/legal settings.