Let me tell you one thing straight away - in every enterprise AI conversation I've been in, the obstacle was never the model. It was the data. And specifically, what happens to the data when the AI runs.

Public AI tools ask you to send corporate records to infrastructure you don't control, in regions you didn't choose, under a privacy regime you cannot verify. For any organisation processing personal data in India, that's not a philosophical tension anymore. It's a legal liability. The Digital Personal Data Protection Act, 2023 - the DPDP Act - puts purpose limitation, data minimisation and reasonable security safeguards on the statute book, with penalties scaling to ₹250 crore.

So in this post, I'll walk you through what we've actually built at Kappal to solve this - not as theory, but as two systems we deploy for enterprise clients, and the design principles behind them that I keep coming back to.

What is private enterprise AI? Private enterprise AI runs inside your own network boundary, in a region you choose, on infrastructure you control. It indexes your internal systems - SAP, SharePoint, legacy documents - and lets teams search them with AI, while every byte of corporate data stays inside your firewall, under your existing permissions.

The Problem I Keep Seeing

Every enterprise AI conversation I walk into collapses into the same two questions, and they're never the questions the vendor wants to answer.

The first: where does my data go? The second: what happens to the systems I already paid for? In my experience, the AI budget dies on the second question more often than the first.

Consider the average mid-sized Indian manufacturer or financial services firm. The customer master lives in SAP ECC. The contracts live in SharePoint. The last fifteen years of vendor correspondence sit in a legacy document system nobody remembers how to migrate. None of these systems talk to each other in any useful way. The data isn't missing. It's present, complete, and locked in place.

So what do employees actually do when they need to find something? They ask a colleague. Then they call around. Then, increasingly, they paste the documents into a public AI tool and hope for the best.

That last habit is the one that should worry a compliance officer. The DPDP Act doesn't distinguish between an accidental leak and a careless one. Processing personal data without a lawful basis, or beyond the purpose for which it was collected, is an offence under the statute. The same tool that makes your sales team productive is quietly turning every employee into someone who processes data without knowing the obligations attached to it.

The deeper problem is structural. Enterprise data isn't sitting in a lake waiting to be queried. It's distributed, duplicative, permissioned, and almost entirely unstructured from the perspective of the people who need it. The value is there. The access is not.

This is the gap we kept running into, and it's the reason we stopped proposing yet another model and started building the thing that sits between the model and the data.

Design Principle One: Data Sovereignty Is the Product

We built the first version of what we call the AI Knowledge Directory the way most teams would - with the embedding pipeline in the same tenant as everything else. It worked. It was also undeliverable, because the client's CISO couldn't sign off on it, and we couldn't argue with his reasons.

Three questions came up in every security review, in the same order:

1. Which region is my data processed in?
2. Who can see it, including your staff?
3. Is my data used to train anything?

We decided to make those three questions the specification rather than the objection. Every design decision since then starts from the answer.

Region. All model inference runs on Azure OpenAI instances locked to the Central India region. If your data is Indian, it stays in Indian infrastructure. This aligns with how the DPDP Act treats cross-border transfer, and it gives the client a single, auditable statement of where processing happens. We don't route anything through another region for convenience, because convenience is exactly how sovereignty commitments evaporate.

Tenancy and training. Corporate data is never used to train or fine-tune models - not in our infrastructure and not in the foundation model. We run inference against the deployed model with your data in context, and we don't persist prompt or document content outside your VPC beyond what the retrieval pipeline itself requires. This isn't a marketing claim. It's a contractual term we put in writing.

Residency. The deployment is a locally hosted stack inside your own VPC. The vector store, the index, the orchestration layer and the model endpoints all live inside your network boundary. Zero data leaves your firewall. Not for a batch job, not for a report, not for a feature demo.

There's a common objection here, and it deserves a straight answer.

Yes, a locally hosted, in-region stack costs more to operate than a shared SaaS tenant. The difference is that it converts an unquantifiable compliance risk into a fixed, known infrastructure cost. For a significant data fiduciary, that trade isn't even close.

Design Principle Two: Integration Over Replacement

The second question - about the systems you already paid for - deserves the same bluntness. Big companies don't replace their ERP because someone builds a nicer one. They don't replace it because the ERP isn't a product they chose. It's a set of business processes that have been accumulating for twenty years. The cost of replacement isn't the licence fee. It's the risk of breaking order-to-cash in a company where order-to-cash is the company.

