Emirates NBD Got In-Country Inference. Here Is What Still Leaves the UAE.
Look. On 19 October 2026 Emirates NBD and OpenAI announced that Emirates NBD will be the first bank in the MENA region to deploy OpenAI's GPT models using in-country inference infrastructure in the UAE. [1]
Big news. Real news. And tons of people read the headline and stopped there. Stopped cold.
Here's the deal. "In-country inference" is a precise promise. It is NOT "everything stays in the UAE." OpenAI's own documentation says so, in plain words. [2] [3] If you are the architect who has to sign the data-flow diagram, the gap between those two sentences is your WHOLE job.
In-country LLM inference for a UAE bank is a GPU promise. Sovereign AI for banking in the UAE is a bigger promise. Bigger. Much bigger. Confuse the two and you write the wrong slide. Wrong slide. Wrong architecture. Wrong.
Everybody wants the headline. Almost nobody wants the hop diagram. The hop diagram is the job. The job.
What Did Emirates NBD Actually Announce?
Folks, start with the bank's own release. Not the secondary write-ups. Not the LinkedIn summary. The release. [1]
From that page:
- OpenAI's GPT models, run with in-country inference infrastructure in the UAE.
- Use cases: customer engagement across digital channels, risk and compliance analytics, knowledge-intensive workflows, employee productivity.
- The bank will connect OpenAI's models with its internal systems, APIs and enterprise data.
That last line matters most. Chat is easy. Agents wired into core banking APIs are where residency gets hard. Very hard.
Four use cases. One wiring sentence. The wiring sentence is the story. Chatbots are marketing. Agents on internal APIs are the architecture review. Period.
Customer engagement. Risk and compliance analytics. Knowledge-intensive workflows. Employee productivity. Four doors. Same model family. Different data. Different tools. Different leak surfaces. Treat them as four systems, not one announcement. Four.
The release does not say which OpenAI product surface (ChatGPT Enterprise, the API, or both) carries each use case. So below I cover both. Frankly, so should your architecture review. Cover both. Always. ALWAYS.
What Does Inference Residency Actually Guarantee?
OpenAI's ChatGPT help article is clear. Clear and narrow. [2]
- Inference residency means GPU execution on in-scope customer content happens in the selected region.
- It requires data residency in the same region. The UAE is one of three inference residency regions (with Europe and the United States).
- In-scope content includes conversations, files, custom GPTs, memory, code interpreter artifacts, and embeddings derived from that content.
That is a REAL control. Prompts and outputs stored at rest in the UAE. Plus model execution on UAE GPUs. Good. Not nothing. Not everything.
Read it again. GPU execution. Content at rest. Embeddings derived from that content. Three buckets. Three. That is the guarantee. That is the WHOLE guarantee for ChatGPT inference residency as OpenAI writes it. [2]
BTW, the UAE sitting next to Europe and the United States on that list is the point. Three regions. Same control shape. Same boundaries. Same "No" when someone asks if all processing stays home.
People hear "in-country" and picture a sealed room. Sealed. The docs picture a GPU region plus matching data residency, with a list of things that may still leave. Two pictures. Only one is in the source. Use the source.
So What Still Leaves the Region?
This is the part nobody puts on the slide. Nobody. Straight from OpenAI's documentation [2]:
| Still allowed outside the UAE (ChatGPT, inference residency on) | Source wording |
|---|---|
| CPU processing, such as extracting text from uploaded PDF or Word files | "may still occur outside the selected region" |
| Routing requests and coordinating steps across services | same |
| Authentication, routing, analytics | "may still occur outside the selected region" |
| Workspace metadata, workspace name, billing information, user logins | "may be stored outside the chosen data region" |
| Anything sent to apps, MCP servers, web search or other third parties | handled under that provider's own terms |
Read row one again. The bank uploads a PDF. The text extraction of that PDF is CPU work. OpenAI says CPU work may run outside the region. The GPU part stays home. The parsing part might not. Might not.
Routing. Coordination. Authentication. Analytics. Metadata. Billing. Logins. Third-party apps. MCP. Web search. That is not a footnote. That is half the agent stack. Half.
OpenAI even answers the question directly: does inference residency guarantee all processing stays in-region? "No." [2]
One word. No. That is the whole section in one word. WRONG to put "sovereign" on a slide that only bought the GPU hop. Wrong.
What Is Missing in the UAE Today for ChatGPT?
For UAE inference residency, OpenAI lists these limits. Limits. Not vibes. [2]
- Models available: GPT-5.5 and GPT-5.6 Luna on this re-read (24 Oct 2026, ~00:03 Dubai; page said "Updated: 18 hours ago"). The same page has flipped between GPT-5.2-only and GPT-5.5 / GPT-5.6 Luna within days. Re-read it on publish day. [2]
- Image generation and internal search: not supported.
- External web search stays available unless Lockdown Mode or workspace search controls turn it off. [2] So a UAE-resident workspace can still send queries to an outside search provider by default.
- GPT-Live: not available for UAE inference residency workspaces (confirm on publish day). [2]
Two models on this re-read. Several features off. External search on unless you shut it. That is the UAE ChatGPT picture on this read. Today. Check the page again on publish day, because it moves. It moves FAST. [2]
Frankly, the search default is the quiet one. Quiet and expensive. Your residency region does NOT turn external search off for you. You turn it off. Or you don't. Your choice. Your log.
Image generation: out. Internal search: out. GPT-Live: out. That is a lot of "out." Design the use case around what is actually on. Or you ship a demo that needs a feature the region does not support. RIDICULOUS.
Where Do Banking Agents Actually Live on the API?
The bank said it will wire models into internal systems and APIs. That is API territory. Not a chat box. API. [1] [3]
OpenAI's API data controls page [3] says:
- The UAE endpoint is
ae.api.openai.com, with regional storage AND regional processing. - Selecting the UAE region requires additional approval from OpenAI sales.
- Any non-US region requires approval for abuse monitoring controls and a signed Modified Retention amendment.
- UAE regional processing is listed for exactly three services:
/v1/chat/completionsand/v1/responses(specific GPT-5.2, GPT-5.5, GPT-5.5 Pro and GPT-5.6 Luna snapshots) and/v1/embeddings(text-embedding-3-largeonly).
Three services. Specific snapshots. Extra approval. A signed amendment. That is the gate. Not a checkbox in a console. A gate.
Pin the endpoint. Pin the snapshot. Miss either one and your "UAE" call is a hope, not a control. Hope is NOT a control. Never was.
Chat completions. Responses. Embeddings. That is the UAE processing list as published. Everything else on the agent wish list? Read the next section. Read it twice.
When the bank connects models to internal systems, APIs and enterprise data, you are in agent land. Agent land lives on tools. Tools live on services. Services have regions. Regions are written down. [3] Write them into the design review. Or skip the review and explain it later. Later is worse.
Which API Services Still Process Outside the UAE?
Now the list that should keep an architect awake. Awake. These API services list United States and Europe as their processing regions, NOT the UAE [3]:
- File Search and Web Search inside Responses
- Code Interpreter
- The Remote MCP server tool
- Moderation
- Batches and fine-tuning
- Image generation and audio
- The Decisions API and Structured Outputs
And for the Remote MCP tool OpenAI adds: MCP servers are third-party services, and data sent to them is subject to their own residency policies. [3]
Think about what a banking agent does. It searches documents. It calls tools. It runs code. Those are exactly the services on the not-in-UAE list. Exactly. SAD.
File Search. Web Search. Code Interpreter. Remote MCP. The greatest hits of an enterprise agent. Greatest hits. And they process in the US or EU on that page. [3] So either you replace them with your own in-country tools, or you accept the hop. Accept it in writing. Or refuse the feature. Those are the three honest options. Three.
BTW, two more lines from the same page [3]: system data (account data, usage statistics, billing, support requests, and the structured output schema) is out of residency scope. And data residency endpoints carry a 10% price uplift for models released on or after 5 March 2026.
Schema is system data. Billing is system data. Your pretty JSON field names that mirror internal account attributes? System data. Outside. Design like you know that. Ten percent uplift is the price of the residency path for newer models. Price it. Don't discover it in finance after go-live.
Why Do Tool Schemas and Agents Still Leak Data?
Even when the GPU is in the UAE, the agent can still overshare. Still. Two peer-reviewed receipts.
First, tool schemas. A peer-reviewed study of 2,344 tool specifications from the OpenAI GPT ecosystem found 36.9% expose at least one loosely constrained free-text field the agent can fill with whatever context it holds. [4] Thirty-six point nine. That is over a third of the specs. A free-text slot is an invitation. An invitation the model will take.
Second, the agent itself. At CCS 2024, Google researchers showed a single context-hijacking query cut a Gemini Ultra agent's protection of user data from 94% to 45%. Minimizing what the agent can see restored it to 97%. [5] From 94 to 45. Back to 97 when you starve the context. The lesson is brutal and simple: residency of the GPU does NOT fix an oversharing agent. Does not.
So you host the tools. You tighten the schemas. You minimize what the agent can see. Three moves. Or you pretend the UAE endpoint solved it. Pretend is a JOKE.
The 2,344 specs are not your bank's specs. Fine. The pattern is the pattern. Loose free-text fields invite oversharing. Tight schemas reduce the blast radius. Same for context: less sitting in the agent window means less to hijack. Less. Always less than you think you need.
Residency without schema hygiene is a locked front door and an open side window. Open. Wide.
What Should a Bank Architect Check Before Writing Sovereign on a Slide?
Five checks. Before anyone writes "sovereign" on a slide about in-country LLM inference for a UAE bank. Five. Do them.
- Map every hop, not just the model call. Chat completion in the UAE, file parsing maybe not, MCP tool call depends on the tool server. Draw all three. All three.
- Pin the endpoint and the snapshot. Only the listed snapshots process in the UAE. A model upgrade can silently move your workload to a non-residency path. Silently. Ugly.
- Host your own tools in-country. If the agent needs retrieval or tool calls, run the MCP server and the vector search inside your UAE perimeter instead of using hosted tools that process in the US or EU.
- Treat schemas and metadata as data. A structured output schema that names your internal fields is system data, outside residency. Do NOT put customer identifiers in it. The same goes for your tool schemas: that 36.9% finding is your warning light. [4]
- Test it, don't trust it. Red-team the agent with canary data and check where it shows up. Residency is a configuration. Configurations drift. And the research says the agent itself is a leak path: 94% to 45% under one hijack query. Minimizing context brought it back to 97%. [5]
Five checks. Miss one and "sovereign AI for banking in the UAE" is a brand line, not an architecture. Brand lines do not survive audits. HUGE difference.
Map. Pin. Host. Treat schemas as data. Test. Say it out loud in the design review. If someone skips to the logo slide, send them back to check one. Back.
Canary data in the prompt. Canary data in the file. Canary data in the tool response. Then look where it lands. Logs. Regions. Third parties. If you cannot show the landing zone, you do not have residency. You have a story. Stories fail audits.
So Which Approach Should You Pick?
Use in-country inference. It is a REAL step forward and Emirates NBD deserves credit for going first in MENA. [1] First. Real. Credit due.
But design as if only the GPU stays home, because that is what the documentation promises. [2] [3] Keep tool execution, retrieval and document parsing inside your own UAE infrastructure, and let the model call be the only thing you hand to OpenAI's UAE endpoint.
GPU in the UAE. Everything else, prove it.
That is the pick for in-country LLM inference at a UAE bank. That is the pick for anyone serious about sovereign AI for banking in the UAE. Prove the rest. Always. ALWAYS.
Do not buy the sealed-room fantasy. Do not. Buy the GPU path. Host your tools. Tighten your schemas. Minimize agent context. Re-read the residency pages when they update. Then prove each hop with canaries. That is the work. The WHOLE work.
About the author. I'm Ercin Dedeoglu, an AI architect in Dubai working on LLM, RAG and agentic systems for regulated banking. I write about sovereign, auditable AI at ercin.info. See my selected work, including security architecture as the default. Related: LLM red teaming for banking in the UAE and sovereign GenAI for regulated banking.
Sources
- Emirates NBD, "Emirates NBD Becomes First MENA Bank to Harness OpenAI's Sovereign AI Infrastructure for customers in the UAE", 19 October 2026. https://www.emiratesnbd.com/en/media-center/emirates-nbd-becomes-first-mena-bank-to-harness
- OpenAI Help Center, "Data residency and inference residency for ChatGPT" (re-read 24 Oct 2026, ~00:03 Dubai, page said "Updated: 18 hours ago"; UAE model line has flipped within days). https://help.openai.com/en/articles/9903489
- OpenAI API docs, "Data controls in the OpenAI platform" (re-read 23 Oct 2026). https://platform.openai.com/docs/guides/your-data
- S. Shayesteh and S. Wilson, "From Conventional Web Privacy to Agentic Disclosure: How Tool Schemas May Invite LLM Oversharing", PrivateNLP 2026 (ACL workshop, position paper). https://aclanthology.org/2026.privatenlp-main.1/
- E. Bagdasarian et al., "AirGapAgent: Protecting Privacy-Conscious Conversational Agents", ACM CCS 2024. https://doi.org/10.1145/3658644.3690350