GDPR compliant AI agents: how to build them for the US, UK and Canada

Compliance is mostly an architecture question

Most questions we get about GDPR and AI agents start with the model: which provider, which region, does it train on our data. Those matter, but they are rarely where an agent goes wrong. An agent reads records, decides what to do, and then writes to your systems: it sends an email, updates a CRM record, closes a ticket. Data protection risk sits in all three steps, and most of it is decided by how the system is built, not by which model sits inside it.

This guide covers what we design into agents for clients in the US, the UK and Canada, and what each region's rules add. It is written from the builder's side. It is not legal advice, and decisions on lawful basis, notices and contracts belong to you and your counsel.

Which rules apply depends on whose data it is

GDPR follows the people in the data, not where your company is registered. A US or Canadian business that offers goods or services to people in the EU or the UK, or monitors their behavior, can be in scope. For the businesses we work with, the picture usually looks like this:

• UK: UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025, with most of its data protection changes in force during 2026. The ICO is the regulator, and its guidance on AI and data protection is the best place to start.
• EU: the GDPR itself and, for some uses, the EU AI Act, which adds its own obligations for systems in high risk areas such as hiring and credit.
• Canada: PIPEDA for private sector organizations in most provinces. Quebec's Law 25 adds specific duties, including telling people when a decision about them was made exclusively by automated processing. Alberta and British Columbia have their own private sector privacy laws.
• US: no single federal privacy law. State laws such as the California Consumer Privacy Act, and comprehensive laws in Colorado, Virginia, Texas and other states, set rules on notice, opt outs and profiling. California's regulations on automated decisionmaking technology add obligations from January 2027 for businesses in scope. Sector rules such as GLBA for financial data and HIPAA for health data apply on top.

The common ground is larger than the differences. Know what personal data the agent touches and why, use no more than it needs, tell people, keep a person in significant decisions, secure it, and delete it on schedule. Each of those translates into a design choice.

Start with a data map of the workflow, not the model

Before we write code, we list every step of the workflow and record, for each one, which records the agent reads, which fields hold personal data, and what it writes back. That list feeds your record of processing and, where needed, a data protection impact assessment. Under UK and EU GDPR, an agent that makes or supports decisions about people, or handles special category data, will usually need a DPIA.

The useful output is a short list of fields the agent actually needs. An agent that triages support tickets needs the ticket text and the customer's plan. It does not need a date of birth or payment history. Data minimization is easiest to enforce here, by never giving the agent a tool that returns the extra fields in the first place.

Scope retrieval in the query

Agents that use retrieval, such as a vector store of documents, emails or past cases, are where personal data leaks most quietly. If one store holds data for several clients, teams or regions and the agent filters results after retrieval, correctness depends on that filter being right every time. We scope the query itself, so a request can only return records the current user and purpose are allowed to see. We explain why in retrieval scope belongs in the query.

The same applies to logs and traces. Prompt logs often end up holding more personal data than the source system. Decide what gets logged, redact what you can, and give logs the same retention rules as the data inside them.

Keep a person on decisions that matter

UK and EU GDPR restrict decisions based solely on automated processing that have legal or similarly significant effects on someone. The Data (Use and Access) Act changed how the UK frames these rules, but safeguards such as the right to human intervention and to contest a decision remain. Quebec requires notice of decisions made exclusively by automated processing, and California's new rules target automated decisionmaking in significant decisions.

Our default is that an agent prepares and a person decides. Reads run freely. Every write that cannot be undone, or that affects a person, stops at an approval gate that shows the reviewer exactly what will change. For a loan file, the agent assembles documents and flags gaps, and an underwriter decides. For hiring, the agent quotes the evidence for each requirement, and a recruiter decides. A gate only counts as real human review if the reviewer has the information and the authority to say no, so we show the evidence, not just a score. The reasoning is in why autonomous agents need approval gates.

Control where data goes

Three questions come up on every engagement.

1. Model provider. Check the provider's data processing terms, whether inputs are retained or used for training, and which regions are available. Business API terms commonly exclude training on your data, but retention periods and abuse monitoring differ, and you need a processor agreement in place. 2. Hosting. We deploy into your cloud accounts, so data stays under your control and your existing contracts. The details are on security and data. 3. People with access. Any team that can see personal data from another country raises a transfer question. Our engineers work from Pakistan. We build and test on seeded data in demo mode, and when production access is needed, it is scoped, logged and covered by the transfer mechanism your counsel chooses, such as the EU standard contractual clauses, the UK International Data Transfer Agreement or the UK addendum.

Being upfront about the third point avoids problems later, and it applies to any offshore or nearshore team, not only ours.

Build for access and deletion requests

People can ask to see, correct or delete their data under UK and EU GDPR, PIPEDA and many US state laws. An agent creates extra copies: embeddings, cached summaries, conversation memory and logs. Each needs to be findable by person and deletable. We key derived data back to its source record, so deleting a customer also removes their embeddings and memory, and we set retention per store instead of keeping everything by default.

Test before it touches real data

We run the whole system end to end on seeded data before it connects to a live system, including rate limits and malformed responses. For data protection, the tests that matter are simple to state. Can a user retrieve another tenant's record? Does a redacted field reappear in a summary? Does deletion remove every derived copy? Does every write that affects a person hit the gate? These become evals that run on every change. More in evaluate before you connect.

Integrations ship behind feature flags, so a connector can be switched off without a rebuild if a problem shows up. See integrations.

A practical checklist

• A data map for each workflow step: fields read, fields written, purpose.
• A lawful basis and notice for each purpose, decided with counsel.
• A DPIA where the agent supports decisions about people.
• Tools that return only the fields the agent needs.
• Retrieval scoped in the query, and logs redacted and on a retention schedule.
• An approval gate on every irreversible write and every significant decision.
• Processor terms with the model provider, and hosting in your accounts.
• A transfer mechanism for any team with cross border access.
• Deletion that reaches embeddings, memory and logs.
• Evals for leakage, redaction, deletion and gate coverage.

How a first project usually looks

We start with one workflow, map its data, and build a custom agent for it in demo mode with the gates in place. Your privacy lead or counsel reviews the data map and the gate design before anything connects to production. You own the code, prompts and evals from the first commit, which makes your own review and any later audit simpler.

If you are planning an agent that touches customer or employee data in the US, UK or Canada, book a call and we will tell you plainly what we would build and where a person should stay in charge.