Kalika Bali: What Inclusive AI Leaders Can Learn From Low-Resource Languages

Kalika Bali is useful to study because multilingual AI is moving from a specialist research topic into a central question for technology, business, education, healthcare, and public services. If AI only works well for dominant languages and digitally visible communities, it will reproduce old exclusions through new systems.

It preserves the live URL, avoids unsupported personal claims, and focuses on multilingual AI as an execution problem: data, culture, speech, access, evaluation, governance, and deployment in communities that mainstream technology often overlooks.

Short Answer

Kalika Bali is a Senior Principal Researcher at Microsoft Research India whose work focuses on AI, natural language processing, speech, multilingual technology, low-resource language communities, and technology for empowerment. Her research is relevant because the next phase of AI adoption depends on whether systems can serve people beyond English and other resource-rich languages.

Weak view	Better operating answer
Multilingual AI means translation	It also requires speech, cultural context, interface design, community participation, evaluation, and trust.
Low-resource languages are niche	They reveal whether AI systems are inclusive or only optimized for digitally dominant populations.
More data automatically solves inclusion	Data must be representative, consent-aware, useful, and connected to community needs.
AI access is only a model problem	Access also depends on devices, literacy, bandwidth, code-switching, voice interaction, and local workflows.
Language preservation is separate from AI strategy	Language determines who can use, question, benefit from, and shape AI systems.

The practical lesson is that inclusive AI is not a cosmetic feature. It is an operating discipline. Teams need to design for language diversity from the beginning rather than treat localization as a final step.

Why Kalika Bali Is Relevant

Bali is relevant because AI is becoming a default interface for information, work, education, services, and decision support. When that interface works poorly in a person’s language, the person is not only inconvenienced. They may be excluded from opportunity.

Her work sits at the intersection of speech technology, natural language processing, multilingual systems, human-computer interaction, and technology for empowerment. That combination matters because language access is not solved by a model alone. It depends on how people actually speak, switch languages, share devices, ask questions, and trust technology.

This is especially important in India and other linguistically diverse environments, where people may use several languages in daily life and where many communities are underrepresented in digital datasets. A system trained mainly on high-resource languages can appear advanced while still failing people who do not fit its dominant data patterns.

It also matters for companies outside India. Multilingual customer bases, migrant workforces, global support teams, regional suppliers, and public-facing services all face versions of the same problem: AI quality is uneven when language reality is more complex than the product team assumed.

For AI leaders, Bali’s work is a reminder that inclusion has to be engineered. It cannot remain a value statement. It needs data practices, evaluation methods, user research, local partnerships, and deployment choices that respect the people the technology is supposed to serve.

Verified Facts That Matter

Microsoft Research lists Kalika Bali as a Senior Principal Researcher at Microsoft Research India working on AI, NLP, speech, and technology for empowerment, with a focus on multilingual technology for low-resource language communities.

Her Microsoft Research profile describes more than two decades of work on human-computer interaction through language technologies, inclusive technology, and underrepresented languages and communities.

Microsoft has identified Bali as part of Project VeLLM, an initiative focused on inclusive applications of large language models across languages and cultures.

Project ELLORA, short for Enabling Low Resource Languages with Technology, has been publicly described by Microsoft as work that helps low-resource languages survive and thrive by building digital resources and enabling participation in the digital world.

Microsoft coverage of Project ELLORA describes work with languages such as Gondi and Mundari and emphasizes collaboration with communities, data collection, literacy, speech, and practical technology use.

Academic and project materials associated with Bali and colleagues discuss the difficulty of building and deploying language technologies for low-resource communities, including the need for representative data and community-centered evaluation.

These facts are enough to build a reliable article. The useful angle is not a broad life story. It is what Bali’s work teaches about multilingual AI, inclusion, and responsible deployment.

Language Access Is AI Infrastructure

Language is often treated as a content layer. In AI, it is infrastructure. It determines who can ask a question, understand an answer, correct a system, give consent, report an error, learn a skill, access a service, or participate in a digital economy.

This matters because AI interfaces are becoming conversational. People are increasingly expected to interact with systems through natural language, voice, chat, translation, summarization, and recommendation. If the system does not understand their language, dialect, accent, code-switching, or cultural context, the interface becomes unequal.

The risk is subtle. A product can claim to be multilingual while still working best for a narrow set of languages, accents, domains, and educated users. It may technically support a language but fail in healthcare, agriculture, legal support, education, or local administration because the vocabulary and context are missing.

