AI in Data Protection: A Draft, Not a Verdict

How it works today in most organizations

Two extremes have taken hold in AI and data protection documentation. Both are understandable, and both produce the same problem: nobody can say where a piece of information came from.

The first extreme: AI is prohibited. An internal rule rules out generative models for internal documents. So every processing activity, every data protection impact assessment and every privacy policy is created by hand. Rarely truly by hand, though. Almost always the nearest similar document is opened, saved under a new name – "DPIA_Applicant_Management_new.docx" – and half adapted. Purpose and title are overwritten, the categories of recipients stay, the retention period is overlooked. A detail entered incorrectly four years ago travels on through a dozen documents. The mistake is not the manual work, it is that copying counts as diligence.

The second extreme: the public chatbot. Under time pressure, people have the text they need generated. The request reads "Write me a processing activity for our applicant management", the result is read, considered plausible and copied into the document. That is where the damage begins. The file now holds a paragraph: nobody can say with which input it was generated, which in-house details it rested on, which model answered, or whether anyone reviewed it afterwards. The wording is clean, the structure complete, the origin gone.

In both cases the workflow is the same. The text is created at one person's desk, goes by email to the shared data protection mailbox, is filed into the folder "Data protection/Documentation/2026" and counts as done. A follow-up question from a business unit is usually answered by that same person, because only they know the document.

Neither stands out in day-to-day work. Both texts look like documentation.

The moment it becomes apparent

It becomes apparent during a review, at a very specific point: somebody asks what a risk assessment is based on. Why was this risk classified as manageable? Which technical and organizational measures does the assessment rest on? Who decided that, and when?

There are only two answers. Either an audit trail exists – linked objects, a log entry, an approved revision with a date and a person. Or a well-worded paragraph exists that could come from a 2019 template as easily as from a chat window the week before last. The second answer is the more expensive one, whether or not the content happened to be correct.

The target process in six steps

The difference between usable and risky use of AI lies not in the model but in the workflow around it. These six steps describe it.

1. Work section by section, not document by document. The AI supplements and revises individual sections – in processing activities, processing activities on behalf, privacy policies, information obligations, security measures and policies, in the transfer impact assessment (TIA) and the data protection impact assessment (DPIA). Generating a whole document in one go shifts the review to a moment when nobody performs it.

2. Point the AI at your own objects. A suggestion is only as good as its basis. For the DPIA suggestions – the necessity assessment under Art. 35(1) GDPR, the structured risk catalog and the matching countermeasures – the basis is the linked processing activities, processing agreements and technical and organizational measures (TOMs). Without that link, the draft invents it.

3. Review suggestions in a preview and select them individually. Importing an existing set of records and deriving new processing activities from a task description both create a preview first. There you select what is adopted – and what is not. A blanket "adopt everything" is where the process tips over.

4. Adopt as a draft, approve only after a review in substance. Adopted suggestions are drafts, and the review belongs before approval, not after. That is not merely attitude: approval automatically creates a revision, which freezes exactly the state reviewed. Approving first and reading afterwards freezes an unreviewed state.

5. Treat legal assessments explicitly as a neutral draft. In the TIA the assessment of the legal situation in the third country is deliberately worded as a neutral draft for your own review. The necessity assessment under Art. 35(1) GDPR deserves the same treatment. Both need the controller's judgment in substance, not a confirmation.

6. Match the generation mode to the task. It can be selected: automatic, deterministic or reasoning in levels. For consistent wording across many documents, deterministic is the better choice. For risk catalogs a higher reasoning level is worthwhile – it delivers more considered content and takes longer.

How to spot a draft you must not adopt

Four patterns are enough. First: invented categories of recipients – a service provider or body is named that does not exist in the organization or never receives this data. Second: retention periods with no basis – a period is stated, but neither a commercial or tax retention obligation nor an internal rule supports it. Third: legal bases that do not fit the purpose – consent where a contract is actually performed, or a legitimate interest without the associated balancing test. Fourth: measures that do not exist in the organization – the draft names an encryption, a logging mechanism or a role concept implemented nowhere. The fourth case is the most dangerous: a measure in a document is a commitment.

Before and after in direct comparison

What the switch means in practice

The switch is not a technology project. The AI functions are optional and activated per team; the actual work lies in deciding once who reviews which draft and where that review ends. Experience suggests that is one meeting, not one quarter.

What changes in day-to-day work is the order. Until now writing was the effort and the review the remainder. Now the draft is there quickly and the review is the actual work – the difference being that it looks at something concrete instead of an empty form. Anyone who does not go along with that shift and books the time gained as a saving has accelerated the documentation and degraded its quality.

Three mistakes that make the use of AI unnecessarily risky

Treating the draft as a result. A suggestion that has not been contradicted has not been reviewed. Approval must remain a deliberate decision in substance, so the automatic revision freezes a state that holds up.

Starting without links. Anyone who sets the AI on processing activities without linked systems, processing agreements and TOMs gets generic text and is surprised at its vagueness. Only the links make suggestions specific.

Leaving the review with one person. If the data protection officer alone reviews every draft, a bottleneck arises that leads to exactly the rubber-stamping it was meant to avoid. The review in substance belongs in the unit doing the processing.

One special case is worth clarifying up front: anyone already using a public chatbot should not have to hide it. Using AI inside the tool is the regulated alternative, not its prohibition – with a log, a preview and an approval where previously there was only a copied paragraph.

How to tell that it is time

• Your documentation is created mainly by copying older documents.
• Your files contain wording whose origin nobody can name.
• Individual people already use a public chatbot without any rules for it.
• You cannot show what a risk assessment rests on.
• The first version of a document takes you longer than reviewing it.