Is OpenAI Safe to Build On? A 2026 Look at Privacy, Data, and Model Risk

OpenAI started life in 2015 as a research lab with an oversized mission: make sure artificial general intelligence ends up benefiting everyone, not just the people who build it. A decade on, the lab is a commercial powerhouse, GPT-5.5 and GPT-5.5 Pro sit at the top of the closed-model leaderboard, and a generation of products - from in-house copilots to customer-facing support agents - runs on top of its API.

That commercial gravity has changed the questions people ask. It is no longer "will AGI go well for humanity" in the abstract. For a head of support evaluating an AI agent, or a CTO signing a data processing addendum, the questions are sharper and more practical:

• Is OpenAI handling the data my customers paste into chats responsibly?
• Could the underlying models behave in ways that hurt my brand or expose me to legal risk?
• Is my data being used - quietly or otherwise - to improve a model that my competitors then benefit from?

This is a 2026 reassessment of where OpenAI stands on each of those, what has actually changed since the GPT-4 era, and how to put GPT-5.5 (and the rest of the frontier) into production for customer support without giving up control. We'll close with how Berrydesk approaches the same problems when you don't want to bet a support function on a single vendor.

What OpenAI ships today, and why support teams care

The OpenAI surface area you actually need to understand for a support deployment is small. There's ChatGPT - the consumer and team product where individual agents and analysts paste tickets, draft replies, and summarize policies. There's the API, where the GPT-5.5 family powers your own agents, retrieval pipelines, and AI Actions. And there's Codex on the GPT-5 stack, which mostly matters for the engineering side of your org but is increasingly used to maintain the very automations that move tickets between systems.

Three things separate the 2026 lineup from earlier versions. GPT-5.5 Pro runs parallel reasoning, which materially changes how it handles multi-step support workflows like "look up the order, check the refund policy, draft the response, and file the case note." Native multimodality means a customer screenshot of a broken checkout page is now a first-class input rather than something you have to OCR upstream. And the cost curve has bent sharply - partly from OpenAI's own pricing moves, partly because open-weight competitors like DeepSeek V4 Flash ($0.14 / $0.28 per million tokens) have forced everyone's hand.

That last point matters for the safety conversation in a way that isn't always obvious. When the cost of a frontier-quality token drops by an order of magnitude, support teams stop sampling AI on a few tickets and start running it across the entire inbound queue. The volume of customer data flowing through a model provider goes up tenfold, and the privacy controls that were "good enough" in a pilot become the thing your DPO grills you about.

How OpenAI describes its own security posture

OpenAI publishes a fairly conventional enterprise-security stance, and it's worth being precise about what they actually claim versus what gets repeated in marketing copy.

Encryption and certifications

Customer data is encrypted in transit and at rest using standard primitives - TLS on the wire, AES on disk. They hold SOC 2 Type 2, which means an independent auditor has tested the design and operating effectiveness of their security controls over a sustained window, not just snapshotted them once. For enterprise contracts they offer GDPR-aligned data processing terms, and HIPAA Business Associate Agreements are available for qualifying customers on the API and ChatGPT Enterprise tiers. None of this is exotic - it's table stakes for a vendor at their scale - but it's the floor most procurement teams need to clear before any conversation about pilots can start.

Restricted internal access

OpenAI states that only a vetted subset of employees can access customer data, with role-based controls, additional training requirements, and logging on top. The category of risk this addresses is real: insider threat and lateral movement after a credential compromise are how most modern data incidents actually unfold, not Hollywood-style external break-ins. The honest caveat is that "small subset" is not a number, and the company does not publish the kind of granular access-log transparency reports that, say, a hyperscaler cloud provider does.

External audits and a bug bounty

Independent firms run penetration tests and security audits on OpenAI's infrastructure on a recurring basis, and a public bug bounty program pays researchers to disclose vulnerabilities responsibly. Crowdsourced pressure-testing genuinely does harden a system over time - it's one of the few security signals you can validate from the outside, since fixed bug reports become public.

Stated responsible-AI practices

Beyond infrastructure, OpenAI publishes usage policies, runs red-team exercises before major model releases, and maintains content filters meant to block the most obvious categories of abuse - CSAM, instructions for mass-casualty weapons, large-scale targeted harassment. They have a model-spec document that describes intended behavior, and they engage with policy bodies in the US, EU, and UK on AI governance.

The shape of all of this is a company that is doing roughly what you'd expect a serious vendor to do, while operating at a scale and speed that makes "expected" feel insufficient.

Where the criticisms still land in 2026

The defenses above are real, but the critical pressure on OpenAI hasn't gone away - if anything, it has sharpened as the models have become more capable and more embedded.

Less, not more, model transparency