Bali’s work is important because it pushes AI leaders to look below the surface. Language access is not only about adding more languages to a menu. It is about whether the system can function in the real conditions where people live and work.

What Project ELLORA Teaches

Project ELLORA is a useful case because it frames low-resource language work as both preservation and participation. Preserving a language digitally matters, but the larger goal is that speakers can use technology in meaningful ways.

The project shows that language technology often begins with resource creation. A community may need text corpora, speech data, lexicons, keyboards, annotation methods, translation pairs, educational material, or interfaces that match local practices. Without those foundations, advanced AI cannot be deployed responsibly.

ELLORA also shows that the work cannot be purely extractive. Communities are not just data sources. They have needs, preferences, knowledge, and priorities. A tool that looks useful from a research lab may fail if it does not match local literacy levels, device access, connectivity, social norms, or trust patterns.

For leaders, the lesson is that inclusive technology is a collaboration problem. A model can be built centrally, but adoption depends on local context. The more underrepresented the community, the more dangerous it is to assume that generic product logic will work.

The Low-Resource Language Problem

A low-resource language is not a low-value language. It is a language with limited digital resources available for building technology. The distinction matters. The language may have deep cultural, social, and practical importance while still having little data that modern AI systems can use.

This creates a structural disadvantage. AI systems learn from available data. If a language has less text, less transcribed speech, fewer labeled examples, fewer benchmarks, and fewer digital tools, the system may perform worse for its speakers. That lower performance then discourages use, which produces less data and fewer incentives for improvement.

Low-resource language work therefore has to break a cycle. It needs better data, but also better reasons for people to participate. It needs benchmarks, but also real use cases. It needs technical models, but also social legitimacy.

The practical implication is clear: organizations cannot wait for market size alone to decide which languages matter. If AI becomes a gateway to services, language support becomes an inclusion responsibility.

Community-Centered AI Design

Community-centered AI design starts from the people affected by the system. What are their goals? What languages do they use at home, at work, in school, with officials, and online? Do they prefer speech or text? Are they comfortable correcting a system? Who is trusted locally? What harms would matter most?

This approach changes the design process. Instead of asking whether a model can handle a language in general, the team asks whether it can support a specific community in a specific context. That might mean health information, farming advice, local administration, education, legal support, or access to benefits.

It also changes evaluation. Accuracy is not enough. A system may score well on a benchmark and still fail users if it uses unnatural phrasing, misses cultural references, cannot handle mixed-language speech, or gives advice that is technically correct but locally unusable.

A serious evaluation plan should therefore include language-specific failure reviews. Teams should look for misunderstanding, unnatural tone, missing domain words, unsafe simplification, accent bias, over-formal phrasing, and answers that assume urban, literate, or high-connectivity users. These issues rarely appear if the test set is built only from clean, formal examples.

Kalika Bali’s work is valuable because it connects technical language research to this human layer. Inclusive AI requires both competence and context.

What Business Leaders Should Learn

Business leaders should not treat multilingual AI as a compliance checkbox or a marketing claim. If a company serves customers, workers, suppliers, patients, students, or citizens across languages, multilingual design affects performance, trust, and adoption.

The first lesson is that language choice shapes demand. People may avoid a service if it feels foreign, unsafe, or hard to use. They may also misunderstand instructions, fail to complete forms, or receive lower-quality support when language is handled poorly.

The second lesson is that voice matters. In many contexts, speech interfaces can be more accessible than text, especially where literacy, typing, device constraints, or local scripts create friction. But speech AI must handle accents, noise, code-switching, and domain vocabulary.

The third lesson is that multilingual AI needs governance. Who approves translations? How are sensitive terms handled? What happens when an AI response is wrong in one language but correct in another? Are users told when content is machine-generated? Can local experts review the system?

The fourth lesson is that inclusion can become a strategic advantage. A company that serves overlooked language communities well can build trust where generic tools fail.

A Practical Deployment Example

Imagine a healthcare organization building an AI assistant for rural patients. The easy product decision is to launch a chatbot in a national language and translate the content into several regional languages. That may look inclusive on a roadmap. It may still fail in practice.

A stronger approach begins with the workflow. What questions do patients actually ask? Do they speak in short voice notes, mixed-language messages, or local terms for symptoms? Are they asking for medical advice, appointment logistics, medication instructions, or reassurance? What should the AI answer directly, and what should it escalate?

