AI conversations tend to revolve around speed: faster content creation, faster translation, faster automation.

But in life sciences, moving faster is not always the objective.

At LocWorld Dublin, Fabiano Cid sat down with Carola Hahn-Auer, Head of Content Operations in medical technology, and Ian Zhang, who works on globalization and AI workflows in animal health, to discuss what AI adoption looks like when language mistakes can have consequences far beyond bad copy.

Their conversation offers a different perspective on AI transformation: one where risk comes first, existing processes are not disrupted simply because new technology exists, and better data may ultimately matter more than a more powerful model.

Start with the risk question

Carola summarizes the tension of working with AI in a regulated environment very simply:

“I love it and I hate it.”

The possibilities are exciting. AI can remove repetitive work, increase efficiency and unlock entirely new workflows.

But medical technology cannot adopt new technology at the same speed as less regulated industries.

Before asking what AI can do, teams have to ask what could go wrong.

That means Carola sometimes finds herself doing the opposite of what we typically associate with AI transformation: instead of pushing her technology teams to move faster, she has to slow them down.

Once a use case has been properly evaluated and can be implemented responsibly, however, the opportunity becomes much clearer. The goal is not to introduce AI everywhere. It is to identify where it can create value without introducing unacceptable risk.

Don't replace a process just because AI exists

Ian describes a particularly pragmatic approach.

His globalization team already had established workflows for traditional medical translation. Rather than immediately trying to rebuild those workflows around AI, they decided to leave them alone.

For established medical translation:

keep the trusted workflow.

For new demands that could not easily be addressed through the existing process:

build new AI-native workflows alongside it.

One example is the consultation translation portal his team is developing, where clinical users and consultants need accurate translations almost instantly across markets.

Human translation alone cannot easily satisfy that requirement.

Instead of asking AI to replace an existing process, the team found a problem where a fundamentally different process was needed.

That distinction is important for any organization experimenting with AI. Transformation does not necessarily mean replacing everything that already works.

Medical translation doesn't usually fail because the sentence isn't fluent

One of the most interesting findings from Ian's work is where machine translation actually struggles.

The problem is often not general fluency.

It's terminology.

Medical communication contains acronyms, abbreviations, shorthand and terms whose meaning changes depending on context. A traditional one-to-one glossary is not always sufficient because the system still needs to understand which meaning applies.

Ian's team therefore started moving beyond conventional glossaries toward richer, concept-based terminology data containing more context and metadata.

Instead of simply telling a system:

Term A = Translation B

the objective is to give it enough information to understand what the concept means, when it applies and how it should behave in a particular context.

The process of developing the AI solution therefore produced something else of significant value: a better terminology dataset.

Carola has a name for this kind of information:

“Data gold.”

Your language assets are more valuable than one translation

For Carola, terminology is part of a much larger argument about the value of content and language data.

Her content operation brings together content creation, translation, terminology, data management and infrastructure.

That structure changes the way the team can think about its output.

Content produced in 45 target languages is not simply something that gets published once in an instruction for use and then disappears into an archive. It becomes structured product and language data that may also support technology teams, marketing, innovation and future AI applications.

This changes the conversation with senior management.

The value of a localization or content team is no longer simply how many words it translated.

It is also the knowledge infrastructure it is creating for the organization.

Stop selling quality. Build the business case.

Carola's experience also illustrates why localization teams sometimes struggle to make their value visible internally.

She was originally hired to establish terminology management.

After joining the company, however, she concluded that terminology itself was not the fundamental problem.

The organization had a broader content infrastructure and process problem.

Creating a terminology database would achieve little if the processes, systems and teams around it could not apply that terminology consistently.

That shifted the discussion from a language problem to an organizational one.

And it eventually took the conversation to the C-level.

But the argument was not simply that language quality needed to improve.

As Carola explains, abstract quality discussions are rarely enough at that level. The conversation needs to connect language to the metrics the business actually cares about.

Turnaround time and cost per word may matter operationally.