The original GPT-2 release was accompanied by a detailed paper. By the time GPT-5.5 shipped in April 2026, the public technical report was thin: capabilities, evaluation suites, broad safety mitigations, and very little on training data composition, model architecture, or post-training methodology. That's a defensible business decision - the frontier is competitive and details get copied - but it does mean independent researchers cannot easily audit how the model was built, what biases it inherited, or where it might fail in non-obvious ways. For a support team, the practical implication is that you can't fully predict how a GPT-5.5-powered agent will behave on the long tail of weird customer queries until you actually run them.

This is one place the open-weight world has pulled ahead. When DeepSeek V4 dropped on April 24, 2026, the weights, architecture, and a meaningful amount of the training methodology came with it. When Z.ai released GLM-5.1 on April 7 under an MIT license, the same was true - and GLM-5.1 happens to score 58.4 on SWE-Bench Pro, ahead of GPT-5.4 (57.7) and Claude Opus 4.6 (57.3) on that particular benchmark. You can audit those models in a way you fundamentally cannot audit GPT-5.5.

Content filtering that still leaks

OpenAI's filters have improved, but they still fail in both directions. Sometimes they over-block - a perfectly reasonable medical or legal question gets refused, frustrating an end user trying to help themselves. Sometimes they under-block - a determined user with a few prompt-engineering tricks can elicit content the policy says should be off-limits. Neither failure mode is unique to OpenAI; every frontier lab has the same problem. But for a brand putting an OpenAI-backed agent in front of customers, the relevant question is "what happens when a screenshot of our chatbot saying something offensive lands on social media?" - and the answer is that the brand absorbs the damage, not the model provider.

Speed versus caution

The internal tension that produced the high-profile board drama at OpenAI in late 2023 hasn't really resolved. The company ships fast, ships often, and ships features (long-running agents, code execution, browsing, persistent memory) that each introduce new attack surfaces. Critics argue that pace makes thorough red-teaming harder; defenders argue that the alternative - a slower OpenAI - just hands the lead to less-cautious labs. There isn't a clean answer, but if you're building on top of GPT-5.5 you should assume the model and its surrounding tooling will change underneath you several times a year, and architect accordingly.

Does OpenAI train on your data?

This is the question that derails more procurement reviews than any other, and the honest answer requires distinguishing three different products.

ChatGPT (consumer and Plus)

By default, conversations with the consumer ChatGPT product can be used to improve OpenAI's models. There is an opt-out toggle in account settings - "Improve the model for everyone" - that disables this, and using temporary chats also keeps content out of training. But the default is opt-in, and a non-trivial number of employees still paste sensitive information into their personal ChatGPT account before anyone at their company has a policy on it. This is the dominant data-leakage vector for most organizations in 2026, and it has nothing to do with OpenAI's security posture and everything to do with the fact that there's a free, very useful tool one tab away from every employee.

ChatGPT Enterprise, Team, and Edu

Data submitted through these tiers is not used to train OpenAI's models. SAML SSO, admin controls, audit logs, and longer-retention options are bundled in. For most knowledge workers inside a regulated company, this is the right tier - the marginal cost over Plus is small relative to the marginal control gained.

The API

API inputs and outputs are not used to train OpenAI's models by default. That has been the position since early 2023 and remains true through the GPT-5.5 generation. Data is retained for up to 30 days for abuse monitoring, and zero-data-retention agreements are available for qualifying enterprise customers who need to eliminate even that window. This is the surface most production support agents are built on, and it's the cleanest of the three from a privacy standpoint - but it's also the one where you, the builder, become responsible for what happens to the data on your side of the wire.

Retention windows worth knowing

ChatGPT conversations on the consumer tier are retained until you delete them, with a 30-day window after deletion before they're purged from backups. Account metadata (email, billing) lives until you close the account. API logs sit at 30 days unless you have a ZDR agreement. Enterprise contracts can negotiate custom retention. None of these are unusual numbers - but they should appear in your data map, not in a vendor brochure you skimmed once.

Where OpenAI fits in the broader 2026 model landscape

It's worth zooming out, because "is OpenAI safe" is increasingly the wrong framing. The right framing is "what is the right portfolio of models for what I'm building, and what does each one cost me in privacy, control, and dollars."

The frontier in May 2026 is genuinely plural. Anthropic's Claude Opus 4.7 leads SWE-Bench Pro at 64.3% and is the model most enterprises reach for when correctness on complex reasoning matters more than raw throughput; Claude Opus 4.6 and Sonnet 4.6 ship with a 1M-token context window at no surcharge, which lets a support agent hold an entire knowledge base, conversation history, and policy doc in memory at once. Google's Gemini 3.1 Ultra carries a 2M-token context and is natively multimodal across text, image, audio, and video - useful for anything involving screenshots, screen recordings, or call transcripts. Gemini 3.1 Pro tops GPQA Diamond at 94.3%.

