UAE AI Call Centres:Where Does One Customer Call Go?

A customer call has a longer life than the conversation

Imagine a customer calling your Dubai support team about a delivery. The agent answers, the customer hangs up, and a neat AI summary appears in the CRM.

Where did the audio go? Which service turned it into text? Where was the summary generated? Can a support engineer download the transcript? What happens to those copies when you delete the call?

These questions are a practical way to evaluate UAE AI call centre data residency. Follow the data through the complete interaction, including the systems that operate after the call ends.

What changed today: the Toku–Core42 announcement

On 8 October 2026, Toku announced an agreement to host its customer-experience platform on Core42 Sovereign Enabled Public Cloud in the UAE. Toku says onboarding has begun; the signing ceremony took place on 2 October.

Core42 describes its platform as Azure infrastructure with UAE sovereignty and security controls managed through Insight.

That news makes the buying question timely: what evidence should a business request for its own call workflow?

The example below is an original, fictional reference workflow. Its components and findings do not describe Toku's production implementation. This article is based on public documentation reviewed on 8 October; we have not audited either company's service.

Map seven data paths before you choose a platform

A voice workflow can create several kinds of data. The following seven paths are a starting inventory. Your system may have more, fewer or combined components.

For each path, record who operates it, where processing happens, where data persists, who can access it and how it expires. Give unknown values an owner and a next action.

For a workload whose approved boundary is the UAE, make that boundary explicit. Ask your compliance owner to identify the applicable rules and permitted transfers. The UAE Government's data-protection overview describes requirements for cross-border sharing and processing; a cloud-region label cannot make that legal assessment for you.

The processing location can differ from the storage location

A model's deployment type is an important detail in this map.

Microsoft's Foundry deployment documentation distinguishes these processing scopes:

The same documentation treats storage at rest separately. Verify the actual deployment type alongside the resource's location. Model and deployment availability varies; obtain a dated answer for the model you intend to use.

These are general Azure distinctions. They do not establish which deployment a particular Toku or Core42 customer uses.

Ask the vendor to show the configuration for the component that creates the summary. Then ask what configuration it uses during retries, overload or an outage. A normal request and a fallback request both belong in your approved data map.

Real-time transcription and saved transcripts are separate checks

Microsoft's Speech privacy documentation says real-time speech recognition processes input in server memory without storing it at rest. Batch transcription has different storage and retention behaviour, including customer-selected storage and generated output.

Your call-centre app can still save the transcript it receives. Identify the service's behaviour and the application's recording settings separately.

For example, ask: “If I disable call recording, will this workflow still save a transcript, a summary or a ticket attachment?” Have the vendor demonstrate the answer with a synthetic interaction.

It is also useful to record whether transcription, translation and summarisation use separate services. Each enabled feature needs a destination and a retention answer.

Work through one fictional call

Use a harmless test sentence such as:

“This is test call DEMO-CALL-008. Please check the delivery window for fictional order DEMO-ORDER-104.”

Avoid real customer names, phone numbers, payment details and account identifiers. The call ID is a correlation marker, not an access credential.

Suppose a fictional pilot produces the following evidence:

The result of this fictional review is incomplete evidence. That is a useful outcome: it tells the buyer what must be resolved before the workflow receives sensitive production data.

A response such as “our main server is in Dubai” leaves those rows unanswered. A stronger response identifies the specific service, deployed setting, contractual scope and dated evidence for each row.

Collect evidence without collecting more customer content

Use the synthetic marker to inspect the application's known stores and event records. Ask for configuration exports, service documentation and request metadata that identify the processing component. Keep evidence access limited to the people who need it.

If you receive only an endpoint URL or an IP address, request the corresponding service commitment. Network observations alone do not establish every backend processing or storage location.

The map should also name any processor that does not expose a customer-visible configuration. For that component, record the contractual answer, its scope and who will notify you when it changes.

A small evidence record can look like this:

