Groq Data Retention (2026): No Training by Contract, and an Off Switch You Can Reach

Short answer - what happens to audio you send Groq?

• Default, any paid or free GroqCloud account → not retained. No training, contractually. Inputs and outputs may be logged up to 30 days only if Groq is troubleshooting a platform failure or investigating abuse.
• With Zero Data Retention enabled → nothing retained for reliability or abuse monitoring at all. Batch and fine-tuning get disabled, which matters to nobody transcribing meetings.
• Where it goes → retained customer data sits in Google Cloud buckets in the US. There is no api.eu.groq.com. If EU-only processing is a hard requirement, this is the wrong provider.
• Nothing sent at all → still an option for meeting notes, because transcription runs fine on-device.

Bias first, because you should weigh everything after this accordingly: I make Humla, a Mac meeting notetaker that can use a Groq key or no cloud whatsoever, and I would love it if you downloaded it. So yes, I have a stake. What I can offer against that is receipts - everything below is quoted from Groq's own pages, checked 11 August 2026, with links, and you can go and disagree with my reading of them.

This is the third of these I've done (OpenAI, then Deepgram), and I went in expecting the third one to be the third flavour of the same disappointment. It wasn't. It also ends with me correcting something I said in the second one, which is the part I'd skip to if I were you.

The clause that does the work

Here's the thing that took me three of these posts to properly notice: it's not what a vendor promises, it's WHERE they put the promise. Most of them put the training commitment on a documentation page, and a documentation page is a thing that can be edited on a Tuesday afternoon by someone who doesn't have to tell you.

Groq puts it in the Groq Services Agreement (last modified 22 June 2026), section 4.2, which defines Inputs and Outputs as Customer Data and then says:

Groq does not access, use, store, or retain Inputs or Outputs except as necessary to provide the Cloud Services, in accordance with the Customer's permission or instruction, comply with applicable law, ensure the reliable operation of the Cloud Services, or confirm Customer's compliance with the AUP. […] For clarity, Groq is not permitted to use Inputs or Outputs for training or fine-tuning any AI Model Services or other models, unless explicitly granted permission or instructed by Customer.

That last sentence is the whole thing. It's a contractual prohibition, it applies to everyone who clicked through the agreement, and moving it requires amending a contract rather than editing a page. The same agreement also makes your Customer Data your Confidential Information and confirms you keep all intellectual property rights in both Inputs and Outputs.

Now compare the SHAPE of that to Deepgram, where the training default is disclosed in a footnote under a pricing table, and the way out is a query parameter on every request. Same category of product. Completely opposite theory of where a promise belongs.

