Apply for AI Grants India

Why inclusion must be an engineering requirement

Building inclusive digital tools with AI means designing for the people most likely to be missed by default assumptions: users on entry-level Android phones, people with disabilities, speakers of Indian languages, first-time internet users, and communities with intermittent connectivity. In India, inclusion is not a cosmetic layer added after launch. It affects product requirements, training data, model evaluation, infrastructure, support, and business viability.

A useful starting point is to define inclusion as a set of measurable product outcomes. Can a user complete the core task using their preferred language? Can someone with low vision navigate without sighted help? Does the model perform consistently across regions, accents, genders, and device types? Can a user understand, challenge, or reverse an AI-assisted decision?

These questions should shape the first prototype, not a late-stage compliance review.

Start with users, tasks, and constraints

Do not begin with a model. Begin with the task and the conditions in which it must work. Conduct research across language, geography, disability, age, income, and digital experience. Include users from smaller towns and rural areas, not only English-speaking smartphone users in major cities.

For each important workflow, document:

• The user’s preferred language, script, and common code-switching patterns.
• Whether the task is completed by text, voice, image, assisted service, or a combination.
• Device limitations, data costs, battery constraints, and network reliability.
• Accessibility needs, including screen readers, captions, keyboard navigation, and adjustable text.
• The consequences of an incorrect recommendation or automated decision.
• Where a human can intervene when the system is uncertain or wrong.

Participatory design is particularly important for high-impact products in healthcare, welfare, education, employment, and finance. Compensate community participants for their time, explain how their feedback will be used, and avoid treating a small number of interviews as representative of an entire language group.

Build representative and accountable data pipelines

Inclusive performance depends on more than collecting a larger dataset. Training and evaluation data must reflect how people actually speak, write, search, transact, and interact with the product.

Useful practices include:

• Track coverage: Record language, dialect, script, region, age range, disability-related needs, device class, and connectivity conditions where ethically and legally appropriate.
• Separate training and evaluation data: Keep a protected test set that reflects real deployment conditions. Do not repeatedly tune against the same benchmark.
• Measure intersectional performance: A model may perform well for Marathi text overall but poorly for Marathi voice queries from older users in noisy environments.
• Document consent and provenance: Know where data came from, what permissions apply, and whether the data can be reused for model training.
• Use targeted data collection: When a group is underrepresented, collect high-quality examples with appropriate consent rather than relying only on synthetic data.
• Review labels: Annotation guidelines should account for code-switching, dialect variation, reclaimed language, disability terminology, and culturally specific meanings.

Synthetic data can expand coverage, but it should not be treated as a substitute for community-generated examples. Validate synthetic samples against real user interactions, and monitor whether they introduce unnatural language or reinforce stereotypes. Tools such as fairness dashboards, slice-based evaluation, and model cards make performance gaps visible to product and engineering teams.

Design multilingual and voice-first experiences carefully

India’s language diversity makes translation alone insufficient. Users may speak one language, read another script, and mix English terms into both. A robust multilingual product should support language discovery, code-switching, transliteration, and graceful fallback.

For voice interfaces, plan for regional accents, background noise, shared devices, interruptions, and users who do not know the formal name of a feature. A short confirmation step can prevent costly errors: repeat the interpreted request, show the key details, and let the user correct one field without restarting the entire flow.

Teams working on local-language products can draw on AI-based tools for local Indian dialects, while a dedicated voice agent architecture guide is useful for planning speech recognition, intent handling, tool calls, and escalation. For speech-heavy applications, test latency and recognition quality on low-cost devices rather than evaluating only through cloud APIs.

Do not hide important information behind voice. Provide equivalent text, visual, and assisted-service paths. Users may be in a noisy place, have a speech disability, lack privacy, or prefer reading before confirming an action.

Make accessibility part of the product architecture

AI can improve accessibility, but generated descriptions and predictions are not automatically reliable. Build against established accessibility expectations and test with assistive technology from the earliest usable version.

Prioritise:

• Semantic structure, screen-reader labels, logical focus order, and keyboard operation.
• Sufficient colour contrast, scalable text, captions, transcripts, and non-audio alerts.
• Simple language, predictable navigation, visible error messages, and reversible actions.
• Image descriptions that distinguish essential information from decorative content.
• Human review for generated captions, medical information, identity-related content, and other high-consequence outputs.