Then there's the open-weight tier, which has changed the cost arithmetic for support workloads completely. DeepSeek V4 Flash at $0.14 / $0.28 per million tokens makes routine ticket triage close to free. MiniMax M2.7 hits 56.22% on SWE-Pro and runs at roughly 8% of Claude Sonnet's price at 2x the speed. Moonshot's Kimi K2.6 holds 12-hour autonomous coding sessions and can swarm up to 300 sub-agents - overkill for a single support reply, but exactly the shape of compute you want for a long-running refund investigation that touches five systems. Z.ai's GLM-5.1 and Alibaba's Qwen 3.6-27B (Apache 2.0) are both viable on-prem options for regulated industries that genuinely cannot ship customer data outside their VPC. Xiaomi's MiMo-V2-Pro, with weights open-sourced under MIT in April 2026, gives you a 1M-context reasoning model you can run yourself.

The point is not that OpenAI is bad. The point is that betting a customer support function on a single model - any single model, from any single vendor - is now a strictly worse strategy than routing intelligently across several. Routine FAQ deflections go to a cheap open-weight model running close to your data. Sensitive policy questions and high-stakes escalations go to Claude Opus 4.7 or GPT-5.5 Pro. Multimodal queries with attached screenshots go to Gemini 3.1 Ultra. The privacy posture of each layer can be tuned independently, and you stop being held hostage to any one provider's outage, price hike, or policy change.

Common pitfalls when teams put OpenAI in front of customers

A few patterns show up repeatedly in incident postmortems we've seen:

Treating prompts as ephemeral. The system prompt that tells your agent how to behave is, in practice, part of your product surface. Customers find ways to extract it, screenshot it, and post it. Don't put credentials, internal URLs, or unflattering descriptions of competitors in there.

Logging more than you need. It's tempting to log full conversations forever for "quality." Then a customer issues a GDPR deletion request, or your logging service has an incident, and suddenly you're cleaning up a much bigger mess than the value of the logs justified. Log structured events; redact free text; set retention deliberately.

Ignoring the "shadow ChatGPT" problem. If your company hasn't issued ChatGPT Enterprise or Team accounts, your employees are pasting customer data into personal accounts. The fix is procurement, not policy memos.

Assuming filters are the safety layer. OpenAI's content filters are a backstop, not your primary control. The primary controls are: a tightly scoped system prompt, retrieval grounded in your verified knowledge base, hard guardrails on what tools the agent can call, and a human-in-the-loop for any action above a defined risk threshold (refunds over $X, account changes, anything involving health or legal advice).

Single-model lock-in. Building your entire agent stack against the OpenAI SDK feels efficient on day one. On day 400, when GPT-5.5's pricing changes or a regulator in your industry mandates on-prem inference, you're rewriting everything. Build against an abstraction.

Practical guidance for safer use of OpenAI

If OpenAI is in your stack - and for most support teams it should be, at least for some workloads - a few habits will save you most of the pain:

• Use the right tier. API or ChatGPT Enterprise for anything touching customer data; never the consumer tier for work.
• Turn off training where it's still on. For any consumer accounts that exist in your org for personal productivity, the toggle is in settings; check it.
• Sign a ZDR agreement if your industry needs it. For most regulated buyers it's available; ask.
• Map your data. Know which prompts include PII, which include payment data, which include health information. Route accordingly - some workloads should never touch a US-hosted model at all.
• Monitor outputs, not just inputs. Sample a percentage of agent responses for hallucination, off-topic content, and tone drift. The drift is real and continuous as models update under you.
• Keep a kill switch. Every AI Action your agent can take - refunds, cancellations, data lookups - should have a circuit breaker that a human can flip in under a minute.

How Berrydesk approaches the same problems

The reason we built Berrydesk the way we did is that none of the questions above have a single-vendor answer. A support agent that needs to be cheap on routine traffic, accurate on hard tickets, multimodal for screenshots, and on-prem-capable for the regulated customers in your book of business cannot live on one model.

So Berrydesk lets you pick the model - GPT-5.5, Claude Opus 4.7, Gemini 3.1, DeepSeek V4, Kimi K2.6, GLM-5.1, Qwen, MiniMax, and others - per agent, or route between them per query. Training data sources (docs, websites, Notion, Google Drive, YouTube) are managed in one place with per-source permissions and retention rules. AI Actions for booking, refunds, payments, and lookups run through scoped tool definitions with audit logs. The chat widget is yours to brand, and you can deploy the same agent to your website, Slack, Discord, WhatsApp, or wherever your customers already are.

On the privacy side, the controls are the ones the questions above demand: per-agent opt-out from any provider's training pipeline, configurable retention on conversation logs, regional data residency where the underlying provider supports it, and SOC 2-aligned operations. When a customer's compliance posture genuinely requires it, you can route their workloads to open-weight models running in your own infrastructure without rewriting the agent.

OpenAI is, on balance, a reasonable building block in a 2026 support stack - encrypted, audited, with the right controls available if you ask for them and use the right tier. It's just no longer the whole stack, and the safety conversation is healthier when you stop pretending it has to be.

If you want to stand up a support agent that uses GPT-5.5 where it makes sense, an open-weight model where it doesn't, and gives you the privacy controls you'd want either way, you can start building on Berrydesk for free - no credit card, live in minutes.