Originally published at ReclaimLLM.
What EU engineering leaders should record when Cursor, Claude Code or Copilot touch personal data: GDPR duties, AI Act scope and an evidence list.
AI coding agents under GDPR and the EU AI Act: what to log
Updated November 14, 2026.
Not legal advice. This is general information for engineering leaders about EU law, not UK GDPR. Ask a qualified data protection advisor about your own processing and check the linked sources when you rely on them.
An AI coding agent reads a log file to fix a bug. The log holds customer email addresses. The agent sends part of it to a model provider in another country. If the processing falls within the GDPR's scope, the data flow needs a lawful basis, appropriate safeguards and an assessment of the recipient's role. It may also be an international transfer. The AI Act is a separate assessment based on the system and its use.
This guide separates the two laws, then gives a practical list of what to record. It is for CTOs and heads of engineering at EU software companies, including fintech and health software teams.
Short answer
- GDPR applies to personal-data processing within its territorial and material scope. Your company may be the controller or may process data for a customer. Confirm whether each vendor acts as a processor, sub-processor or independent controller for the relevant purpose.
- The EU AI Act makes your company a "deployer" of the AI system. For a coding assistant used to write code, the main duty in force today is AI literacy (Article 4). Coding assistants are not in the Act's high-risk use-case list, so the high-risk logging duties do not apply to ordinary use.
- The record you keep is mostly a GDPR record: what personal data went where, under which contract, for how long, and what you did when something went wrong.
GDPR and the AI Act are not the same question
| Law | Question | What changes | What does not change |
|---|---|---|---|
| GDPR | What personal data is processed, by whom, on what basis, and where does it go? | The data, the role and the transfer path | You still need a record of processing even when the tool changes |
| EU AI Act | What kind of AI system is this, and what does the deployer owe? | The classification (high-risk, limited-risk, minimal-risk) | Coding assistants are not a high-risk use case |
The EDPB's SME guide says the GDPR applies to any organisation that processes personal data in the EU, or that offers goods or services to people in the EU, even if it is based outside the EU (EDPB SME guide, data protection basics). The GDPR's territorial scope is in Article 3, and the material scope, including the household exemption, is in Article 2. Check the linked GDPR text and ask your advisor whether your processing falls within scope. The EDPB's guidance on data protection basics is a useful starting point.
The AI Act's scope is separate. It entered into force on 1 August 2024, and its duties apply in phases. The general-purpose AI rules apply from 2 August 2025, the high-risk rules from 2 August 2026, and the remaining rules from 2 August 2027 (see the AI Act application timeline). AI literacy is the deployer duty in force today, and the Act's transparency duties for generated content do not apply to ordinary internal code.
What to record for a coding agent
The record below is the evidence list an engineering leader can keep per tool. It is not a record of processing under Article 30, but it feeds one.
1. What personal data went into the prompt. Which categories: customer email addresses, logs, source code comments, internal user names. Record the source: which repository, which file, which log.
2. Where it went. Which model provider, which region, which endpoint. Record the vendor's data terms and the region you selected.
3. What the tool did with it. Which files the agent read, which it changed, which commands it ran, and which approvals the user gave or refused. The vendor's own records may not link these into one entry, so keep your own.
4. What left the session. Which external calls the agent made: package downloads, MCP servers, web lookups, and any data sent to a third party. Record the destination and the data sent.
5. What was kept, and for how long. The vendor's retention, the local record's retention, and the export you kept. Record the dates.
6. What you did about a problem. A secret in a prompt, a file read outside the repo, an unexpected external call. Record the date, the action and the owner.
7. What was agreed before you started. The policy, the approved tools, the data that must not enter prompts, and the settings you required. Record the version and the date.
8. What you tested. A coverage test per tool: one allowed read, one denied read, one failed command, one file edit. Record what the capture showed and what it missed.
Most teams do not have this record today. The vendor's own records are not a single audit trail. Cursor staff stated that there is no platform audit trail linking a proposed tool call, the user's decision and the execution result into one record, and that approval-card decisions are not passed through hooks (Cursor forum, t/156247/10). Build the record from the tool's own logs, the session capture and your own notes.
The retention clock starts when the data is created, not when you notice it. Keep the record for the period your policy states, and delete it when that period ends.
What changes between vendors
The record above is the same for every tool. What changes is what each vendor lets you see.
| Vendor | What to log | Known gap |
|---|---|---|
| Cursor | Tool calls, file reads and writes, approvals, external calls | Cloud Agent PR actions are not visible to project hooks; headless CLI runs do not yet run the stop, beforeSubmitPrompt or afterAgentResponse hooks |
| Claude Code | Permission decisions, file reads and writes, commands | Local settings may allow actions without a prompt; check settings.local.json |
| Copilot | Agent mode tool calls, file reads and writes | Content exclusion does not cover every path; check the vendor's docs for the gaps |
Cursor's own docs describe the run modes and the data use for the agent. Cursor staff confirmed that the Cloud Agent pull-request tool runs on Cursor's backend and is not visible to project hooks (Cursor forum, t/178134/5). The EDPB's guidance on data protection basics and on being compliant (EDPB, be compliant) is a useful starting point for the GDPR side.
What an auditor or customer asks for
| Question | What to show |
|---|---|
| What personal data do you process, and on what basis? | The record of processing (Article 30), the lawful basis for each purpose, and the categories of data (EDPB, be compliant) |
| Who processes it for you? | The vendor's role (processor, sub-processor or independent controller) and the contract (EDPB, controller or processor) |
| Where does it go? | The regions, the transfer mechanism, and the safeguards for international transfers (EDPB, international data transfers) |
| How long do you keep it? | The retention periods for each category, and the deletion dates |
| What happens when something goes wrong? | The breach process, the 72-hour notification duty, and the record of incidents (EDPB, data breaches) |
| What did the agent do? | The session record: prompts, tool calls, file reads and writes, approvals, and external calls |
The GDPR's record of processing is in Article 30. Organisations with fewer than 250 employees are exempt from keeping a record under Article 30(5), unless the processing is not occasional, is likely to result in a risk, or involves special categories of data or criminal-conviction data (Article 30(5)). Check the GDPR text and ask your advisor whether the exemption applies to you.
Keep the vendor's own terms with the record: the data-processing agreement, the retention terms, and the sub-processor list. The EDPB's guidance on secure personal data and on data breaches is a useful starting point.
What ReclaimLLM records
ReclaimLLM captures AI coding sessions from Cursor, Claude Code, Copilot, Codex and Antigravity through hooks, and makes them searchable. It records the prompt, the tool calls, the files read and written, and the approval decisions. It applies local redaction before upload, so secrets and personal data can be removed before the session leaves the machine.
What it records:
- The prompt and the tool calls in the session.
- The files read and written, and the commands run.
- The approval decisions the user made.
- The external calls the agent made, where the hooks see them.
What it does not record:
- Paths the hooks do not see, such as the Cloud Agent pull-request tool and headless CLI runs in Cursor.
- The vendor's own backend records, which the hooks cannot reach.
- Data that local redaction removed before upload.
Detection of secrets and external egress in captured sessions runs on an hourly or daily sweep and raises alerts; it does not block. It cannot prevent a secret from being sent in the first place.
What to ask your counsel
- Does the GDPR apply to our processing, and are we the controller or the processor for each purpose?
- Which lawful basis applies to each purpose, and is consent the right basis for employee data?
- Which vendors are processors, sub-processors or independent controllers for the relevant purpose?
- Which transfers are international transfers, and which safeguards apply?
- What is our retention period for session records, and when do we delete them?
Where ReclaimLLM fits
ReclaimLLM gives you the session record for the list above. It captures sessions from the tools your team uses, applies local redaction before upload, and keeps the record for the retention period you choose. The record is exportable for an audit or a customer questionnaire. Check the current plan comparison and confirm the available team-management, audit and integration capabilities for your account before including them in a compliance scope. Hosted data is stored in the US or EU region today (see data residency).
The record is only as complete as the hooks that capture it. The vendor's own backend records are not visible to the hooks, and the Cloud Agent and headless CLI gaps apply. State the gaps in the record, and do not present it as complete.
For the method behind the record, see AI coding session audit trails. For the Canadian rules, see our PIPEDA and Law 25 guide.
FAQ
Does the AI Act require logging for coding assistants?
No, not for ordinary use. Coding assistants are not in the Act's high-risk use-case list, so the high-risk logging duties in Article 12 and the deployer duties in Article 26 do not apply to ordinary code writing. The main duty in force today is AI literacy under Article 4 (AI Act Service Desk, Article 3; European Commission, AI literacy Q&A).
What is AI literacy?
Article 4 requires providers and deployers to ensure that staff have a sufficient level of AI literacy, taking into account their technical knowledge, experience, education and training and the context in which the AI systems are to be used. The Commission's AI literacy Q&A explains what that means in practice.
Who is the deployer?
The deployer is the natural or legal person, public authority, agency or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity (AI Act Service Desk, Article 3). For a coding assistant used at work, the company is the deployer.
What does the deployer owe under Article 26?
Article 26 sets out the deployer duties for high-risk AI systems, including using the system in accordance with the instructions for use, ensuring human oversight, and keeping the logs generated by the system. These duties apply to high-risk systems, not to ordinary coding assistants (AI Act Service Desk, Article 26).
Review AI coding security and compliance.
Read the original article at ReclaimLLM.
![Obfuscating a Polymorphic JSON Contract: Why [JsonDerivedType] Survives Renaming and TypeNameHandling Does Not](/storage/uploads/covers/auto/p223664.svg)
