Where an agent breaks a processing record written for humans
Most records of processing activities assume a person signs in to an app and reads a record there. Put an AI client in front of the same app and two things change. A model vendor's infrastructure now handles the request and the result, and the call is made by software acting for one named employee.
The entry keeps its shape. A GDPR Article 30 AI agent entry still names purposes, categories of data subjects and personal data, and categories of recipients. It also names third-country transfers, erasure time limits and a general description of security measures. What moves is where each answer comes from. Part of it falls out of the audit log, Elaichi's record of what actually ran. Part of it does not, because the log deliberately never holds it. Elaichi's own position on data protection sits on its GDPR page.
The agent reaches those apps over MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
What a GDPR Article 30 AI agent entry has to name
The entry names the same things as any other entry. The agent changes the evidence, not the fields. Write it in this order and the audit log becomes an annex rather than a source of truth.
- Purposes: the work the team does, written as a purpose and not as a tool name.
- Categories of data subjects and personal data: taken from which connectors and tools a role can reach, not from the log.
- Categories of recipients: the AI client, Elaichi, and the app whose account was used.
- Transfers: the organization's region, plus the legs that sit in the EU for everyone.
- Erasure time limits: 90 days of audit history, and 7 days for a file a tool result produced.
- Security measures: per-person sign-in, credentials held outside the main data store, and restrictions checked before a call leaves. A restriction is a rule saying which connectors and tools a role or one member may reach.
Controller or processor: naming the parties in the path
Under the regulation, whoever decides the purposes and means is the controller. A vendor processing on documented instructions is a processor. Adding an agent does not move that line by itself. The company that decided support may read tickets is still the one that decided.
What it does is lengthen the list of parties. You already have a relationship with the app, and Elaichi does not replace it. For a connected-tool call, Elaichi fetches that connection's stored credential, applies it, and calls the third party from inside the organization's region gateway. The app sees a call authorized by the account your member connected. The terms Elaichi takes are in the data processing agreement, and the parties behind it are named on the subprocessors page.
The AI client vendor is in the path too, and a reviewer will ask where its servers sit. Anthropic's own documentation says Claude reaches a custom connector's remote MCP server from Anthropic's cloud, not from the user's device. That holds on every Claude client (support.claude.com, checked October 2026).
One category of data subject gets forgotten: employees. Every audit row records the acting user, so the log itself processes staff personal data and belongs in the entry.
Which Article 30 fields come straight from the audit row
Recipients, surfaces and timing come straight out. Elaichi writes one row for each connected-tool call that reaches execution and then runs, fails or is refused there. That holds whether the call came from an MCP client, a Code Mode program or the Elaichi Agent.
Each row records the acting user and the toolbox the call went through, a toolbox being a named list of tools pinned to connections. It records the tool's advertised and catalog names, the connector, and the connection the call actually reached. It also records the tool's classification as a read, a write or a delete, and whether approval was required and how it was given. It records whether a person edited the arguments, the surface (console, api, mcp or app), and the outcome. When the surface is mcp, it records the MCP client's id. For list and search calls it adds a result count.
The console renders that as one sentence: 'Using Claude, Emily Carter updated the page "Q4 Roadmap" in Notion through the connection "Acme Notion".' For Article 30 purposes that line carries the recipient, the account, the action class and the client at once.
One filing trap. Connected-tool calls sit in the audit log's assistant category, because their action name is assistant.toolbox_tool. The mcp category holds grant events instead. A reviewer who filters to MCP and finds no tool calls has not found a gap.
The fields the audit row will not give you
Categories of personal data are not in the row, by design. Elaichi records no argument values, with one exception. The value of the single URL path argument that names the object is kept as the target id. It records neither argument names nor an argument count.
It goes further than that. A target never keeps a title for a person's record, such as a contact, lead, employee or candidate, nor for a message. An email address is never stored as an id or a title. For a list or search call the row holds the resource type and how many items came back, nothing about the items.
Two gaps are worth writing down before a reviewer finds them. A call refused before execution writes no row at all: a tool a restriction withheld, an unknown tool name, a rate limit. The same goes for a missing OAuth scope, the permission a person granted that client at sign-in. Listing tools and searching them are not audit entries either. So the log records calls that ran, not everything a client asked for. "Full audit logging of every request" is not a sentence to put in the entry.
That leaves categories of personal data to come from access design. Restrictions are readable by anyone holding the view-restrictions permission, which Org Owner, Org Admin and Auditor hold. Toolboxes work differently. They have no organization-wide oversight view, and an admin sees only the ones they own or that were shared with them. Write that field from roles and restrictions, not from a toolbox inventory.
Categories of recipients: the client, the gateway, the app
Three kinds of recipient sit in the path, and the audit row names two of them directly. The connector and the connection say which app and which account. The surface and the MCP client's id say which client.
Be careful how confidently you name the client. Elaichi marks a client's name verified only when every non-loopback redirect address it registered maps to the same known client. Exactly seven can be verified: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. Anything else shows the name the client registered for itself, which the console flags as self-reported. A client that registers only loopback addresses, which is how command-line clients work, is never verified.
For the list of clients that exist at all, use grant events rather than call rows. Elaichi writes an entry when a grant is created at consent, carrying the client, the scopes and the toolbox reach. It writes one again when the grant is activated, changed or disconnected.
Article 30(1)(e) transfers: where each leg runs
An organization's region is chosen when it is created and cannot be changed afterwards. For an EU or a US organization, the per-organization data store is pinned to that jurisdiction, and org-scoped requests execute there. That includes the connected-tool call: the credential is fetched, applied and sent to the third party inside that region. APAC uses best-effort placement and is not a residency guarantee.
Two legs sit in the EU for every organization whatever its region. The audit trail is stored in one EU log instance, as the privacy policy, the data processing agreement and the GDPR page all state. Files kept from binary tool results go to one EU bucket.
Then there are the parts not placed by region at all. User accounts, the organization row, API tokens and single sign-on connections sit outside the per-organization store. Sessions, MCP access and refresh tokens, sign-in state and short-lived permission caches sit in a key-value store that is not pinned to a jurisdiction. Requests that do not act inside an organization run wherever they land, including sign-in, signup, creating or listing organizations, and the OAuth endpoints.
Credentials carry a date. Connections created since October 5, 2026 have their credentials placed in the organization's region, inside the EU or US jurisdiction for those regions. Older connections stay where they were until they are copied, and reconnecting copies one into the region. If the entry claims EU placement for credentials, reconnect the older connections first. The leg-by-leg version is in EU data residency for AI agents.
Retention: 90 days of evidence behind a standing record
Elaichi keeps an organization's audit history for 90 days. The Article 30 record is a document you maintain for as long as the processing continues; the rows that evidence it are not. For a longer history, forward it to your own log service: export to your own Datadog comes with the Black plan, which is launching soon. The trade-offs in that decision are set out in how long to keep a record of AI actions.
Each vendor in the path keeps its own clock, so do not assume one number covers the chain. OpenAI says its Compliance Logs Platform retains data for 30 days, and that retention for other endpoints depends on the endpoint and workspace settings (help.openai.com, checked October 2026).
Two related limits belong in the erasure field. A file Elaichi stored from a tool result expires 7 days after it was created. Expiry is enforced when the file is read, not only by the daily sweep. Deleting the organization does not clear the audit history either. It stays until retention removes it, which the entry should say plainly instead of promising erasure on request.
Keeping the entry true after an access change
Changes land on two clocks, and the entry should name both. A role, team membership, restriction or access-grant change reaches every surface within about two minutes. Revoking a share, disconnecting an account, and removing or suspending a member take effect on the client's next call.
The changes are themselves evidence. Restriction writes are recorded as created, updated and deleted events. Access grants are recorded when granted, superseded, expired or revoked. So the log dates the version of the entry you were operating under, which is the question a reviewer asks second.
If a data protection officer wants to read this themselves, the Auditor role gives read-only visibility across the organization, including the audit log. It does not take a billable seat, and it cannot change anything or run tools.
When your entry needs none of this
If the agent touches nothing personal, Article 30(1)(c) and (d) have very little to list. A gateway in front of it is solving a different problem. Build logs, public documentation and your own code are the usual cases.
If one team uses one app, that app's own MCP server is the shorter path and adds no second processor. Notion's documentation describes its server as reading and updating only the content the authorizing user can access (developers.notion.com, checked October 2026). The activity lands in that app's own records. The argument for one governed endpoint starts when the entry has to cover several apps at once. Recipients, transfers and retention are then answered once rather than per vendor.
When it does come to that, the connector catalog is the starting list for categories of recipients. How access is decided across apps covers the layers above it. For the fields a reviewer asks about in the trail itself, read what an AI agent audit log must capture. The governance surfaces in the product are at /use-cases/governance/.
