Sovereign and On-Premise LLMs for Indian Insurers and Brokers: Why DPDP, IRDAI Record-Localisation and STQC Cloud Rules Push Models In-House

An insurer or broker that wants a language model in its workflow, summarising claims files, drafting client communications, extracting data from policy schedules, is not really choosing a model first. It is choosing where the model runs and what data crosses what boundary, and in Indian insurance that choice is set as much by regulation as by engineering. The build-versus-host question reduces to a small set of options: a general hyperscaler region, a localised hyperscaler region inside India, a sovereign or community cloud, or an on-premise deployment of an open-weight model.

The regulatory gravity in this market pulls toward the in-house end of that spectrum. The reason is a stack of overlapping rules, record-localisation for insurance data, empanelment and audit requirements for cloud, and a cyber-security regime that now folds in the Digital Personal Data Protection Act, 2023, that together make casual use of an external, general-purpose model API hard to justify for regulated data.

This post sets out those rules as a CIO would weigh them, then maps them against the realistic deployment options, including the open-weight Indic models that make a self-hosted route practical in a way it was not a few years ago.

The anchoring obligation is record-localisation. The IRDAI (Maintenance of Insurance Records) Regulation, 2015 requires insurance records to be held within India, and where those records sit on cloud, the provider must be MeitY-empanelled with valid STQC audit status. That is two conditions, not one: the data stays in India, and the infrastructure it stays on is an audited, empanelled service.

For a language-model deployment this is the first filter. If processing a claims file or a policy schedule through a model means that record, or a copy of it, leaves Indian infrastructure or lands on a provider outside the empanelled, STQC-audited set, the deployment is hard to square with the regulation. A general model API hosted abroad fails the test for regulated records by construction. A localised region from an empanelled provider can satisfy it, provided the data genuinely stays in-region and the audit status holds.

• A general hyperscaler region outside India: fails record-localisation for insurance records.
• A localised hyperscaler region inside India, empanelled and STQC-audited: can satisfy it.
• A sovereign or community cloud meeting the same conditions: can satisfy it.
• On-premise inside the regulated entity: satisfies it by keeping records on the entity's own infrastructure.

The Digital Personal Data Protection Act, 2023 is often read as the headline data law, but for insurance its effect is more subtle than a blanket localisation mandate. The DPDP Act does not itself require data to stay in India. What matters is Section 16, which lets sector-specific rules from regulators such as IRDAI or the RBI override the Act's more permissive position where they impose a higher standard of protection.

The practical result is that insurance data flows are governed by the stricter sectoral rule, not by the DPDP default. So a CIO cannot reason from the DPDP Act alone that a cross-border flow is permitted; the IRDAI record-localisation obligation sits on top and is the binding constraint for insurance records. DPDP supplies the consent, purpose-limitation and data-fiduciary obligations; the sectoral rule supplies the localisation hard line.

This layering is why a deployment decision cannot be made by reading one instrument. The model architecture that satisfies DPDP's processing duties may still fail IRDAI's localisation requirement, and the architecture that satisfies localisation must still meet DPDP's obligations around consent and purpose. Both have to hold at once.

The supervisory link between the two regimes was made explicit in 2026. On 6 April 2026 IRDAI updated its Information and Cyber Security Guidelines, requiring regulated entities to take technical and organisational measures to comply with the DPDP Act from the current financial year.

That is a meaningful shift in posture. DPDP compliance is no longer only a matter for a general data-protection regulator; for an insurer or an insurance intermediary it is now part of what the insurance supervisor expects under its cyber-security framework. A language-model deployment that processes personal data therefore sits inside the IRDAI cyber-security perimeter, and the technical and organisational measures around it, access control, logging, data-flow governance, vendor assurance, are supervisory expectations rather than optional good practice.

For the build-versus-host decision, this raises the assurance burden on any external dependency. If a model runs on third-party infrastructure, the regulated entity has to be able to demonstrate the technical and organisational measures over that infrastructure to its supervisor. That is achievable with an empanelled, audited provider and proper contractual control, but it is more demanding than pointing a workflow at a public API, and it tilts the calculus toward deployments the entity can fully attest to.

The regulatory pull toward in-house deployment would be academic if there were no capable models to run there. There are. Open-weight Indic-language models such as AI4Bharat IndicTrans2, which covers all twenty-two scheduled languages, and Sarvam are available under permissive terms through the government Bhashini and AIKosh stack, which means a regulated entity can host them on its own empanelled infrastructure rather than calling an external service.

That changes the build-versus-host arithmetic. A few years ago, declining a general external API meant declining strong language capability. Now an insurer or broker can run a capable Indic model in a sovereign cloud or on-premise, keep insurance records on empanelled STQC-audited infrastructure, meet the localisation gate, and still serve a multilingual book across Indian languages. The trade-off becomes one of engineering and operating cost against control, rather than control against capability.

The sensible reading of the regulatory stack is therefore a tilt, not an absolute: a general external model API is hard to justify for regulated insurance records; a localised, empanelled, audited deployment, whether sovereign cloud or on-premise, is the defensible middle; and open-weight Indic models make the self-hosted end genuinely usable. A CIO should match the deployment to the sensitivity of the data each workflow touches, reserving the most controlled architecture for workflows that handle the most regulated records.

Getting that match right depends on understanding exactly which records a workflow touches and how the cover and wordings around a deployment respond if something goes wrong. Sarvada gives commercial insurance brokers structured, searchable access to insurer policy wordings and the intelligence around them, so the data-governance and cyber-cover questions around an AI deployment can be grounded in real policy detail. Request Access to bring that depth to your build-versus-host decision.