GDPR AI agents: what UK and EU SMBs need to know

You brief an AI developer to build a custom agent that qualifies sales leads from inbound enquiries. Two weeks in, your in-house counsel asks whether the agent processes personal data, what your lawful basis is, and whether you have signed a data processing agreement with the vendor. No one has an answer. The agent goes live anyway. Three months later, a data subject access request lands on your desk, and you realise the agent's training logs contain email addresses, job titles, and notes about individual prospects. You now have fifteen calendar days to explain every decision the agent made about that person, and you have no audit trail.

This is not a hypothetical. It is the most common compliance gap we see when SMBs deploy GDPR AI agents without mapping data flows first. The General Data Protection Regulation applies to any processing of personal data relating to individuals in the EU or UK, and AI agents built on large language models, vector databases, and third-party APIs often process significantly more personal data than their buyers realise. The penalties for getting this wrong start at up to €10 million or two per cent of global turnover for certain infringements, and up to €20 million or four per cent for others. More often, the real cost is reputational damage, loss of client trust, and the operational paralysis that follows an enforcement notice from the Information Commissioner's Office or a European data protection authority.

This guide explains what GDPR and UK GDPR require when you deploy custom AI agents that touch personal data. It covers lawful basis, data minimisation, the role of data processing agreements, transfer mechanisms when your agent uses US-based models, and the audit trails you need to respond to data subject rights. It is written for founders, operations leads, and in-house counsel at SMBs in recruitment, professional services, marketing, and ecommerce, where GDPR AI compliance is a board-level risk, not an IT footnote.

What counts as personal data when an AI agent processes it

Personal data is any information relating to an identified or identifiable natural person. That includes obvious identifiers like names, email addresses, phone numbers, and postal addresses, but it also includes IP addresses, cookie identifiers, device fingerprints, job titles when combined with employer name, CV text, interview notes, customer service transcripts, purchase histories, and behavioural metadata that can single someone out. Under GDPR, special category data (health, biometric, genetic, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation) attracts additional restrictions and usually requires explicit consent or another narrow lawful basis.

When you deploy an AI agent, the question is not whether it processes personal data in a loose sense, but whether it performs any operation on personal data within the scope of GDPR. Processing is defined as any operation or set of operations performed on personal data, whether automated or not, including collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure by transmission, dissemination, restriction, erasure, or destruction. An AI agent that reads inbound emails, extracts sender details, and writes a summary has processed personal data at collection, structuring, and storage. An agent that enriches a lead record with LinkedIn profile data has processed personal data by retrieval and combination. An agent that generates a customer support response based on ticket history has processed personal data by consultation and use.

The GDPR AI intersection is that most large language model APIs, vector databases, and retrieval-augmented generation pipelines involve multiple processing operations, often across several legal entities and jurisdictions. If your custom AI agent sends a user query containing a name to OpenAI's API, OpenAI processes that data as your processor (if you have signed their data processing addendum) or potentially as a joint controller (if the model training terms are ambiguous). If the agent logs the query to a Pinecone vector index hosted in AWS us-east-1, you have made a transfer of personal data to the United States, and you need a transfer mechanism under Chapter V of GDPR. If the agent retrieves a historical conversation from your CRM, enriches it with external data, and generates a response, you have combined data from multiple sources, which triggers data minimisation and purpose limitation obligations.

The practical test is simple. Open your agent's data flow diagram. Trace every API call, every database write, every log line, and every model request. If any step involves information that relates to an identified or identifiable person, you are processing personal data, and GDPR applies.

Establishing a lawful basis for AI agent processing

**GDPR requires a lawful basis for every processing activity.** Article 6(1) lists six bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. For most SMBs deploying custom AI agents, the choice is between contract (Article 6(1)(b)), legitimate interests (Article 6(1)(f)), and consent (Article 6(1)(a)). Each has different requirements, and choosing the wrong one is a common root cause of compliance failures.

Contract is the cleanest basis when the AI agent performs processing that is necessary to deliver a service the data subject has signed up for. If a customer books a call through your website and your AI agent confirms the appointment via email, that processing is necessary to perform the contract. If a recruitment agency candidate submits a CV and your AI agent parses it to match them with open roles, that is contract, provided the terms of service make matching explicit. The test is necessity. If you could deliver the same service without the AI agent processing that data, contract may not hold, and you need a different basis.

