Together AI Data Privacy: Sub-Processors, Shared Inference, and the Model Catalog Problem (2026)

Together AI's value is breadth: hundreds of open models behind one key, one billing relationship and one wire format, on shared serverless capacity or dedicated instances depending on what you pay for. Breadth is exactly what makes the privacy analysis different from a single-lab provider. When someone asks who processes our data, the honest answer has more than one part, and the part that changes most often is a string in a config file that any engineer can edit without triggering a review.

The short version

Answer the sub-processor question explicitly and write the answer down, because a catalog provider has a supply chain and a single-lab provider mostly does not. Know whether you are on shared serverless inference or a dedicated endpoint, since they are different blast radii and different arguments in a procurement review. Pin the model string and treat changing it as a change with a privacy consequence, not a performance tweak. And redact at the boundary regardless, because that control survives every catalog change.

A note on scope. This guide is about the data you send and what happens to it -- a different concern from prompt injection, which is about untrusted input coming the other way, and from credential handling, which is about who can make the call at all. It is also not legal advice: it is the set of questions an engineer should be able to answer before a lawyer is asked anything, and the code changes that make those answers short.

The Four Questions That Actually Decide It

Most privacy conversations about an LLM API sprawl because they mix four separate questions that have four separate sources of truth. Separate them and the work becomes tractable, because each one has a specific document or a specific code change attached.

Question	Where the answer lives	What to do with it
Training use -- can my content improve the service?	Current terms and DPA, for your tier	Save a dated copy; enable any opt-out as a deployment step with an owner
Retention -- how long does the request body exist?	DPA, not the dashboard	Make your privacy notice agree with the number; design so the window does not matter
Sub-processors -- who else touches it?	Published sub-processor list	Subscribe to change notifications; mirror the list in your own data map
Residency -- which jurisdiction ran the inference?	The endpoint and deployment, not the company address	Re-verify on every tier, region or platform change

Three of those four are answered by reading a document someone else wrote, which means they can change without you doing anything. Only the fourth column contains work you control -- and there is a fifth question, absent from every vendor document, that you control entirely: what did you send in the first place.

Redact at the Boundary, Not in the Postmortem

The highest-leverage control here is unglamorous and takes an afternoon: route every outbound Together AI call through one internal client, and make that client the only place in your codebase that knows how to build a request. Give it four jobs. Pseudonymise identifiers -- names, emails, account numbers, internal ids -- swapping in per-request tokens and keeping the mapping in your own database so you can re-substitute in the response. Drop payloads nobody meant to send, particularly whole file bodies that reached the prompt because passing them through was easier than extracting the three fields the feature needs. Cap size, since an unbounded prompt is both a cost bug and a disclosure bug. And reject patterns your policy forbids outright, loudly, in tests.

What makes this worth doing first is that it is the only control in this guide that survives everything else changing. Terms get revised, tiers get migrated, endpoints move region, sub-processor lists grow. A prompt that never contained a customer's name is unaffected by all of it, and a retained log full of pseudonyms is a much smaller conversation in a security review than a retained log full of customers.

Then apply the same discipline to your own systems, because this is where teams that did everything else right still end up with the data. Application logs, exception trackers and distributed traces routinely capture full request bodies by default. A provider with impeccable retention practices does not help you when the same prompts sit in three internal tools with a longer retention window and a wider access list than the provider has. Scrub at the logging layer, and write a test that fails if a known sentinel value reaches your log sink.

Six Ways This Goes Wrong, All Returning 200

Symptom	HTTP	Usual cause	Fix
Full customer record pasted into a prompt template	200	Prompt built by string interpolation over a database row	Build requests through one boundary client that pseudonymises identifiers before serialisation
Prototype on a free key pointed at production data	200	Free and evaluation tiers can reserve broader rights than paid tiers	Separate keys per environment; block production data sources from non-production keys
Full prompts and responses in your own error tracker	200	Default exception capture serialises the whole request object	Scrub request bodies at the logging layer; assert on it in a test
Attachment or document body forwarded wholesale	200	Upload path passes the file through untouched to save an extraction step	Extract only the fields the feature needs; cap payload size at the boundary
Residency claim in the data map no longer true	200	Tier, region or deployment changed without a code change	Re-verify processing region per endpoint on every plan or platform change
Deletion request cannot be satisfied	200	No mapping from a user to what was sent or derived	Pseudonymise at the boundary and keep the mapping; cascade deletion to derived stores

Every row returns a successful response. That is the whole difficulty of this subject: there is no error to alert on, no retry to write, no status page to check. The only detection mechanism is a control that runs before the request leaves.

The Together AI Trap: The Catalog Is the Supply Chain

With a single-lab provider, who processes this data has one answer plus a published sub-processor list. With a marketplace, the shape of the question changes: you are contracting with the host, the host serves models from many upstream sources, and the entry your config points at can be added, updated or retired on a schedule that has nothing to do with your release calendar. Your contractual counterparty is stable. Your processing arrangement is only as stable as the catalog entry you named -- and the difference between those two sentences is where most catalog-provider privacy surprises live.

