ChatGPT Business apps: who receives your company data?

A SaaS team wants to connect its customer-support system to ChatGPT Business. Staff could ask for a ticket history without opening another application. The tickets contain names, email addresses, incident descriptions and sometimes production data.

The administrator sees that OpenAI does not train its models on business data by default. Is that enough to connect the system?

No. The training commitment concerns OpenAI’s use of the data. A connected app adds source access, possible onward disclosure and the external provider’s own processing. Review the actual task, permissions and contracts before exposing customer information.

Product documentation and terms were checked on 1 October 2026. Capabilities depend on the app, plan, region and configuration. The support workflow below is hypothetical, not a claim that a particular integration has every capability described.

What you will learn

In brief

• The Business no-training default does not settle retention or external disclosure.
• Review source access, supported actions and approval settings separately.
• Assess each provider’s role and contract before using customer data.

Apps, plugins and the connection underneath

The current connected-app documentation describes apps as connections to external services, with information retrieval and, where supported, actions. A plugin can package apps, skills or both. Installing a plugin does not replace account authorisation or workspace approval.

Older material may use “connectors”, while current interfaces commonly manage these capabilities under Plugins. Judge the underlying capability rather than the label: live retrieval, supported synchronisation, a write action or an interactive app can have different data flows.

For the proposed ticket workflow, identify the actual provider and connected account. Is the app retrieving one record when asked, using an administrator-managed index, or sending a new note to another service? Availability in a menu does not answer those questions.

No training does not mean no retention

OpenAI’s business-data commitments say that Business inputs and outputs are not used to train or improve models by default. They also describe encryption and security measures. Those commitments do not mean data is never stored or processed.

For app information, OpenAI’s help documentation confirms the Business no-training default. It also explains that relevant conversation context can be shared with an app, and that app information may inform Memory or web searches where those features and source restrictions permit it.

Keep different copies separate in the assessment: the source record, information included in a conversation, a supported synced index, operational records and the external provider’s copies. A training setting is not a deletion rule for all of them.

Do not extend Business assurances to personal accounts or assume the same behaviour across plans. In a pilot, record which workspace and account staff actually use.

Draw the data flow in both directions

Section 7 of the OpenAI Service Terms allows applicable content to be sent to a connected application and makes that application’s terms relevant to what it receives. It does not say every app receives the entire conversation history.

For the hypothetical support process, map three operations:

1. Source to ChatGPT: retrieve the ticket information needed to answer the employee’s request.
2. ChatGPT to the connected provider: send the relevant context or proposed note required for that app operation.
3. Action in the source system: where permitted, update a ticket, send a reply or trigger a workflow.

Ask what is transmitted at each step: full records, excerpts, prompts, generated responses, attachments or metadata. Read-only retrieval can still disclose personal or confidential information. Write access adds a separate risk of changing the wrong record or communicating an incorrect answer.

The Services Agreement also distinguishes third-party services and their terms. For an administrator, this means reviewing the connected service’s contract and privacy rules alongside the OpenAI agreement. The familiar ChatGPT interface does not merge the providers into one contractual relationship.

Access and approval are different controls

According to the current admin documentation, Business administrators manage workspace-wide app availability. Role-specific controls described for Enterprise and Edu should not be assumed available in Business. Supported action controls also vary by app.

Treat these as separate checks:

• Whether the workspace allows the app.
• Which account and source permissions authorise its access.
• Which supported actions are enabled.
• When ChatGPT asks the user before reading or acting.

Approving provider scopes does not itself enable an action in ChatGPT. A policy disabling future new actions does not remove already enabled actions or revoke previous provider consent. Check all layers after any change.

For a status lookup, granting rights to edit every ticket would exceed the stated purpose. Prefer a source account and supported settings that match the task. Test what happens when the employee asks for an unrelated customer’s ticket or attempts a write operation.

Live access and a synced index need separate review

Current Google Drive setup guidance describes account permissions and provider setup for Drive and associated document actions. Do not assume a folder restriction applied to one configuration limits every separate capability.