Legitimate interests is more flexible but requires a three-part test: you must identify a legitimate interest (for example, improving operational efficiency or preventing fraud), demonstrate that the processing is necessary to achieve that interest, and show that the data subject's rights and freedoms do not override your interest. For GDPR AI agents, legitimate interests works when the processing is not strictly necessary to perform a contract but serves a genuine business need that is proportionate and expected. An AI agent that analyses support ticket trends to improve response times, without processing identifiable data in model training, may qualify. An agent that scrapes LinkedIn profiles to enrich sales leads without clear notice may not. You must document the balancing test in your legitimate interests assessment, and you cannot rely on this basis for special category data without meeting one of the Article 9(2) conditions.

Consent is the basis of last resort for most AI agent use cases in a commercial setting. GDPR consent must be freely given, specific, informed, and unambiguous, and it must be as easy to withdraw as it was to give. For an AI agent that processes personal data in ways that are not covered by contract or legitimate interests, consent is an option, but it is operationally fragile. If a user withdraws consent, you must stop processing immediately and delete their data unless you have another lawful basis. In practice, this means consent is best suited to optional features, like an AI chatbot that personalises responses based on browsing history, where the user can opt in or out without breaking the core service.

For custom AI agent development, the lawful basis must be documented before processing starts, not reverse-engineered after deployment. Our /solutions/ai-agent-development workflow includes a data protection impact assessment at scoping, where we map every data flow, identify the lawful basis for each processing purpose, and confirm that the basis is documented in your privacy policy and terms. If the agent will process special category data, we map the Article 9(2) condition and confirm whether you need explicit consent, a collective agreement, or another gateway. This is not a tick-box exercise. It is the foundation of defensible AI GDPR compliance.

Data minimisation and purpose limitation for AI agents

**GDPR's data minimisation principle requires that personal data be adequate, relevant, and limited to what is necessary for the purposes for which it is processed.** For AI agents, this principle is often the hardest to satisfy because large language models and vector retrieval pipelines are designed to ingest as much context as possible to improve output quality. The tension is real. A sales agent that has access to every historical email, every CRM note, and every support ticket will generate better responses than one with access to only the current lead record, but the former approach is almost certainly excessive under GDPR.

The minimisation test is purpose-specific. If the purpose is to qualify inbound leads by extracting company name, job title, and pain points, the agent does not need access to previous purchase history, support tickets, or personal contact preferences. If the purpose is to generate a renewal proposal, the agent may need contract value and usage data but not the full text of every support conversation. The question is what data is necessary, not what data is available. Necessity is a legal standard, not an engineering preference.

In practice, data minimisation for GDPR custom AI agents means field-level access control, context windowing, and data masking. If your AI agent queries a CRM, it should request only the fields it needs for the task, not the entire record. If it retrieves historical conversations for context, it should fetch the most recent three exchanges, not the entire relationship archive. If it processes support tickets, it should mask or pseudonymise names, email addresses, and phone numbers unless those identifiers are necessary for the response. Klevere's AI OS recruitment agent, for example, processes candidate CV text and match criteria but does not store identifiable contact details in the vector index. Contact information stays in the client's CRM, and the agent retrieves it only at the point of outreach, under a separate lawful basis.

Purpose limitation, the twin of data minimisation, requires that personal data collected for one purpose is not reused for an incompatible purpose without a new lawful basis. If you deploy an AI agent to qualify sales leads based on inbound enquiries, you cannot later train a marketing model on those enquiries without checking whether the original privacy notice covered model training and whether your lawful basis permits that reuse. If the original purpose was contract and the new purpose is marketing, you likely need consent or a fresh legitimate interests assessment. This is a common failure mode when companies treat AI agent logs as general-purpose training data without revisiting the original processing purpose.

Our approach on the /solutions/ai-audit page includes a data flow review against the minimisation and purpose limitation principles. We map every data source the agent will access, confirm that each field is necessary for the documented purpose, and recommend masking, aggregation, or access restrictions where the data is excessive. If the agent will use personal data for secondary purposes like model fine-tuning or quality assurance, we document that purpose in the privacy policy and confirm that the lawful basis extends to it. This is not gold-plating. It is the baseline for defensible ai agent data protection under GDPR.

Data processing agreements and the controller-processor relationship

