Four AI modules are being built. None has shipped, and this page will not pretend otherwise while you are deciding.
The platform decides a great deal on its own. Every one of those decisions is a rule you can read, not a model you have to trust.
Ten weighted dimensions, penalties drawn from the Act’s own Schedule, and the three gaps that cost you most, ranked. The same answers from the same inputs, every time.
Your industry and a few facts about what you process select the templates that apply, and flag where §9 children’s provisions change the answer.
A grievance mentioning deletion is recognised as carrying an erasure right and routed as one, so it lands in the right queue rather than the polite one.
Naming an affected system derives the categories and the cohort from your registry, which is the hardest question of the first hour.
Every clock across every module — rights, breach, retention, expiring agreements — resolved into one queue, worst first, with nobody maintaining a spreadsheet of deadlines.
This is AI compliance automation in the sense that matters commercially — work that used to need a person no longer does. It is not a language model, and we would rather tell you that than let the word do work the software is not doing. Where AI compliance automation usually means a model answering, here it means a rule deciding and showing you which rule.
If you are named a Significant Data Fiduciary, algorithmic due diligence is not good practice. It is prescribed.
An SDF has to satisfy itself that algorithmic software it deploys to process personal data is not likely to put data principals’ rights at risk. Including software it bought.
“The tool decided” is not diligence. If a vendor cannot tell you what its system relied on, you cannot discharge the duty by buying it.
Rule 13 also requires a data protection impact assessment and an independent audit every twelve months. Both look at exactly this.
Which is the awkward position most AI compliance tools are in: sold to reduce your compliance burden, and adding one the moment you switch them on. It is also why these four modules are taking longer than they would if we only had to make them impressive.
Written as intentions rather than features, because not one of them is finished and you are entitled to know which is which.
Drafts a Rule 3 notice from the processing your registry already describes, in plain language and in the languages you serve. Your DPO edits and publishes it. How the drafter works
Reads the privacy policy and notices you already have and says where they fall short of the Act, naming the provision rather than the general shortfall. What it finds
Writes the plain-English summary that sits on top of an audit pack, so a board or a regulator meets a paragraph before they meet a manifest. What it writes
Answers “are we allowed to do this?” against your own configuration, and shows the clause and the record it relied on to say so. What it answers
DPDP documentation automation is the near-term prize here: notices, policies and audit summaries are the work that consumes a DPO’s week and follows patterns a model is genuinely good at. Judgement calls are not on that list, deliberately.
Four things a rule engine cannot do. Each is the argument its own page makes at length.
“We process patient data to improve our services.”
Four separate purposes, only two of them optional — because a bundle cannot be consented to under §6.
And two more judgements“We will provide your information in a commonly used electronic format so you can transfer it to another provider.”
A portability commitment the Act never required. The word “portability” never appears, so no keyword scan finds it.
And what else it readsDSR-2026-000026 · erasure · billing done · clinical HELD
“One deletion request could not be completed in full, because another law requires the clinical record to be kept. The patient was told why the same day.”
And the same row for an auditor“Can we send the camp invite to everyone who visited endocrinology last year?”
No, not to all of them — 1,204 accepted that purpose, the rest consented only to treatment. Cited to §6(1) and to your own notice.
And when it declines insteadNot because it could not produce an answer. Because someone has to be accountable for the answer, and it cannot be the software.
§6 consent or a §7 legitimate use is the most consequential call in the Act, and getting it wrong either way is expensive. It shows you what you set, and what follows.
Erasure is irreversible and often owed to nobody — another statute may require you to keep the record. Two named people approve it, and no model is either of them.
Rule 7 has no materiality threshold, so this is not a judgement about severity. It is a decision to start a clock, and a person makes it and is timestamped doing so.
A filing is a statement to a regulator by your organisation. It can be drafted from the record; it is signed by somebody who read it.
That already runs on a deterministic gate checking Rule 3 and §6 line by line. A generated draft goes through the same gate and earns no exemption from it.
A useful test for any tool in this category: ask which decisions it makes without a person, then ask who is answerable when one of them is wrong. If the answer is you, you have bought a liability with a subscription attached.
These are the reason it is slower, and the reason it will be defensible when it arrives.
Every output names the provision and the record behind it. An answer you cannot trace is an answer you cannot use in front of the Board, so producing one is not a partial success.
Drafting is automated. Publishing a notice, approving an erasure, filing to the Board and signing anything remain a named person’s act, recorded as theirs.
A model that answers everything is worse than one that declines, because you cannot tell the confident answers from the invented ones until it matters.
Your records are not used to train models, yours or anyone else’s. The registry is metadata-only for the same reason: what we do not hold cannot leak.
Including us. Every one of these has an answer that is easy to give and hard to give honestly.
Not the interface — one real output with the provision and record behind it. A citation generated alongside an answer can be wrong in exactly the way the answer is.
Ask them to show you a refusal. A system that has never declined a question in a demo is either being asked easy questions or does not decline, and the second is worse.
Then ask who is answerable when one of them is wrong. Automation that acts unattended on personal data transfers the work to the vendor and leaves the liability with you, which is rarely how it is sold.
Read the answer carefully. “We do not train our models on your data” leaves the model provider out of the sentence, and that is usually deliberate.
If personal data leaves India to reach a model, that is a transfer you have to be able to describe, and it belongs in your notice and your registry.
Rule 13 asks a Significant Data Fiduciary to have verified the algorithmic software it deploys. Ask what they will hand you to evidence that, and whether it exists yet.
Our own answers, for the record: nothing generative has shipped, so today the honest answer to most of these is “not applicable yet” — which is itself worth knowing when a competitor answers all six about a product they have.
Not when it demos well. Join the waitlist and you hear from us at the point it is doing something you could rely on — and the compliance suite it sits on is live today.
The platform automates a great deal — scoring, risk classification, template selection, request routing, breach scoping, deadline resolution — and all of it runs on deterministic rules rather than a language model. That is a deliberate choice, not a stage we have not reached: the same inputs give the same answer every time, which is what makes an outcome explainable to an auditor. The four generative modules are in build and every one of them is marked as such wherever it appears on this site.
Not by name, and be wary of anyone claiming otherwise. What it does is impose duties that bite when you deploy it. A Significant Data Fiduciary must observe due diligence to verify that algorithmic software it deploys for processing personal data is not likely to pose a risk to data principals’ rights, and must run a data protection impact assessment and an independent audit every twelve months. If your AI touches personal data, that is where your obligation sits.
For understanding the Act, genuinely yes, and we would rather say so. For running compliance, three things stop it: pasting personal data into a general model is itself a processing decision you would have to justify, nothing it produces is tied to your actual configuration, and none of it lands in a record you can show a regulator. The value here is not the drafting. It is that the draft is anchored to your systems and the act of approving it is recorded.
No. Your records are not training data for us or for anyone we build on. It is worth asking every vendor this and reading the answer carefully, because the common formulation — “we do not use your data to train our models” — leaves the model provider out of the sentence.
If you are a Significant Data Fiduciary, you owe a data protection impact assessment periodically regardless, and deploying algorithmic software on personal data is exactly the kind of change that belongs in one. If you are not an SDF there is no prescribed DPIA — but the diligence question does not disappear, it just has no form to fill in. Either way, the practical answer is the same: know what the tool decides, what it reads, and where the processing happens, before you switch it on.
The registry these modules read is metadata-only by design — system, table and column names, categories, owners, never values. That constraint was not built for the AI Suite, but it is what makes the AI Suite tractable: a drafter that works from the shape of your estate rather than its contents has far less to leak, and far less to justify. Where a module needs more than metadata, that will be stated on its own page rather than buried here.
Not decided, and we would rather say so than invent a packaging answer. What is settled is that the compliance suite does not depend on them: consent, rights, breach, vendors and the registry work today and will keep working whether or not you ever turn one of these on.
We are not giving you a date, because a date we later move is worse than not having given one. The waitlist exists so we can tell you when a module does something you could rely on rather than something that demonstrates well. Meanwhile the compliance suite these sit on top of is live and does not depend on any of them.
Real client quotes, attributed by role and sector — we never name a client.
Working across
Consent, rights, breach, vendors and the registry are working today and do not wait on any of this. Come and see those.
Thank you — we have it. Someone will reply by email, usually within one working day.
Nothing else is needed from you. If it is urgent, email tushar@ruleexpert.com and it will reach the same people.
RuleExpert