There is a tidy assumption behind a lot of data-protection record-keeping: a tool is a tool, and once you have logged what data it holds, you have done the job. Add the vendor, the data categories, the retention, move to the next row. It works well for SaaS. It quietly fails for AI, because two tools can hold exactly the same personal data and owe completely different things to the people that data belongs to.
The difference is not what the tool stores. It is what the tool does.
The same data, a different act
Picture two tools in a lending business, both working from the same customer records. One is a CRM - it stores the customer's details, their contact history, their account status. The other is an AI model that reads those same details and scores each customer's creditworthiness.
To a records exercise that logs data categories, these look similar: same customers, same financial data, same retention. But under GDPR they are not doing the same thing. The CRM holds data. The AI makes an assessment about a person from it, and the moment a tool starts making or feeding decisions about people, a set of obligations switches on that never applied to the tool that merely stored the same information.
This is the distinction a flat record misses. It captures what data a tool holds and stays silent on what the tool does with it - which, for AI, is exactly where the obligations live.
Article 22: the obligation SaaS never triggers
The clearest example is automated decision-making. Under Article 22, a person has the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects.
A credit refusal, an insurance decision, a recruitment screen-out, these are the kinds of decision it governs.
A SaaS tool storing customer data does not engage Article 22. An AI tool scoring those same customers to drive a decision can. That single difference pulls in a chain of further obligations the SaaS entry never had to think about: a lawful basis specific to automated decisions, information to the affected person, and in many cases a mandatory impact assessment.
The record for the AI tool has to carry all of that. The record for the CRM does not.
So two entries that look alike in a flat inventory are, in obligation terms, nothing alike. One is a storage activity. The other is a decision activity, and GDPR treats decision activities about people far more seriously.
The human-in-the-loop trap
There is a common belief that Article 22 is easy to sidestep: put a person in the loop, have them approve the AI's output, and the decision is no longer "solely" automated. It is not that simple, and the record should not assume it is.
European courts have taken a broad view. Where an AI produces a score or a recommendation that a human then signs off, but the human's decision is in practice decisively driven by the machine's output, the automated step can still fall under Article 22.
A rubber-stamp is not meaningful human involvement.
This matters for records because it changes what an honest entry says. "There's a human in the loop, so Article 22 doesn't apply" is a conclusion, not a fact, and often the wrong conclusion. The record has to reflect how the decision is actually made, not how the org chart says it is made - which is a question a SaaS entry never has to answer.
Inference: the special-category problem SaaS doesn't create
The second place AI diverges is subtler and, for records, easy to miss entirely. GDPR gives special protection to certain categories of data - health, ethnicity, sexual orientation, and others.
A SaaS tool holding ordinary data does not create special-category exposure unless it actually stores special-category data.
An AI tool can create that exposure without anyone entering a single special-category field, because it can infer protected characteristics from mundane inputs - buying patterns, location, the shape of someone's behaviour. Regulators have read this widely; enough ordinary signal can amount to an inference about health or sexuality. The tool never stored the sensitive attribute; it derived it. And a derived special category counts.
For the record this is a genuinely new question. It is not "does this tool hold special-category data", the SaaS question - but "could this tool infer it", which a flat inventory has no column for and a SaaS-shaped process was never built to catch.
What this means for the record
Put together, the point is not that AI tools need to be in the record and SaaS tools do not. They both do. The point is that an AI entry and a SaaS entry are different kinds of entry, and a record that treats them the same is inaccurate about the AI even when every field is filled in.
An accurate record for an AI tool has to capture what the tool does, not only what it holds: whether it makes or materially drives decisions about people, whether those decisions have significant effects, whether a human is genuinely in the loop or nominally so, and whether the tool could infer protected characteristics from what it processes. None of those columns exist in a SaaS-shaped inventory, because SaaS never raised the questions.
I keep coming back to this because it is the failure I find most often: not a missing tool, but a present tool recorded as if it were something simpler than it is.
The AI is in the record. The record just describes a filing cabinet where there is actually a decision-maker.
From SaaS-shaped record to AI-aware one
The fix is not more rows. It is a record that asks the right questions of the AI tools already in it.
That means going back through the AI entries and asking, for each, the questions a SaaS process never posed: what decision does this feed, with what effect, under what human involvement, with what risk of inference. Some entries will turn out to be simple after all, an AI feature that genuinely only summarises internal text may carry little more than a SaaS tool would.
Others will turn out to be Article 22 decision systems wearing the disguise of an ordinary app, and those need the fuller treatment: the lawful basis, the transparency, the impact assessment.
I will be straight about the limit. Sorting which AI entries are simple and which are decision systems is judgement, not a lookup - it depends on how the tool is actually used, which changes, and which no field auto-populates.
What is achievable is asking the question at all, of every AI tool, rather than letting the SaaS habit answer it by default. The record becomes accurate when it stops assuming an AI tool is just another app and starts accounting for what each one actually does.
Frequently asked questions
Do AI tools and SaaS tools need different GDPR records?
Montro's position is that they need records that ask different questions. Both belong in the Record of Processing Activities, but an AI tool that makes or feeds decisions about people engages obligations a SaaS tool storing the same data does not - automated-decision rules, profiling, and the possibility of inferring protected characteristics.
A record that logs both in identical terms is accurate about the SaaS tool and incomplete about the AI one.
Why does an AI tool trigger GDPR obligations that a SaaS tool doesn't?
Because the obligations attach to what a tool does, not only what it holds. A SaaS application storing customer data is a storage activity; an AI tool scoring those customers to drive a decision is a decision activity, which can engage Article 22's automated-decision rules, mandatory impact assessment, and specific transparency duties.
The same underlying data, put to a different use, produces a different obligation set.
Does having a human approve an AI decision avoid Article 22?
Not automatically. If the human's approval is in practice decisively driven by the AI's output, a rubber-stamp rather than a genuine independent decision, the processing can still fall under Article 22.
For records, this means "a human signs off" is not enough on its own to conclude Article 22 does not apply; the entry has to reflect how the decision is really made.
Can an AI tool create special-category data risk without storing sensitive data?
Yes. An AI tool can infer protected characteristics - such as health, from ordinary inputs like behaviour or location, and a derived special category can bring the processing within the GDPR's special-category rules.
A SaaS tool holding the same ordinary data creates no such exposure unless it actually stores sensitive data, which is why the record has to ask whether an AI tool could infer it.
