Record of processing activities for AI: what belongs in it

Does AI have to go into the record of processing activities?

Yes, as soon as the AI processes personal data. Art. 30(1) GDPR obliges every controller to document all processing activities. An AI platform is not a purpose in itself but a tool: what you enter is what you use it for. The exemption for organisations with fewer than 250 employees (Art. 30(5)) rarely applies to AI in daily work, because the use is not only occasional and often involves health or social data.

Which details does Art. 30(1) require?

Mandatory detail	Art. 30(1)	Typically for AI
Name and contact details of the controller and the data protection officer	point (a)	as in the rest of your record
Purposes	point (b)	specific: drafts of doctor’s letters, replies to citizens’ enquiries, summaries of files
Categories of data subjects and data	point (c)	patients, citizens, staff; master data, health data, content of applications, login and log data
Recipients	point (d)	AI provider as processor, its sub-processors, data centre, model provider
Transfers to third countries	point (e)	whether a provider outside the EU is involved, with safeguards (adequacy decision, standard contractual clauses)
Erasure periods	point (f)	chats, uploaded documents, logs, backups
Technical and organisational measures	point (g)	general description, reference to the provider’s TOMs

One entry or many?

The data protection supervisory authorities recommend structuring the record by purpose. For AI, this means one entry per area of use, each with its own legal basis and its own types of data. A single catch-all entry “AI platform” hides the fact that an assistant for doctor’s letters processes health data, while an assistant for tender texts hardly involves any personal data.

A two-part structure has proven useful:

• Basic entry for the platform: login, permissions, logs, operation. The data subjects are staff; the purpose is secure operation.
• One entry per application: purpose, types of data, legal basis and erasure period of that application, with a reference to the basic entry for technology and recipients.

Example: entry for an assistant for doctor’s letters

• Purpose: drafts of discharge letters from findings and progress notes, checked and approved by the doctor
• Legal basis: Art. 9(2)(h) GDPR together with the treatment contract and state law
• Data subjects and data: patients (health data, master data), staff (identifier, time of use)
• Recipients: provider of the AI platform as processor, its sub-processors as listed
• Third country: no transfer (or: name the provider and the safeguard)
• Erasure: draft after it has been transferred to the patient record, logs after the configured period
• Measures: access only for the approved group, logs, encryption in transit, reference to the TOMs

Which gaps do auditors often find?

• The model provider is missing as a recipient because only the platform is entered.
• Erasure periods only for chats, not for logs and backups.
• No statement on whether a provider from the USA is involved.
• Web search or other additional services not recorded.
• No reference to the DPIA, even though health data is processed (DPIA for AI).

How does this work with basebox?

For your record, there is a template as a PDF with the details on basebox, together with the list of sub-processors and the TOMs, all on /sicherheit. The list shows which service providers are involved in each operating model; web search via Staan.ai is only added if you enable it. You set the retention periods for the logs yourself: by default, the audit log is kept for 6 months, adjustable from 3 to 36 months. More on this: logging and retention.

Not legal advice: The example shows one possible structure, not a model solution for your organisation. Legal bases and periods depend on the federal state, the body responsible for your organisation and the use. Research as of: 11 October 2026.