At company level, the questions are different:

How does content affect the user experience?

Can better processes save time and money?

Does language influence whether someone buys or continues using a product?

Can better governance reduce risk?

For medical devices that may be used repeatedly by healthcare professionals, clear and intuitive content forms part of the product experience itself.

As Carola puts it:

language influences the buying decision.

That argument eventually helped position the content team within the user experience organization.

Content is part of user experience

That organizational move is significant.

When content sits within user experience, translation and localization no longer happen at the end of a chain.

People designing interfaces can work with people thinking about linguistic and cultural requirements. Internationalization, accessibility, terminology and local-market needs can be considered alongside the product experience rather than after it.

This is particularly important for global products.

A technically excellent interface is not necessarily an excellent experience if the terminology is unclear, the language feels unnatural or the design does not work in another market.

Language becomes part of product design.

One AI model doesn't have to do everything

Risk becomes even more important when AI is producing medical content.

Ian openly acknowledges one of the central problems his team encounters:

hallucinations.

His initial approach was to call one model and give it multiple responsibilities: translate the content, perform checks and determine whether the result was accurate.

It was not reliable enough.

So the architecture changed.

Instead of asking one model to do everything, the workflow uses several model calls with different responsibilities.

One performs a task.

Another checks it.

Additional layers can verify specific aspects of the output.

Each model receives a narrower job rather than being expected to understand and control the entire process.

It does not make hallucinations magically disappear. But it creates a workflow designed to detect and reduce them.

The lesson extends beyond medical translation: as organizations move toward agentic and AI-based workflows, reliability may come from orchestration and control, not simply from choosing the most powerful model.

Sometimes the hardest work is still manual

The conversation also provides a useful reality check on AI automation.

Ian's team may be experimenting with sophisticated multi-model workflows, but one of its most important processes remains stubbornly manual:

term mining.

He describes reviewing a dataset of roughly 70,000 consultation reports to identify terminology and shorthand that needs to be understood correctly.

One example involves an internal German abbreviation referring to a pet owner. The shorthand may not even be universally understood by German-speaking consultants, creating problems when content is translated or back-translated.

These edge cases are exactly where contextual terminology becomes valuable.

But discovering them still requires human expertise, feedback from users and a growing understanding of how people actually communicate in the field.

AI adoption does not eliminate the need for humans to structure knowledge.

In many cases, it makes that work more valuable.

Adoption is also a change-management problem

Technology is only one part of the implementation.

Carola turns the interview around at one point and asks Ian about skepticism inside the organization.

And there has been skepticism.

That is hardly surprising. These are regulated environments, and someone ultimately needs to take responsibility for the process and its risks.

Ian's team's approach has therefore been collaborative rather than prescriptive.

They develop and test a solution, show markets what is possible and invite them to participate. Early implementations can include subject-matter experts validating the output. Markets can adopt the workflow when the use case and quality justify it.

That gives people time to understand both the globalization team and the technology it is introducing.

It also allows adoption to be driven by an actual business need.

In the consultation use case, for example, instant translation is something users genuinely need and human availability makes the traditional approach difficult.

The AI workflow exists because there is a problem worth solving.

Responsible AI can mean knowing when not to accelerate

Perhaps the most important takeaway from the conversation is that mature AI adoption does not mean maximizing automation.

It means understanding where automation makes sense.

Carola and Ian describe an approach based on a few principles:

• Start with risk, not technology.
• Protect established workflows when they already solve the problem well.
• Build AI-native processes where new needs justify a different approach.
• Treat terminology and contextual language data as strategic assets.
• Give different models clearly defined roles rather than expecting one model to do everything.
• Connect language quality to business outcomes, user experience and governance.
• Bring markets and subject-matter experts into the adoption process.
• Accept that some critical knowledge work may remain human.

In other words, responsible AI transformation is not about asking, “How quickly can we automate this?”

Sometimes the better question is:

“Where should we deliberately slow down?”

And in regulated industries, knowing the difference may be the most important AI capability of all.