The single fastest way to lose a regulated buyer is to cite a regulation incorrectly to the
one person in the room who has read it. Several instruments commonly invoked by AI vendors
in this market are not in force, and one of the most frequently asserted requirements does
not exist at all.
So this article does two things: it states what the DPDP framework actually requires of an
AI system, and it corrects three claims you will hear repeatedly — including two that
would flatter our own position if they were true.
The dated fact
The DPDP Act's substantive obligations commence on 13 May 2027.
The Act was enacted in August 2023. The DPDP Rules 2025 were notified on 13 November 2025
and gazetted the following day, with a phased commencement: the Data Protection Board
constituted immediately, consent manager provisions from 13 November 2026, and the
substantive duties from 13 May 2027.
The significance for an AI transformation programme is scheduling,
not fear. An organisation procuring AI infrastructure in 2026 is choosing the architecture
it will be audited on, before the audit regime exists. Systems bought now will still be
running then, and retrofitting evidence capability into a system that was not designed to
produce it costs more than designing it in.
What Rule 6 actually requires
Rule 6 of the DPDP Rules 2025 sets out reasonable security safeguards. Read as an
engineering specification rather than a legal one, it asks for:
- Encryption and masking of personal data
- Access control
- Access logging and monitoring
- Backups
- Retention of access logs for at least one year
And separately, breach reporting within 72 hours, with no materiality threshold —
every personal-data breach is reportable, not only the significant ones.
Three of those bear directly on how an AI system is built.
Access logging over retrieval. A retrieval system reads personal data on every query.
If your architecture cannot say who asked, what was retrieved and what was returned, it
cannot produce the log this rule contemplates. Bolting logging on afterwards usually means
logging the request but not the retrieved context — which is the part that matters.
One year of retention. This is a storage and lifecycle requirement, and it means the
log has to be tamper-evident to be worth anything. A log an administrator can quietly edit
is not evidence.
No materiality threshold on breach reporting. You cannot report what you cannot detect.
A 72-hour clock with no lower bound means detection has to be systematic rather than
incidental.
The three corrections
These are worth publishing precisely because two of them weaken arguments that vendors —
including on-premise vendors — like to make.
1. DPDP does not require your data to stay in India.
Section 16 operates as a restriction list, not a general prohibition: cross-border
transfer is permitted except to territories the Central Government notifies otherwise. Any
material claiming "DPDP requires data residency" is simply wrong.
Hard localisation for Indian financial data comes from the RBI, not from DPDP. The
Storage of Payment System Data circular of 6 April 2018 requires end-to-end payment
transaction data to be stored only in India, with the foreign leg of a transaction
permitted to be stored abroad as well.
This correction removes a convenient argument for on-premise deployment. It should be
removed anyway, because a data protection officer will catch it and everything else you
said becomes suspect.
2. DISHA imposes no obligation on anyone.
DISHA was proposed by the health ministry in 2017, redrafted in 2022, and never
enacted. It is a draft bill. It creates no duty and cannot be cited as a compliance
driver — at most as direction of travel.
What actually governs Indian digital health data today is the DPDP Act read with the DPDP
Rules 2025, plus the ABDM Health Data Management Policy for participants in that ecosystem
— a policy of the National Health Authority, revised April 2022, which relies on the IT Act
2000 and DPDP for legal force and which specifies a federated architecture where records
stay with the creating facility rather than a central store.
3. HIPAA does not yet mandate encryption or MFA.
The HIPAA Security Rule in its current form has required and addressable implementation
specifications, a Business Associate Agreement with any vendor touching ePHI, and audit
controls. Encryption at rest and in transit, and multi-factor authentication for ePHI
access, are proposals in the NPRM published in the Federal Register on 6 January 2025 —
comment period closed 7 March 2025, with a final rule indicated around July 2027. They are
not current law.
Saying otherwise misrepresents the rule in the direction that flatters the vendor, which is
the worst direction to get it wrong in.
What survives, and why it is the stronger argument
Strip out the overstatements and two obligations remain that are unambiguous, in force
today, and structural rather than contractual.
RBI's payment-data localisation, which no contractual assurance can satisfy. And
relatedly, the RBI Master Direction on Outsourcing of IT Services, effective 1 October
2023: outsourcing agreements must address data localisation and must preserve the regulated
entity's and the RBI's access and audit rights. A cloud AI API used on regulated data is
an IT outsourcing arrangement. That is not an interpretation; it is what the direction
covers.
DPDP Rule 6's evidence duties — a year of access logs, breach reporting at 72 hours
with no materiality threshold.
That second one is the argument, and it is worth stating precisely:
Rule 6 is an evidence obligation. You cannot discharge it with a vendor's promise.
You discharge it with a record.
This is the case for architecture over assurance. A system where every request passes
through a fixed path — privacy filter, injection scanner, model, output validator, audit
chain, with no bypass — produces that record as a by-product of running. A system that
calls an external API produces a record of the call, not of what happened to the data
afterwards.
The architectural implications, concretely
If you are specifying an AI system in 2026 with 2027 in view:
- Require a per-decision audit record, covering the retrieved context, not just the
request. Ask to see one. - Require tamper-evidence on that record — a hash chain, not an append-only promise.
- Require the failure mode to be refusal. In a fail-closed on-premise mode, a
misconfiguration cannot silently transmit data because the system stops instead. - Require permission inheritance from source systems into the retrieval index. A
system that surfaces documents a user could not otherwise open has created a breach
under Rule 6's access-control expectations, and it will not be noticed in testing. - Ask where the boundary is enforced — in code, or in a configuration file someone can
change.
None of that requires the regulation to be exaggerated. The real obligations are demanding
enough, and they are dated.
Next: Shadow AI in Indian enterprises
· AI transformation in regulated sectors
