Trustworthy enterprise knowledge search for regulated teams in India

01Why a demonstration proves little

Most knowledge assistants rest on one technique, retrieval-augmented generation (opens external site): fetch the passages that best match a question, then let a language model compose an answer from them. With fifty hand-picked documents, an impressive demonstration takes about a week.

Live deployments are messier. A compliance team at an NBFC works across RBI master directions and circulars, board-approved policies, internal notes on how each requirement was implemented, audit observations and long email trails, many of them superseded or restricted. An operations team at a pharma plant has SOPs, validation records and deviation reports in several versions. Here an assistant can fail in two ways: it answers wrongly and staff abandon it, or it answers wrongly with confidence and staff act on the answer.

So trustworthy search is mostly a property of the system around the model, not of the model. Five such properties matter, and each can be designed and, more to the point, tested.

02Permissions: show only what the reader is entitled to

The principle is plain: nobody should see a passage through the assistant that they could not open in the original system. The question is where that is enforced. Whatever reaches the model can surface in its answer, so filtering must happen at retrieval, before generation, for the person who is asking.

OWASP’s list of the principal risks in large language model applications includes sensitive information disclosure (opens external site) and vector and embedding weaknesses (opens external site), the latter covering leaks across permission boundaries. Four requirements follow.

• Copy each document’s access rights from its source system onto every chunk in the index, instead of maintaining a separate permission model by hand.
• Filter on those rights for the signed-in user at query time, before ranking and before generation.
• Sync permission changes no slower than content changes, and agree the maximum delay before a revoked right stops working.
• Use real roles in testing. “Can a branch officer open the inspection report meant for the board?” is a test case to write now, not a finding for an incident review.

03Provenance: citations a reader can verify

Each statement should link back to its source passage: the document title, its version or date, the owner, and a deep link to the exact spot, whether that is paragraph 12 of a circular or section 4.3 of an SOP. Display the passage, not just the title, so the reader sees at a glance whether it supports the sentence.

Shape the answer so that unsupported text is visible. A sentence that no retrieved passage backs up should be dropped or flagged. Verify this automatically by comparing every citation with the sentence it is attached to, and route a sample to human reviewers. A citation that is present but does not actually support its claim is a frequent failure, and an easy one to miss.

04Freshness and authority

Regulatory and organisational knowledge comes in versions. A master direction is amended, a circular is withdrawn, the board revises a policy, and old and new texts both match the same question while giving different answers. Store what distinguishes them in the index: the date from which a text applies, its state (draft, approved, superseded, withdrawn) and who owns it. Put current approved texts on top, hide superseded ones unless someone asks for the history, and print the date beside each citation.

Decide per topic which source carries authority: the regulator’s published text for the rule itself, the compliance function’s register for how it was implemented, the HR portal for leave policy rather than an email that quotes an old version. Give each source its own refresh schedule, close to real time for case files and once a day for a wiki, and alert on missed runs, because an index that falls behind produces plausible but outdated answers.

05Honest gaps: “I found no reliable source”

Often the most useful answer is an admission. Fluent but unsupported statements are a known behaviour of language models, which NIST’s generative AI profile calls confabulation (opens external site). Grounding answers in retrieved passages makes this rarer without eliminating it. The consequence, staff taking decisions on false output, is a risk OWASP lists separately under misinformation (opens external site).

Below a chosen relevance score, the system should say it has no reliable source and point to a person or team who can help. For questions on regulatory obligations, rights or policy, never let the model fill the gap from general knowledge: a plausible answer about an RBI requirement that is not in the indexed text is worse than no answer. Count unanswered questions by topic. During the first few months, that count tends to be the most useful thing the project produces, since it tells content owners precisely where their documentation is thin.

06Documents in more than one language

An Indian organisation may hold policies, circulars or customer correspondence in Hindi or other Indian languages alongside English. Treat that as a design question from the start: whether to index each language separately or translate for retrieval, how to cite the passage in its original language, and how to test answer quality per language. Bhashini, the national language platform of the Digital India Bhashini Division, is one option to evaluate for translation; the right choice depends on your data and your security requirements.

07The architecture behind the five properties

No exotic technology is needed. What is needed is that access rights, document metadata and checks are designed into the pipeline from day one, not bolted on after the demonstration.

Personal data needs explicit handling, because indexing documents is still processing the personal data inside them. Where the people concerned are in the EU, Article 5 of the GDPR, with its principles of purpose limitation and data minimisation (opens external site), applies. In India, the Digital Personal Data Protection Act, 2023 requires consent to be limited to the personal data necessary for the specified purpose (section 6(1)), and from May 2027 the DPDP Rules add security safeguards and the duty to keep logs of processing for at least one year. Index only the sources the use case requires, propagate deletions from source systems to the index, and cover the index in every response to an access request, whether from a data subject under the GDPR or, once the DPDP Rules apply, from a Data Principal.

08Measured quality, before and after go-live

Trying a handful of questions in a review meeting says little about trustworthiness. Settle quality criteria with the content owners, then measure retrieval, grounding, answers, access and use separately, so a fault can be traced to its layer.

Build the test set from questions people really ask: search logs, helpdesk tickets, queries raised with the compliance desk, questions new joiners put to colleagues. Start with a few hundred, each with an answer the content owners have approved. Rerun the whole set on every change, whether a new model, another chunking approach or an extra source. Quality slides quietly as content changes, and without a fixed test set nobody notices.

09How trustworthiness looks to a user

For the people who use the assistant, all of this shows up in a handful of behaviours. It draws only on documents they are allowed to open. Each claim links to a source they can check. Each source shows its date. When there is no reliable answer, it says so. And when they report a mistake, they see it corrected, which tells them that someone is measuring quality.

Some answers will still be wrong, and some questions are better put to a colleague in the compliance function than to a search box. Saying so in the design builds the confidence that makes people use the assistant for everything else.