Azure OpenAI and Azure AI Speech in UAE North: is all processing and storage guaranteed inside the UAE for a healthcare assistant?

Hello @Ammar Alyousef ,

The key distinction is between regional inference and an end-to-end contractual guarantee that every supporting operation remains inside the UAE. For a healthcare workload containing identifiable patient data, I would not treat the deployment region alone as sufficient evidence of compliance.

Azure OpenAI data residency

For Azure OpenAI, use only a Standard/Regional or Regional Provisioned Managed deployment in UAE North. Microsoft’s deployment documentation states that inference data for these regional deployment types is processed in the region associated with the deployment. Global deployments may process inference in any supporting Azure region, while Data Zone deployments can process it anywhere within the applicable data zone. Region availability for Foundry Models sold by Azure

Azure OpenAI prompts, completions, embeddings, and training data are not made available to OpenAI, are not available to other customers, and are not used to train foundation models without the customer’s permission. However, optional stateful features such as stored responses, Threads, Files, vector stores, and stored completions create persistent data stores and must be evaluated separately. Azure OpenAI data, privacy, and security

Abuse monitoring is also a separate consideration. By default, prompts and completions identified by automated systems as potentially abusive can undergo further automated review and, in some circumstances, review by authorized Microsoft personnel. Eligible managed customers can apply for modified abuse monitoring, under which prompts and completions are not stored for abuse-monitoring review. This is an approval-based control, not a setting that can simply be disabled in the portal, and healthcare status alone does not automatically qualify an organization. Azure OpenAI abuse monitoring

Therefore, if your requirement means that no patient content may leave the UAE under any circumstance, obtain written confirmation through your Microsoft account team or an Azure support/compliance engagement covering:

• Regional inference processing
• Abuse-monitoring storage and review
• Operational and support access
• Service and diagnostic telemetry
• Stateful Azure OpenAI features
• Backup and disaster-recovery behavior
• Every connected service used by the application

Until that confirmation and modified-abuse-monitoring approval are in place, do not send identifiable patient data to the solution.

Model availability and PTUs

The current Azure OpenAI model catalog includes gpt-6-sol and gpt-6.1-sol, but model existence and API support do not establish that a particular deployment type is available in UAE North. Availability must be checked against the UAE North column under the exact Standard/Regional or Regional Provisioned Managed tab in the region-availability matrix. Azure OpenAI model catalog Regional model availability matrix

You can also verify what is actually available to your UAE North resource through the Foundry deployment interface or the Models List API. Availability can depend on deployment type, model version, subscription, quota, and regional capacity. Working with Azure OpenAI models

Do not assume that gpt-6.1-sol has a committed UAE North rollout date unless Microsoft publishes it in the availability matrix. Public documentation should be treated as authoritative for released availability; an unpublished roadmap cannot be confirmed through Microsoft Q&A.

Provisioned throughput is charged per PTU per hour and provides reserved model-processing capacity. The minimum PTU deployment size is model- and deployment-specific, so there is no single minimum that can safely be quoted for every model. Use the capacity calculator in the Foundry portal after selecting the exact model, version, deployment type, and UAE North region. Provisioned throughput for Foundry Models

Voice processing

Azure AI Speech supports UAE North. Microsoft documents that the core Speech service stores and processes speech data in the region where the Speech resource is created. This applies to supported regional capabilities such as conventional speech-to-text and text-to-speech. Supported Azure Speech regions

Voice Live is an exception. Its speech recognition, high-definition voice synthesis, and LLM inference can have different processing scopes, and processing can occur outside the Speech resource’s region. It should therefore not be used for this workload unless its current region-support documentation explicitly confirms UAE-only processing for every component.

Similarly, an Azure OpenAI Realtime model must not be assumed to run in UAE North merely because the Azure resource was created there. The model must explicitly support a Regional deployment in UAE North. A Global Standard Realtime deployment does not satisfy a UAE-only processing requirement.

For the initial compliant architecture, the safer pattern is:

1. Create an Azure AI Speech resource in UAE North.
2. Use UAE North speech-to-text for transcription.
3. Send the resulting text to an Azure OpenAI Regional deployment in UAE North.
4. Send the response to UAE North text-to-speech.
5. Keep recordings, transcripts, application logs, search indexes, databases, Key Vaults, and backups in UAE regions.
6. Disable payload logging and avoid optional stateful AI features unless their storage behavior has been reviewed.

Arabic voices and custom voice

Azure Speech supports Arabic locales, including ar-AE, ar-SA, ar-KW, ar-QA, ar-BH, ar-OM, ar-LB, ar-JO, and others. The language-support page identifies the available voices and locales, but dialect availability and regional hosting must both be checked. A voice being listed for Arabic does not by itself prove that it is served from UAE North. Azure Speech language and voice support

Custom Voice requires approval under Microsoft’s eligibility and responsible-use process. Professional Custom Voice also requires a recorded consent statement from the voice talent. The normal workflow uploads recordings and scripts, trains the model, and deploys it to a custom endpoint. Custom Voice overview

Before uploading your voice or patient-related material, verify separately that UAE North supports:

• Custom Voice data upload
• Model training
• Model storage
• Custom endpoint deployment and inference

If training is not shown as supported in UAE North, creating the Speech resource there does not make out-of-region training compliant. Written confirmation is required before using the feature.

Compliance documentation

The principal Microsoft contractual document is the Microsoft Products and Services Data Protection Addendum, which governs Microsoft’s processing and security obligations for Customer Data and Personal Data. Use the current edition rather than an archived copy. Microsoft Products and Services DPA

Microsoft’s current Online Services Subprocessor List and available Health and Life Sciences subprocessor documentation can be obtained from the Service Trust Portal. Search the Service Trust Portal for subprocessors

The DPA, Azure compliance reports, and subprocessor lists support your assessment, but they do not themselves certify that a particular clinical-assistant architecture complies with UAE Federal Law No. 2 of 2019, applicable Department of Health Abu Dhabi requirements, DHA requirements, or other UAE healthcare rules. That determination remains the healthcare provider’s responsibility and should be documented through a legal assessment and a data-protection impact assessment.

Before production use, obtain an architecture-specific compliance statement from Microsoft that lists the exact model, deployment type, Speech features, storage services, monitoring configuration, support-access model, subprocessors, and disaster-recovery design. Also ensure the assistant remains clinician-supervised: model output should not be treated as an autonomous diagnosis, prescribing decision, or substitute for professional medical judgment.

Thank you.