We don't position ourselves against the ERP. We sit on top of it.

The Knowledge Directory connects to SAP ECC and Oracle through their native interfaces: RFC and BAPI on the SAP side, REST and OData where the system exposes them. Same for SharePoint, and for the legacy document stores, and for whatever the client is actually running. We pull the metadata and the content that needs to be searchable, we index it, and we return the user to the source system for the authoritative record. Writes, where they exist, go back through the same governed APIs, so the source of truth stays the source of truth.

The positioning is simple, and we use it in every conversation: we're not here to replace your ERP. We're here to make it searchable.

This reframe matters more than it sounds. It changes the buying conversation from a migration project to an augmentation project. The risk profile collapses. The CTO is no longer defending a multi-year, multi-crore replacement plan against a sceptical board. They're approving a pilot that connects to a system already running, with read-only access, and measurable outcomes in weeks.

The AI Knowledge Directory: How It Actually Works

The Directory is a retrieval pipeline, not a chatbot bolted onto SharePoint. The pieces are worth naming, because the failure modes live in the joints between them.

• Connectors. Each source system has a connector that understands its permission model. The SAP connector reads the same authorisation objects your users already have. The SharePoint connector reads the same sharing permissions. The legacy connector handles scanned documents with OCR, because most of the institutional knowledge in an Indian enterprise is still paper that was scanned and then forgotten.

• Ingestion and chunking. Documents are split into chunks sized for retrieval, with structural context preserved. This sounds mundane, and it's where most retrieval quality is won or lost. A chunk without its section heading is a chunk that cannot answer a question.

• Embedding and storage. Chunks are embedded using Azure OpenAI embeddings - again in the Central India region - and stored in a vector store inside the VPC. We keep the keyword index too. Hybrid retrieval, keyword plus semantic, consistently outperforms pure vector search on the messy, acronym-heavy language of real enterprise documents.

• Query time. A user's query is embedded, both retrieval paths run, results are re-ranked, and then the access control layer runs. The RBAC check is not an afterthought on top of search. It is the search. Every result is filtered against the permissions materialised from the source systems, so the index can only return what the specific user could open in the source system anyway.

This is the part we're most asked about, because it's the part that usually gets skipped. Permission models in SAP and SharePoint are per-user and per-object. You cannot index once and let everyone search everything, because that defeats the entire purpose of having permissions. We materialise the effective permissions at index time, for each document and each group, and we enforce them at query time. The practical consequence: a junior engineer can search the same corpus as the CFO and see a smaller, correct, authorised slice of it. The financial projections are in the index. They're simply not in the junior engineer's answer.

I'll be honest about the cost of doing this properly. Materialising permissions adds ingestion overhead and a little query latency. That's the difference between a demo and a deployment, and we build the real one.

The Private AI Vendor Directory: Procurement Gets the Same Treatment

The second deployment is the same architecture pointed at a different, equally siloed dataset: your supply base.

A mid-sized manufacturer we know keeps vendor master data in the ERP, and purchase order history in the ERP too. But delivery performance lives in a spreadsheet that one manager maintains. Compliance certificates live in email attachments. Market pricing lives in whatever a sourcing analyst last negotiated. When a supplier fails, the knowledge of who could step in is distributed across roughly twenty people, none of whom are in the same meeting.

The Vendor Directory ingests all of it: vendor master records, historical delivery timelines, quality and compliance records, and market pricing. It builds a dynamic, searchable intelligence graph, not a static table. The graph knows that Vendor A delivers on time in normal conditions but fails under surge demand. It knows that Vendor B - a Tier-2 supplier who has never held a prime contract - has the capacity, the certifications and the delivery record to step in.

The procurement scenario is the one that sells this to operations teams. When the supply chain breaks - and it will break - your procurement officers shouldn't have to call twenty people and reconstruct what the data already knows. They type a question in plain language: who can supply this component, in this region, within this timeline, with this compliance certificate. The graph answers in seconds, ranked by capacity, compliance and historical reliability. The officer still makes the call. But the call is informed by everything the company knows, not by whoever happened to pick up the phone first.

Nothing about the vendor data leaves the firewall either. Your supplier relationships, your negotiated prices and your exposure when a supplier fails are commercial intelligence you don't want in a shared cloud tenant, and the architecture doesn't require you to put them there.

