# Enterprise data readiness for AI: clean, governed and able to forget Source: https://dpdp.miravlabs.com/services/enterprise-data-readiness-for-ai/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs **Short answer:** AI-ready data is data you can find, trust, govern and delete. Once personal data is copied into embeddings, indexes and caches, the DPDP Act follows it there: section 8(7) erasure, section 12 correction and section 8(5) safeguards apply to those copies from 13 May 2027. We build retrieval systems where every chunk links to its source, so erasing the source erases the copy. ## In plain words Most company AI projects get stuck on data, not on the model. The data is spread out, out of date, and nobody knows who owns it. And when you copy customer or employee data into an AI search system, the privacy law follows it there. If a person asks you to delete their data, it has to disappear from the AI system too. - **13 May 2027** when the main privacy duties start - **₹250 crore** maximum penalty for weak security - **1 year** minimum time to keep logs of each use ### What it means for you - An AI assistant that answers from your documents keeps its own copy of them. That copy holds personal data. - When a person's record is deleted or corrected, the AI copy must be deleted or corrected too. - The assistant must only show each user what that user is allowed to see. - If it shows one customer's details to someone else, that counts as a data leak. - Hide personal details before they go into the AI system, if the task does not need them. **Example:** An insurance broker in Pune builds an assistant over its claims emails. Each piece of text it stores remembers which email it came from. When a customer asks to be deleted, one job removes her emails and every stored piece linked to them, then checks that a search for her finds nothing. ### What to do - List the data sources the AI project actually needs, and who owns each one. - Mark which of them hold personal data, and remove what the task does not need. - Link every stored piece of text back to the record it came from. - Copy each user's access rights into the AI search, so it never shows more than they could see. - Test that deleting a record also deletes it from the AI system. The law: sections 2(t), 6, 8(5), 8(6), 8(7) and 12 of the DPDP Act and Rules 6 and 8 of the DPDP Rules, 2025. Applies from 13 May 2027. ## The detailed guide ## Key takeaways - Most enterprise AI work is data work: finding the right sources, cleaning them and recording who owns them. - Embeddings, indexes and caches built from personal data are copies of it, so erasure and correction must reach them. - Tag every chunk with its source ID and access rules, so you can delete by source and filter by user. - Permission-aware retrieval stops one user getting another person's data; a leak of that kind is a personal data breach. - Mask personal data before indexing where the use case does not need it. Enterprise AI projects usually start with a model and a demo, and then slow down when they meet the real data: documents in shared drives nobody has opened in years, customer records that disagree across systems, and no clear answer to “who is allowed to see this?”. A retrieval system built on that data gives confident answers from stale or wrong sources, and sometimes shows people things they should never see. The DPDP angle makes this sharper. A retrieval-augmented generation (RAG) system copies your documents into chunks, embeddings, indexes and caches. If those documents hold personal data, every copy carries the same obligations as the original. This page explains how we make enterprise data ready for AI, with privacy built into the pipeline rather than added after launch. ## What does “AI-ready data” actually mean? In practice, data is ready for AI when you can answer five questions about it: - **Which sources matter?** Not every drive and database belongs in a knowledge system. The use case decides. - **Can we trust it?** Current, de-duplicated, with the authoritative version marked and superseded versions excluded. - **Who owns it and who may see it?** Each data set has an owner, a sensitivity label and access rules. - **What personal data is in it, and why do we hold it?** Personal fields tagged, with the purpose and basis recorded. - **Can we change or remove it everywhere?** A correction or erasure in the source reaches every copy the AI system made. The first three are good data engineering and would matter without any privacy law. The last two are where the DPDP Act comes in, and they are the ones most retrieval projects skip. ## Why DPDP follows your data into embeddings and indexes The Act defines personal data as any data about an individual who is identifiable by or in relation to it (section 2(t)). A chunk of a support ticket that names a customer is personal data. In our reading, so is the embedding of that chunk when it is stored with a pointer back to the ticket or the customer, because it exists only to retrieve that text. Your counsel should confirm the position for your systems, but we design as if the copies are in scope. From 13 May 2027, that brings in several duties: - **Purpose.** Consent is specific to a purpose and limited to the data necessary for it (section 6(1)). Indexing customer data for a new use needs a basis for that use. See our [consent and legitimate uses guide](https://dpdp.miravlabs.com/guides/dpdp-consent/). - **Accuracy.** Where personal data is used to make a decision that affects the person, or is disclosed to another fiduciary, you must ensure it is complete, accurate and consistent (section 8(3)). An assistant answering from an outdated record can break this. - **Safeguards.** Reasonable security safeguards (section 8(5)), with Rule 6 measures such as masking, access control and access logs. The penalty ceiling is ₹250 crore. Our [security safeguards guide](https://dpdp.miravlabs.com/guides/dpdp-security-safeguards/) covers Rule 6 in detail. - **Rights.** Access, correction and erasure under sections 11 and 12 reach every copy. See the [rights guide](https://dpdp.miravlabs.com/guides/dpdp-data-principal-rights/). - **Erasure and withdrawal.** Erase when consent is withdrawn or the purpose is served, and make your processors erase (section 8(7)); stop processing within a reasonable time after withdrawal (section 6(6)). - **Processors.** If an outside service computes embeddings or hosts your index, it is a processor working under your contract, and you remain responsible for it (section 8(1)). Our [fiduciary and processor guide](https://dpdp.miravlabs.com/guides/data-fiduciary-vs-data-processor/) covers the contract terms. ## How an engagement runs: find, clean, govern, index, forget We work with your data, platform and security teams, alongside your legal counsel, on one use case at a time. Each step produces something your team keeps and runs. ### 1. Find the sources that matter We start from the questions the AI system must answer and work back to the sources that hold the answers. For each source we record the system, owner, volume, update frequency and whether it holds personal data. Sources that add risk without adding answers stay out. This is usually where scope shrinks most, and where the project gets faster. ### 2. Clean and label We remove duplicates and superseded versions, mark the authoritative copy, and fix broken structure such as scanned files without text or tables flattened into noise. In the same pass we tag personal data: names, contact details, identifiers, financial and health information, and free text about people. Each source gets a purpose and a legal basis, agreed with your counsel. ### 3. Govern: catalogue, owners, access rules The output of the first two steps goes into a data catalogue: an inventory of every indexed data set with its owner, sensitivity, purpose, retention period and access rules. The catalogue decides what the pipeline may ingest. It is also what you use to answer “where else is this person's data?” when a rights request arrives. ### 4. Index with permissions We build the pipeline that chunks, embeds and indexes the approved sources. Every chunk carries metadata: the source system, the source record ID, a version, the purpose tag, the access rules inherited from the source, and the person IDs where a record is linked to a known individual. Personal fields the use case does not need are masked or replaced with tokens before embedding, which follows the masking and virtual-token measures Rule 6 names. ### 5. Forget Correction and erasure events in the source systems flow to the index automatically. When a record changes, its chunks are re-embedded. When it is erased, its chunks go. The next section shows how. ## How do you delete a person's data from a RAG system? This is the question most retrieval designs cannot answer, because the link between a chunk and its source was never kept. If you design for it from the start, deletion is a routine job: - **Link every chunk to its source.** At ingestion, store the source record ID and, where known, the person ID on every chunk, in the vector index, the keyword index and the chunk store. - **Erase at the source first.** The rights workflow or the retention job erases the source record, which emits an erasure event with the source ID. - **Delete by source ID.** A pipeline job deletes every chunk carrying that ID from each index. Delete by filter on metadata, never by searching for similar text, which can miss chunks or remove the wrong ones. - **Handle shared documents.** An email thread or a contract names many people. Redact the person in the source, then re-chunk and re-embed that document, rather than deleting it for everyone. - **Purge caches and history.** Answer caches, conversation histories and prompt logs can hold the same text. Tag cache entries with the source IDs they used so they can be purged, and give everything else a short expiry. - **Re-index and compact.** Check whether your index removes deleted vectors at once or marks them for later clean-up, and schedule that clean-up. Let index snapshots and backups expire on a documented cycle. - **Tell processors.** Send erasure instructions to any service that holds a copy, as section 8(7) requires. - **Verify and record.** Search for the person's identifiers and confirm nothing comes back. Write the erasure to a ledger that holds an internal ID and a date, no personal fields. Erasure has a floor tooRule 8(3) requires every fiduciary to keep personal data, associated traffic data and processing logs for at least one year from processing, for the purposes in the Seventh Schedule. Remove the person from the live index, but keep the required logs restricted and out of retrieval. Our [data retention guide](https://dpdp.miravlabs.com/guides/dpdp-data-retention/) explains how the floor and the ceiling fit together. Training or fine-tuning a model on personal data makes this much harder, because there is no record to delete. For personal data we usually recommend retrieval over training, so the data stays in a store you can correct and erase. ## How do you stop one user retrieving another person's data? A knowledge assistant that ignores source permissions will, sooner or later, answer one employee's question with another employee's salary letter, or one customer's question with another customer's account. Unauthorised disclosure is a personal data breach under section 2(u), and every breach must be intimated to the Data Protection Board and to each affected person (section 8(6)), with a detailed report to the Board within 72 hours under Rule 7. See our [breach notification guide](https://dpdp.miravlabs.com/guides/dpdp-breach-notification/). Permission-aware retrieval is the control: - **Inherit access rules from the source.** Each chunk carries the groups, roles or customer account allowed to see its source. - **Filter before ranking.** The search applies the user's permissions as a filter, so chunks the user cannot see never reach the model. Telling the model in a prompt to withhold information is not an access control. - **Keep permissions in sync.** When someone leaves a team or a document is restricted, the index reflects it on the next sync, not the next rebuild. - **Separate tenants.** For customer-facing assistants, keep each customer's data in its own partition. - **Log access.** Record who asked, what was retrieved and from which sources, which gives you the Rule 6 visibility over access and the evidence for an investigation. We then test it the way an attacker would, with prompts designed to pull out data across permission boundaries. Our [AI red teaming](https://dpdp.miravlabs.com/services/ai-red-teaming/) service covers this in depth, and [AI governance](https://dpdp.miravlabs.com/services/ai-governance/) covers the policies around it. ## What you get Deliverables are owned and run by your team after the engagement. A typical scope looks like this: | Step | What we do with your team | What you keep | |---|---|---| | Find | Map the use case to sources, owners and personal data | Source inventory with in-scope and out-of-scope decisions | | Clean and label | De-duplicate, mark authoritative versions, tag personal fields | Cleaning jobs, personal data tags, purpose and basis per source (agreed with counsel) | | Govern | Set up the catalogue and access rules | Data catalogue with owner, sensitivity, purpose, retention and access per data set | | Index | Build the chunk, embed and index pipeline with metadata and masking | Ingestion pipeline, chunk metadata schema, masking rules, permission-aware retrieval | | Forget | Connect correction and erasure events to the index and caches | Delete-by-source job, cache purge, erasure ledger, test evidence | | Prove | Test retrieval across permission boundaries and run a sample erasure end to end | Test report, access logs, runbook for rights requests that reach AI systems | If your data or index runs on services outside India, we also map those transfers. No country has been restricted under section 16 so far, but sector rules can be stricter; see the [cross-border transfer guide](https://dpdp.miravlabs.com/guides/dpdp-cross-border-data-transfer/) and our [data localisation](https://dpdp.miravlabs.com/services/data-localisation-india/) service. For the wider erasure and consent plumbing across your other systems, see [DPDP privacy engineering](https://dpdp.miravlabs.com/services/dpdp-privacy-engineering/). ## How to start - **Pick one use case.** A support assistant, an internal policy search or a sales knowledge base. One is enough to set the pattern. - **List its sources.** Even a rough list of systems and owners lets us scope the work. - **Bring counsel in early.** Purpose and legal basis per source are decisions for your legal team; we give them the data map to decide on. - **Agree the erasure test.** Decide up front that the system is not done until a sample erasure passes end to end. We aim to leave you with a pipeline your team can extend to the next use case without us. To discuss your data and your first use case, [get in touch](https://dpdp.miravlabs.com/#contact), or see all our [services](https://dpdp.miravlabs.com/services/). ## Frequently asked questions ### What is AI-ready data? Data that an AI system can use safely and usefully: the right sources are known, the content is accurate and current, each data set has an owner and access rules, and personal data is tagged. For DPDP purposes it also means you can correct or erase a person's data everywhere it has been copied, including vector indexes. ### How do you delete personal data from a vector database? Store the source record ID with every chunk at ingestion. When the source record is erased, delete every chunk carrying that ID from the vector index, the keyword index and the chunk store, purge caches that reference it, and confirm that a search for the person returns nothing. Then record the erasure in a ledger that holds no personal fields. ### Are embeddings personal data under the DPDP Act? The Act defines personal data as any data about an individual who is identifiable by or in relation to it (section 2(t)). In our reading, an embedding of text about a person, stored with a link back to that text or that person, should be treated as personal data. Your legal counsel should confirm the position for your systems. ### Do we need fresh consent to put customer data into a RAG system? It depends on the purpose. Consent under section 6(1) is specific to a purpose and limited to the data needed for it, so a new use may need a new basis. Some uses may fall under a legitimate use in section 7. We map each source to its purpose and basis with your counsel before it is indexed. ### Does DPDP apply to an internal enterprise knowledge base? Yes, if it holds digital personal data, which most do: employee records, customer emails, support tickets, contracts with named signatories. Employment purposes are a legitimate use under section 7(i), but security safeguards, accuracy and erasure duties still apply to the knowledge base. ### What is a data catalogue and do we need one for AI? A data catalogue is an inventory of your data sets with their owner, location, sensitivity, purpose and access rules. For AI it is the list of what may and may not be indexed, and it is the starting point for answering a rights request across every copy.