Your AI doesn't speak Nepali — what it takes to build one that does

Nepali is the mother tongue of 44.86% of the population. The other 55% grew up speaking something else - Maithili, Bhojpuri, Tharu, Tamang, and 119 more. Any AI that only works in polished written Nepali is, by the census, a minority-language product. Building for the rest is a specific engineering problem with a known shape.

Why doesn't AI understand Nepali properly?

It mostly does, in writing. Ask a current frontier model a question in standard written Nepali and you will usually get a sensible answer. That is a real change from three years ago, and it is worth saying plainly rather than manufacturing a problem to sell against.

The failures are at the edges, and the edges are where much of Nepal lives. Speech is the first. Nepali is a low-resource language for audio, meaning there is far less transcribed speech to train on than for English. Published work on fine-tuning Whisper for Nepali reports substantial word-error-rate reductions over the off-the-shelf model, and attributes the gains to variation in speaker age, gender, acoustic environment and dialect - exactly the variation that general training sets are thin on. Independent benchmarks across other low-resource South Asian languages show the same pattern.

The second edge is dialect. A model tuned on Kathmandu-accented Nepali read into a good microphone is not the same product as one that survives a Terai accent over a noisy line. That gap does not close by choosing a bigger model.

Who actually gets left out?

The census answers this more usefully than intuition does. Nepali is the mother tongue of 44.86%; Maithili follows at 11.05%, Bhojpuri at 6.24%, Tharu at 5.88% and Tamang at 4.88%. Twenty-one languages cover about 95% of the population, which is the genuinely encouraging part - you do not need all 124 to reach nearly everyone.

Then there is reading. Nepal's literacy rate was around 71% in 2021. For close to three in ten adults, a beautifully written chat interface is not a smaller experience - it is no experience. That is the case for voice, and it is a stronger case than novelty.

What does voice-first actually change?

Voice-first is not a text product with a microphone bolted on. It changes what you are allowed to assume. You cannot assume a smartphone, so a feature phone over an ordinary call has to work. You cannot assume the user will phrase things the way your intents expect, because there is no visible menu to anchor them. And you cannot assume a connection - a constraint we have written about before in the context of offline-first systems for far-west Nepal.

This is the bet NepalX AI is making publicly: a voice-only assistant in Nepali, Maithili and Bhojpuri, trained on thousands of hours of village recordings, running on low-cost Android devices, with a public launch flagged for late 2026 after closed trials in Mahottari and Dhanusha. Whether or not that particular project lands, the shape of it is instructive - the hard parts are audio data and the phone in the user's hand, not model choice.

How is a Nepali voice stack actually put together?

Here is the pipeline we would build. Nothing in it is exotic; the difficulty is concentrated in two places - the fine-tuned speech model, and the exit to a human.

Should you fine-tune, or just use a frontier model?

Both are defensible. The honest split is by input type and by who your users are, not by which sounds more sophisticated.

What does the National AI Policy change?

Nepal's National AI Policy names Nepali-language and voice-first tools as priorities, alongside training 5,000 AI professionals and lifting ICT's contribution to GDP, with an AI Regulation Council for governance. Treat it as direction rather than funding: it will not pay for your build, but it does give language work official standing, which matters for public-sector procurement in particular. We covered the wider policy and money picture in Nepal's AI moment in 2026.

What does 'good enough' look like?

Voice projects drift because nobody agreed what success meant before the build started. Three numbers settle it, and all three should be written down before a single hour of audio is collected.

The first is word error rate on your own audio - not on a clean benchmark, but on recordings made the way your users will actually call, with the background noise of a shop or a field. A model that scores well on read speech and badly on your recordings is telling you the benchmark was the wrong test.

The second is containment: the share of calls that reach a correct answer without a human. This is the number that decides whether the system saves money, and it is the one most often quietly redefined halfway through a project.

The third is the handoff rate, and it should not be zero. A system that never escalates is either solving genuinely trivial questions or, more likely, answering hard ones badly. Watching the handoff rate fall as the audio set grows is the clearest evidence that the work is compounding.

On cost, be wary of anyone quoting a figure before those three are defined - including us. What is safe to say is where the money goes: a general-model text pilot is priced per token and starts cheap, while a tuned voice stack front-loads spend into audio collection and telephony, then gets cheaper per call as volume rises. Which shape suits you depends on call volume, and that is a question your existing support logs can usually answer in an afternoon. The same reasoning we apply to automation ROI applies here.

Where is this worth doing first?

The pattern that pays is narrow, repetitive, high-volume questions where the answer already exists in writing and the user cannot easily read it. Crop prices and advisory calls, as in our crop advisory blueprint. Citizen services, where eligibility rules are public but impenetrable - see the citizen-services assistant. Multilingual visitor enquiries, as in the tourism concierge.

• Start with one language and one question type. Breadth is what kills these projects.
• Budget audio collection as a real line item, not a research afterthought - it is the component that decides accuracy.
• Instrument the handoff to a human from day one; how often it fires is your honest quality metric.
• Decide up front which languages you can support well, and say so publicly. Half-working Maithili is worse than none.

If you are weighing this up, the useful first conversation is about who is being left out today and what they are actually trying to ask. That is a scoping question rather than a modelling one - and it is where our Neural AI work usually starts.