Is the OpenAI API safe to use with confidential business data?

A build is close to going live and somebody has to say yes. Not to a trial with dummy records, but to real contracts, customer data and pricing leaving your systems for a third party in the United States.

The engineer says it is fine. The person signing the DPIA is not sure what "fine" is being claimed about. Both are usually reading material about the wrong product.

Almost everything written about this is about ChatGPT, and you are not buying ChatGPT

ChatGPT is a product people log into. The OpenAI API is a platform your software calls. They are governed, configured and contracted differently, and they fail differently. An assurance about ChatGPT seats does not transfer to the API, and the reverse is also true. Three concrete examples.

OpenAI's consumer privacy policy states that it "does not apply to content that we process on behalf of customers of our business offerings, such as our API." A review that reads the ChatGPT privacy policy and reaches a conclusion has reviewed a document that does not apply.

Certification scope splits the same way. OpenAI's ISO/IEC 27001:2022 certificate covers the API Platform, ChatGPT Enterprise and ChatGPT Edu. ChatGPT Business sits outside it, so the API can be inside the certified boundary even where the seats your colleagues bought are not. The ChatGPT Business and Enterprise governance gap covers the tier side properly.

And the controls live in different places. On ChatGPT, governance is a tier and an admin console. On the API, governance is a project structure, a set of keys and the code you wrote. Nobody sells you the second one. You configure it or you do not have it.

What OpenAI states it does with API data

The following is the vendor's documented position, read off its own pages on 08 Aug 2026, not something we have audited. What you get is a contract plus third-party audit reports (the SOC 2 Type 2 covers the API Platform, and it sits behind an access request at trust.openai.com, where scope statements are public but the documents are not). That is the same basis on which you use every other processor in your stack. The regulated-firm version of this question is in ChatGPT for finance teams in FCA-regulated firms.

Training. "As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." The default is off and opting in is a deliberate act. Consumer ChatGPT is the opposite, opted in unless a user turns it off, which is why the largest unmanaged exposure in most companies is not the API. It is the staff still on personal accounts.

Abuse-monitoring logs. Generated by default for all API usage and retained up to 30 days, unless longer retention is required by law. Excluding your content from them means Zero Data Retention, an approval you apply for rather than a setting you find. What it covers, and where "ZDR enabled" overstates it, is a subject of its own: see Zero Data Retention.

Application state. Varies by endpoint, and this is the part people assume rather than check. Stateless calls hold nothing by default. Stateful objects (conversations, threads, vector stores) are retained until you delete them, and objects nobody ever deletes are retained indefinitely. Where responses are stored, OpenAI states the data "will be stored for at least 30 days".

Encryption. At rest, AES-256. In transit, TLS 1.2 or above.

What you control, and what you can only contract for

The useful split is not "safe" against "unsafe". It is which risks you can engineer away and which ones you are accepting on paper.

That last row is more useful than it looks. OpenAI's DPA gives you 30 days from notice of a new sub-processor to object, after which OpenAI must work with you to address the concern, and if that fails either party may terminate the affected services with a pro-rata refund. Somebody should be subscribed to those notices. Usually nobody is. The current list names Microsoft, CoreWeave, Oracle Cloud Infrastructure and Google Cloud Platform, each with the United Kingdom among their processing locations, which is where you read from if your own contracts oblige you to disclose onward processors.

The incidents are almost never the vendor

Confidential data rarely leaks because OpenAI mishandled it. It leaks through five failures, all of them yours, all cheap to prevent before launch and expensive afterwards.

A key in source control. Still the most common. OpenAI's guidance is to keep keys out of code and public repositories and supply them through environment variables or a secret management service. A key in a repository is also a key in every clone, fork, CI cache and laptop backup, and revoking it is the easy half of the job.

One key doing everything. If the same key serves production, staging, a pipeline and somebody's laptop, you cannot revoke it without an outage, so you will not revoke it. OpenAI's production guidance is to create separate projects for staging and production, isolating development work and allowing separate rate and spend limits.

No separation between test and production data. Somebody copies a slice of the live database into a test environment so the results look realistic. That environment has looser access, no redaction and verbose logging. The data has been through the least controlled part of your estate, and the security review only looked at production.

