AI models & providers in voi

​

What is an AI gateway?

An AI gateway sits between voi and the companies that run AI models. voi sends one request to the gateway, the gateway forwards it to whichever model is configured for that feature, and the answer comes back the same way. Whichever model serves a call, the request passes the same regional rule, the same retention setting, and the same authentication on its way out, and lands in one record voi can read afterwards to see what a study cost or to work out why something failed. Three roles are easy to confuse, and the difference decides whose terms cover your text:

• The model maker builds and licenses the model. For example, Anthropic makes Claude, Google makes Gemini, OpenAI makes GPT.
• The model provider runs a copy of it in a particular place. For example, Claude runs on AWS, Gemini on Google Cloud, GPT on Microsoft Azure. All of it is processed in the EU, none of it is used for model training, all of our endpoints adhere to zero data retention (ZDR).
• The gateway routes voi’s request to one of those providers. It handles the request in passing and runs no model of its own.

Google appears in both of the first two roles, since it makes Gemini and also hosts it, while Anthropic and OpenAI appear only as a maker, because the copies of Claude and GPT voi uses run on AWS and Azure. voi’s gateway is Opper, operated by Opper Technology AB in Sweden, and it runs in Stockholm.

​

Why does voi run its AI calls through a gateway?

Around thirty features in voi make AI calls, and they ask for different things. The live interviewer turn has to answer inside twelve seconds while a respondent waits, and the safety check that reads each answer has four, while a report draft or an analysis summary can take a minute and is judged instead on how well it reasons over a large amount of material. One model chosen for all of them would be wrong for most of them. A gateway makes the choice per feature, and keeps that choice out of the product’s code. Which model serves a feature is a setting in the gateway, so it can change without a release, and voi is never held to one company’s model because switching costs a configuration edit rather than an engineering project. It also gives every feature a second path. Each route holds a fallback, in most cases with a different provider behind it, and the gateway moves to it on an error, an unavailability, or a provider rate limit, so one company having a bad afternoon does not stop a study collecting responses. Worth being precise about the limit of that: a fallback catches a failed request. A model that answers successfully but badly counts as a success, so voi watches for those separately rather than relying on the fallback to catch them. The last reason is the one that matters most for your data. Rules that would otherwise have to be repeated for every provider are set once, at the gateway, for the whole organisation. Processing region is pinned to the EU, the list of permitted providers is fixed, and retention is set to 14 days. A call to a provider outside that list fails rather than being served somewhere else.

​

Which AI models does voi use, and how are they chosen?

Text work runs on models made by Anthropic, Google and OpenAI, run for voi in European regions of AWS, Google Cloud and Microsoft Azure. Six routes cover the whole product, and each names one primary model and one fallback, in most cases from a different provider. Every one of the roughly thirty AI features in voi is measured on recorded examples of that exact feature. Three criteria come first, and a model is not used unless it clears all three: Only once a model clears those three is its quality compared, against further criteria fixed before any model is tested:

• Output quality above a floor set for that feature
• A response time inside a ceiling taken from that feature’s own timeout
• Cost within a fixed cap
• Correctly formed output every time, since fluent but unusable text disqualifies a model however well it scores

Where no model clears all of them, the cost cap gives way first, then the response time, and the exception is recorded. AI-powered transcription is a separate path that does not go through the gateway: recordings go to ElevenLabs Scribe, the large language models never receive them. ElevenLabs Scribe runs on servers in the US, but cannot train on the study data either. We aim to replace transcription with a European alternative soon.

​

What happens to your study’s text at the model provider?

No provider voi uses trains on it. That obligation runs the length of the chain, from leonardo’s agreement with the gateway to the gateway’s agreements with the companies running the models, and it covers development and improvement of any model rather than training runs alone. Processing stays in the EU, and this is enforced rather than intended. The gateway carries an organisation-wide rule naming the permitted region and the permitted providers, and a call to anything outside that set is refused instead of being routed elsewhere. What a provider keeps afterwards differs, and voi treats that difference as part of choosing where a feature runs:

• Claude models, in AWS European regions, keep no request or response content once the request has been answered, and hold nothing for content review.
• Gemini models in the EU, and GPT models in Azure’s EU regions, do not log request content and do not train on it. Their providers run automated content moderation, which may retain content it flags, for example sexual or harassing material, for up to 30 days.
• The gateway keeps request and response content for 14 days inside the EU, so voi can trace a processing error and check output quality, after which it is deleted.

​

What is zero data retention?

Zero data retention means a provider keeps no copy of a request or its answer once it has served the call, except for content moderation purposes for a maximum of 30 days. Nothing else is written to a log, nothing is held for review, and nothing survives for anyone to read later. It is the strictest arrangement a model provider offers. voi runs all of the models accessed via its AI gateway on exactly those terms.

​

Does voi use open-weight models?

Not at the moment, and voi keeps testing them. An open-weight model that clears all of our mandatory quality standards will be prioritised. An open-weight model is published together with its trained parameters, so anyone can download it and run it on infrastructure of their choosing. Where a model runs is a separate question from who published it: voi would run an open-weight model only through a European host, under the same terms as every other provider, and would not send study data to a model laboratory’s own hosted service.

​

How does voi choose the companies that process your data?

Every company in the chain has to clear the same three things before its quality is discussed at all: it does not train on customer data, its retention position is documented well enough that voi can state it to you plainly, and it is bound by a data processing agreement. Processing in the EU is the fourth requirement and the one with a defined exception, since a company outside the EU can only be used where the transfer is covered by Standard Contractual Clauses, as the GDPR requires. The full list of sub-processors, including the providers behind the rest of the platform, is in the app at voi.leonardo-impact.com/legal/sub-processors when you are signed in, and forms part of the Data Processing Agreement. Workspace owners are notified of a change within 30 days and can object on data protection grounds within that period.