← All articles
Applied AI

The code-switching problem in health AI

AI handles many languages well. But normally, patients in African clinics don't speak one language at a time — they braid English/French/Portuguese, a local tongue, and slang inside a single sentence, and most health AI, built for clean translation, breaks exactly there.

Building health AI for multilingual settings isn't a translation problem. It's a code-switching problem — and treating it as translation is the mistake.

From this article
By Mike · August 14, 2026 · 5 min read
Applied AIHealth dataNLPLocalization

Picture a consultation in a clinic in Nairobi, or Kampala, or Lagos. A mother describes her child’s illness. She doesn’t do it in clean, grammatical English, and she doesn’t do it in clean, grammatical Kiswahili either. She says something closer to: “the baby amekuwa na homa since juzi, and now she’s not breastfeeding vizuri.” Fever since the day before yesterday, not feeding well — delivered in a fluid braid of English, Kiswahili, and the ordinary slang of how people actually talk.

Every clinician in a multilingual setting parses this without effort. It’s not broken language; it’s the normal language of the clinic. And it is precisely where most health AI falls apart.

Translation is the wrong frame

Let’s be clear about what the problem is not. Modern AI handles many languages well — French, Spanish, Arabic, Mandarin, dozens more, often fluently. The gap isn’t that these systems can’t work outside English. It’s that when it comes to African languages — and especially to the braided, code-switched way they’re actually spoken in a clinic — the models fall down. The problem is narrower and harder than “AI only speaks English,” and naming it precisely matters.

When teams set out to build AI health tools for African contexts, the language problem is almost always scoped as translation: build a model that works in one language, then add Swahili, then Hausa, then Yoruba, one clean language at a time. Each language is treated as a discrete, self-contained system to be supported in parallel.

But normally, patients don’t present in one language at a time. They code-switch — alternate between languages and registers within a single utterance — and they do it constantly, unconsciously, and meaningfully. The switch itself often carries information: the English medical term because that’s how the condition was named at a previous visit, the local word for the symptom because that’s how it’s felt, the slang because that’s the register of distress. A system built to handle “Swahili” as a clean language will choke on real Swahili-as-spoken, because real Swahili-as-spoken is half English and a quarter something the training data never saw.

This is the technology-first trap, and it’s the same one Microsoft’s own research names in a recent analysis of AI across Africa: the continent’s AI progress, they argue, will be decided by depth of real-world adoption, not by impressive demos — and language relevance is one of the decisive barriers, because most large language models are trained predominantly on English and other high-resource languages, reducing relevance for the millions who don’t operate in those languages. But even that framing undersells the problem. The issue isn’t just that the models don’t speak enough languages. It’s that they don’t speak the mixed language that people actually use.

Why code-switching is genuinely hard

It’s tempting to think this is just a bigger training-data problem — feed the model enough mixed-language transcripts and it will learn. That helps, but it understates three real difficulties.

The data barely exists. Clean monolingual corpora are scarce enough for low-resource African languages; code-switched clinical corpora — real patient speech, mixed, transcribed, annotated — are almost nonexistent. You cannot simply download your way to this. The data has to be built, ethically and with consent, in the settings where the speech actually happens.

The switching is unpredictable and personal. Two patients with the same condition, from the same town, will braid their languages differently depending on age, education, which clinic they last visited, and what a health worker once called their illness. There is no single “Swahili-English clinical dialect” to model — there’s a spectrum, and the model has to be robust across it rather than tuned to one point on it.

Meaning hides in the switch. When a patient switches from the local word for a symptom to an English clinical term, or back, the choice is often diagnostic — it signals what they understand, what they’re worried about, what a previous provider told them. A system that flattens everything into one translated language throws that signal away. Getting the words right isn’t enough; the switching pattern is part of the content.

What building for it actually requires

If translation is the wrong frame, what’s the right one? A few principles, drawn from building data systems in exactly these settings.

Design for the mixed input from the start — don’t bolt it on. Code-switching can’t be a post-processing step that “cleans up” messy input into one language before the model sees it. That cleaning is where the signal dies. The system has to treat mixed-language, mixed-register speech as the expected input, not the exception.

Build the data where the speech lives. The corpus that matters here isn’t on the internet; it’s in the clinics. That means real, consented, locally-collected speech data — which is slow, unglamorous, and the actual work. It also means the communities whose language it is should have a stake in how it’s used, not just be the source of extraction.

Keep a human in the loop at the point of care. Precisely because the switching is unpredictable and meaning hides in it, a health AI operating on code-switched input should surface its uncertainty and defer to the clinician, not answer with false confidence. This is the same discipline that matters everywhere in health AI — ground the output, signal confidence, never let the system sound more certain than it is — but it matters double when the input itself is something the model has only partially seen.

Measure the system on real speech, not clean benchmarks. A model that scores well on tidy monolingual test sets can fail completely on the braided language of an actual consultation. The only benchmark that counts is performance on speech as patients really produce it — which means your evaluation data has to be as messy as your input.

The deeper point

The code-switching problem is a specific instance of a general truth about building technology for real contexts: the gap between how a system is specified and how the world actually behaves is where good intentions go to die. A health AI that assumes clean, single-language input has quietly assumed away the actual conditions of the clinic it’s meant to serve.

Africa’s health-AI moment won’t be decided by whether we can build a model that speaks Swahili. It’ll be decided by whether we can build one that understands a worried mother saying her baby has homa since juzi — and knows that’s a fever, knows it’s urgent, and knows enough to ask. That’s not a translation feature. It’s the whole problem, and it’s worth building for directly.


This is a field note from our practice. If you’re building health data or AI systems for multilingual, real-world settings and want to talk through the language problem honestly, start a conversation.

The Enkop dispatch

Field notes and tutorials, twice a month.

Practical data & AI methods for mission-driven organizations — the same rigor we bring to engagements, written to be used.

Twice a month at most. Unsubscribe any time via the link in every email.

Not sure which engagement fits?

Book thirty minutes. You will leave with a clearer view of your options and an honest recommendation on the right next step.

Book a 30-minute call →