Keeping the Human Voice in AI Translation With DeepL

What happens to a good idea when the person who understands the problem best cannot express it confidently in the language used by the rest of the team?

In this episode of Tech Talks Daily, I speak with Gonçalo Gaiolas, Chief Product Officer at DeepL, about real time voice translation and the work required to make a multilingual conversation feel natural. Our discussion moves from the business cost of language barriers to the technical choices behind speaker identity, tone, speed, and the handling of sensitive meeting data.

Gonçalo begins with a cost that is difficult to place on a spreadsheet. An employee may understand a local market, a product, or a customer need but struggle to contribute in the company's shared language. The organization can miss that knowledge even when the person is present in the meeting. Customers also tell DeepL that language barriers affect the time needed to make decisions and understand nuance. These are experiences he describes, rather than independently measured results presented in the interview.

Live translation introduces a demanding set of constraints. People pause, interrupt, change direction, and build meaning at different speeds across languages. A system needs enough context to produce an accurate translation while responding quickly enough to remain useful. Waiting can interrupt the flow, but responding too early can lose the meaning of the sentence. Tone creates another challenge because urgency, hesitation, and a question can carry information that the translated words alone do not capture.

We discuss DeepL's approach to retaining the characteristics of individual speakers. Gonçalo describes separating speakers and carrying elements of voice, rhythm, and emotion into the translated audio. He also explains that some original audio remains audible at a lower level. His aim is to help listeners follow who is speaking while understanding the translated conversation. He says users have options around retaining vocal identity, acknowledging that people may feel differently about using that capability.

The enterprise adoption discussion is equally practical. Gonçalo describes a desktop app intended to provide a consistent experience across Zoom, Microsoft Teams, and Google Meet. A global workforce may use one platform internally and encounter several others when speaking with customers and partners. For him, working across those environments is part of the product's usefulness, alongside the quality of the translation itself.

Accuracy remains a recurring theme. Gonçalo describes testing with real users and evaluating whether the result works in the customer's context. He gives the example of an engineering department whose acronyms and specialist terms can confuse a model. DeepL's customization capabilities, he says, let customers supply terminology and guidance about how language should be handled. The example offers a useful reminder that a fluent sentence can still misinterpret the way a particular team speaks.

We also discuss procurement and governance. Meeting audio can contain sensitive business information, so buyers need to understand technical architecture, policies, and how their data is processed. Gonçalo says DeepL does not use customer data to train its own models. The interview does not supply the contractual scope, retention periods, or detailed controls behind that statement. Those remain questions for buyers to check against the service and agreement they intend to use.

Examples range from conversations between parents and teachers to contact centers, large events, and use alongside human interpreters. Gonçalo describes customer demand that extends beyond the scenarios the team originally expected. I also ask about translating podcasts, which leads to a discussion of possible uses outside live meetings. We keep that possibility separate from a confirmed podcast production service or a promise about this show's availability in other languages.

I'd welcome your thoughts. Where could voice translation help someone contribute knowledge your organization is currently missing, and what would you need to test before relying on it?