The documentation for administrator-managed apps with sync describes an indexed source configured by administrators, subject to app and workspace eligibility. Individually authorised sync is no longer the setup route described there.

When assessing a supported synced source, ask which material enters the index, who can retrieve it and what removing the connection does. For a live action, assess the connected account and its permissions separately. An approval based only on one layer can leave the other with broader access than intended.

These are provider-specific questions. The hypothetical ticket integration might have no sync capability at all. Confirm the actual implementation before applying a Drive example to it.

Does OpenAI’s DPA cover the external provider?

The OpenAI Data Processing Addendum governs its processing of customer personal data on the customer’s behalf. It describes instructions, security, assistance, subprocessors and relevant international-transfer arrangements. It does not automatically make every service connected by the customer an OpenAI subprocessor.

The current subprocessor list, dated 9 July 2026 when checked, identifies entities supporting OpenAI’s services, their purposes and product scope. Use the applicable rows and change-notification mechanism for that relationship. Separately assess the provider behind the selected app; being reachable through ChatGPT does not settle its role.

Under GDPR, the role depends on who determines purposes and essential means. A provider processing only on the company’s instructions may be its processor, requiring an Article 28 arrangement. If the SaaS company processes customers’ data on their behalf, adding another processor may require customer authorisation and corresponding obligations down the chain.

An external provider using data for its own purposes may have a controller role for that processing. The EDPB’s Guidelines 07/2020 explain the functional assessment. Neither an OAuth consent screen nor a label such as “integration” resolves it.

Review the customer contracts too. A permitted supplier in the company’s own workspace may still conflict with a client’s restrictions on subprocessing or confidential information.

Review retention, transfers and evidence before approval

For each data flow, ask the provider to explain storage, retention, deletion and access locations, including support access and further suppliers. A selected storage region does not establish that every processing step or connected provider remains there.

OpenAI’s admin guidance distinguishes the external provider’s storage terms, supported data-residency boundaries and plan-dependent compliance functionality. Business admins do not automatically gain access to members’ ordinary private conversations. Confirm actual audit coverage before promising a customer complete access logs.

For personal-data transfers outside the EEA, assess the relevant GDPR Chapter V mechanism and safeguards. A European server address alone does not explain remote access or every onward transfer.

Keep a short review record:

• The task, app, connected account and data categories.
• The source permissions and permitted reads or writes.
• What each provider receives and for what purpose.
• The applicable agreements, DPA and subprocessor permissions.
• Retention and deletion for each copy or index.
• Transfer arrangements and available audit evidence.
• The process owner, review date and exit procedure.

Pilot the workflow before exposing the customer database

Begin with fictional or effectively anonymised tickets. Replacing a name with initials may not anonymise an incident description containing identifiable details.

Have the team perform the intended status lookup, draft a reply and, only if approved, test a write action. Check the actual content sent, record affected permissions and test incorrect or out-of-scope requests. For writes, establish who reviews the change and how a mistake is corrected.

The privacy and contract review should consider whether a data protection impact assessment is required. Article 35 GDPR turns on likely high risk to individuals, not merely on the presence of an AI tool.

After the pilot, decide to approve, narrow or reject the workflow. Remove unused permissions. Distinguish disabling the app, disconnecting an account, revoking provider consent, removing a supported index and deleting previously transmitted data. One action should not be assumed to complete the others.

If the team cannot explain the flow or deletion process, use a less sensitive task while resolving the gap. Do not test uncertainty against the full customer database.

For the wider purchase assessment, use our AI vendor and GDPR checklist. For tools connected informally by staff, see Shadow AI governance. We can help review the configuration and contracts through our technology legal services or contact page.

Sources and further reading

• OpenAI: Business data privacy, security, and compliance.
• Connected apps in ChatGPT.
• Admin controls, security, and compliance for plugins and apps.
• Google Drive app and setup in ChatGPT and administrator-managed apps with sync.
• OpenAI Services Agreement, Service Terms, Data Processing Addendum and subprocessor list.
• GDPR, particularly Articles 28 and 35 and Chapter V.
• EDPB Guidelines 07/2020 on controller and processor concepts.