Technical questions

These are the questions technology, architecture and security teams ask most often, answered directly. Each answer gives the position in a few sentences and links to the page with the full detail. If your question is not here, your technical contact at Telonic answers it in writing.

Where your data lives and how it is protected

Where does our data live?

In the region you choose. Telonic runs in a UAE region, a Saudi Arabian region, your own cloud account or your own premises, and all processing for your deployment runs in the region you choose, unless you explicitly choose a language model provider outside it. Regional hosting uses major cloud providers' data centres in each country, and the provider and region are named in your agreement. Backups and disaster recovery copies are encrypted and stay in the same country as your deployment.

See Hosting and data residency.

Which AI models does Telonic use?

Each deployment uses speech recognition, a language model and voice synthesis, chosen with you for your languages, your brand's voice and your region. Language models come from providers including OpenAI, Anthropic, Google Gemini, Mistral AI, Meta (Llama models) and TII (Falcon models), and speech recognition and voice synthesis from specialist providers such as Deepgram, ElevenLabs and Speechmatics. Which providers and models are available in your region is confirmed during implementation, and named in your agreement. Speech recognition and voice synthesis always run in your chosen region; only a language model can be chosen outside it, and personal information is redacted before any text reaches it.

See Models and providers.

Do you or your providers train models on our data?

Your data is used only to run your deployment. Contracts with every provider prohibit using your data to train or improve their models, and zero data retention arrangements (where the provider keeps no copy of what it processes) are used wherever a provider offers them. What Telonic carries from one deployment to the next is industry knowledge, such as workflows, edge cases and test sets, never your customer data.

See Models and providers.

How is our data encrypted?

Every connection between your systems and your deployment uses TLS (Transport Layer Security, the standard encryption for data crossing a network), version 1.2 or higher. Call audio is encrypted with SRTP (Secure Real-time Transport Protocol, the encrypted form of the stream that carries voice) by default, and unencrypted audio is used only over a private network connection, at your written request. Stored data is encrypted with AES-256 (the Advanced Encryption Standard, using 256-bit keys), with keys managed through your hosting environment's key management service (the cloud service that creates, stores and controls access to encryption keys). In your own cloud account, you can use keys you manage yourself.

See Encryption.

Can our team sign in through our own single sign-on?

Yes. Your team signs in through your own identity provider (the system that manages your staff's logins) using single sign-on (SSO, one login managed by your organisation) over SAML 2.0 or OpenID Connect (the two standard protocols identity providers use to confirm who someone is), with multi-factor authentication (a second check beyond a password). Each person, and each agent, has only the access its role needs, and access and changes are logged.

See Access control and single sign-on.

Can we host Telonic ourselves?

Yes, in your own cloud account or on your own premises. For your own cloud account, Microsoft Azure, AWS, Google Cloud and Core42 are supported, every component runs inside your environment, and customer-managed keys are supported. On your premises, the deployment runs open-weight language models (models that can be run on your own hardware) and self-hosted speech models, with computing capacity sized with you during implementation. In both options, only operational health signals containing no customer data are sent to Telonic, and you can switch them off.

See Hosting and data residency and Deployment separation.

Connecting to your systems

How does it connect to our phone system?

Through the carrier and phone system you already have, over SIP (the standard protocol business phone systems use to set up and connect calls). Your numbers, your carrier contract and your call routing stay yours, and your phone system decides which calls reach the agent. Trunks are authenticated with IP allow-listing (accepting connections only from addresses you list) and SIP digest credentials (a username and password check on each connection), and mutual TLS (where both sides prove their identity with certificates) is supported. Telonic provides fixed IP addresses, port ranges and a domain name for your allow-list.

See Voice: connecting your telephony over SIP.

Our systems are old. Will this work?

The agent connects to most systems, old or new, as long as the system can expose an interface, such as an API (a defined way for one system to request data or actions from another). Systems that are not on the integrations list are connected through a custom action defined during implementation. Tell us which systems you have in mind at the start, and our technical team confirms how each one connects before you commit.

See Custom actions and How a system gets connected.

Who maintains the integrations after go-live?

Telonic does. We maintain the connections we build for your deployment, monitor them, and test any change to them before it is released. When one of your systems is upgraded, tell us in advance and we test the connection against the new version before it goes live. You are told before any significant change on our side.

See How a system gets connected.

What do you need from our IT team?

Access to the systems being connected, with the permissions you choose to grant, and a person who knows how those systems work. For voice, a SIP route and network access to the Telonic endpoint in your region. For your team's logins, the configuration in your identity provider. The integration work itself is ours.

See What we need from your IT team.

Reliability, testing and accuracy

What happens if a provider goes down?

Your deployment switches to another approved provider in your chosen region. Failover is configured during implementation, and fallback providers are tested in advance, like any other change. For voice, your phone system can check the Telonic endpoint with SIP OPTIONS health checks (regular messages that confirm the other side is available) and route calls to your team if it cannot be reached.

See Models and providers.

How is the agent tested?

Against test sets drawn from real conversation patterns in your industry, scored against what a correct outcome means there, before every release. Changes are made and checked in a test environment before they reach your live deployment, and scope and escalation rules are tested with them. A new model is adopted only when it performs at least as well on the industry test set, and you approve any change of model or provider before release. The platform is also tested by independent penetration testers (security specialists who try to break in, so weaknesses are found and fixed) at least once a year and after major changes.

See Testing before every release and Secure development and testing.

How do you stop it making things up?

Anything that could create an obligation for you comes from your systems and approved documents, not from the model. A price, a policy term, an amount or a date is retrieved from those sources, and figures are inserted directly from the system record rather than retyped by the model. When the answer is not in your sources, the agent says so and offers a person. Topics you place out of scope are declined, including when a question is rephrased, and scope is tested before every release.

Every lookup is logged with its source.

See How an agent works and Knowledge and documents.

What is logged, and can we see it?

Every conversation leaves a record, kept as your storage settings allow: the transcript, what was looked up and from where, the rule or trigger that applied, each action taken and the agent's stated reason. Access to the console and changes to configuration are logged too. If your policy does not allow conversation content to be stored, a content-free audit record of actions, sources, triggers and outcomes is still kept for the period you set. Your team reads these records in the console.

See Audit trail and decision records.

Related

• Hosting and data residencySecurity and data protection
• Models and providersAgents
• Security and data protection overviewSecurity and data protection
• What we need from your IT teamIntegrations
• Testing before every releaseGovernance and control

Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.