Prompts and completions are not used to train any model, ours or a provider's. Beyond that, the honest answer depends on which product you're using — the direct API and the chat product handle content differently, so we describe both rather than paper over the difference.
Calls to api.inferencedirect.com are proxied straight
through to the model provider and back. The prompt and completion
text itself is never written to a database, cache, or log — the only
record kept is call metadata (token counts, model, latency, cost),
held for 7 days for billing and then purged.
Tenants can opt into short-TTL, tenant-scoped caching for deterministic calls (temperature 0, non-streaming) to cut latency and cost on repeated requests. It's off by default. When it's on, a matching prompt/response pair is held for the configured TTL, scoped so no other tenant can ever read it.
Unlike the raw API, the chat product keeps a full, indefinite record of your conversations — that's what makes search, project history, and picking a thread back up tomorrow possible. If you need content gone rather than merely inaccessible, that's a support request today; self-serve export/delete tooling is on our roadmap, not yet shipped.
Leaving or being removed from a team chat, or losing access to a project, revokes visibility into that conversation right away — both the app's authorization check and the underlying membership record enforce it, not just the UI.
Every tenant-scoped table is checked by a query-level guard, not just application logic above it — a second, independent layer that catches a cross-tenant query even if a handler above it has a bug.
Closing an account starts a 90-day window (for audit trail and accidental-deletion recovery), after which every row tied to that tenant — conversations, messages, knowledge, everything — is permanently purged, not just hidden.
Where caching exists at all (see above), cache keys are derived per tenant and per billing node — there's no code path where one tenant's cached response can be served to another.
Every response carries HSTS and standard hardening headers, and HTML responses are served with a per-response Content-Security-Policy nonce. All traffic is TLS.
Identity data, MFA secrets, Bring-Your-Own-Key provider credentials, and chat conversation content are individually encrypted (AES-256-GCM) before they're stored. Conversation content is additionally encrypted under a key derived per tenant (so one derived key compromise doesn't expose another tenant's data) and versioned, so the root key can be rotated without a hard cutover.
Route calls through your own OpenAI, Anthropic, Azure, Google, OpenRouter, or AWS account instead of the platform's. Details →
A billing node can be restricted to only route to catalog models we've flagged as zero-retention with their provider. That's a curated attribute reflecting the provider's own stated policy, not something we independently audit — and it governs upstream routing, not chat's own conversation storage above.
Inline prompt-injection, jailbreak, and PII detection on both sides of a call, configurable per tenant. Details →
InferenceDirect itself doesn't make automated decisions about people — it's an inference conduit: it routes your prompt to a model and returns the response. If a decision that produces legal or similarly significant effects on someone gets made using that response (a loan approval, a hiring screen, an eligibility determination), that decision is made by whatever application you or your organization built on top of the API — which makes you the controller responsible for any automated-decision-making disclosure or human-review obligations that apply to it, not us. We don't profile individuals or make those decisions ourselves anywhere in this platform.
We don't hold a SOC 2, ISO 27001, or HIPAA certification today. Where a page elsewhere references HIPAA, it's describing an account-level attestation a tenant makes about their own use of a feature, not a platform certification — we'd rather say that plainly than let the distinction blur. See the Privacy Policy for the full legal terms; this page is the plain-language version.