Security and Compliance Posture

For anyone evaluating this against the DPDP Act, here's how the pieces line up.

The enterprise remains the data fiduciary under the Act. We act as a data processor on its instructions and under contract - which is the relationship the Act is built around. Purpose limitation is enforced by design: the index stores only what the deployment is scoped to index, and nothing is repurposed. Data minimisation is enforced at ingestion; we don't hoard source systems wholesale. Reasonable security safeguards are implemented as a default architecture: encryption in transit and at rest, tenant isolation inside the VPC, RBAC at every layer, and audit logs of who queried what. And because inference runs in the Central India region, the organisation can state, in one sentence, where its data is processed.

We also keep the human layer honest. When access is revoked in the source system, it's revoked in the index at the next refresh. We don't maintain a parallel permission set that drifts from the one your security team already manages.

What a Deployment Actually Looks Like

The pattern we recommend - and the one that has worked - is deliberately unglamorous.

Start with one connector and one use case. A pilot should index a single system, usually the one with the most trapped knowledge, and serve a single team. Define the success metric before the pilot starts, and we recommend retrieval hit rate: of the questions that team actually asks, what fraction returns a useful, authorised answer. Four to six weeks is enough to know whether the deployment earns its keep. Then add connectors, expand the RBAC mapping, and widen the user base one team at a time.

The sequencing exists for a reason. Every connector you add is a new permission model to materialise and a new set of users to protect. It's better to do one system perfectly, with the security review signed off, than to index everything and then explain to a CISO why a test environment's documents are showing up in production search.

Frequently Asked Questions

What is the DPDP Act, and why does it affect enterprise AI?

The Digital Personal Data Protection Act, 2023 is India's data protection law. It requires purpose limitation, data minimisation and reasonable security safeguards for personal data, with penalties up to ₹250 crore. When employees paste corporate records into public AI tools, the company - as data fiduciary - carries the compliance risk. Private AI removes that risk by design.

Can AI search work on SAP and SharePoint without replacing them?

Yes. The AI Knowledge Directory connects to source systems through native interfaces - RFC and BAPI for SAP, REST, OData and SharePoint APIs - and indexes metadata and content into a vector store inside your VPC. Users are returned to the source system for the authoritative record. Writes go back through the same governed APIs, so the ERP stays the source of truth.

How does role-based access control work in AI search?

Permissions are materialised from the source systems at index time and enforced at query time. SAP authorisation objects and SharePoint sharing permissions are read per user and per group, so the index can only return what a user could open in the source system anyway. A junior engineer and the CFO can search the same corpus and see different, correctly scoped answers.

What happens when a user's permissions are changed or revoked?

The index re-materialises effective permissions from the source systems on every refresh cycle. Access that is granted or revoked in SAP or SharePoint is reflected in the index at the next refresh. We don't keep a parallel permission set that drifts from the one your security team already manages.

Where is my data processed?

All model inference and embeddings run on Azure OpenAI instances locked to the Central India region, inside the client's own virtual private cloud. Corporate data is never used to train or fine-tune models. Zero data leaves the firewall - not for batch jobs, not for reports, not for feature demos.

Does private enterprise AI cost more than public AI?

Yes, a locally hosted, in-region stack costs more to operate than a shared SaaS tenant. The difference is that it converts an unquantifiable compliance risk into a fixed, known infrastructure cost. For a significant data fiduciary, that trade is worth it - data never leaves the firewall and nothing is used for training.

Final Thoughts - What Actually Matters

The next decade of enterprise software won't be won by whoever builds the better model. It will be won by whoever makes the systems companies already run searchable, without asking those companies to surrender their data to do it.

The model is a commodity that gets cheaper every quarter. The data is not. It's unique, it's permissioned, and it's protected by law. The companies that treat their data that way - and bring the model to the data instead of the other way around - are the ones that get the benefit of AI without inheriting its liabilities.

We built the Knowledge Directory and the Vendor Directory on that bet. The first makes your existing systems answerable. The second makes your supply base legible at the exact moment you need it. Both run inside your firewall, in your region, under your control.

Your ERP doesn't need replacing. It needs to be asked the right questions. We built the system that lets it answer.

So if you're about to embark on an enterprise AI project, start from the data - not the model. Keep it in your region, keep it in your VPC, keep it under your permissions. The model will keep getting better every quarter. Your data won't wait that long.