Voice AI vendors love to talk about "global availability." Look at the network diagram and it's usually a single primary region in us-east-1, with CDN edges routing your user through multiple network hops before the synthesis call actually runs.
For Arabic voice AI, that topology doesn't work. Not in a product sense, not in a regulatory sense, and not even in the narrow engineering sense of getting the first audio byte back in under 200 ms.
This is a note on why Hakim runs in four regions from day one. Frankfurt, UAE, KSA, Qatar, instead of one-and-a-CDN.
The latency floor
Speech is real-time. Humans start noticing latency at around 150 ms of perceived delay between an action and the corresponding sound. That's the target any voice product is implicitly fighting against. For conversational voice AI, the perceived delay includes: network round-trip, inference, first-audio-byte emission, decoder startup, and then the audio itself.
If your inference runs in Northern Virginia and your user is in Riyadh, you've spent 120-180 ms on the network alone before the model even begins. You can compensate by shipping a faster model, we've done that, but you can't compensate by enough. Once you cross the speed-of-light budget, no amount of optimization buys it back.
Our published p95, 113 ms end-to-end for TTS, is real, but it's also regional. It's the number a user in the region where the model runs actually sees. Publishing a number that requires routing to a far-away primary would be dishonest.
Data residency isn't optional
Beyond latency, regulatory posture in MENA markets isn't the polite "please don't move our data" of 2015. It's the explicit "if you process this audio, it processes inside the country." KSA's PDPL, the UAE's federal data laws, and the sector-specific regulations in telecoms, healthcare, and finance all work this way.
You can try to bend that with contractual assurances and audit reports. In practice, for any customer doing anything sensitive, which in voice AI is most customers, the only safe answer is physical residency. Audio leaves the customer's device, hits a model running in-country, and nothing cross-border except the metered billing data.
Frankfurt solves that for the EU. UAE, KSA, and Qatar solve that for the markets each is home to. There's no hub-and-spoke; each region is its own deployment.
What "each region is its own deployment" means
Four regions, four full stacks:
- Independent Postgres. Workspaces are pinned to a region at creation. The workspace's metadata, API keys, usage counters, and audit logs live in that region's Postgres. No cross-region replication, no "read replica in us-east-1." Recovery plans are per-region.
- Independent model replicas. Each region runs its own set of GPU-backed inference pods, with the same model artifacts loaded locally. A region's synthesis calls don't leave the region.
- Independent object storage. Audio uploads (for STT, for cloning, for webhooks) land in a regional S3-compatible bucket. The bucket lives in the region; lifecycle rules are configured per-region to match the residency promise.
- Independent secrets. API keys, webhook secrets, and any customer-supplied encryption keys are scoped per-region. A key issued in Frankfurt simply doesn't work against UAE, the key format includes a region prefix that's validated before any call routes.
The only thing that is genuinely "global" is the public marketing site and the billing metadata (which is itself aggregated from per-region usage records and stored in the region of the billing entity, us, not the workspace).
Why not a CDN?
People ask. CDNs are fantastic for static assets. For a synthesis call, though, a CDN doesn't help, the call has to hit model weights, not cached audio. You can put a CDN in front of the cached result and get a speed-up for replays, but the first call of any unique (voice, text) pair has to traverse to an origin. Putting origins in four regions solves the first-call latency and the residency requirement in one step.
A CDN also doesn't change the regulatory story. A cached audio file that traversed borders is still audio that traversed borders; for the customers we care about, that's a hard no regardless of the cache HIT rate.
How we rolled it out
Not all at once. We ran Frankfurt first (December 2025) because it was the region with the most mature hardware availability and the cleanest regulatory answer (EU GDPR is well-understood). UAE came a week later, bootstrapped with a first-party partner who helped us navigate the Emirates-specific compliance surface.
KSA and Qatar followed in February 2026, because the in-country infrastructure matured separately. The order wasn't commercial; it was physical.
Each region went from "available" to "production" only after we'd run the full suite of model evals on regionally-deployed pods, verified residency manually against our own audit trail, and reviewed the deployment with our compliance partner. We'd rather launch a region slow and right than fast and wrong.
What you get as a customer
A workspace pinned to the region closest to your users. An X-Hakim-Region header on every response so you can verify, from your side, where the call was served. A per-region status page. A regulatory posture you can hand to your own compliance team without wincing.
And, honestly, the 113 ms, which only the right topology gets you.
What's next
More regions when the market asks. We've had discussions about Egypt and Jordan; if the volume is there, so will the deployment be. No promises on dates, we'd rather ship a region when it's ready than book one on a slide deck.
If you have a specific regulatory or latency requirement that isn't covered by the current four, we want to hear it. The enterprise-contact form on /enterprise goes straight to the team.