**When you engage a vendor to build or host a custom AI agent that processes personal data on your behalf, GDPR requires a written data processing agreement under Article 28.** This agreement must specify the subject matter, duration, nature, and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller (you). It must also require the processor (the vendor) to process data only on your documented instructions, to implement appropriate technical and organisational measures, to ensure confidentiality, to assist with data subject rights requests, to delete or return data at the end of the engagement, and to submit to audits.

For GDPR AI agents, the controller-processor boundary is often blurred because AI development involves iterative prompt engineering, model selection, and retrieval tuning, all of which involve the vendor making processing decisions. GDPR treats anyone who determines the purposes and means of processing as a controller, and anyone who processes data on behalf of a controller as a processor. If the vendor chooses the model, the embedding strategy, the retention period, or the logging level, they may be determining means, which can shift them toward joint controller status. Joint controllership requires a transparency arrangement under Article 26, not just a processing agreement, and it makes both parties liable for compliance.

The safest approach is to specify every material processing decision in the statement of work before the build starts. Define which model family the agent will use (for example, OpenAI GPT-4, Anthropic Claude, or Google Gemini). Define the embedding provider, the vector database, the retention period for logs, the geographic region for data residency, and whether the agent will use retrieval-augmented generation with your proprietary data. Define whether the agent will be fine-tuned and, if so, whether personal data will appear in the fine-tuning dataset. Define who controls the prompt templates and whether the vendor can update them without your approval. The more granular the instruction, the stronger the processor relationship and the weaker any joint controller argument.

Klevere's standard engagement model documents processing instructions in the project scope, signs a data processing addendum before build, and delivers the agent under a deployment architecture where the client retains access control over all personal data. Our DPA commits to GDPR Article 28 requirements, ISO 27001 and SOC 2 Type II controls, regional data residency options (EU, UK, US), and zero-knowledge processing wherever feasible. If a client needs to subcontract embedding or model inference to OpenAI, Anthropic, or Google, we confirm that each subprocessor has signed a compliant data processing agreement, and we list those subprocessors in the DPA. This is standard for gdpr custom ai work. If a vendor cannot produce a data processing agreement or insists on training their own models on your data without restriction, walk away.

Transfer mechanisms when your AI agent uses US-based models

**Most commercial large language model APIs are operated by US-based companies, which means any API request containing personal data is a transfer of personal data to a third country under GDPR Chapter V.** After the Schrems II decision invalidated the EU-US Privacy Shield, and after the European Commission adopted the adequacy decision for the EU-US Data Privacy Framework in July 2023, the compliant transfer route for US-based processors is either DPF certification or standard contractual clauses plus supplementary measures. The UK has a parallel adequacy decision for the UK extension to the DPF. If your AI agent sends personal data to OpenAI, Anthropic, or Google in the US, you need to confirm the transfer mechanism.

The Data Privacy Framework covers organisations that self-certify and maintain active certification on the DPF list. OpenAI, Anthropic, and Google Cloud are certified as of mid-2026, which means transfers to their US entities are permitted under the adequacy decision without additional contractual clauses, provided they process data within the scope of their certification. The practical issue is that DPF certification is self-certified and can lapse, so you must check the status before deployment and periodically thereafter. If a processor's certification lapses mid-contract, you must fall back to standard contractual clauses or stop the transfer.

