Regulators rarely give you a rehearsal. Most data-protection regimes arrive as a wall of obligations and a deadline, leaving operators to reverse-engineer compliance from enforcement actions. So when one jurisdiction publishes concrete, dated rules on how AI must be disclosed and how complaints must be handled, it is worth reading closely — even if you have no customers there.
That is the situation Indian founders, marketers, and operators find themselves in with the United Kingdom’s incoming data rules. They are not binding in India. But they are a remarkably legible draft of the disclosure-and-accountability logic that India’s Digital Personal Data Protection (DPDP) framework is building toward. Treat the UK timeline as a free dress rehearsal, and you buy yourself months of lead time.
What changed in the UK
According to Techerati’s reading of the legislation, from 19 June 2026 the UK’s Data (Use and Access) Act 2025 will require organisations to operate a formal complaints process and to meet higher transparency expectations whenever AI processes personal data — and crucially, this applies regardless of size or sector. (Operators should verify the specifics against the UK ICO and the legislation itself before acting.)
Three features of this rule matter more than the date. First, the transparency expectation is aimed squarely at AI. Privacy notices can no longer bury automated decision-making and model-driven processing in legalese; organisations are expected to explain, in language an ordinary person can understand, how AI touches their data. Techerati notes the rules build on existing UK GDPR transparency and fairness obligations — Articles 5(1)(a), 12-15, and 22 — which cover lawful and fair processing, the right to information, access rights, and protections around automated decisions.
Second, the complaints process becomes mandatory and formal. It is no longer enough to have a support inbox that occasionally fields a data question. Organisations must stand up a defined route for individuals to raise concerns, with a process behind it.
Third — and this is the part that should reset assumptions — there is no exemption by size or sector. A two-person agency running a chatbot on customer data carries the same baseline obligation to explain and to handle complaints as a bank. The era of “we’re too small to worry about this” is closing.
Why it’s a preview for India
None of this is UK exceptionalism. It is the direction of travel for modern data law, and India’s DPDP framework sits firmly on the same road. DPDP is built on consent, notice, and accountability — the same trinity the UK rules are now operationalising for AI. Where DPDP requires a clear notice describing what personal data is collected and why, the UK is showing what “clear” has to mean once AI is in the loop: not a disclosure a lawyer can defend, but one a customer can actually parse.
Plain-language disclosure is the shared theme. DPDP’s notice requirements and its emphasis on informed consent point in exactly the same direction as the UK’s transparency push — away from dense, defensive privacy policies and toward explanations a non-specialist can read and understand. An Indian operator who learns to explain their AI plainly for a hypothetical UK standard is, in practice, building the muscle DPDP compliance will demand.
Then there is the strategic argument: compliance as a moat. It is tempting to treat all of this as cost. But disclosure done well is a trust signal, and trust is increasingly the scarce resource in AI-mediated business. The firms that can tell a customer — clearly, without flinching — how their data trains a model, feeds a recommendation, or informs a decision will win the customers who have learned to be suspicious. The ones who treat transparency as a box to tick will keep paying for it in churn and complaints. Early movers convert a regulatory floor into a competitive edge.
Where AI use hides
The hardest part of any AI-disclosure obligation is not writing the disclosure. It is knowing what to disclose. AI has crept into business operations through dozens of side doors, and most organisations cannot produce an accurate inventory of where it lives.
Start by mapping AI across the business, not just in the obvious product features. The model-driven lead scoring in your CRM is AI. The chatbot on the support page is AI. The resume-screening tool in your hiring stack, the fraud-detection layer in your payments flow, the ad-optimisation algorithms inside the platforms you buy from, the email tool that decides send times, the analytics suite that segments your audience — all of it can involve automated processing of personal data. Much of it was switched on by a vendor default that no one logged.
For each touchpoint, ask what personal data those systems actually consume. A recommendation engine might touch browsing history and purchase records. A support bot might ingest names, order details, and whatever a frustrated customer typed into the chat. A screening tool processes the most sensitive category of all — information about identifiable job applicants. The exercise of tracing data into each system is where most teams discover they were processing more, and more sensitively, than they assumed.
Then comes the genuinely difficult skill: explaining it to non-specialists. The UK rules — and DPDP’s notice obligations — are not satisfied by accurate-but-impenetrable text. “We use machine-learning algorithms to optimise user experience” tells a customer nothing. “We use your past orders to suggest products you might like, and you can turn this off here” tells them something true and useful. The translation from engineering reality to plain English (or plain Hindi, Tamil, or Bengali) is the work, and it is best done before a regulator or an angry customer forces it.
A readiness checklist
You do not need to wait for an Indian enforcement deadline to start. Three concrete moves put you ahead of both the UK timeline and DPDP’s eventual demands.
- Inventory your AI touchpoints. Build a living register of every system — first-party or vendor — that uses automated processing on personal data. For each, record what data it touches, what it does with it, who the vendor is, and whether it makes or informs decisions about individuals. This single document is the foundation for everything else, and it doubles as your DPDP processing record.
- Draft plain-language disclosures. For each material AI touchpoint, write a short, honest explanation a non-specialist would understand: what the system does, what data it uses, what choice the individual has. Test it on someone outside your team. If they can’t explain it back to you, it isn’t plain enough. Fold these into your privacy notice rather than appending a separate, unread annexe.
- Stand up a complaints process before you’re forced to. Define a clear channel for data and AI complaints, name an owner, set a response timeline, and log what comes in. Even a lightweight version — a dedicated address, a tracked queue, a documented escalation path — puts you ahead of the field. A complaints log is also an early-warning system: patterns in what people object to will tell you where your disclosures are failing before a regulator does.
The instinct will be to file this under “foreign regulation, not our problem yet.” That instinct is expensive. The UK has effectively published a working specification for the transparency-and-accountability regime that DPDP is converging on, complete with a date. Operators who build to that specification now will meet India’s requirements as a by-product — and, more importantly, will have learned to talk to their customers about AI honestly while their competitors are still drafting evasive boilerplate. In a market growing more wary of automated systems by the month, that honesty is the moat.
