A policy assistant that says "the policy doesn't cover this"

Every lender runs on documents that most staff never read end to end. The credit policy, the product notes, the deviation matrix, the collections process note, a steady stream of regulatory circulars and the internal clarifications that follow them. When a credit officer in a branch needs to know whether a co-applicant's income can be counted for a particular product, the answer is somewhere in that pile. Finding it quickly is the hard part.

So people ask a colleague, or the regional credit manager, or they search a shared drive and open the first file that looks right. Sometimes that file, or the colleague's memory, is two versions old. The answer arrives with confidence either way, and nobody records where it came from.

A language model placed in front of these documents can help, but only if it is built to behave differently from the confident colleague.

The answer must carry its source

An answer about policy is only useful if the person receiving it can check it. For credit and operations staff, that means every answer names the document, the version and the clause it relied on, and lets the reader open that clause in one step.

This matters for three reasons:

• The reader can see whether the clause actually says what the answer claims. Models paraphrase, and a paraphrase can drift from the text.
• A reviewer or auditor can later reconstruct why a decision was taken. "The assistant said so" is not a reason; "clause 4.3 of the retail credit policy, version effective from April" is.
• It changes how staff use the tool. When the clause is always shown, people read the clause.

RBI's committee report on the FREE-AI framework lists "Understandable by Design" among its seven guiding principles, and states that "Accountability cannot be delegated to the model and underlying algorithm." A cited clause is the simplest practical expression of both ideas: the human stays accountable, and the human can see what the answer rests on.

An honest decline is safer than a confident guess

The most dangerous behaviour in a policy assistant is filling a gap. A question arrives that the documents do not address, perhaps a new product variant or an edge case the policy writers never considered. A general-purpose model will still produce a fluent answer, drawn from patterns in its training data or from a loosely related clause. It reads exactly like a correct answer.

In lending, that guess can become a sanctioned loan outside policy, a waiver given without authority, or a collections step that should not have been taken. The cost lands later, during an audit or a dispute, when nobody can say where the rule came from.

The better behaviour is plain: when the retrieved documents do not cover the question, the assistant says so. "The documents available to you do not address this. The closest clause is 6.2, which covers salaried applicants only." That reply is less satisfying in the moment, but it sends the question to the right person, and it gives the policy team a record of gaps worth closing.

Building this takes deliberate design. The system has to judge whether the retrieved text actually answers the question, not merely whether it found something on the topic. It needs to be tested on questions the policy does not cover, not only on ones it does, and a decline should be counted as a correct result when the documents are silent.

Keep circulars current

A policy assistant is only as good as the version of the policy it reads. Lenders revise policies often, and circulars supersede earlier ones in part or in full. If the knowledge base holds every version side by side with no dates, the model may quote a withdrawn rule as readily as the current one.

A workable approach:

1. Store every document with its version, its effective date and, where relevant, the date it was withdrawn or superseded.
2. Answer from the version in force on the date that matters. Usually that is today, but a question about a loan sanctioned last year may need last year's policy.
3. Show the effective date next to the cited clause, so the reader knows which version they are looking at.
4. Name an owner for each document set, so that uploading a new circular and retiring the old one is someone's job, not an afterthought.

Keep old versions: they answer "what was the rule when this decision was taken".

Access follows roles

Not every document is meant for every reader. Delegation-of-powers matrices, internal audit notes, fraud typologies and draft policies under review are usually restricted. A policy assistant that searches everything and answers anyone can leak restricted content through a summary, even if the document itself never appears on screen.

The control has to sit at retrieval, not at display. The assistant should only search documents the person asking is allowed to see, based on the same roles the lender already uses. If the answer exists only in a restricted document, the right response is the same honest decline: the documents available to you do not cover this.

In Inferova's Worker, policies, circulars and process notes sit in knowledge bases built in LLM Studio, answers cite the clause used, and retrieval follows the user's role.

What to ask before you deploy one

• Does every answer show the document, version, effective date and clause?
• What does the assistant do when the documents do not cover the question, and has that been tested?
• How are superseded circulars handled, and who owns updates?
• Is access enforced before retrieval, using your existing roles?
• Where do the documents and the questions go? Do they leave your environment?

If you want to see how this works on your own policy documents, you can request beta access at inferova.com/demo.

Sources