Records of Processing Activities for an AI System (Article 30)

A record of processing activities is the one compliance document a supervisory authority is entitled to ask for without opening a case. For an ordinary CRM the template writes itself. For an AI feature, four of the required fields have answers that most teams have never written down: who the recipients are, how long each store keeps the data, what the retention period is for something that has been embedded, and which third country the inference actually happened in.

What Article 30 actually requires

Article 30(1) of the GDPR obliges a controller to maintain a record of processing activities under its responsibility, containing: the identity and contact details of the controller, any joint controller, the representative and the data protection officer; the purposes of the processing; a description of the categories of data subjects and the categories of personal data; the categories of recipients to whom the data have been or will be disclosed, including recipients in third countries; transfers to a third country, identifying that country and, for transfers under the second subparagraph of Article 49(1), the documentation of suitable safeguards; where possible, the envisaged time limits for erasure of the different categories of data; and, where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

Article 30(2) sets a shorter list for processors: the processor and each controller it acts for, the categories of processing carried out on behalf of each controller, third-country transfers, and the security measures. Article 30(3) requires the record to be in writing, including electronic form, and Article 30(4) obliges both controller and processor to make it available to the supervisory authority on request. The full text is at EUR-Lex, Regulation (EU) 2016/679.

The exemption in Article 30(5) is narrower than it is usually read. It relieves an organisation with fewer than 250 employees, but only where the processing is unlikely to result in a risk to rights and freedoms, and is occasional, and does not include special categories of data under Article 9 or criminal-conviction data under Article 10. Those conditions are cumulative and the second one is usually fatal: a feature that runs on every request a user makes is not occasional processing. In practice a company shipping an AI feature keeps a record regardless of headcount. Article 30 sits in the lower fine tier under Article 83(4)(a) — up to ten million euro or two per cent of worldwide annual turnover, whichever is higher.

The five fields AI processing breaks

The template you already have was written for processing where data goes in one place and stays there. An AI feature scatters it. These are the fields where a generic entry becomes wrong:

• Categories of personal data. The honest answer for a free-text prompt is that the user decides what goes in it. That is not a reason to write “user content” and move on. Name the categories you intend to process, name the categories the interface makes likely (a support assistant will receive order numbers, addresses and complaints about health), and record what you do about the ones you did not intend — filtering, redaction, or nothing. A record that pretends a prompt box is structured is a record that will not survive being read.
• Categories of recipients. The model provider is a recipient. So is anything the provider routes to. So is the vector database, the observability vendor that receives traces, and the evaluation tool that stores sampled outputs. Each is a separate line.
• Third-country transfers. One AI feature can transfer to several countries at once — the API endpoint, the region a provider actually serves from, and any support access from elsewhere. The record must identify the country, not the vendor’s headquarters.
• Erasure time limits. There is no single number. Prompt logs, abuse-monitoring copies held by the provider, conversation history in your own database, embeddings in a vector store, evaluation datasets and fine-tuning corpora each have their own clock, and they are frequently different by an order of magnitude. Record them per store.
• Purposes. Serving the feature is one purpose. Improving the feature is another. Abuse detection is a third, and it is often the purpose that justifies the longest retention. Splitting them in the record is what later lets you answer a subject access request without guessing.

A filled-in entry

Below is one activity, written out. It is deliberately a single feature rather than “AI” as a category: Article 30 records activities, and lumping every model call in the company into one entry produces a record with a retention field that cannot be filled in.

activity: AI support assistant (customer-facing chat)
controller: Example BV, Amsterdam — [email protected]
purposes:
  - answering customer support questions (primary)
  - detecting abuse and prompt-injection attempts (security)
  - offline quality evaluation on sampled, redacted transcripts
lawful_basis: Art 6(1)(b) performance of contract (primary);
              Art 6(1)(f) legitimate interests (security, evaluation)
data_subjects: customers; employees of customers; third parties named
               by a customer in free text
personal_data:
  intended: name, account id, order id, message content
  foreseeable_unintended: contact details of third parties, health or
                          financial detail volunteered in free text
  special_category: not intended; Art 9 filter + human review escalation
recipients:
  - <model provider>, acting as processor — inference
  - <model provider>'s own infrastructure sub-processors — see its list
  - <vector db vendor>, acting as processor — embeddings of help articles
  - <observability vendor>, acting as processor — request traces
transfers:
  - country: United States
    mechanism: SCCs Module 2 (2021/914) + TIA dated 2026-05-14
  - country: none for embeddings — EU region pinned, contractual
retention:
  live conversation history: 90 days from last message
  provider-side abuse logs: 30 days (contractual maximum)
  observability traces: 14 days, prompt body redacted at ingest
  evaluation dataset: 12 months, pseudonymised at extraction
  embeddings of customer messages: not created
security_measures: TLS 1.2+ in transit; per-tenant encryption at rest;
  no training on customer data (contractual); access limited to the
  support-tooling group; prompt bodies excluded from application logs

Two things in that entry do the most work. The first is the split between intended and foreseeable-unintended data, which is the only honest way to describe a free-text field and is also the sentence a supervisory authority will look for. The second is the per-store retention block, because it forces someone to find out what the provider’s log window actually is rather than assuming it is zero.

Recipients, sub-processors and transfers

1. List every place a prompt or a response comes to rest. Walk one request end to end: your application logs, the gateway, the provider, the provider’s abuse-review store, the trace collector, the analytics warehouse. Anything that keeps bytes is a recipient.
2. Get the provider’s sub-processor list and date it. Article 30 asks for categories of recipients, so you do not have to reproduce the list — but you cannot describe the categories without reading it, and the transfer field depends on it. See sub-processor disclosure obligations for AI vendors.
3. Record the country of processing, not the country of incorporation. A vendor headquartered in Ireland that serves inference from Virginia is a transfer to the United States.
4. Name the transfer mechanism and its date. Adequacy decision, SCC module, or a derogation. If it is SCCs, the record should point at the transfer impact assessment — see transfer impact assessments for a US-hosted AI provider.
5. Cross-reference the DPIA if one exists. Article 30 does not require it, but a record that points at the assessment is the difference between a document that answers questions and one that generates them. See which AI processing triggers a DPIA.

Keeping the record true

The failure mode for an AI RoPA entry is not that it is written badly. It is that it is written once, correctly, and then a team adds a fallback provider on a Tuesday. Nothing about that change touches the document, and the record now names the wrong recipients and the wrong third country. Article 30 does not set a review cadence, which is precisely why one has to be imposed: tie the entry to the change that invalidates it rather than to the calendar. A new provider, a new region, a new retention setting, a new store, or a new purpose are the five events that should force an edit.

Keep the record separate from your marketing claims about the feature. A RoPA that says training on customer data is disabled is a statement you will be held to, and it should trace to a contractual clause rather than to a settings page that a future account administrator can change. Where the underlying position is contractual, cite the clause number in the security-measures field — see the DPA clauses specific to AI sub-processing for what those clauses need to say.

Finally, resist the urge to make the record a policy. Article 30 asks what you do, not what you intend. A short entry that is accurate is worth more under Article 30(4) than a long one that describes a control environment nobody has built, and the second kind is actively dangerous because it is an admission that the control was expected and absent.