guide
By ReclaimLLM TeamWhat EU engineering leaders should record when Cursor, Claude Code or Copilot touch personal data: GDPR duties, AI Act scope and an evidence list.
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.
Personal data is any information about an identified or identifiable person: names, emails, customer numbers, booking references, location data (EDPB SME guide, data protection basics). In a coding session it usually arrives in logs, fixtures, support tickets, database results and screenshots.
Folder paths can count too. Cursor staff confirmed that every new chat receives the absolute path of the opened folder, which includes the OS username (Cursor forum, t/178134/5). A username is personal data when it identifies or can be linked to a person. A client name in the path can also be confidential business information.
Article 5 sets the core principles, including purpose limitation, data minimisation and storage limitation. The organization must also be able to demonstrate compliance (EDPB, data protection basics; GDPR text on EUR-Lex).
For coding agents, minimisation is the practical test: does the agent need the production log, or would a redacted sample do?
Controllers must build in measures so that, by default, only personal data necessary for each purpose is processed. This covers the amount of data, the extent of processing, storage period and accessibility. The EDPB recommends keeping records of these decisions to show compliance (EDPB SME guide, be compliant).
For AI coding tools, "by default" means settings. Examples: in Cursor, Read Access defaults to System, which lets the agent read outside the workspace without asking; switching to Workspace requires approval for those reads (Cursor run modes docs). Record which default you chose and why.
The relationship with a processor must be governed by a contract. The processor may not engage a sub-processor without the controller's written authorisation. The controller is liable for its own compliance and for its choice of processor (EDPB SME guide, controller or processor).
An AI coding tool often has a chain: the editor vendor, then one or more model providers. Ask each vendor for its data processing agreement and sub-processor list. Check what the vendor says about retention and training. For example, Cursor's data use page describes Privacy Mode, zero data retention agreements with providers, and the exceptions for abuse detection (Cursor data use).
Article 30 requires records of processing activities, subject to its exemptions. The exemption for organizations with fewer than 250 employees is limited: it does not cover non-occasional processing, processing likely to risk individuals' rights and freedoms, or processing involving special-category or criminal-offence data. Keep records available to the supervisory authority (EDPB SME guide, be compliant; Art. 30(5) on EUR-Lex).
Day-to-day use of AI coding tools on systems that hold customer data is unlikely to be "occasional". Add a row for it.
Do not rely on a proposed simplification as an exemption. Check the applicable legal text before omitting a processing activity from your record.
Controllers and processors must implement technical and organisational measures that give a level of security appropriate to the risk (EDPB SME guide, secure personal data). For AI coding tools, that includes limiting what agents can read, keeping secrets out of prompts and session records, controlling who can see captured sessions, and setting retention.
If a personal data breach occurs, the controller must notify the supervisory authority as soon as possible and within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Article 33(5) requires the controller to document every breach, including those not notified. A processor must tell the controller without undue delay (EDPB SME guide, data breaches).
The EDPB recommends a system for recording how and when you became aware of a breach. A searchable session record helps here: it shows what the agent read, what it sent and when.
Build the incident process around the applicable notification rule, rather than a proposed reform. Retain the timing and risk assessment behind the notification decision.
A transfer outside the EEA generally relies on an adequacy decision or appropriate safeguards under Article 46, such as standard contractual clauses. Article 49 provides limited derogations for specific situations; they should not be treated as a routine outsourcing shortcut. If the recipient is a processor, an Article 28 contract is still needed (EDPB SME guide, international data transfers).
A prompt sent to a model provider outside the EEA can be such a transfer. Your vendor file should say which transfer tool covers each provider.
The AI Act defines a deployer as a person or organization "using an AI system under its authority", except in personal non-professional use (AI Act Service Desk, Article 3). A company that gives developers Cursor, Claude Code, Copilot, Codex or Antigravity is a deployer of those systems. The vendor is the provider. If you build your own product on top of a model, you may also be a provider; that is outside this guide.
Article 4 requires providers and deployers to take measures to support the AI literacy of their staff and others who use AI systems on their behalf. It has applied since February 2, 2025. National market surveillance authorities supervise and enforce it from August 2, 2026 (European Commission, AI literacy Q&A).
After the AI Omnibus amendments, the Commission says AI literacy remains an obligation, but no specific level is mandated, and there is no duty to measure employees' knowledge. "Other persons" can include contractors and service providers.
For an engineering team, a proportionate measure is short training on what agents can read and send, which settings you enforce, and how to report a mistake. Keep a record of who received it.
The Act's high-risk use cases cover areas such as critical infrastructure safety components, education, employment and worker management, access to essential services, biometrics, law enforcement, migration and justice (European Commission, AI Act). Generating and editing source code is not on that list.
One caution: if you use an AI system to evaluate or manage workers, for example to score developers' performance from their sessions, that use may fall under "employment, management of workers". Treat that as a separate assessment.
The high-risk deployer duties in Article 26, such as keeping automatically generated logs for at least six months, apply to deployers of high-risk systems (AI Act Service Desk, Article 26). They are not a general duty to log every tool call of a coding assistant.
| Date | What applies |
|---|---|
| August 1, 2024 | AI Act entered into force |
| February 2, 2025 | Prohibited practices and AI literacy (Article 4) |
| August 2, 2025 | Governance rules and obligations for general-purpose AI model providers |
| August 2, 2026 | General application, including transparency rules; national enforcement of Article 4 |
| December 2, 2027 | High-risk rules for Annex III use cases (moved by the AI Omnibus) |
| August 2, 2028 | High-risk rules for AI in regulated products (Annex I) |
Source: European Commission, AI Act application timeline. The AI Omnibus entered into force on July 27, 2026, according to the same page.
The example is invented. Use it as a template.
| Step | Event | Personal data | Recipient and location | GDPR record |
|---|---|---|---|---|
| 1 | Developer in Berlin asks the agent to fix a failed invoice export. | None yet | Laptop | — |
| 2 | Agent reads exports/failed-2026-11-10.csv. | 25 customer names and emails | Laptop | Purpose: debugging (Art. 5) |
| 3 | Prompt with file content goes to the tool vendor and model provider. | Same | Processor chain, possibly outside the EEA | DPA and sub-processor list (Art. 28); transfer tool (Art. 46) |
| 4 | Session copy is redacted on the laptop, then uploaded to the capture service. | Emails replaced by placeholders, if the rule matches | Capture vendor, EU region | Processor contract; redaction rule list (Art. 25, 32) |
| 5 | Session record deleted after the retention period. | — | Capture vendor | Retention in record of processing (Art. 30) |
The record shows two different processors at steps 3 and 4. Redaction at step 4 protects the stored copy. It does not change what was already sent at step 3.
This list mixes legal duties and good practice. The "Basis" column says which.
| Item | Basis |
|---|---|
| Record of processing row for AI coding tools: purposes, data categories, recipients, transfers, retention | GDPR Art. 30, subject to the limited Art. 30(5) exemption |
| DPA and sub-processor list for each tool vendor and model provider | GDPR Art. 28 (duty) |
| Transfer tool for each non-EEA recipient | GDPR Art. 44–46 (duty) |
| Chosen defaults: read access, privacy mode, permission rules, who can change them | GDPR Art. 25 (duty to apply; recording is recommended) |
| Security measures: secret handling, access to session records, retention | GDPR Art. 32 (duty) |
| Breach log, including breaches not notified | GDPR Art. 33(5) (duty) |
| AI literacy training record | AI Act Art. 4 (duty to take measures; record is good practice) |
| Session records showing which tool call read or sent what, and when | Good practice; supports Art. 5(2) accountability and breach assessment |
| Approved tool list and versions | Good practice |
Cursor staff stated in November 2026 that there is no platform audit trail that links a proposed tool call, the user's decision (accepted, rejected or auto-approved) and the execution result into one record. They also said the approval card decision is not passed through hooks (Cursor forum, t/156247/10). Users in that thread named GDPR and NIS2 among their reasons for asking (t/156247). Those are user motivations, not legal findings.
If you need that evidence, you have to build or buy your own record. See AI coding session audit trails.
ReclaimLLM captures sessions from Cursor, Claude Code, Copilot, Codex and Antigravity and makes them searchable, so you can answer "what did the agent read and send?" for a GDPR record or breach assessment.
For the Canadian version of this guide, see AI coding tools under PIPEDA and Québec Law 25.
Is Cursor or Claude Code a high-risk AI system under the AI Act? Not for ordinary code generation. Software development is not in the high-risk use-case list published by the European Commission. A use that evaluates or manages workers may need a separate assessment.
Does the AI Act require us to log every agent tool call? No general duty does. Logging duties for deployers in Article 26 apply to high-risk systems. You may still want a session record for GDPR accountability and breach assessment.
Do we need consent from customers before an agent reads a log with their data? Consent is only one of the GDPR legal bases (EDPB, process personal data lawfully). Which basis fits depends on why you hold the data. Ask your data protection advisor, and minimise the data first.