A weekly Founder Note on the infrastructure, decisions and operating models shaping enterprise AI.
An enterprise can have an excellent English AI assistant and still fail most of the people it serves.
Adding a translation button may make the interface look multilingual. It does not ensure that the system understands a customer's intent, retrieves the right policy or communicates a decision accurately.
Language is part of the architecture. If it is introduced only at the final response, important meaning may already have been lost.
The workflow begins before the answer
A customer may speak in one language, mix two languages, use a local product name and refer to a document written in English. The system has to identify the request before it can answer it.
Speech recognition, optical character recognition, transliteration, machine translation, search and the language model each make a contribution. An error early in that chain can flow through every later step. A fluent final answer is no proof that the original meaning survived.
Design the workflow so it preserves the original input, marks uncertainty and can trace the answer back to an approved source.
Meaning has to survive retrieval
Enterprise knowledge is often stored in one language while questions arrive in many. A literal translation of the question may miss regional terminology or a domain-specific phrase. Retrieval can then find a plausible document that is irrelevant to the customer's actual situation.
A multilingual knowledge layer needs approved terms, alternative expressions and a way to connect concepts across languages. It also needs document versions, permissions and source authority. The system should retrieve the policy that applies, not merely text that resembles the translated query.
This is especially important in banking, insurance and healthcare, where a small shift in meaning can change the next action.
Evaluate the entire path
A translation benchmark is useful, but it cannot measure the whole customer experience. Test real tasks across languages and accents, including code-switching, names, numbers, dates, disclosures and difficult edge cases.
Measure whether the system understood the request, selected the right source, preserved critical terms, took the permitted action and communicated it clearly. Review failures at each stage so teams know whether to fix the speech model, translation, retrieval, prompt, knowledge source or handoff rule.
Quality will vary by language and task. Publish those differences inside the organization and use them to set safe operating boundaries.
Control where data and decisions go
A multilingual workflow may call several models and services. Enterprises should know what information each component receives, where it runs, what it stores and who can inspect its output.
Some use cases call for on-premise deployment or tighter controls on personal data. Others may use hosted services within approved boundaries. The architecture should make these choices explicit, with logs and access controls that support review without exposing unnecessary customer information.
At Devnagri, we think of this as language infrastructure: connected speech, text, document and model capabilities with governance around the workflow. No single model can carry that responsibility alone.
Let people stay in their language
A well-designed system should not make a customer repeat a problem in English or make an employee manually bridge every language gap.
It should keep the original expression available, provide a faithful working interpretation and make high-impact messages reviewable. The goal is equal access to a dependable service, regardless of the language in which a person begins.
Language diversity is not an edge case. It is the real operating environment for enterprises that serve broad populations.
What next
What this means for enterprise leaders
Choose one customer journey and follow a request from the customer's first word to the final action. Record every point where language changes, every model involved and every place meaning could be lost.
Test the journey in the languages your customers actually use, with real terminology and exceptions. Give each failure an owner and a measurable fix.
In the next Founder Note, I will look at what it takes to move a promising enterprise AI pilot into dependable production.