Logs that quietly capture whole prompts. This one catches careful teams. The prompt holds the customer record, the observability stack logs the request body, and the log platform is a third party with its own retention, access model and region. You have made a second copy of the data somewhere your DPIA does not mention. Note the irony: teams that obtain Zero Data Retention often start logging prompts themselves, because OpenAI no longer holds anything to debug against, so the retention moves into their estate rather than disappearing.

Prompts assembled without sanitisation. Two variants. First, prompt injection, where text a user supplied gets treated as instruction. OpenAI's guidance is unglamorous and correct: constrain the input, prefer validated selections over open text. Second, less discussed, a retrieval step hands the model whatever it found, and instructing the model not to reveal something is not a control. Filter on the requesting user's permissions before the prompt exists.

None of these five involve OpenAI at all.

Configure this before the first real payload

Most of this is configuration rather than build, and the first item genuinely cannot be done later.

1. Set the region when you create the project. Residency is configured per project and chosen on creation. It cannot be added afterwards. If UK or EU storage is a requirement, or might become one, decide now. This is the only irreversible item here.
2. One project per environment, with its own keys. Production, staging and analytics get separate projects, keys and spend limits. Use project service accounts rather than keys tied to an individual, so a leaver does not take a running integration with them.
3. Keys in a secrets manager, with a rehearsed revocation path. Not a config file, not a committed .env, not a shared password note. Write down who can revoke a key and how long the swap takes, then test it once. Revoking has to be routine to be useful.
4. Decide retention per endpoint rather than inheriting it. Know which endpoints your code calls, whether it asks for responses to be stored, and what deletes the stateful objects you create. Nothing tidies vector stores up for you.
5. Redact at the point of logging, not in a later clean-up job. Enforce it in the logging layer rather than at each call site, then check your error handler, which is usually where the full payload escapes.
6. Apply permissions before the prompt is built. Retrieval filters on the requesting user's access rights. Instructions are not a permission model.
7. Execute the DPA before go-live, not during a client's security review.

What the UK contract actually names

Whether your processing is lawful is a question for your DPO or your solicitor. What we can tell you is what the contract names, because it gets written up wrong repeatedly.

For a UK customer, the counterparty under OpenAI's Data Processing Addendum is OpenAI OpCo, LLC, the US entity, not OpenAI UK Ltd (which appears on the sub-processor list as an affiliate, not as the contracting party). Transfers rely on the EU Standard Contractual Clauses as amended by the ICO's UK Addendum, issued under section 119A(1) of the Data Protection Act 2018, which is a different instrument from the standalone IDTA that many DPIA templates still name. Write "UK Addendum". The DPA sets governing law for UK data as England and Wales with the ICO as supervisory authority, and the clauses are deemed entered into once the DPA is in place, leaving you the ordinary obligations: your lawful basis, your transfer risk assessment, and the residency decision in item 1.

One question worth asking before any of this

If the reason you are on the API is that the work must run unattended, on a schedule or on a trigger, check first whether a workspace agent in a ChatGPT subscription already covers it. Since 22 Apr 2026 a fair amount of what used to require a build does not, and that changes the data question entirely, because you are then governing a workspace rather than an integration. Where the boundary now sits is set out in the OpenAI API compared with ChatGPT for operations. Building an integration you did not need is a worse outcome than any risk on this page.

The honest answer, and the decision in front of you

Yes, with conditions, and the conditions are mostly about your engineering rather than the vendor's.

The vendor side is a documented, audited, contractable position that stands up next to the other processors you already trust with the same data. It is neither perfect nor unconditional, and the claim to be suspicious of is anyone telling you nothing is stored anywhere. What determines whether you have an incident is the part nobody sells you: key hygiene, environment separation, what your logs capture, and where access control happens.

So the question is not "is this safe". Of the seven items above, how many are already true of the system you are about to put live, and which one will you find out about during someone else's security review? Settle item 1 before the project exists, because after that the region is fixed.

If you have not yet decided which route you are on, how the OpenAI options compare for a UK business covers the ground.

We are an OpenAI Select Partner and we build on the platform, and if you want the above worked through against your actual architecture, that is how we scope OpenAI implementation work. The same seven questions apply whichever model you run, which is why they sit under AI implementation rather than under any one vendor. We resell nothing and take no margin on your usage, so we have no reason to talk you into sending data you could have kept. To have the configuration and the contract position documented before you send real data, request a quote.