Records of processing activities are the list of every processing operation involving personal data in your organisation, maintained by the controller and produced on request to the supervisory authority. Article 30 GDPR prescribes what has to be in it. The moment your team uses an AI tool that touches personal data, that is a processing activity like any other and it belongs in the records.
In practice this is exactly the entry that is missing almost everywhere. The records were created once in 2018, the IT landscape has changed three times since, and Copilot has been running in Word and Outlook for a year without appearing in any documentation. This is not a minor gap. A missing or incomplete entry is a violation in its own right, regardless of whether the AI use itself is lawful. And it is usually the first thing a supervisory authority asks for, because it is the cheapest check they can run.
This post covers what Article 30 requires, when it applies to you at all, and what an AI entry looks like that you can write in an hour.
What does Article 30 GDPR actually require?
Article 30(1) GDPR lists the mandatory information for controllers. For each processing activity you need:
- Name and contact details of the controller, and where applicable of the representative and the data protection officer
- Purposes of the processing
- Categories of data subjects and categories of personal data
- Categories of recipients to whom the data have been or will be disclosed, including recipients in third countries
- Transfers to third countries, naming the country and the documentation of suitable safeguards
- Envisaged time limits for erasure of the different categories of data, where possible
- A general description of the technical and organisational measures under Article 32(1)
The records must be kept in writing, and electronic form counts. A spreadsheet satisfies the requirement if the content is right. You do not have to publish or file the records, you have to make them available to the supervisory authority on request.
One distinction matters for understanding this. The records document what you do. They do not justify that you are allowed to do it. Legal basis, data processing agreement, and where relevant a DPIA are separate duties. A clean entry describing an unlawful processing activity does not make it lawful, it only documents it better.
Does this apply to small firms too?
Almost always yes, and the reason surprises people.
Article 30(5) contains an exemption for organisations with fewer than 250 employees. That exemption falls away as soon as any one of the following applies:
- The processing is likely to result in a risk to the rights and freedoms of data subjects, or
- the processing is not occasional, or
- it involves special categories of data under Article 9 or data on criminal convictions under Article 10.
The second condition kills the exemption for practically every business. HR administration is not occasional. Client administration is not occasional. An AI assistant your team uses in Outlook every day is certainly not occasional. The exemption only bites for genuinely one-off processing, such as a single action that is not repeated.
For law firms, tax advisors, and financial services providers there is an additional point: you routinely work with data whose disclosure can cause serious harm. Arguing about whether the 250-employee threshold applies is simply not worth the time. Keep the records.
What does an entry for an AI tool look like?
Here is the structure of an entry for an AI assistant used in day-to-day office work. The brackets show what you replace with your own details.
Name of the processing activity: use of an AI assistant for text and document work (product name and plan, for example Microsoft 365 Copilot on a business plan).
Purpose: support with drafting, summarising, translating, and researching in internal casework. Name the purposes concretely. “Efficiency gains” is not a purpose under the GDPR, “producing drafts for client correspondence” is.
Legal basis: depending on the case, Article 6(1)(b) (contract performance), (c) (legal obligation), or (f) (legitimate interests with a documented balancing test). Article 30 does not explicitly require the legal basis, but every usable set of records carries it anyway, because the authority will ask regardless. Which basis fits when is covered in my post on the five questions before processing personal data with AI.
Categories of data subjects: clients and their family members, employees, contacts at business partners, and third parties named in the documents being processed. That last group gets forgotten most often and is the largest one in law firms.
Categories of personal data: master data, contact data, contract and billing data, correspondence content, and where relevant health data or other Article 9 data if it appears in the documents being processed.
Categories of recipients: the AI provider as processor, its sub-processors (the list sits in the data processing agreement and changes, so note the date of the version you checked), and where applicable your IT service provider.
Third-country transfers: yes or no, and if yes: destination country, legal basis for the transfer (adequacy decision, standard contractual clauses), and where the documentation sits. If you have booked an EU region, that belongs here too, along with the caveat that support or abuse review may still happen outside it. The checks for that are in my post on data location with cloud AI.
Retention periods: how long the provider keeps chat histories and prompt history (this is in the documentation for your plan), and retention rules for outputs you file into your own records. If you do not know the value, that is a finding, not a reason to leave the field blank.
Technical and organisational measures: access control and role model, encryption in transit and at rest, permissions on the data sources the AI reads from, logging, acceptable use policy and training, and disabling the use of inputs for model training.
That last point deserves a note. With AI assistants that reach into your existing document stores, the permissions on those stores are themselves a technical measure under Article 32. If your SharePoint permissions are poorly maintained, you have an oversharing problem with Copilot, and that belongs honestly in the description of measures as long as it is unresolved.
One entry or several?
Rule of thumb: one entry per purpose, not per tool.
If you use the same AI assistant for client correspondence and for internal HR matters, those are two processing activities with different data subjects, different legal bases, and different retention periods. Two entries are clearer than one entry full of if-then clauses.
Conversely, you do not need a separate entry for every feature. Copilot in Word and Copilot in Outlook within the same purpose is one processing activity.
And a third option is often the fastest: if you already have an entry for “client administration” and AI is simply a new means of processing within that purpose, extend the existing entry with recipients, third-country details, and measures. What matters is that the AI processing becomes visible rather than disappearing between the lines.
What Article 30 does not cover
The records are one of several documentation duties, and they do not discharge the others.
The DPIA. Where the risk is likely to be high, you additionally need a data protection impact assessment under Article 35. The records do not replace it, but they do half the preparatory work, because purposes, data categories, and recipients are already written down. The process is in my DPIA guide for AI tools.
The data processing agreement. The Article 28 agreement is a contract with the provider, not a record entry. The records name the provider as a recipient, the agreement sets the terms.
Proof of AI literacy under the EU AI Act. Article 4 of the AI Act requires that staff who operate AI systems have sufficient AI literacy. That is a separate duty with its own evidence trail, covered in my post on the AI literacy obligation.
The internal rule. The records describe what happens. They do not tell your staff what is allowed. For that you need an AI acceptable use policy, and in workplaces with a works council potentially a works agreement as well.
The three most common mistakes
Mistake 1: the records only know the tools that IT purchased. If three employees use their private ChatGPT accounts for work text, processing is happening that is absent from the records and has no processing agreement behind it. Before you document, you need to know what is actually running. How to find that out is in my post on shadow AI.
Mistake 2: the entry describes the desired state. I see records listing a role and permissions concept under measures that does not exist. That is worse than a gap, because in an audit it looks like a false statement. Write the actual state and keep open items separately as a dated action list.
Mistake 3: written once, never touched again. AI providers change sub-processors, regions, and retention periods more often than traditional software vendors. A fixed date on which you check the AI entries against the current provider documentation is the only way to keep the records current. Twice a year is enough in most firms, sooner when something substantial changes.
The next step
Open your existing records and check one single question: does any AI tool appear anywhere in them? If not, the entry above is your template, and you need neither budget nor a project for it, just an hour and the provider documentation.
If you want to know which other documentation duties are still open at your firm, take my free AI compliance check. It takes 2 minutes and shows you where the gaps sit between what you use and what you can evidence.
Jose Lugo is a CISSP-certified AI compliance consultant. He advises law firms, tax advisors, and financial services providers in Germany on GDPR-compliant AI adoption.