The Short Answer
Language coverage in healthcare AI is an infrastructure choice, not a vendor roadmap item — open-weight models like SraVaani can be downloaded and served for languages no commercial system supports. On ibl.ai you own all the code and the data, run it model-agnostic across any LLM including models you choose for your own patient population, with no per-seat pricing, and can deploy anywhere.
On August 13, IISc's SPIRE Lab, working with ARTPARK and with support from Google, released SraVaani 1.0 — a multilingual Indian speech recognition model trained on more than 31,000 hours of Indian speech.
It covers 65 Indian languages and dialects: the 20 languages scheduled in the Indian constitution plus 45 regional languages and dialects. More than 40 of those are not officially supported by today's commercial speech recognition systems.
It is published under an MIT licence, on Hugging Face, freely downloadable.
That last sentence is the one with consequences.
Why is language coverage a healthcare problem specifically?
Because the patients least served by English-first systems are frequently the ones with the most to gain.
Healthcare AI is largely built in English and extended outward.
Symptom triage lines, intake agents, discharge-instruction explainers, medication-adherence follow-up, appointment scheduling — all of it assumes the patient can operate comfortably in the language the system was trained on.
When they cannot, the failure is not a degraded experience. It is a patient who does not understand their discharge instructions, or who cannot describe a symptom precisely enough for triage to work.
The clinical stakes make this different from multilingual support in, say, retail. A misunderstanding in a shopping assistant costs a sale. A misunderstanding in a discharge conversation costs a readmission.
What changes when the model is MIT-licensed?
The decision moves from the vendor's roadmap to your infrastructure.
Under a managed AI service, the languages you support are the languages your vendor chose to support, and adding one is a feature request competing against every other customer's feature request.
For a language spoken by a community that is large locally and small globally, that request loses indefinitely.
An openly licensed model inverts this. A health system serving a specific linguistic population can download the model, evaluate it on their own recordings, and serve it — without anyone's permission and without a commercial case being made to a product manager.
That is only actionable if the platform can run models you choose.
A stack locked to one provider's models cannot adopt SraVaani no matter how good it is, which is the practical meaning of model-agnostic architecture — the argument in Model-Agnostic AI: Why Single-Vendor Lock-In Is the Real Risk.
Does self-hosting matter here, or just model choice?
Both, and in healthcare the second reinforces the first.
Speech in a clinical setting is protected health information the moment a patient describes a symptom.
Sending that audio to an external API is a disclosure, governed by a business associate agreement rather than prevented by one — the distinction we set out in HIPAA BAA vs Self-Hosted AI.
An open-weight speech model running inside the clinical network resolves both problems at once: the language is supported because you chose the model, and the audio never leaves the perimeter because the model runs where you put it.
That combination is not available from any managed service, because the weights of commercial speech models are not distributed. It is available from an owned deployment, and the licence on SraVaani is what makes it practical.
Is an open-weight speech model good enough for clinical use?
That is an evaluation question, and it should be answered with your own recordings rather than with a benchmark.
SraVaani is built on the FastConformer architecture and trained on over 31,000 hours of Indian speech, which is substantial.
It is also new, and no model — commercial or open — should enter a clinical workflow without being measured against a held-out set drawn from the actual population, the actual accents, and the actual acoustic conditions of the setting.
The advantage of an openly licensed model is precisely that you can run that evaluation before committing, on your own infrastructure, without a procurement process. The advantage of a commercial system is support and a contractual counterparty.
Those are real trade-offs. What has changed is that for 40+ languages, the commercial option does not exist at all, so the comparison is not open-versus-commercial — it is open-versus-nothing.
What is the general principle?
That in a model-agnostic, self-hosted architecture, language coverage becomes something you decide rather than something you are allocated.
India is the vivid example because SraVaani exists and covers 65 languages. The same logic applies to any health system, school district or public agency serving a population whose languages are commercially unattractive but locally universal.
The requirement is unglamorous: a platform that can run any model, including one you downloaded this morning, on infrastructure you control. That is what makes an MIT-licensed release usable rather than merely interesting.
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and deploy anywhere — including fully air-gapped, which is where clinical audio often has to stay.
The broader case for open weights is in The Open-Source Model Explosion Is Rewriting Enterprise AI Strategy.