When you call an AI model, where does your data actually go?<\/p>\n\n\n\n
For financial institutions, this is not a theoretical infrastructure question. It can determine your data-residency, governance and deployment options.<\/p>\n\n\n\n
The model provider’s name doesn’t necessarily tell you where inference happens.<\/p>\n\n\n\n
Anthropic does not operate Claude entirely on infrastructure it owns. Its infrastructure relationships include AWS and Google Cloud. OpenAI similarly relies heavily on cloud infrastructure, while Google has the unusual advantage of owning much more of the underlying stack itself.<\/p>\n\n\n\n
So when a compliance or security team asks:<\/p>\n\n\n\n
\u201cWhere is our data processed?\u201d<\/strong><\/p>\n\n\n\n \u201cAnthropic\u201d, \u201cOpenAI\u201d or \u201cGemini\u201d isn’t a sufficient answer.<\/p>\n\n\n\n You need to understand the infrastructure and, more importantly, the deployment path<\/strong>.<\/p>\n\n\n\n This is where things become interesting.<\/p>\n\n\n\n Calling Claude through Anthropic’s API and deploying Claude through AWS Bedrock may ultimately involve closely related underlying infrastructure.<\/p>\n\n\n\n But from an enterprise perspective they are not the same deployment.<\/p>\n\n\n\n The contractual framework, regional controls, data routing, identity and access management, logging, security controls and accountability can all be different.<\/p>\n\n\n\n The same applies to other models.<\/p>\n\n\n\n For a regulated financial institution, choosing an AI model therefore isn’t enough. You also need to choose how and where that model is deployed<\/strong>.<\/p>\n\n\n\n This has a practical consequence that is easy to underestimate.<\/p>\n\n\n\n You might decide that a particular model is technically the best model for your use case, only to discover that it cannot be deployed in the region required by your organisation.<\/p>\n\n\n\n That can leave you with several choices:<\/p>\n\n\n\n use another model available locally, use an approved cloud-provider deployment, accept cross-border processing where regulations and institutional policy permit it, or deploy an open-weight model within infrastructure you control.<\/p>\n\n\n\n This is one reason I increasingly think enterprise AI architecture has to separate the application from the model<\/strong>.<\/p>\n\n\n\n Models change. Regional availability changes. Regulatory requirements change. Your architecture should make changing the inference layer possible without rebuilding the application around it.<\/p>\n\n\n\n This is particularly important in the Gulf.<\/p>\n\n\n\n UAE, Saudi Arabia and Qatar have very different AI infrastructure footprints. Treating \u201cGCC deployment\u201d as a single architecture decision can therefore be a serious mistake.<\/p>\n\n\n\n I mapped the major proprietary and open-weight deployment options across the UK, EU, UAE, Saudi Arabia and Qatar<\/strong> in the accompanying guide, including Claude, GPT, Gemini, Llama, Mistral, DeepSeek, Phi, Gemma and Qwen.<\/p>\n\n\n\n The differences are significant.<\/p>\n\n\n\n And there is another lesson here: cloud availability itself is an operational dependency.<\/strong><\/p>\n\n\n\n Since the guide was produced, disruption to AWS infrastructure in the Gulf has affected regional availability. Even where a region satisfies your residency requirements on paper, resilience and availability still need to form part of the architecture decision.<\/p>\n\n\n\n There is also now a limited OpenAI direct-API inference option in the UAE, but access is restricted to government and selected organisations. For most commercial organisations, this does not yet change the broader deployment considerations described in the guide.<\/p>\n\n\n\n For organisations with particularly strict deployment requirements, open-weight models change the equation.<\/p>\n\n\n\n They can be deployed inside infrastructure controlled by the institution, including private cloud and potentially air-gapped environments. This provides much greater control over inference location and data routing.<\/p>\n\n\n\n That doesn’t automatically make open models the right choice. Model quality, operational complexity, security, hardware requirements and ongoing model management all have to be considered.<\/p>\n\n\n\n But it gives the architect another lever when data cannot leave a particular environment.<\/p>\n\n\n\n One of the mistakes we make when talking about generative AI is treating the model as though it were the whole system.<\/p>\n\n\n\n It isn’t.<\/p>\n\n\n\n Behind every inference request is infrastructure, networking, identity, storage, logging, contractual responsibility and a physical location where computation happens.<\/p>\n\n\n\n For regulated financial services, those details matter.<\/p>\n\n\n\n The question isn’t simply which AI model you’re using.<\/strong><\/p>\n\n\n\n It’s where it runs, where your data goes, and who is accountable for it.<\/strong><\/p>\n\n\n\nThe same model can have a completely different compliance posture<\/h2>\n\n\n\n
Data residency can become a model-selection constraint<\/h2>\n\n\n\n
The Gulf is not one market<\/h2>\n\n\n\n
Open-weight models provide another option<\/h2>\n\n\n\n
The infrastructure layer is always there<\/h2>\n\n\n\n