# GDPR Article 30 AI agent entry, field by field

> A GDPR Article 30 AI agent entry needs recipients, transfers and retention. Elaichi's audit row fills part of it; your role design fills the rest.

**TL;DR** Elaichi fills in part of a GDPR Article 30 record for AI agents and not the rest. Its audit log names the acting person, the connector, the connection and the AI client. It also records whether the call read, wrote or deleted, which covers categories of recipients. Categories of personal data have to come from your roles and restrictions, because the log records no argument values. Transfers come from the organization's region plus the legs that sit in the EU for every organization.

## 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](/gdpr/).

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](/dpa/), and the parties behind it are named on the [subprocessors page](/subprocessors/).

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](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), 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](/privacy/), 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](/blog/eu-data-residency-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](/blog/audit-log-retention-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](https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-and-edu-customers), 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](/blog/auditor-seat-for-compliance-reviewers/) 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](https://developers.notion.com/guides/mcp/overview), 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](/connectors/) is the starting list for categories of recipients. [How access is decided across apps](/blog/mcp-governance/) 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](/blog/what-an-ai-audit-log-must-capture/). The governance surfaces in the product are at [/use-cases/governance/](/use-cases/governance/).

## FAQ

### Does Elaichi's audit log record the personal data an AI agent read?

No. Each connected-tool row records the acting user, the tool, the connector and the connection the call reached. It also records whether the tool read, wrote or deleted, how approval was given, the surface and the outcome. It records what kind of object was touched. It records no argument values apart from the one URL path argument that names the object, and neither argument names nor an argument count. A target never keeps the title of a person's record or of a message. An email address is never stored as an id or a title. For a list or search call it keeps only the resource type and how many items came back.

### Where is the audit trail stored for an EU organization using Elaichi?

Every organization's audit trail is stored in one log instance in the EU, whatever region the organization chose. Elaichi's privacy policy, data processing agreement and GDPR page all state this. Separately, an EU organization's per-organization data store is pinned to the EU jurisdiction, and its org-scoped requests, including connected-tool calls, execute there.

### How long does Elaichi keep audit history for a record of processing activities?

Elaichi keeps an organization's audit log for 90 days. 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. Deleting the organization does not clear the audit history; it stays until the 90-day retention removes it.

### Who counts as a recipient when an employee uses Claude through Elaichi?

Three kinds of party sit in the path: the AI client vendor whose infrastructure handles the request, Elaichi, and the SaaS app whose account the call used. Elaichi's audit row names the last two directly, through the connector and the connection. It names the client through the surface and the MCP client id. Elaichi's subprocessor list and data processing agreement cover the parties behind Elaichi itself.

### Can a data protection officer read the log without taking a paid seat?

Yes. The Auditor role is a free seat with read-only visibility across the organization. It holds the audit-view permission, so it reads every event in the organization. It holds no create, share, manage or tool-execution permission, so it cannot change anything or run tools.

## Read next

- [CCPA data subject request MCP evidence for Salesforce](/blog/ccpa-data-subject-request-third-party-saas/) — A CCPA data subject request MCP trail: Salesforce holds the consumer record, and Elaichi holds the access record. The audit log keeps 90 days of it.
- [MCP audit log comparison: what each shape records](/blog/audit-log-comparison-mcp-tools/) — An MCP audit log comparison across four shapes: what each one records about intent, the account reached, arguments, and whether AI actorship is a field.
- [Vendor Security Questionnaire AI Access: 20 Answers](/blog/vendor-security-questionnaire-ai-agent-access/) — Twenty vendor security questionnaire ai access questions, answered with the mechanism: which key, which role, which log row.