The team would then map language risk. Which terms are dangerous if mistranslated? Which dialects are underrepresented? Which responses require a clinician review? Which disclaimers are understandable in the local language? What happens when the patient cannot read a long response?

Only after that should the organization choose the model, data strategy, interface, and evaluation process. The system should be tested with representative users, reviewed by domain experts, and monitored for language-specific failure patterns.

This is the deeper lesson from Bali’s work. Multilingual AI is not a translation layer added to a finished product. It changes the product, the data, the testing, the governance, and the deployment plan.

Where The Example Has Limits

There are limits to using Kalika Bali’s work as a general model. Research projects focused on low-resource language communities often require patience, local relationships, and methods that do not fit a fast commercial rollout.

Most companies will not run their own version of Project ELLORA. They may not have the mandate, research team, or community partnerships needed for deep language-resource creation.

But the transferable lesson is not that every organization should become a language research lab. The lesson is that AI quality must be judged in the languages and contexts where the system will actually be used.

The mature stance is to avoid two extremes. Do not ignore low-resource languages because they look commercially small. Do not pretend that a generic AI model automatically solves multilingual inclusion. The right question is: what level of language support is responsible for this use case?

A Multilingual AI Readiness Framework

Use this framework before deploying AI across languages, especially in customer service, healthcare, education, public services, financial access, internal operations, or field support.

Identify The Real Language Mix

List the languages, dialects, accents, scripts, and code-switching patterns people actually use. Do not rely only on official-language categories.

Define The Use Case Risk

Separate low-risk convenience use cases from high-stakes decisions involving health, money, rights, safety, employment, or public services.

Audit The Data Foundation

Check whether training, retrieval, and evaluation data exist for each language and whether the data reflects real users rather than only formal written text.

Design For Speech And Access

Decide whether users need voice input, voice output, offline access, simple interfaces, or assisted use because text-only design may exclude them.

Test With Representative Users

Evaluate the system with the people it is meant to serve. Include local vocabulary, noisy conditions, mixed-language inputs, and realistic tasks.

Create Language-Specific Escalation Rules

Some languages or domains may need tighter human review until quality is proven. Escalation is a responsible design feature, not a failure.

Measure Equity Of Performance

Track whether the system performs differently across languages and user groups. A single average score can hide exclusion.

Keep Community Feedback Open

Language evolves. AI systems need ways for users, local experts, and community partners to report errors, harmful phrasing, missing terms, or broken assumptions.

This framework turns Bali’s work into operating discipline. Inclusive AI is built through decisions about data, design, deployment, evaluation, and accountability.

Where This Fits In Selected Thought Leadership

This page belongs in Selected Thought Leadership because Kalika Bali is useful as a lens on multilingual AI, low-resource languages, speech technology, community-centered design, and the social consequences of AI deployment.

It connects with AI skills, because teams need language, evaluation, and deployment skills rather than prompt skills alone. It also connects with artificial general intelligence readiness, because broad AI capability is incomplete if it excludes people through language and culture.

If your AI roadmap needs to serve multilingual customers, teams, or communities, an AI Readiness Diagnostic Report can help identify where language, data, workflow, and governance gaps may block adoption.

FAQ

Who is Kalika Bali?

Kalika Bali is a Senior Principal Researcher at Microsoft Research India working on AI, natural language processing, speech, multilingual technology, low-resource languages, and technology for empowerment.

What is Project ELLORA?

Project ELLORA, or Enabling Low Resource Languages with Technology, is a Microsoft Research initiative focused on building digital resources and technology support for low-resource language communities.

Why are low-resource languages important for AI?

Low-resource languages matter because AI systems often perform worse when a language lacks digital text, speech data, benchmarks, tools, and evaluation resources.

What can business leaders learn from Kalika Bali’s work?

They can learn that multilingual AI should be designed from the start around real users, local language practices, data quality, speech access, testing, governance, and measurable adoption.

Is multilingual AI just translation?

No. Translation is only one part. Multilingual AI also involves speech, culture, context, interface design, code-switching, evaluation, community participation, and accountability.

Sources and further reading

These sources are useful context for checking the article’s claims, boundaries, and current relevance. They are not endorsements and should be read as reference material rather than advice.

• Kalika Bali at Microsoft Research
• Karya, Microsoft Research