Accessibility testing should include people who use screen readers, switch controls, magnification, captions, or alternative keyboards. Automated checks catch common implementation failures, but they cannot determine whether an interaction is understandable or whether a generated description is useful.

Test bias, safety, and uncertainty before launch

A model’s average accuracy can conceal serious harm. Evaluate performance by user segment and by failure severity, not only by one overall score. For example, a missed product recommendation is inconvenient; a wrong eligibility decision or health instruction can be dangerous.

Create a pre-launch review that includes:

• Slice-based accuracy, latency, and failure rates across languages, regions, accents, devices, and accessibility modes.
• Counterfactual tests for protected or sensitive attributes where appropriate and lawful.
• Adversarial testing for stereotyping, harassment, unsafe instructions, prompt injection, and misinformation.
• Clear confidence thresholds and fallback behaviour when the model is uncertain.
• A human escalation path with service-level targets.
• User-visible explanations, correction controls, and appeal mechanisms.

Avoid collecting sensitive attributes merely to produce a fairness report. Where measurement is necessary, minimise collection, restrict access, document the purpose, and define deletion timelines. Privacy-preserving approaches such as on-device processing, aggregation, and carefully governed federated learning may reduce exposure, but they do not remove the need for consent and security controls.

Design for affordable devices and unreliable networks

Inclusion fails when a product requires a recent phone, continuous connectivity, or expensive data. Profile the application on the lowest-supported device and network conditions. Track time to first interaction, memory use, battery impact, model download size, and failure recovery—not just cloud inference cost.

Practical techniques include:

• Quantised or distilled models for on-device inference.
• Progressive loading so core actions work before optional AI features download.
• Caching of language packs, prompts, and previously retrieved content.
• Asynchronous workflows that queue requests while offline.
• Compressed audio and images with user-controlled quality settings.
• Human-assisted channels for cases where automation is unavailable.

Use AI selectively. A deterministic rules engine may be faster, cheaper, and easier to explain for a simple eligibility check or navigation flow. Reserve generative models for tasks where they add clear value, and constrain them with retrieval, structured outputs, validation, and permissioned tools. For complex systems, patterns from building high-performance AI applications with open-source tools can help reduce vendor dependence and improve deployment flexibility.

Measure inclusion after release

Inclusive design is an operating practice, not a launch milestone. Establish a dashboard that tracks completion rates, error recovery, abandonment, support requests, language-specific performance, accessibility defects, and escalation outcomes. Review results by relevant user segment and investigate sudden changes after model or UI updates.

Give users a direct way to report mistranslations, inaccessible screens, harmful recommendations, and incorrect personalisation. Close the loop by telling users what changed. A community advisory group can provide ongoing qualitative insight, while independent audits are valuable for high-impact systems.

For builders, the strongest business case is practical: better language coverage expands reach, accessible flows improve completion, and transparent safeguards build trust. Teams that make these requirements explicit early are less likely to face expensive retrofits, reputational damage, or exclusionary growth.

A practical build checklist

Before shipping, confirm that your team can answer “yes” to the following:

• Have intended users helped define the problem and tested the workflow?
• Do evaluation sets represent the languages, devices, accents, and accessibility needs of the target market?
• Can users complete essential tasks without English, a touchscreen, or continuous connectivity?
• Are model limitations, confidence thresholds, and human escalation paths documented?
• Have privacy, consent, retention, and deletion requirements been reviewed?
• Can users correct an AI output and recover from a wrong action?
• Are monitoring, incident response, and periodic fairness reviews funded and assigned to named owners?

Founders exploring adjacent speech products can also compare implementation choices in building a voice agent with Whisper and ElevenLabs. For teams developing open infrastructure, Indian student developers building open-source AI offers a useful path for community-led experimentation and talent development.

Inclusive AI is ultimately a product discipline: understand the user, measure what matters, reduce avoidable barriers, and keep people in control when the system is uncertain. Indian builders who follow that discipline can create tools that are not only fairer, but more reliable and more useful at national scale.