OpenAI Subprocessors List: Which SaaS Vendors Send Your Data

As of our check on 26 September 2026 (UTC), nine vendors’ published lists in our directory name OpenAI: Amplitude, Atlassian, Datadog, Deepgram, Redis, Sentry, Twilio, Zapier and Zoom. Former vendors on that pull were empty. This OpenAI subprocessors list roundup is built from our public API and each vendor’s own subprocessor page, not from marketing copy.

If several of your SaaS tools name the same model provider, customer content may leave your stack through different products. Everything below is from the published subprocessor rows only. We have not published a reading of these vendors’ AI-usage terms yet, so this post does not state their training or opt-out positions. Where a field is empty in our extract, the list did not state it.

Why an OpenAI subprocessors list view beats vendor-by-vendor reading

The OpenAI company page in our directory shows who lists OpenAI today. What that page cannot do alone is force the concentration question: how many of your critical processors share that dependency at once.

A privacy or security reviewer who only opens Atlassian’s list sees support and intelligence features. The same reviewer who also uses Datadog, Sentry, Zapier and Zoom may discover OpenAI four or five more times, with different purposes and different gaps in what the row discloses. Fourth-party risk is exactly that pattern: you have no contract with OpenAI, yet several contracts you do have point at it.

For the legal baseline on what a subprocessor is and why lists exist, see what a subprocessor is. This post stays on the cross-stack read.

Vendors that name OpenAI (dated pull)

All facts below come from https://clausetrail.com/v1/entities/openai/vendors and the linked vendor pages, with list extractions dated 25 September 2026 and the API pull dated 26 September 2026 (UTC). Former vendors (lists that once named OpenAI and no longer do) were empty in this pull.

Productivity and collaboration

Atlassian. Purpose on the list: generative AI services for intelligence product features, and for Atlassian support. Location: USA. Data categories: customer personal data created by the customer and stored in applicable cloud products, or shared with Atlassian during support. That is one of the fuller rows in this set: purpose, country and categories are all present.

Zoom. Purpose: intelligent features service provider. Locations: United States and the European Union. Data categories: the list states that OpenAI may process customer content and context if AI features are enabled. The conditional wording matters: the row ties processing to features being on, which is a control you can often govern in product settings as well as in contract review.

Observability and engineering

Datadog. Purpose: AI services. Location: United States. Data categories: not stated on the extracted row. A purpose this short tells you OpenAI is in the chain for AI features; it does not tell you which telemetry, prompts or support content can reach the model provider.

Sentry. Purpose: AI/ML services. Location: United States. Data categories: not stated. Same pattern as Datadog: named provider, thin purpose line, no categories on the row we extracted.

Communications, automation and analytics

Twilio. Purpose: OpenAI provides AI functionality, including large language models, for specific Twilio products and services. Location: USA. Data categories: not stated. The “specific products and services” caveat is useful: your review should map which Twilio products you actually buy before assuming every workload is in scope.

Zapier. Purpose: artificial intelligence provider. Location: USA. Data categories: not stated. In an automation layer, “AI provider” can mean optional helpers, agents inside Zaps, or both. The list row alone does not settle which customer content can flow.

Amplitude. Purpose: generative AI technology used to enhance Amplitude and Statsig’s AI features. Location: United States. Data categories are not stated cleanly on this row (the extract does not give a usable category description); rely on purpose plus location until the vendor’s page states categories clearly.

Data and AI vendors

Redis. Purpose: generative artificial intelligence and natural language processing services. Locations on the row: San Francisco, CA, USA. Data categories: not stated.

Deepgram. Purpose: developer of general AI systems and large language models. Locations: not stated on the extracted row. Data categories: interactive text and audio. A named AI vendor listing OpenAI with text and audio categories, but no location on the row, still leaves a transfer question open.

What the rows share, and what they omit

Across this OpenAI subprocessors list set, almost every vendor places OpenAI in the United States (Zoom also names the EU; Deepgram’s location is not stated). Purposes cluster into three buckets:

