AI in India: build for the workflow, the language and the constraint

The national context, without the hype

The IndiaAI Mission was approved in March 2024 with an announced outlay of ₹10,371.92 crore. Its programme spans compute, datasets, indigenous models, applications, skills, startup support and safe AI. The official compute portal describes access to empaneled cloud AI services for eligible and approved organizations, including startups, researchers and MSMEs. These are useful starting points for research; availability, eligibility and commercial terms should be checked directly with the programme.

Infrastructure and policy create opportunities, but they do not choose a useful product for a team. An application still needs a clear user, a reliable information source and a reason to exist beyond access to a model. The following recommendations are an engineering perspective on product design, not a forecast of market size or a statement of government endorsement.

Language is a product requirement

A multilingual assistant should be evaluated with the language people actually use. That can include English mixed with Hindi or another Indian language, transliterated text, local names and domain-specific abbreviations. Translating a polished English benchmark is unlikely to represent every real interaction.

Start with a defined language pair and a small collection of realistic requests. Ask reviewers familiar with the subject to assess meaning, tone and whether the answer preserves qualifications. If speech is involved, test background noise, interruptions and names separately from answer quality. A fluent response can still misunderstand the original request. Make it easy to correct the transcript and keep a text alternative.

Choose a bounded business workflow

Possible starting points include finding an approved document, sorting incoming enquiries, preparing a draft response or extracting fields from a document for human review. These are illustrative use cases, not a claim that every business needs AI. Their appeal is that the input, reviewer and acceptance criteria can be made explicit.

Before a pilot, describe the current process. How long does it take? Which steps require judgment? What exceptions appear each week? Then compare the assisted workflow with that baseline. Count the time spent correcting errors, not only the time spent generating a first draft. An impressive response speed can hide a poor end-to-end experience.

Budget for the whole system

Model pricing is only one line in the operating budget. Document preparation, retrieval, storage, monitoring, reviewer time and support also matter. Long context windows and repeated agent loops can increase cost without improving the outcome. Set limits around the amount of work a single request can trigger and explain what happens when those limits are reached.

Hosting choices should follow the sensitivity of the information, latency needs, operational capability and applicable requirements. Self-hosting is a responsibility as well as a deployment option. A managed service also needs scrutiny of its data handling and service terms. The useful comparison is between complete operating models, not a list of model names.

A practical first month

Begin with workflow mapping and a representative evaluation set. Build a narrow prototype against approved information. Run it alongside the existing process with a person reviewing every result. Use the observed failures to decide whether to improve retrieval, change the interface, reduce scope or stop the experiment.

Publish what the pilot actually establishes: the scope, the sample, the measured outcome and the limitations. This creates a useful record for colleagues and future collaborators. For the Indian AI ecosystem, implementation knowledge that other teams can inspect is more valuable than another unsupported claim about transformation.

Questions, answered.

Keep connecting the dots.