Sovereign AI and the Right to Erasure

A welfare department DPO in a state secretariat opened the week's grievance pile and found a letter that was not about a ration card. A resident wanted every trace of a complaint from 2024 removed. The complaint had been typed into the new assistant. The assistant had retrieved three older tickets, embedded the PDF the resident uploaded, and written a draft that an officer later approved. The DPO asked the vendor where the person now lived inside the system. The vendor sent a screenshot of the ticket marked closed.

That screenshot answered one store. It did not answer the vector index, the plan trace, the reviewer cache, the backup tape, the evaluation set a consultant copied to a laptop, or the LoRA the SI had trained in March because the model kept mixing two similarly named schemes. Each of those is a place personal data can still be related to a person. Each is a place Section 12 can land.

This is the field guide we walk with departmental DPOs before they promise a principal that they have been erased. It is not legal advice. It is the map of stores, not a sermon about machine unlearning. Indian law does not currently require you to rewrite a base weight file. It does require you to stop holding personal data you no longer have a basis to keep.

What Section 12 actually says

Section 12 of the Digital Personal Data Protection Act, 2023 gives a Data Principal the right to correction, completion, updating and erasure of personal data for processing they previously consented to, including certain consent referred to in Section 7. On an erasure request, the Data Fiduciary must erase the personal data unless retention is necessary for the specified purpose or for compliance with any law in force.

Three facts follow, and vendor decks usually hide at least one of them. First, erasure is of personal data, not of a product feature. Second, retention can be lawful. A statutory retention schedule, a pending prosecution, or an unfinished specified purpose is not a loophole a DPO invented. Third, the Act never uses the words unlearning, weights, or gradient. If someone tells a committee that DPDP now requires certified machine unlearning, they are reading a research paper into a statute.

Operational duties under the 2025 Rules are phased. MeitY notified the Act and the Rules on 13 November 2025. The Board stood up immediately. Consent-manager provisions apply from 13 November 2026. Most remaining operational duties apply from 13 May 2027. Until then the IT Act and the 2011 SPDI Rules are still live. Designing the erasure map now is how you avoid writing it under a Board query later.

Stores you can address, and stores you should stop creating

An agent does not live in one table. It writes as it works. The erasure file is a list of those writes, not a philosophy of neural nets. Start with stores a competent operator can actually delete or isolate.

Erasure is a store-by-store job. A single closed-ticket screenshot is not a certificate.

Store	Typical content	Erasure action that is honest
Case or ticket database	The complaint, identifiers, officer notes	Delete or legally redact; record the legal hold if any
Object store / uploaded files	PDFs, images, voice notes the principal sent	Delete object and thumbnails; confirm CDN and backup copies
Vector index	Embeddings of the ticket, PDF chunks, similar-case hits	Delete vectors keyed to the principal or document IDs; rebuild only if the index cannot delete by ID
Plan traces and tool logs	Thoughts, retrieved chunks, tool payloads	Purge by conversation or principal ID; check APM copies
Reviewer and eval caches	Screenshots, golden sets, failed-answer dumps	Search by identifier; quarantine consultant laptops
Fine-tune or adapter set	Rows that still contain the person	Remove the rows; decide whether the adapter must be retired
Public base checkpoint	Pre-training you never ran	Do not pretend you erased it; do not put new personal data into it

The last row is where sales conversations go to die. A public checkpoint trained on an internet crawl is not a store you operate. You cannot honestly certify that a person has been removed from it. You can honestly certify that you will not keep their record in any store you do operate, and that you will not use their record to train or evaluate a further model.

Fine-tunes and adapters sit in the middle. If the training set still exists, delete the rows and decide whether the resulting weight file is still a reasonable way to serve the specified purpose. Sometimes retiring the adapter is the clean action. Sometimes the set was already aggregated and the person is not identifiable in the file. Write which of those is true. Do not write we unlearned the citizen unless you actually ran a documented process and can show the before-and-after set.

Why agents make erasure harder than a 2011 form

