Privacy & security

Privacy in AI inference: retention, training, and isolation

Every request you send to an AI service hands someone your data to process. Before you send a million records, find out five things: how long it is kept, whether it trains a model, who can read it, whether it lands in logs, and how it is encrypted. Here is what to ask, and why each answer matters.

5 min read Updated 16 October 2026

The questions that actually matter

Privacy is not one question but five, and two providers can answer them very differently:

Retention: How long are your inputs and results stored after the job, and where?
Training: Is your data ever used to train or fine-tune a model?
Access: Who or what can read your data while it is processed, and is it kept apart from other customers’ data?
Logging: Do your prompts or results end up in logs?
Encryption: Is the data encrypted while it travels and while it is stored?

Read the terms closely. On some services the answers change with the plan or the endpoint you use, and the default is not always the most protective setting.

Why training is not an abstract risk

Of the five, training is the one people tend to wave away. It should not be: a model trained on text can be made to repeat that text. The best-known study pulled real data out of a production-scale model using nothing but ordinary queries, including:

personally identifiable information (names, phone numbers, and email addresses), IRC conversations, code, and 128-bit UUIDs
— Carlini et al., Extracting Training Data from Large Language Models (USENIX Security 2021)(opens in a new tab)

What matters for your risk assessment is how little it took. The attack worked on sequences "included in just one document in the training data". Your record is not safely lost in a sea of others: a single record, seen once, can come back out. That is why "is my data trained on?" deserves a written answer, not a reassuring one.

Why open models on controlled compute help

With a proprietary AI service, your data goes into systems you cannot see, run by a company whose model and data handling you cannot inspect. Open models (models whose weights anyone can download) change that. The model runs on machines the platform itself controls, your data never goes to another company’s model, and when the code that handles your data is open, you can check what it does instead of taking it on trust.

Tenant isolation and minimization

The strongest privacy setups do not rely on a policy someone has to follow. They build the protection into how the system works:

A key per customer: each customer’s data is encrypted with its own key. Someone who reached another customer’s stored files would find only data they cannot unlock, so the protection survives a mistake in access controls.
Minimal exposure: a machine processing your work gets only the one job it is running and a short-lived key that opens only that job, never other customers’ keys or the rest of your data. A compromised machine exposes at most what it was working on.
No content in logs: operational logs record job IDs, token counts, models and error types, never the text of prompts or results.
A fixed deletion schedule: inputs and results are deleted automatically after a stated period, rather than kept until someone remembers to clean up.

A privacy checklist before you send data

Retention: how long is data kept, and can you have it deleted on request?
Training: get "never trained on" in writing.
Isolation: is your data kept apart by encryption, or only by access rules?
Logging: is the content of prompts and results kept out of logs?
Encryption: in transit, at rest, and limited key access on the machines doing the work.
Checkable, not just promised: open code lets you verify the claims instead of trusting them.

How Otium answers the five questions

Retention: Inputs, results and batch files, and a workflow’s inputs and step outputs, are kept for 30 days after the job finishes so you can collect them, then deleted. Job IDs, token counts and cost are kept for billing. Workflow assets you publish to reuse are kept until you purge them, and an account with its own agreed window gets that instead.
Training: Never. We run open models we did not train.
Access: Each customer has its own key, and each machine sees only the job it is running.
Logging: Prompt and result content is never written to logs.
Encryption: Encrypted on its way to us, while stored, and on its way to the machine that processes it.

Notifications follow the same rule: a webhook tells you a batch has finished and carries identifiers and counts, never your content. The full details are on the privacy page.

Sources

Sources and further reading

Extracting Training Data from Large Language Models(opens in a new tab)
Carlini, Tramer, Wallace, Jagielski et al., USENIX Security 2021. Word-for-word extraction of training data, including personal information, from a production model, for sequences that appeared in a single document.
Regulation (EU) 2016/679 (GDPR), official text(opens in a new tab)
The source rather than a summary of it. Chapter IV covers controller and processor obligations, which is the frame your inference provider sits in.
Who is actually running your inference?
The gap none of the five questions closes: a model needs your prompt in readable form, on a specific machine.
Data residency: pick a boundary, not a region
The legal-location half of the same problem.

Frequently asked questions

Is my data used to train the model?

It depends on the provider and the plan, so get an explicit answer in writing. A batch platform built on open models has no reason to train on your data, since not keeping it is cheaper and carries less liability, so "never trained on" is a fair bar to insist on.

What does cryptographic tenant isolation mean?

Each customer’s data is encrypted with its own key. If someone reaches another customer’s stored files, they find only data they cannot unlock, so the separation holds even if an access check fails, rather than depending on policy alone.

How long does Otium keep my data?

Inputs and results are deleted 30 days after the job finishes; until then you can collect them. Billing metadata (job IDs, token counts, cost) is kept. Workflow assets you publish are kept until you purge them.

Related guides

Who is actually running your inference?

Encryption does not protect a prompt during inference: the model needs plaintext in memory. That makes the machine, and whoever controls it, part of your risk.

Data residency for AI inference: pick a boundary, not a region

Compliance obligations are jurisdictional, not regional. Why a residency boundary is the right primitive for AI inference, and how a lock must behave.

A security review checklist for an AI inference vendor

The questions a security reviewer should ask any AI inference vendor, what a good answer looks like, and the three things no vendor can honestly promise.

Prompt injection in AI pipelines versus agents

An injected instruction can only do what the system around the model allows. Where the three ingredients of an attack live in an agent loop and a fixed graph.

Open-weight vs. proprietary models: when open is enough

Open-weight models are competitive on many batch tasks. The real trade-offs in cost, control, privacy and quality, and how to measure them on your workload.

What is batch AI inference?

Batch AI inference runs large volumes of requests against a deadline instead of in real time. How it differs from interactive inference, and why it costs less.