A team stands up an AI tool, someone remembers it needs to go in the Record of Processing Activities, the entry gets written, and the box is ticked. The processing is documented. Except, for an AI tool of any real consequence, it usually is not - not fully.
The RoPA is the first document GDPR asks for, not the only one. The gap between "we have a RoPA entry" and "we have documented this processing" is where a lot of AI compliance quietly falls short.
The RoPA answers one question: what are we doing with personal data. AI processing tends to raise three more, each with its own document.
The RoPA is necessary, not sufficient
There is nothing wrong with starting at the RoPA. It is the foundational record, and an AI tool absolutely needs an entry in it.
The mistake is treating the entry as the finish line.
The RoPA is a register - it describes each processing activity in standard terms: purpose, data categories, recipients, retention. What it does not do is assess whether the processing is safe, justified or fair. It records that you are doing something; it does not establish that you are allowed to, or that you have thought about the harm it could cause.
For low-risk processing that is fine, because the register is genuinely the whole story. For AI making decisions about people, it is the opening chapter.
So the question is not "is this in the RoPA" but "which of the other documents does this processing also require" - and for AI, the answer is usually more than one.
The DPIA: is it safe to do this at all
The second document is the Data Protection Impact Assessment, and for AI it is the one most often owed and least often produced.
Under Article 35, a DPIA is required where processing is likely to result in a high risk to people's rights and freedoms.
AI processing frequently clears that bar: automated decisions, profiling, large-scale data, novel technology - several of the recognised high-risk signals describe ordinary AI deployments. In practice, for an AI tool making or materially influencing decisions with significant effects on individuals, the safer assumption is that a DPIA is required, not that it is optional.
Lower-stakes AI - a tool that only speeds up work a person still fully controls, may not reach the threshold. That is exactly the judgement the DPIA question forces you to make rather than skip.
And a DPIA is not a lighter version of the RoPA entry. It has its own required content: a systematic description of the processing, an assessment of necessity and proportionality, an analysis of the risks to data subjects, and the measures taken to mitigate them.
For an AI system that description has to go further than a register line - the model, the data flow from input to output, what happens to prompts and responses, and what the output is then used for. The RoPA says the tool exists; the DPIA says why it is defensible to run it.
Transparency: have we told the people affected
The third document is the one aimed outward, at the people whose data is processed.
GDPR requires that individuals be informed about how their data is used - the purposes, the lawful basis, the recipients, their rights.
For an AI tool this is easy to overlook, because the processing often happens behind an existing interface, a customer never sees the model that scored their application or the assistant that summarised their file. The obligation does not disappear because the AI is invisible to the person; if anything, invisibility makes the transparency duty more important, not less.
Where the AI makes automated decisions with legal or similarly significant effects, the transparency duty sharpens further, into an obligation to give meaningful information about the logic involved. A RoPA entry does none of this outward-facing work. It is an internal record; transparency is a separate, public-facing obligation that the internal record does not satisfy.
The lawful-basis assessment: are we actually allowed
The fourth document is the one that decides whether any of the rest is even permitted.
Every processing activity needs a lawful basis, and where an organisation relies on legitimate interests, it has to be able to show the balancing exercise behind that choice, the legitimate-interests assessment.
For AI this is rarely trivial. The interests being pursued, the necessity of using AI to pursue them, and the impact on the individual all have to be weighed and recorded. A RoPA entry names the lawful basis in a word or two; the assessment behind that word is a separate piece of documentation, and for AI it is frequently the hardest to do honestly.
Put the four together and the shape is clear. The RoPA says what you do; the DPIA says whether it is safe; the transparency information says whether you have told people; the lawful-basis assessment says whether you are allowed. A team that produced only the first has documented the least demanding of the four - and, understandably, believes it is finished.
The part that makes AI harder: none of it stays still
There is one more twist that hits AI specifically. These documents are not write-once artefacts. A DPIA in particular is a living assessment, it has to be revisited when the processing changes, and AI processing changes constantly.
A model retrained on new data, repurposed for a new decision, or upgraded to a new version is not the processing the original documents described. The paperwork that was accurate at launch quietly stops matching the system.
This is the maintenance burden the RoPA-only view never sees coming. It is not four documents produced once; it is four documents kept in step with a system that keeps moving.
The organisations that struggle are not the ones that never documented their AI. It is the ones that documented it once, at the start, and assumed the record would stay true.
I will be straight about what this does and does not settle. Knowing which documents are owed is the easy part; producing them well is skilled work, and keeping them current as the AI changes is harder still. No tool removes the judgement in a DPIA or a balancing test.
What is achievable is knowing the full set is owed in the first place, and keeping the four in step as the system moves - which is the work Montro is built around: not just the record, but whether the documentation behind each AI tool is complete and current. The RoPA entry is the start of that, not the whole of it.
Frequently asked questions
Is a RoPA entry enough to document an AI tool under GDPR?
Montro's position is that it usually is not. The RoPA records that an activity exists and its basic parameters, but AI processing frequently also requires a Data Protection Impact Assessment, transparency information for the people affected, and a documented lawful-basis assessment.
Treating the RoPA entry as the whole documentation obligation is one of the more common gaps in AI compliance, because the register looks complete while the assessments behind it are missing.
When does an AI tool need a DPIA?
Under Article 35, a DPIA is required when processing is likely to result in a high risk to individuals' rights and freedoms, and AI often meets that threshold, through automated decision-making, profiling, large-scale processing or the use of novel technology.
Regulators including the CNIL treat a DPIA as presumed necessary for high-risk AI systems processing personal data, so for an AI tool making or supporting decisions about people, the safer assumption is that a DPIA is owed.
What GDPR documents does an AI tool need besides the RoPA?
Typically three more: a DPIA assessing the risk of the processing; transparency information telling data subjects how their data is used, including meaningful information about automated decisions where they apply; and a lawful-basis assessment, such as a legitimate-interests assessment where the organisation relies on that basis. Each answers a different question the RoPA does not - whether the processing is safe, whether people have been told, and whether it is permitted at all.
Do AI compliance documents need to be updated?
Yes, and this matters more for AI than for static systems. A DPIA is a living document that must be revisited when the processing changes, and AI changes often - retraining, repurposing and version upgrades can all alter the processing of the documents originally described.
Documentation produced once at launch and never revisited stops reflecting the system, which means it stops demonstrating compliance.
