Where does our data go? Running AI inside a lender's walls

Inferova is now in private beta. Before anyone asks what our software can read, extract or say on a call, the first question in almost every conversation with a lender is the same: where does our data go? It is the right question, and it deserves a plain answer rather than a reassuring one.

The question behind the question

A loan file is one of the most sensitive bundles of personal data a business holds. It carries identity documents, salary slips, tax returns, bank statements, property papers and, often, an Aadhaar number. When a team wants to try AI on that file, the easiest route is to upload it to an outside AI service and read back the answer.

For a regulated lender, that easy route creates three problems at once.

• Localisation. RBI's digital lending rules require data to be stored only on servers located in India. Data processed abroad must be deleted there and brought back to India within 24 hours. A general-purpose AI service may process requests in another country, cache them, or log them in ways the lender cannot see.
• Outsourcing risk. RBI's directions say outsourcing in no manner dilutes or absolves the lender of its obligations, and core decisions such as sanctioning loans cannot be outsourced at all. If a model provider reads loan documents, it is part of the lender's outsourcing chain, whether or not anyone signed a contract that says so.
• Personal data law. The Digital Personal Data Protection Act, 2023 makes the lender the data fiduciary. It decides the purpose of processing and answers for every processor it uses. The DPDP Rules, 2025 were notified in November 2025 and their main obligations come into force in phases over the following eighteen months. A lender that cannot say which processors touched a borrower's documents, and whether they kept a copy, will struggle to meet those obligations.

What "inside your walls" should mean

"On-premise" and "private cloud" are used loosely. For a Chief Risk Officer or CIO, the test is not the label on the brochure. It is whether you can answer five questions without asking the vendor.

1. Where does it run? The software, the models and the storage sit on the lender's own servers or in the lender's own cloud account. The vendor does not operate a shared copy that many customers send data to.
2. Who holds the keys? Documents are encrypted with keys the lender controls. If the lender runs several entities, each should be able to choose its own storage location and key, so that one entity's data cannot be read with another's key.
3. Who can see what? Sign-in goes through the lender's own identity provider, so joining, moving and leaving staff are handled where they already are. Data for each entity is kept apart in the database itself, not only in the screens.
4. What leaves the building? By default, nothing. Open models run on the lender's hardware. An outside AI provider is used only if the lender deliberately connects one, and that choice is visible and reversible.
5. Who trains on whose data? If a model is improved using the lender's reviewed work, that training happens inside the lender's environment and the resulting model serves only that lender. It does not become part of a product sold to the next customer.

This is how we have built Inferova. It is deployed in the customer's data centre or the customer's own cloud account, it uses open models, and documents do not go to an outside AI service unless the customer connects one. There are no subprocessors by default in a customer deployment.

The details that usually get missed

The failures tend to sit in the plumbing.

Background workers. Document reading and speech recognition often run on separate GPU machines. If those machines hold standing database credentials, a compromise of one machine exposes everything. A safer pattern is to give each job a single-use ticket and a time-limited link to the one file it needs, and nothing more.

Logs and copies. Teams lock down the main database and forget the debug log that printed a full PAN, or the temporary folder that kept every uploaded statement. Sensitive identifiers should be masked as documents arrive. Aadhaar numbers, in particular, should be masked at intake rather than cleaned up later, in line with the RBI's long-standing expectation that Aadhaar numbers be redacted where authentication is not required.

Audit that can be trusted. An audit trail that an administrator can quietly edit is not much of an audit trail. Records of who viewed, changed or approved something should be append-only and tamper-evident, so that an auditor can check that nothing was removed.

A person makes the decision. When AI reads a payslip or a bank statement, every value it reports should link back to the page it came from. What it cannot confirm should be flagged, not filled in with a plausible guess. Then a maker and a checker sign off, as they would on any other credit decision.

Questions to put to any AI vendor

Whether or not you speak to us, these are worth asking before any loan document goes near an AI system:

• Can it run entirely in our data centre or our cloud account, with no calls home?
• Which external services does it contact by default, and can we switch every one of them off?
• Who holds the encryption keys, and can each of our entities have its own?
• Does any data, including logs and prompts, leave India?
• Is our data ever used to train a model that serves anyone else?
• Can we show an auditor exactly who saw a borrower's file, and prove the record was not altered?

Vague answers leave the risk with you.

If you would like to see how this works on your own documents and infrastructure, you can request beta access at inferova.com/demo.

Sources