{
  "test_call_id": "DEMO-CALL-008",
  "component": "ai_summary",
  "approved_boundary": "UAE",
  "model_provider": "TO_BE_CONFIRMED",
  "deployment_type": "TO_BE_CONFIRMED",
  "processing_boundary": "TO_BE_CONFIRMED",
  "storage_boundary": "TO_BE_CONFIRMED",
  "retention_policy": "TO_BE_CONFIRMED",
  "fallback_route": "TO_BE_CONFIRMED",
  "evidence_reference": null,
  "reviewed_at": null,
  "owner": "Platform team",
  "status": "needs_evidence"
}

This JSON is an original worksheet, not a provider API schema. Replace the placeholders with reviewed evidence. Do not place API keys, access tokens or customer content in it.

Ask about training, retention and support access separately

Microsoft's Foundry privacy documentation says prompts and completions are not used to train its base models. It also describes storage associated with stateful features and abuse monitoring, including authorised human review in specified circumstances.

Those are separate operational questions. For every provider in your own workflow, establish:

• whether customer inputs or outputs may be used for training;
• which features retain them and for how long;
• what diagnostic or safety-review processes apply;
• who can access content, under which approval and with what record.

Apply the answers to the precise service and account arrangement. Avoid treating one provider's documentation as a commitment from every other processor.

Logs deserve their own review. Azure Monitor's guidance identifies user IDs, IP addresses and custom fields as places to look for personal data. It recommends reducing unnecessary personal data at collection.

For your pilot, begin with the fields needed to diagnose failures: component name, result category, timing and a controlled correlation ID. Review what the application actually writes. A “debug” switch can change the contents of your data map without changing the app's hosting region.

Test deletion after recovery, too

Choose one synthetic interaction for an authorised deletion exercise. Before starting, agree which artefacts should be deleted, which may legitimately remain under retention or hold rules, and the deadline for each action.

Then test the live workflow and an isolated recovery copy.

An immutable backup may expire through a retention process rather than permit an individual record to be edited. Record that behaviour and the safeguards for any restore.

Azure Storage documentation distinguishes primary-region replication from replication to a secondary region. Check the actual destination; “geo-redundant” alone does not name a country. Replication also needs separate consideration from recoverable backup history.

Microsoft's sovereign implementation guidance includes tested recovery, controlled operational access and residency-aware failover. Treat these as evidence to obtain for your intended design.

A synthetic marker search has limits: it can miss transformed summaries, hashed identifiers and stores you cannot query. Combine the exercise with the component inventory and vendor evidence. Passing one search is not proof that every copy has disappeared.

The vendor question that brings the map together

You can send the following request when evaluating a platform:

For the specific voice, transcription, summarisation, CRM and recovery features in our proposal, please provide the processing and storage locations, enabled retention/stateful features, processors, support-access arrangements and fallback destinations. Please attach dated configuration or contractual evidence, identify any unknowns, and demonstrate how one synthetic interaction is traced, deleted and handled after a backup restore.

This is a request template; we have not sent it to any vendor.

Review the answers with the people who own the platform, customer-service workflow and data obligations. Resolve unknown routes before sending data that depends on those assurances.

Choose the workflow you can explain and recover

A useful AI contact-centre pilot should improve the customer's experience while leaving a data trail your team can account for.

Alongside the location checks, try representative Arabic and English interactions, corrections, transfers to a human, and requests the agent should decline or escalate. Check whether the written summary matches what the customer actually asked. Use synthetic scenarios with expected outcomes; this guide does not supply vendor performance scores.

For the wider infrastructure decision, see our UAE hosting and latency guide and UAE hosting-provider due-diligence guide. If an AI agent can modify your website or business systems, our guide to agent permissions and website security covers the next access boundary.

Start with one call. Account for its processing, stored copies, human access and recovery. Repeat the review whenever a model, integration, logging setting or fallback route changes.