(I want to be fair here: a footnote is still disclosure, and Deepgram did not hide anything. It's just that "we told you, technically, underneath the numbers" and "we signed something" are not the same species of telling.)

What "not retained by default" actually means

The Your Data in GroqCloud doc is unusually direct, to the point where I read it twice looking for the trapdoor:

By default, Groq does not retain customer data for inference requests.

Retention happens in two situations. The first is the boring one - features that structurally need to keep your data, so batch jobs (30 days) and fine-tuning (until you delete it). Neither is anywhere near transcription. The second is the one worth reading slowly:

We may temporarily log inputs and outputs only when troubleshooting errors that degrade platform reliability, or investigating suspected abuse (e.g. rate-limit circumvention). These logs are retained for up to 30 days, unless legally required to retain longer.

Read that as conditional and event-triggered, not as a standing 30-day log that happens to have a nice explanation attached. It's a materially different claim from OpenAI's, where 30 days of abuse-monitoring logs on /v1/chat/completions is just the normal path.

And now the awkward bit, which I'm including because leaving it out would make Groq look better than the documents do. Further down that same page there's a summary table listing the inference endpoints, /openai/v1/audio/transcriptions included, with "Data Retention Type: System reliability and abuse monitoring, Retention Period: Up to 30 days." Skim only the table and you'd walk away certain that 30 days is the default. The prose directly above it says the opposite.

The prose is the more specific statement, and it's the one the contract backs, so the prose wins. But the table is what people screenshot. Groq has built the rare documentation page that UNDERSELLS its own product, and I don't think anyone there has noticed.

Zero Data Retention is a checkbox here

This is the section that actually changes what a five-person shop should do, so I want to be exact about both what it says and what I could not check.

The docs promise it to everybody:

All customers may enable Zero Data Retention (ZDR) in Data Controls settings. When ZDR is enabled, Groq will not retain customer data for system reliability and abuse monitoring.

Turning it on disables the features that need persistence, and admins can flip it globally or per feature. For a transcription workload that trade costs you precisely nothing.

Put that next to the other two and the gap is not subtle. OpenAI's ZDR is, in its own words, "subject to prior approval by OpenAI and acceptance of additional requirements," which is a sentence that means "call sales" - I wrote last month that if you're a solo consultant wondering whether to tick the ZDR box, there isn't one to tick. Deepgram's control is self-serve but per-request, and self-hosting is Enterprise-gated. Groq appears to hand the strongest available setting to a developer with a credit card and no account manager, which as far as I can tell nobody else in this comparison does.

Two caveats I'm not papering over.

First: the Services Agreement doesn't match the docs. Section 4.2 says "Eligible Customers may enable Groq's zero data retention setting." Eligible. So I went looking for the definition, because agreements define their capitalised terms, that's the entire point of capitalising them. "Eligible Customer" appears exactly once in the whole document and is never defined. Not in the definitions section. Not anywhere.

So there's a ghost in this contract. An undefined term propping up the headline promise, doing nothing at all right up until the day it does everything. I don't think it's malice, I think it's a drafting leftover. But the docs say all customers and the binding document says eligible ones, and if those two ever have to be reconciled by a lawyer, it won't be the docs that win.

Second: the Data Controls page sits behind a login, so what I verified is the promise, not the toggle. I can tell you what Groq has published about ZDR. I can't tell you from first-hand experience that a free-tier account actually sees a switch there. If your policy depends on it, log in and look before you write the policy.

The three providers, side by side

Groq column read 11 August 2026; Deepgram column 4 August 2026; OpenAI column 28 July 2026. All three change - re-check before making a compliance decision.

The honest summary: Groq has the best default and the most reachable off switch, and the worst answer on residency. The other two let you pick a region. Groq doesn't have one to pick.

Where your audio physically goes

Groq is clear about retained data and vague about processing, and once you see that those are two different questions you can't unsee it.

Retained data: "All customer data is retained in Google Cloud Platform (GCP) buckets located in the United States." Transfers ride on standard contractual clauses, and the DPA (effective 15 October 2025) incorporates the EU SCCs, the UK International Data Transfer Addendum, Swiss FADP handling and Saudi PDPL clauses. The legal machinery for an EEA customer is properly assembled. It just terminates in America.

Processing: the DPA says Groq "may transfer and Process Personal Data to and in the United States and other countries where Groq or its Subprocessors maintain Processing operations," and the privacy policy (effective 12 November 2025) says Groq "maintains processing operations in various global jurisdictions." Neither one names them. Groq has a Saudi entity, and the Services Agreement carries Kingdom of Saudi Arabia regional terms, so "various" is doing some real load-bearing work in that sentence. From the published documents you can establish which country stores your audio if it gets stored, and you cannot establish which country transcribed it.

For a GDPR posture: US processing under SCCs is lawful and completely routine, and it is also not the same thing as EU processing. If your client contract says the second one, there is no Groq setting that gets you there.

Who else touches it: the subprocessor list runs to 20 entries, and reading it is a bit like reading someone's expense report. Stripe, Netsuite, Lago and Anrok for billing. Intercom and SupportNinja for support. Mailchimp, HubSpot and Salesforce for comms. Cloudflare out front, Stytch for identity, Wiz and PostHog internally. Nineteen of them are business plumbing that will never be within a mile of your audio.

The only infrastructure entry sitting in the path of an inference request is Google Cloud Platform. Four search-and-sandbox vendors do appear - Tavily, Exa, Anchor Forge, e2b - and the list scopes them to Groq's agentic Compound product rather than the transcription endpoint. Call /audio/transcriptions and they're not involved. Use Compound and three more companies are in your pipeline, which is a fine trade to make and a bad one to make by accident.

The DPA's security annex commits to encryption at rest and in transit and to "annual engagements of a qualified, independent external auditor […] including SOC 2 Type II certification audits." The reports themselves live behind a Request Access button on the Trust Center. That's completely normal and still worth saying out loud: the subprocessor list is public, the audit evidence is not.

What Groq doesn't publish

This list is short, which is the point - the other two vendors' versions of it were considerably longer.

• What makes a customer "Eligible" for ZDR. Our ghost, still undefined, still standing under the headline promise.
• Where inference physically runs. Storage is stated. Processing is "various global jurisdictions."
• A single deletion timeline. The Services Agreement says that on termination Groq "will delete any Customer Data […] within 30 days." The DPA says a customer deletion request gets honoured "as soon as reasonably practicable and within a maximum period of 180 days," with backups isolated rather than purged. Both are defensible. They are not the same number, and a procurement questionnaire is going to ask for one number.
• An opted-out price. There isn't one, because there's nothing to opt out of at list price. Groq's docs put whisper-large-v3-turbo at $0.04 per hour of audio and whisper-large-v3 at $0.111 per hour. Not a privacy discount, not a privacy penalty. Just the price. After spending a week with that Deepgram footnote, I found this weirdly moving.

The BYOK correction I owe you

In the Deepgram post I wrote that bring-your-own-key gets you an account, a bill and no unknown middleman, but not control over per-request privacy flags, because the app builds the URL and your key merely pays for it.

That was true. I stand by it for Deepgram. It was also too pessimistic as a general claim, and Groq is the counter-example that made me go back and reread my own sentence.

Groq's retention control is account-level, not per-request. It lives in your Console, on your account, and no application can set it, unset it, or quietly override it. There is no zdr=true parameter for a developer to forget on a Friday. Which means the failure mode I had to confess to last week - a privacy-first notetaker cheerfully shipping the training-on default because it never occurred to me to check - cannot happen here. Not because I got smarter. Because Groq put the control where the person paying is the person deciding.

So the accurate version of my claim is narrower than the one I made: BYOK gives you control over exactly those privacy settings the vendor chose to put at the account level, and none of the ones it chose to put in the request. Which settings live where is the vendor's design decision, not yours, and you don't find out until you read the API reference. With Groq it happens to be all of them.

What Humla actually does, checked against the source today: the Groq adapter posts your audio to api.groq.com/openai/v1/audio/transcriptions with the model, verbose_json, word-level timestamp granularity, temperature=0, the recording's language, and - this one deserves a moment - a prompt field carrying your custom vocabulary plus a little prior context to help spelling. If you've put client names or internal jargon in your bias terms, those leave your Mac alongside the audio. The only model Humla offers here is whisper-large-v3-turbo, and your key gets validated once against /openai/v1/models and is otherwise untouched.

Three things verified by contrast, exactly the way I checked them for Deepgram. Humla never asks Groq for anything except transcription: speaker labels come from a local sidecar on your Mac, and summaries and chat over your notes never touch Groq at all. Your key lives in the macOS Keychain under no.humla.app. And there is no Humla server anywhere in this path - I grepped the entire cloud repo and it contains zero references to Groq, so the request really is your Mac straight to Groq. Unlike the Deepgram adapter, Groq's base URL here is deliberately fixed rather than accidentally unexposed. The code says so in a comment and points anyone who wants a different host at the generic OpenAI-compatible provider instead.

What to actually do

If you write the code:

1. Turn on ZDR in the Console and confirm with your own eyes that you can see the toggle. It's the whole ballgame and it takes a minute.
2. Don't go hunting for a per-request flag. There isn't one, and that's the good news.
3. If residency is a requirement, stop reading here. Groq has no regional endpoint. Use a provider that does, or run the model locally.
4. Ask for the DPA if you need retention to be contractual rather than published. It's public, dated, and already carries the SCCs.

If you use somebody else's app with your own Groq key:

1. Set ZDR yourself. This is the rare case where the app cannot undermine you.
2. Ask the vendor what goes in the prompt field. Custom vocabulary often does, and it's the sort of thing nobody mentions until asked.
3. Check whether that same app also ships your transcript somewhere else to be summarised. That's usually a different vendor with a different policy, and for a notetaker it's the bigger exposure by a distance. The text says far more than the audio does.

The option of not sending it

My bias, stated plainly, since I opened with it: for meeting notes specifically, cloud speech-to-text is now optional, and I built a tool on exactly that premise.

Humla records your microphone and the call's system audio with no bot in the meeting, and it can run Whisper on your Mac's GPU with offline speaker labels and summaries against a local model through Ollama. Set up that way there's no request at all, so there's no retention policy to read and no toggle to remember to flip. You can mix it per language too - Norwegian on-device, English to a cloud provider, or the reverse. It's MIT-licensed, so the request-building code I described up there is code you can go and read for yourself instead of taking my word for it.

The tradeoffs, honestly, because I'd rather you find them here than three weeks in: Groq is genuinely FAST, and whisper-large-v3-turbo at four cents an hour is cheap enough that cost is not a real argument against it. On-device Whisper is slower on a long meeting and wants a few gigabytes of model download first. Humla is Apple Silicon only - no Windows, no Linux, no mobile - with no integrations and a much smaller community than the incumbents. If your audio is clean and the content isn't sensitive, sending it to Groq with ZDR on is a defensible, well-documented choice, and I would much rather you make that choice knowingly than end up with a tool that never told you it had a default. If you're a lawyer or a therapist under a duty of confidentiality, though, "processed in an unnamed jurisdiction under standard contractual clauses" is still a sentence you'd have to say out loud to a client one day, however good the retention terms are.

The short version

Groq has the best-documented default of the three providers I've now read end to end. No retention on inference, no training, and the no-training promise living in the contract instead of on a page that can be quietly edited. The off switch for whatever remains is a self-serve toggle rather than a sales call, which makes it the only one of the three that a five-person agency can actually reach without someone's account manager getting involved. The two soft spots are real and narrow: our undefined ghost holding up the headline promise, and no region to choose, so everything lands in the US under SCCs.

The thing I've taken from doing all three of these, and I didn't expect it to be this: the vendors' defaults differ far more than their marketing does. Three companies selling the same commodity, and one prohibits training in a contract, one opts you in via a footnote, and one wants a meeting before it'll let you turn logging off. You cannot tell which is which from the landing page. You find out by reading the boring document. See what private actually means here and what runs locally - and then go and read your other vendors' boring documents, because I've now done three and I have never once found what I assumed I'd find.

All facts above verified against Groq's published pages - the Services Agreement, DPA, privacy policy, GroqCloud data docs, speech-to-text docs and Trust Center subprocessor list - on 11 August 2026, and all Humla claims against the app's own source on the same date. These pages change; re-check before making a compliance decision on them.