A UK operations lead reading the May 2026 coverage of PolyAI, including DILR's own, would have seen one kind of product: a managed enterprise build, designed and delivered by PolyAI's own team. By late October 2026 the picture looks different. PolyAI now runs three routes side by side. There is the managed enterprise programme, a self-serve version of Agent Studio that anyone can sign up to free, and a raw model API for Dialog-RSN-1, which PolyAI's training data page lists with a release date of 1 July 2026. So "PolyAI or something else" is no longer one question. It is three.
This guide is written for the Head of Customer Operations who owns the phone line and the CIO who signs off where caller data goes. It covers what each PolyAI route actually includes, what the model API leaves for your own team to build, where UK caller data is processed on each route, when PolyAI is the right answer, and what moves if you leave. It updates two older DILR pieces that described PolyAI before it opened self-serve: the PolyAI Canada expansion analysis and the May 2026 vendor map. It cedes UK transfer law to the Synthflow alternative guide, PECR and Ofcom calling duties to the Vapi alternative guide, and vendor pricing to the best AI voice agent 2026 guide. No price for any vendor appears below.
The stakes are practical, not theoretical. McKinsey's State of AI (November 2025) found 33% of organisations have AI in production but only about 6% are AI-mature enough to see material EBIT impact. In our experience, the gap often comes down to choices like this one: who builds the agent, who runs it, and who answers for the data.
This guide is shipped by the team behind Dilr Voice, a multi-agent voice AI platform that hands one call between specialist agents and applies each country's calling rules. Or see DATS, our five-stage consulting system for placing AI where the P&L moves.
What changed at PolyAI in 2026, and why does it matter for a UK buyer?
PolyAI, the voice AI company founded in 2017 with an office in London, is best known for managed enterprise builds. In 2026 it also offers two self-serve routes: a free sign-up to Agent Studio, which got a new layout on 24 June 2026, and the Dialog-RSN-1 model API, released on 1 July 2026. A UK buyer now has to pick which route to compare, because each one moves the build work, the data location and the contract.
The company itself is not new to the UK market. PolyAI's about page says it was founded in 2017 by Cambridge machine learning researchers, lists a London office at 3 Sheldon Square and around 250 employees. That matters for one reason: the UK angle in a PolyAI decision is not about leaving a foreign vendor. It is about which of PolyAI's routes keeps your build, your data and your accountability where you need them, and whether a different platform does that better for your call volume and team.
The three routes share a lot underneath. PolyAI's platform overview says most agents run on Raven, its proprietary model, and describes one platform reachable through Agent Studio, a Python agent development kit (ADK) and REST APIs, with an agent built in one surface editable in the others. The Dialog-RSN-1 API is different in kind: it is a model, not an agent platform. The PolyAI pricing page says so in its own words, listing "Telephony and orchestration" as not included in the API column. Our enterprise AI voice agents guide explains why that layer is where most production risk sits.
Two dates on that pricing page are worth a calendar entry. The launch sign-up credit and free voice output on the API both run until 19 November, and the Dialog-RSN-1 limits page says its concurrency and session caps apply from 20 October 2026. A pilot scoped around launch terms should be costed on the terms that apply after them.
Which PolyAI route are you actually comparing against?
PolyAI now offers three distinct routes, and an honest alternative search compares like with like. The managed enterprise route has PolyAI's team designing and running the agent on reserved capacity. Self-serve Agent Studio lets your own team build on the same platform. The Dialog-RSN-1 API sells the model alone, so your engineers supply telephony, orchestration, voice and guardrails. Each route competes with a different kind of alternative.
The table below sets the three side by side, using only what PolyAI's own pages say today. Read it as a map of who does the work, not a ranking.
| Managed enterprise | Self-serve Agent Studio | Dialog-RSN-1 API | |
|---|---|---|---|
| Who builds the agent | PolyAI's team with yours | Your team, in Agent Studio, the ADK or the APIs | Your engineers, from the model up |
| What is included | Platform, numbers, integrations, analytics | Same platform, self-serve | The model only; telephony and orchestration not included |
| Capacity | Reserved capacity, outside the self-serve cap | Self-serve account limits | 2 concurrent sessions on the sign-up credit, 10 with a card on file |
| Languages | Raven, listed at 24+ in the platform docs | Raven, 24+ | English only today |
| Data region | One region per workspace; the API docs list US, UK and EU | The Studio region, which the docs do not name | Self-serve keys US only; UK and EU served from Ireland on request |
| Compares best against | Other managed enterprise vendors | Self-serve platforms such as Dilr Voice | Model and orchestration stacks |
The most common mistake we see is comparing a managed PolyAI programme with a self-serve platform's free tier, or comparing the Dialog-RSN-1 API with a finished agent platform. Neither comparison is fair to either side. A managed build buys you PolyAI's delivery team; the API buys you a fast model and an empty workbench.
Those are different purchases, and they should sit in different business cases. If you are still deciding whether to build or buy at all, our guide to in-house versus vendor voice AI operating models sets out the staffing cost of each. The rest of this guide starts with the route that asks the most of your own team, then covers where data sits on each route and when the managed route is the right call.
What does the Dialog-RSN-1 API leave for your team to build?
The Dialog-RSN-1 API gives you an audio-native model that hears the caller, decides when to speak and writes the reply. PolyAI's own pricing page lists telephony and orchestration as not included, so your team supplies the phone numbers, the call routing, the handover to a human, the call records and any guardrails. For a UK contact centre, that list is most of what makes a voice agent safe to put on a live line.
The model itself is serious engineering. PolyAI's Dialog-RSN-1 overview explains that it folds transcription and generation into one pass and can return text instead of audio, so you can voice replies through your own text-to-speech vendor and "run your own guardrails" before a caller hears anything. It speaks the OpenAI Realtime standard, and the docs include a guide for porting an existing OpenAI Realtime app. If your engineers already run a realtime voice stack, that is a genuine reason to test it.
The limits page is where an operations lead should spend ten minutes. Today it says:
- Concurrency: 2 concurrent sessions per account on the sign-up credit and 10 once a card is on file. More is agreed per account, and enterprise deployments run on reserved capacity outside the self-serve cap.
- Session length: 60 minutes per session, after which the session expires and your code must reconnect. There is also a 5 minute idle timeout without a client event.
- Languages: English only, with more promised in a future model update.
- Audio: G.711 mu-law and A-law at 8 kHz are accepted, which suits phone audio, alongside PCM16.
Each line has an operational consequence. Ten concurrent sessions is a pilot, not a Monday morning in a busy UK service team. A 60 minute ceiling is fine for most calls, but your orchestration must handle the reconnect cleanly on a long complaint call. English only rules the route out today for a Welsh-language line or a multilingual inbound queue.
The fourth box is the one UK teams underestimate. Recording consent, calling-hours rules, opt-out handling and the audit trail a regulator or a complaints team will ask for all have to be built when you buy a model rather than a platform. Our guide to orchestration versus platform buying sets out that trade in general; the PolyAI API is one specific, well-engineered instance of the orchestration side of it.
The same build-or-buy logic runs through our AI operating model consulting, which decides who owns each of those four layers before any contract is signed.
Where is UK caller data processed on each PolyAI route?
UK caller data lands in different places depending on the PolyAI route. The Dialog-RSN-1 API reference says self-serve keys run in the US only, with UK and EU workspaces served from PolyAI's EU region in Ireland on request. The wider platform API lists US, UK and EU regions, and PolyAI's homepage advertises data residency with no cross-region transfer. A UK buyer must confirm which route and region a given contract actually uses.
The exact wording matters, so here it is from PolyAI's Dialog-RSN-1 API reference: "Self-serve keys run in the US only. UK and EU workspaces are served from our EU region (Ireland) via api.uk.poly.ai and api.eu.poly.ai, available on request." The platform's API introduction separately lists US, UK and EU regions and says a workspace lives in exactly one region. The PolyAI homepage lists data residency across US, UK, EU and APAC with no cross-region transfer.
These statements sit on different pages and describe different products, so read each one for the route it covers. On PolyAI's own wording, the narrow and useful point for a buyer is this: a developer who signs up self-serve and starts calling the model API is sending UK caller audio to the US unless a UK or EU workspace has been arranged. Whether that is acceptable is a transfer question, and our Synthflow alternative guide covers how a UK team should handle a vendor that processes outside the UK. The point here is that the default and the enterprise route differ.
There is a second data question that applies to every route: who is the processor, and is your due diligence on file? UK GDPR puts that duty on you as the controller, not on the vendor. Article 28(1), as published on legislation.gov.uk, reads:
"Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject."
On the managed route that is one main processor relationship with PolyAI. On the API route you are assembling a chain: PolyAI for the model, a telephony carrier, a voice vendor and whatever hosts your orchestration code. Each link needs its own guarantees on file. Our UK and EU voice AI compliance guide covers the wider duties.
Training data is the last check. PolyAI's training data page says Dialog-RSN-1 training data was collected from November 2024 to June 2026 and sourced from PolyAI customers "to the extent contractually authorized", with personal information redaction applied. Read your own contract's training clause with that in mind, and ask for the opt-out position in writing.
When is PolyAI the right choice for a UK enterprise?
PolyAI is a strong choice for a large UK contact centre that wants a vendor's team to design and run the agent, needs published certifications, and already runs Genesys, Five9 or NICE CXone. Its homepage lists SOC 2+ Type 2, ISO 27001 and PCI DSS, its docs connect those contact-centre platforms over SIP, and enterprise deployments run on reserved capacity. Where those three needs meet, the managed route is, in our view, hard to beat.
It is worth being specific about where PolyAI leads, because an alternative that cannot match these should not be on your shortlist for that kind of programme:
- Published certifications. PolyAI's homepage lists SOC 2+ Type 2, ISO 27001, PCI DSS and GDPR, and its security page says it is ISO 27001 certified and hosted on AWS. If your procurement team requires a SOC 2 report or PCI DSS for card payments taken on the call, that is a hard filter, and some platforms, Dilr Voice included, do not meet it. Ask PolyAI for the reports themselves rather than relying on the homepage list.
- Contact-centre fit. The numbers documentation connects Genesys, Five9 and NICE CXone over SIP, alongside numbers bought from PolyAI and Twilio. A team keeping its existing contact-centre platform gets a supported path.
- Delivery capacity. PolyAI's about page says it works with enterprises to build, run, govern and improve their agents. Our earlier Canada expansion analysis read that as a capacity-scaling model, which suits an enterprise that wants a partner to own the build.
- Release discipline. The platform has branches, separate environments, rollbacks and live experiments that run a branch against live traffic, which a regulated team needs for change control.
PolyAI also publishes strong outcome figures, and they should be read for what they are. Its homepage says 90% of calls are resolved end to end with no human agent "on our largest deployments", and quotes 99.994% uptime over the trailing twelve months. Both are vendor-reported, measured on PolyAI's own terms. Ask for the definition of "resolved" and for references in your own sector before putting either number in a business case, and write any uptime commitment into the contract rather than the slide; our SLA design guide shows how.
How does Dilr Voice differ from a PolyAI build?
Dilr Voice is a self-serve, multi-agent platform from DILR.AI that chains specialist agents, such as a greeter, a qualifier and a customer-care agent, into one phone call and ships per-country calling rules by default. Most teams start self-serve at app.dilr.ai. It suits a UK team that wants to run inbound and outbound itself, and it does not hold SOC 2 or HIPAA certification, which rules it out for some procurement checklists.
That last point belongs in the first paragraph, not the footnotes. If your security team needs a SOC 2 report, PolyAI lists SOC 2+ Type 2 on its homepage and Dilr Voice does not hold SOC 2. Within that limit, the two products make different bets:
- Who builds. On Dilr Voice, most teams build their own agents in the visual editor. When calls touch a CRM, a regulated process or several sites, the DILR consulting team scopes the rollout and can stay on through the AI execution office until it runs in production.
- How a call is structured. Each Dilr Voice agent has its own prompt, model and tools and passes context to the next on handover. A greeter can hand to a qualifier, which hands to a knowledge agent that answers from your own documents through RAG.
- Calling rules. Dilr Voice ships per-country compliance rules for the US, UK, EU, India, Australia and more: recording consent, DNC registry checks, opt-out recognition and permitted calling hours, with an audit trail on every call. On the PolyAI API route those rules are yours to build. On either route, consent to call stays your responsibility under PECR and UK GDPR: rules shipped in software help you apply it, they do not take the duty off you.
- Telephony. Calls run on Twilio or Vobiz, routed by country code. Outbound campaigns run through your own connected Twilio account, which bills its telephony to you.
- Hosting. Dilr runs on Google Cloud Platform (GKE), encrypted at rest and in transit, and the DILR FAQ lists dedicated tenancy and regional data residency options for enterprise customers.
- Speed and languages. Dilr Voice targets a response time under 500 milliseconds, based on DILR's own on-platform measurement, and supports 30+ languages. PolyAI publishes its own latency figures on its own terms, so compare the two on your own test calls rather than on either vendor's page.
The honest summary: PolyAI's managed route is a partner-led programme for large, certified, multi-site contact centres. Dilr Voice is a platform your own team runs, with consulting on hand for the regulated parts. Which is right depends on who you want doing the work, not on a feature count. You can try Dilr Voice on your own calls before deciding.
What moves if you leave PolyAI, and what stays behind?
Leaving PolyAI means moving phone numbers, call records and agent logic. Numbers connected from your own Twilio account stay in that account, so only the routing changes. Numbers bought through PolyAI need a written porting answer first. Recordings move cleanly only if the S3 sync was set up, and flows, knowledge and tools should be planned as a rebuild on the new platform.
Work through it in this order, because each step has a lead time:
- Numbers. PolyAI's Twilio guide says connecting your own Twilio numbers means you keep them, with no port needed. If your numbers were bought through PolyAI, ask in writing how a port-out works and how long it takes before you sign anything new.
- Call records. PolyAI's call data page says transcripts in Agent Studio include audio but no download, while the AWS S3 integration syncs downloadable recordings and transcripts to your own bucket. If you have recordings you must keep for complaints or regulatory review, switch on the S3 sync well before you leave.
- Outbound history. The outbound calling page says call status data is retained for about 2 hours after a call ends. If your outbound reporting depends on it, your own systems should already be storing it.
- Agent logic. Plan to rebuild flows, knowledge, tools and handover rules on the new platform unless the new vendor offers an importer you have tested. Export your knowledge base content and write down every flow's decision points first; that document is worth more than any converter.
- Cut-over. Run the new agent on a slice of traffic before you move the full number range, and keep the old route live as a fallback.
The mechanics of a safe cut-over are the same whichever vendor you leave, and the Retell alternative guide walks through them step by step. If you move numbers between carriers, the Bland alternative guide covers port-in timing.
The business case for moving at all should rest on return, not on features. Our AI voice ROI framework shows how to cost the migration against what the new platform saves, and a placement diagnostic tells you whether voice is even the right place to start.
What is the best PolyAI alternative for UK teams in 2026?
The best PolyAI alternative depends on which PolyAI route you are replacing. In our view, a UK team replacing the managed route should shortlist another certified, partner-led vendor. A team weighing the Dialog-RSN-1 API should compare other model and orchestration stacks. A team that wants to run its own agents, with UK calling rules shipped by default, should test a self-serve platform such as Dilr Voice.
The criteria we would use, in order:
- Certification needs. If SOC 2 or PCI DSS is mandatory, the shortlist is short. PolyAI's homepage lists both; Dilr Voice does not hold SOC 2.
- Who builds and runs it. Partner-led favours PolyAI's managed route. Your own team favours a self-serve platform. Your own engineers favour a model API.
- Where the data sits. Confirm the region in the contract, not on the homepage, for the route you are actually buying.
- Languages. The Dialog-RSN-1 API is English only today, while PolyAI's about page says 75 languages and its platform docs list 24+ for Raven; ask which figure applies to your agent. Dilr Voice lists 30+.
- Calling rules. On any API route, budget the time to build consent, quiet hours and opt-out handling yourself.
Where PolyAI wins outright: a large UK contact centre on Genesys, Five9 or NICE CXone, with a SOC 2 requirement and appetite for a delivery partner, will usually find PolyAI's managed route the stronger fit. Where Dilr Voice wins: a team that wants to build and run its own inbound and outbound agents, with per-country rules shipped and consulting available for the regulated parts. Our AI execution office can run whichever platform you choose until it holds up in production.
Does the Dialog-RSN-1 API give you PolyAI without the platform?
The Dialog-RSN-1 API gives you PolyAI's model, not PolyAI's platform. PolyAI's pricing page lists telephony and orchestration as not included on the API, so any cost comparison is the model plus your carrier, your voice vendor, your hosting and your engineers' time, against a platform price that PolyAI says includes improvements, maintenance and round-the-clock support.
In our view, engineering time is often the largest line. If you do not already run a realtime voice stack, cost the build properly before treating the API as the lighter option, and compare it with a finished platform such as Dilr Voice on the same call volume.
Can a self-serve PolyAI account keep UK caller data in the UK?
A self-serve PolyAI account using the Dialog-RSN-1 API does not keep UK caller data in the UK by default. PolyAI's API reference says self-serve keys run in the US only, and UK and EU workspaces for that API are served from its EU region in Ireland on request. A UK team that needs a specific location should agree the workspace region in writing before any live calls.
That answer is about the model API. Enterprise PolyAI workspaces are provisioned to a region, and PolyAI's API introduction lists US, UK and EU hosts, so ask which host your workspace sits on and write it into the data processing agreement.
Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, compare platforms in the best AI voice agent guide, or read about our approach to placing AI inside enterprise systems. More vendor comparisons sit in the voice AI category, and you can read about our DATS methodology.
Pick the route before you pick the vendor.
30-min scoping call · No deck · Confidential. We will tell you whether a managed build, a platform or a model API fits your calls, and who should own each layer.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.