Standard contractual clauses are template contracts approved by the European Commission (or the UK's ICO equivalent for UK GDPR) that impose data protection obligations on the importer and provide enforceable rights for data subjects. SCCs alone are not sufficient after Schrems II. You must also conduct a transfer impact assessment to evaluate whether the laws of the destination country allow government access to personal data in a way that undermines GDPR protections. If the assessment identifies risks, you must implement supplementary measures, such as encryption in transit and at rest, pseudonymisation, data minimisation, contractual prohibitions on disclosing data to government authorities without data subject notice, and transparency about any requests. For AI agent data protection, encryption and pseudonymisation are the most practical supplementary measures, but they are effective only if the model provider cannot decrypt the data.

Klevere's default architecture for GDPR AI deployments keeps personal data within EU or UK regions wherever possible. Our /ai-os/sales-agent and /ai-os/support-agent offerings can be deployed on EU-region infrastructure using models from providers with EU data residency commitments, such as Azure OpenAI Service in the EU or Google Vertex AI in the EU. When a client requires a US-based model, we confirm DPF certification, execute SCCs, and conduct the transfer impact assessment as part of the build. We document the transfer mechanism in the client's privacy policy and the data processing agreement, and we flag expiry dates for DPF certification so the client can monitor compliance. This is table stakes for GDPR custom AI in any regulated industry.

Responding to data subject rights requests when an AI agent processed the data

**GDPR grants data subjects the right to access their personal data, the right to rectification, the right to erasure, the right to restriction of processing, the right to data portability, and the right to object, plus the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects.** When a data subject exercises one of these rights, the controller must respond within one month (extendable by two further months in complex cases), and they must demonstrate compliance. For AI agents, the compliance burden is technical. You must locate every instance of the data subject's personal data in your system, including training datasets, vector indexes, model fine-tuning data, API logs, and audit trails. You must explain the processing, the lawful basis, the retention period, and the logic of any automated decisions. You must correct inaccurate data, delete data when required, and suppress processing when requested.

The right of access is the most common request and the hardest to satisfy for AI agents. The data subject is entitled to a copy of their personal data, information about the purposes of processing, the categories of data, the recipients, the retention period, and the existence of automated decision-making, including meaningful information about the logic involved. If your AI agent made a decision that affected the data subject (for example, rejecting a loan application, declining a recruitment match, or assigning a customer service priority), you must explain how that decision was reached. This does not mean providing the model weights or the prompt template, but it does mean describing the inputs, the processing steps, and the factors that influenced the output. If you cannot do that, you cannot comply.

The right to erasure (the right to be forgotten) requires you to delete personal data without undue delay when the data is no longer necessary, when the data subject withdraws consent, when they object under legitimate interests and you have no overriding grounds, or when the data was unlawfully processed. For GDPR AI agents, erasure is complicated because personal data may be embedded in vector indexes, baked into fine-tuned model weights, or logged in immutable audit trails. You cannot erase data from a fine-tuned model without retraining the model, and you cannot erase data from an immutable log without breaking the audit chain. The legal answer is that if you designed the system knowing you might receive erasure requests, you must have a deletion process that works. If you did not, you are in breach.

Klevere's AI agent architectures separate identifiable personal data from model context by design. Personal data lives in the client's CRM, database, or data warehouse under the client's access control. The AI agent retrieves data at query time, processes it in memory, and does not persist identifiable data in vector indexes or model training data. Logs are pseudonymised by default, with the key held separately so that erasure requests can be honoured by deleting the key. When a data subject rights request arrives, the client deletes the record in their system, and the agent no longer retrieves it. This pattern is not legally required, but it is the only pattern that makes compliance operationally feasible at scale. If your vendor cannot explain how they handle erasure requests, they have not thought about GDPR AI compliance.

Documentation, audit trails, and accountability under GDPR

**Article 5(2) of GDPR requires controllers to be able to demonstrate compliance with the principles, which means documentation is not optional.** For AI agents, the accountability burden includes records of processing activities, data protection impact assessments for high-risk processing, legitimate interests assessments, transfer impact assessments, data processing agreements, privacy policies, internal training records, and incident response logs. The ICO and European authorities increasingly use documentation failures as the basis for enforcement, even when no data breach has occurred. If you cannot produce a data flow diagram, a lawful basis assessment, or a DPA when asked, you are not compliant, even if the agent itself is well-designed.

A record of processing activities under Article 30 must list the name and contact details of the controller, the purposes of processing, the categories of data subjects and personal data, the categories of recipients (including processors and third countries), the retention periods, and a general description of security measures. For GDPR AI agents, this record must distinguish between processing activities. Lead qualification is a different activity from customer support, which is different from recruitment matching. Each activity has its own lawful basis, its own retention period, and its own security measures. Bundling everything under one generic 'AI processing' entry is insufficient.

A data protection impact assessment is required when processing is likely to result in a high risk to the rights and freedoms of individuals, particularly when using new technologies, when processing special category data, when making automated decisions with legal or significant effects, or when processing on a large scale. GDPR AI agents that analyse CVs, score leads, route support tickets, or generate contract summaries are often high-risk and require a DPIA before go-live. The DPIA must describe the processing, assess necessity and proportionality, identify risks to individuals, and document mitigation measures. If the residual risk is high, you must consult the relevant data protection authority before processing starts.

Audit trails are the final piece. GDPR does not explicitly require logs of every processing operation, but Article 5(2) accountability and Article 15 access rights effectively do. When a data subject asks what processing occurred, you must be able to answer with specificity. This means your AI agent must log every query, every retrieval, every API call to an external model, and every decision output, with timestamps, user identifiers, and enough context to reconstruct the processing. Logs must be tamper-evident and retained for long enough to respond to access requests and regulatory investigations, but not so long that you violate data minimisation. The sweet spot is usually 12 to 24 months, with a documented retention policy and a process to anonymise or delete logs after the period expires.

Klevere's compliance posture includes SOC 2 Type II and ISO 27001 certification, both of which require documented policies, access controls, change management, and incident response. For clients deploying ai gdpr compliance-sensitive agents in recruitment, financial services, or legal, we deliver a compliance pack that includes the DPIA template, a sample records of processing entry, a data flow diagram, and a retention schedule. This is included in the /solutions/ai-agent-development scope at no extra cost, because we see compliance as a build requirement, not a post-go-live bolt-on. If you are comparing vendors and one offers to 'deal with GDPR later', you know what to do.

How Klevere approaches GDPR for custom AI agents

We treat GDPR AI compliance as a scoping question, not a legal afterthought. Every AI agent build starts with a data protection impact assessment, where we map data flows, confirm lawful basis, identify transfer mechanisms, and agree on retention and deletion policies before a single line of code is written. We document processing instructions in the statement of work, execute a data processing agreement before build, and deliver agents under architectures that separate identifiable data from model context. Our standard DPA meets GDPR Article 28 requirements, includes regional data residency options, and lists all subprocessors with their own compliant agreements.

Our AI OS offerings, including the /ai-os/sales-agent, /ai-os/support-agent, and recruitment agent, are deployed with pseudonymisation and encryption by default, and we configure retention policies to match the client's documented processing purposes. For custom builds on the /solutions/ai-agent-development track, we conduct a transfer impact assessment if the agent will use US-based models, confirm Data Privacy Framework certification, and implement supplementary measures where required. We deliver audit trails that log every query, retrieval, and decision, with tamper-evident storage and automatic anonymisation after the retention period. If a client receives a data subject access request, we provide query tools that surface every instance of the data subject's personal data in the agent's logs and context store.

We also train client teams on GDPR fundamentals during handover, covering lawful basis, data minimisation, and how to respond to common data subject rights requests. This is not a compliance theatre exercise. It is the operational knowledge your team needs to run the agent without calling a lawyer every week. For clients in recruitment, professional services, or ecommerce, where GDPR risk is material, we recommend starting with a free /solutions/ai-audit to map existing data flows, identify gaps, and scope remediation before deploying new AI agents. The audit is a 30-minute structured conversation followed by a written summary of findings and recommendations. Book one at /contact if you are unsure whether your current setup would survive an ICO investigation.

What to do next if you are deploying GDPR AI agents

If you are planning to deploy or have already deployed an AI agent that processes personal data, start with a data flow audit. Map every source of personal data the agent accesses, every API it calls, every log it writes, and every jurisdiction data passes through. Confirm the lawful basis for each processing purpose, check that your privacy policy describes the processing, and verify that you have signed a data processing agreement with every vendor in the chain. If the agent uses a US-based model, confirm Data Privacy Framework certification or execute standard contractual clauses with a transfer impact assessment. If the agent makes automated decisions with legal or significant effects, check whether you need a data protection impact assessment and whether you are meeting the Article 22 transparency requirements.

For SMBs without in-house data protection expertise, the most common mistake is assuming that GDPR AI compliance is someone else's problem. If you are the client deploying the agent, you are the controller, and you are liable for compliance, even if the vendor built the agent. The DPA does not transfer that liability. It just defines the processor's obligations. If the agent breaches GDPR, the ICO will come to you first, and your recourse against the vendor is contractual, not regulatory. This is why documenting processing instructions, retention periods, and deletion processes in the contract is not optional. It is your evidence that you took reasonable steps.

Klevere deploys AI agents under GDPR-compliant architectures as standard. We hold SOC 2 Type II and ISO 27001, we execute data processing agreements before build, we support EU and UK data residency, and we deliver agents with audit trails and deletion processes that meet Article 17 requirements. If you are comparing vendors, ask them for their DPA template, ask where data will be processed, ask how they handle erasure requests, and ask whether they conduct DPIAs. If they cannot answer, they are not ready for GDPR custom AI work. Book a free AI audit at /contact to map your current risk, or visit our /solutions/ai-agent-development page to see how we scope compliance into every build from day one.