OpenAI Enterprise API: Data Residency, Compliance & What Regulated Teams Must Verify

What to Verify

• Processing location ≠ storage location: Zero-retention means data isn't stored — but it IS processed. Where does inference happen? Azure regions backing OpenAI API may route globally unless you specify.
• EU data boundary: OpenAI offers EU processing via Azure EU regions. Confirm this is contractually guaranteed for your org, not just a default that can change.
• Sub-processors: Review the sub-processor list in the DPA. Any US sub-processor triggers Schrems II considerations for EU personal data.
• Model versioning: When OpenAI deprecates a model version, where does the replacement run? Does your DPA cover successor models?
• Abuse monitoring: OpenAI's Trust & Safety team may access flagged content. Understand what triggers review and whether regulated data could be exposed.

"Zero data retention" on the API means prompts and completions are not stored after the request completes. But:

• In-flight data: During processing, your data exists in GPU memory (potentially in the clear). Confidential computing isn't standard — ask if it's available.
• Logs vs content: Zero retention on content doesn't mean zero logs. Metadata (timestamps, token counts, user IDs, error codes) may be retained for operational purposes.
• Abuse exceptions: Content flagged by automated abuse detection may be retained for review. Understand what types of content trigger this.
• Caching: Prompt caching (for cost optimisation) means some input data IS retained briefly. Understand the TTL and scope.

Before Going to Production

1. Request the SOC 2 Type II report: Read it. Specifically check the scope boundaries — does it cover the API tier you're using? Enterprise ≠ Team ≠ Platform.
2. Review the DPA: Not the marketing page about the DPA — the actual document. Check data controller vs processor roles, breach notification timelines, and international transfer mechanisms.
3. Pen test your integration: Even if OpenAI is secure, your integration layer (API keys, prompt construction, response handling) introduces risk. Test it.
4. Implement input/output filtering: Don't rely on OpenAI to prevent your users from sending PII. Filter on your side before it reaches the API.
5. Rate limiting & cost controls: A compromised API key with no spending limit is an expensive breach. Set hard caps per project, per user, per day.
6. Audit logging: Log every API call (sanitized) on YOUR side. You need an audit trail regardless of OpenAI's retention policy.
7. Exit strategy: What happens if OpenAI changes terms, has an outage, or is sanctioned? Have a fallback (Azure OpenAI, Anthropic, self-hosted) tested and ready.

• Financial services (DORA): OpenAI API is likely a "critical ICT third-party service provider" if AI is in production workflows. This triggers DORA's concentration risk, exit strategy, and oversight requirements. Have your register of ICT third-party arrangements updated.
• Healthcare (HIPAA): Verify OpenAI will sign a Business Associate Agreement (BAA) for your use case. Not all tiers qualify.
• EU AI Act: If you're building a high-risk AI system using OpenAI's models, YOU remain the provider/deployer responsible for compliance — not OpenAI. Their compliance doesn't transfer to your system.
• Public sector: Government use may require FedRAMP or equivalent. OpenAI's government offering (via Azure Government) has different access paths than commercial API.