The practical consequence is that model selection is a governed change. An engineer swapping one open model for a better-benchmarking one is doing something that looks like a performance tweak and is, on a marketplace, potentially a change of processing path. Pin exact model identifiers, keep the pinned list somewhere a reviewer can read, and require the same lightweight approval to change it that you would require to add a new sub-processor -- one line in a review checklist, not a committee. Then poll the model list and diff it, so a retirement or a silent repoint is something you discover in CI rather than in an incident.

The second Together-specific decision is shared serverless capacity versus dedicated endpoints, and it deserves to be made deliberately rather than by default. Shared inference is cheap, elastic and completely reasonable for most workloads; dedicated capacity gives you a materially simpler story about isolation, a cleaner answer in a security questionnaire, and usually a firmer contractual footing for retention terms. The mistake is not choosing shared -- it is choosing shared for a workload whose data you have promised customers is isolated, and only discovering the mismatch when their auditor asks you to describe the tenancy model in writing.

What to Record

Keep four things where an auditor, a customer's security team or your future self can find them in a minute: the dated copy of the terms and DPA you relied on; the tier, endpoint and model identifiers you actually call, since those are what your residency and sub-processor answers are keyed to; the redaction rules your boundary client enforces, with the tests that prove it; and the retention windows for every store that holds a copy -- the provider's, yes, but also your logs, your traces and any derived index.

What none of that gives you is a timeline of Together AI's own behaviour, because your logs only contain your traffic. That gap matters more than it looks: when something goes wrong, the first hour is spent establishing whether the problem was yours or the provider's, and an independent record answers it immediately instead of by reconstruction.

Frequently Asked Questions

Who actually processes my data when I call Together AI?

Together AI as the host, plus whatever infrastructure sits in its published sub-processor list, and the analysis is keyed to the specific model entry and deployment tier you named rather than to the vendor in the abstract. That is the material difference between a marketplace and a single-lab provider: the contract is with one company, but the processing path is described by a catalog entry that can change. Get the sub-processor list, subscribe to changes if the provider offers notification, and record in your data map which model identifiers and which tier -- shared serverless or dedicated -- you are actually on.

Does Together AI train on my prompts?

Take this from the current terms and data processing addendum for your tier rather than from any general statement about open models, and check whether free and evaluation tiers differ from paid ones -- that gap is where most accidental exposure happens, because prototypes on free keys get pointed at production data long before anybody re-reads the terms. Note that the answer covers the host's use of your requests; the licences on the open models in the catalog are a separate matter governing the weights, not your data.

Are dedicated endpoints more private than shared inference?

They give you a simpler and stronger story, which in practice is most of what an enterprise reviewer is buying. Dedicated capacity means your workload is not sharing an inference instance with other tenants, which narrows the blast radius of an isolation failure and usually comes with firmer contractual commitments on retention and access. Shared serverless is not inherently unsafe, and for the majority of workloads it is a perfectly defensible choice. What is not defensible is promising customers isolation you did not buy -- so decide it explicitly, price it, and make sure the answer in your security questionnaire matches the tier in your account.

Does switching models on Together AI change my privacy position?

It can, which is why model selection belongs in change control on a marketplace even though it feels like a tuning decision. A different catalog entry can mean a different upstream source and a different processing path even though your key, your endpoint and your code are unchanged. Pin exact identifiers rather than aliases, keep the pinned set in a file a reviewer can read, poll the model list and diff it so retirements and repoints surface in CI, and require the same one-line approval for a model change that you require for adding a sub-processor.

What should I redact before sending to Together AI?

Everything the feature does not need in order to work, enforced in one place. Route every outbound call through a single internal client that pseudonymises names, emails, account numbers and internal ids, drops attachments nobody meant to send, caps payload size, and rejects patterns your policy forbids. This is the only control in this guide that survives a catalog change, a tier change and a terms revision without you doing anything, which is exactly why it should be the first thing you build rather than the thing you promise to add later.

Does a Together AI outage put my data at risk?

No -- availability and confidentiality are separate concerns with separate obligations, and the useful thing an outage record gives your privacy programme is timeline evidence. Knowing exactly when api.together.xyz started failing lets you state which requests were affected, rule the provider in or out quickly, and avoid the far more common failure of degrading into a fallback provider you never put through a privacy review at all.

Related Guides

A Fallback Provider You Never Reviewed Is a Privacy Change Made Under Pressure

The moment Together AI degrades, someone reaches for a fallback -- and that decision is made in minutes, by whoever is on call. API Status Check probes api.together.xyz and the rest of your stack independently and alerts on latency and errors, so the failover is a planned path you already reviewed rather than an improvisation at 2am.

Start Your Free Trial →