1. Product intelligence features (Atlassian, Zoom, Amplitude, Redis generative AI and NLP services).
2. Support or operations AI (Atlassian support; Twilio’s product-specific AI).
3. Thin labels (“AI services”, “AI/ML services”, “artificial intelligence provider”) that name the provider without describing the workload.

Data categories are often not stated. Zoom and Atlassian are the clearest on what may be processed. Deepgram names text and audio. Several others leave the category column empty in our extract. Empty means the published list did not give us that field; it does not mean no personal data is involved.

We have not published a reading of these nine vendors’ AI-usage terms yet, so this post does not state training, retention or opt-out positions. The subprocessor row is the dated fact you have here; open each vendor’s DPA and any AI schedule they publish for the rest.

Concentration: how to read this against your stack

The directory page answers “who lists OpenAI?”. Your register of processors should answer “how many of our processors list OpenAI, for which products, with which notice windows?”.

A practical pass:

1. Export the vendors you actually use (not every name in our directory).
2. Check each against the live OpenAI subprocessors directory page or the vendor’s own list.
3. For each hit, copy purpose, location and categories into one grid, with the date you checked.
4. Mark feature flags or product editions that disable the AI path where the list or product docs allow it (Zoom’s “if AI features are enabled” language is the model).
5. Align the grid with transfer language in each data processing agreement (standard contractual clauses, the EU–US Data Privacy Framework, or both). Our comparison of standard contractual clauses versus the Data Privacy Framework is the companion read; SOC 2 evidence answers a different question (Type I versus Type II).

If three observability and collaboration tools all route support text or customer content toward OpenAI, your residual risk is not three isolated “AI feature” tickets. It is one model provider appearing across channels your staff already treat as routine.

Two example stacks from the dated set (not recommendations, only illustrations). A product-engineering stack that runs Atlassian, Datadog and Sentry has OpenAI on three lists for intelligence features, AI services and AI/ML services, mostly with a United States location and thin or missing categories on the observability rows. A go-to-market and ops stack that runs Zoom, Twilio, Zapier and Amplitude shows OpenAI again for intelligent features, product-specific LLMs, generic AI provision and analytics AI features. Neither stack “uses OpenAI” as a direct vendor; both inherit it. That is the sentence the single-vendor directory page cannot write for you.

The one check worth making this week

Take your top ten SaaS processors by data sensitivity. For each, search the live subprocessor list for OpenAI (and note the date). Build a single table: vendor, product in scope, purpose text, location, categories, and whether AI features are optional. If more than one row lights up, schedule one concentration review instead of five separate “AI addendum” threads.

ClauseTrail reads vendor subprocessor lists, DPAs, privacy policies, terms and AI-usage terms, and surfaces when OpenAI (or another provider) appears or disappears. Browse the OpenAI subprocessors page; see pricing when you are ready to watch those lists continuously.

Frequently Asked Questions

What is an OpenAI subprocessors list in practice?

It is either a vendor’s own subprocessor list naming OpenAI, or a directory view that aggregates which vendors currently publish that name. ClauseTrail’s OpenAI page is the second kind: it is built from each vendor’s published list, re-checked on a schedule, and dated.

Do all of these vendors send the same customer data to OpenAI?

No. Purposes and categories differ, and many rows leave categories not stated. Zoom ties processing to AI features being enabled; Twilio limits the purpose to specific products and services; Atlassian names cloud-product and support data. Always read the row you are relying on.

Why does this post omit AI-usage terms?

We have not published a reading of these vendors’ AI terms yet, so this post does not state their training or opt-out positions. Revisit those documents on each vendor’s site, or return to this topic once a published reading exists.

Does listing OpenAI mean the vendor trains models on my content?

Not by itself. A subprocessor row shows that OpenAI is engaged for a stated purpose. Training, retention and opt-outs usually live in AI terms or a DPA schedule. If those terms are not in a published reading here, treat training as not stated in our data, not as “no”.

How often does this set of vendors change?

Whenever a vendor publishes a list that adds or drops OpenAI. Our OpenAI directory page moves names as those lists change; this post captures the API pull dated 26 September 2026 (UTC) and should be read against the live page for anything after that.