AI that holds up in the languages your customers actually type
AI development in India has to survive input nobody wrote a benchmark for: Hindi typed in Roman letters, a sentence that starts in English and finishes in Telugu, a question with three spellings of the same word. Model quality drops on all of it, so it has to be measured on your own messages. Cost per interaction and the DPDP Act shape the rest.
A system that answers well in clean English tells you almost nothing about how it will behave here. Indian users write in Roman script, in their own script, in both within one sentence, with spellings that vary between people and between messages from the same person. Each of those is further from the training data than the demo was, and the drop is real, uneven across languages, and invisible until someone looks.
The common failure is a launch based on a demo. The system is tested on a few dozen well-formed English questions written by the team building it, performs well, and goes live. Then real messages arrive: romanised Hindi, a mix of two languages, product names spelled by ear, a question asked in Tamil script. The model does not refuse, it answers, confidently and wrongly, and nobody notices because there is no evaluation set, no logging of low-confidence cases and no one reviewing what it actually said. The first sign of trouble is a customer complaint about something the business never knew it had promised.
When this work makes sense
Questions worth asking any supplier
Is there an evaluation set built from your own historical messages, including the badly written ones? Without it, quality is an opinion held by whoever demonstrated it.
Has performance been measured separately for each language and for romanised input? A single accuracy figure across mixed traffic hides exactly the cases that fail.
What happens when the model is unsure? A system that always answers is a system that will occasionally invent, and the handover path matters more than the accuracy.
Where is personal data going, how long is it kept, and what did the user consent to? The DPDP Act makes this a design question rather than a policy document written afterwards.
What does one interaction cost, and what happens to that number at ten times the volume? Model choice is a commercial decision and should be presented as one.
Deliverables
An evaluation set drawn from your real messages, covering each language and romanised input, reported per language rather than as one number
Retrieval grounded in your own documents, so answers come from your content rather than the model's recollection
Explicit refusal and handover behaviour, with low-confidence cases routed to a person and logged
Model routing where it pays, a smaller model for routine traffic, a larger one for the cases that need it
Consent capture, retention limits and deletion handling built to your adviser's reading of the DPDP Act
Cost per interaction reported alongside quality, so the two are traded off deliberately
Transliteration and spelling-variant handling for names, products and places people type several ways
Built with
Process
We start by taking a sample of your actual conversations and building an evaluation set from them before choosing a model. That sample includes the messy ones: half-English sentences, phonetic spellings, questions with no verb. We score candidate models against it per language, and the result is frequently not the model anyone expected, a cheaper one is sometimes better on romanised Hindi than a more expensive one, and the difference is only visible because the test used your traffic rather than a benchmark. Choosing first and measuring later is how projects end up committed to the wrong economics.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to handle Indian language input
One large model for everything
Fits: Low volume, many languages, and a preference for simplicity over unit cost
Limits: You pay the premium on every routine interaction, including the ones a much smaller model would have answered correctly
Route by language and difficulty
Fits: Higher volume where cost per interaction is a real line item
Limits: More to build and to monitor, and the routing rules need reviewing as traffic and models change
English only, with people for the rest
Fits: B2B categories where customers write in English and volume in other languages is genuinely small
Limits: Excludes callers who would have used their own language, and that exclusion is silent, it never appears in your data
Case studies
No published Indian AI case study yet. This work is built by the engineering team at our Hyderabad head office. We will publish client work when we have permission to name the business and results that can be evidenced.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do models handle Hindi and regional languages well?
Better than they did, unevenly, and worse than the marketing suggests. Quality varies substantially between languages and drops further when the language is typed in Roman script. The only useful answer is a measured one, which is why we build the evaluation set from your messages before recommending anything.
What is code-mixed input and why does it matter?
It is how a great many Indians actually write: a sentence that moves between English and another language, often mid-clause, often in Roman letters. Models trained largely on monolingual text handle it less reliably, and because it looks like ordinary text the failures are quiet rather than obvious.
How does the DPDP Act affect an AI project?
It makes consent, purpose and retention design decisions rather than paperwork. What you collect, what you send to a model provider, how long conversations are kept and how deletion is handled all have to be decided during the build. We build to what your legal adviser specifies, the interpretation is theirs, not ours.
Can you stop it making things up?
You can reduce it substantially and you cannot eliminate it. Grounding answers in your own documents, constraining what the system may discuss, and making refusal an acceptable outcome all help. What matters as much is the handover: a person picking up the flagged cases, and someone reading the logs.
How much does each conversation cost to run?
It depends on the model, the length of the exchange and how much context is retrieved each time. It is a number we report alongside quality rather than burying, because a system that is slightly better and several times more expensive per interaction is not automatically the right choice at your volume.
Do we need our own model?
Almost certainly not. For nearly every Indian business the right shape is a hosted model with your content retrieved at query time, which is faster to build, cheaper to run and easier to change. Training your own is a reasonable answer to a narrow set of problems, and we would tell you if yours were one of them.
How do we know it is still working six months later?
Because the evaluation set is run again, the flagged conversations are read, and both are reported. Systems drift as models are updated and as customers start asking about new things. Without a standing review, the first sign of a problem is a customer telling you about it.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.