A 2011 web form wrote to a database and a log. An agent retrieves, embeds, plans, calls tools, and sometimes writes memory. The principal's data is copied into contexts the notice never named. Similar-case retrieval is the quiet one. The resident asked about their own file. The model pulled a neighbour's file because the embeddings were close. That neighbour is now inside a trace they never consented to enter.

Tool calls are the loud one. A search against the scheme database, a write to the CRM, a call to a translation API, a fallback to a hosted model when the local GPU timed out — each call can persist a payload. If the translation API keeps text for abuse review, your erasure process now includes a processor you may not have listed.

Memory features are the new one. Product managers love a thread that remembers the last visit. DPOs should treat long-term memory as a personal-data store with a retention clock. If the product cannot delete memory by principal, it is not ready for a Section 12 workflow.

Objections you will hear, and how to answer them

The first objection is technical theatre. We cannot erase because the model has generalised. Answer: then show the stores that are not the model. If those stores still hold the person, the objection is a stall.

The second is legal overclaim. Unlearning is now mandatory under global best practice. Answer: cite Section 12 as written. Foreign guidance on GDPR Article 17 is interesting comparative reading. It is not Indian law. If counsel wants a stricter internal standard, write it as policy, not as a misquote of the Act.

The third is operational despair. We have thirty-seven systems. Answer: that is why the map exists. You do not erase thirty-seven systems on the first request. You erase the systems this workflow actually wrote to, which is why every agent launch needs a write-set list before it sees a live record.

The fourth is vendor fog. Our platform is DPDP ready, erasure is on the roadmap. Answer: a roadmap is not a control. Ask for the API or the runbook that deletes by principal ID today. If it does not exist, the platform is not ready for production personal data.

Joint fiduciaries and the second copy

A state resident desk that routes into three departments will leave copies. The erasure certificate that names only the desk is incomplete. Before you promise a principal that they have vanished, ask which bodies received a derived record: a retrieved chunk, a forwarded draft, a screenshot in another officer’s mail. Those bodies may be joint fiduciaries or they may be separate. Either way, the request has to travel.

Write the travel path in peacetime. A letter that arrives at the wrong desk and dies in a pile is not a Section 12 process. Name a coordinator. Give them the write-set lists. Time the hop. If a department cannot delete its own vector index, the coordinator’s job is to record that failure, not to hide it in a polite closing email.

Processors who keep a safety copy need the same hop. If the DPA recast safety logs as the vendor’s own fiduciary processing, you already have a problem the erasure article cannot solve. Fix the DPA. Then add the store to the certificate.

A 90-day playbook that survives the first real request

1. Days 1–10: pick one live or soon-to-be-live agent. List every write it performs, including embeddings, traces, backups and human review copies.
2. Days 11–25: for each write, name the owner, the retention rule, the delete path, and whether another law forces a hold.
3. Days 26–45: run a tabletop on a fictional principal. Time how long each store takes. Record the stores that have no delete path.
4. Days 46–65: close the gaps or disconnect the agent from those stores. Ban production-to-eval copies without a scrub.
5. Days 66–80: put the store list and the certificate template into the processor contract. Require a deletion report that names backups.
6. Days 81–90: process one real, low-risk request end to end. File the certificate. Brief the grievance officer on what you will and will not claim.

What goes in the file

• The write-set list for each agent workflow, signed by the technical owner.
• The retention and hold table, with the statute or schedule cited in the hold column.
• The deletion-certificate template that names stores, dates and remaining holds.
• The processor clause that forbids training and requires delete-by-principal.
• The tabletop record, including the stores that failed and the date they were fixed.
• A one-paragraph statement that you do not certify unlearning of public base weights.

If those six items exist, a Section 12 request is work. If they do not, it is an incident. Prcept AI is designed so logs, embeddings and traces stay in stores you can address, and so we do not train on your records. Demand the write-set list from us the same way you demand it from anyone else.

This article is an operational map, not legal advice. Counsel should apply Section 12 and any sector retention law to the specific workflow before a certificate goes out.