GDPR and AI for Irish businesses

This is general information, not legal advice. Rules and guidance change; check current terms with the Data Protection Commission or a solicitor before making a compliance decision.

Yes. GDPR applies to any processing of personal data, and it doesn't matter whether a person, a spreadsheet macro or an AI agent is doing the processing: your business is still the data controller and still carries the legal obligations that come with that.

If an AI agent reads customer emails, updates a CRM record, matches a bank transaction to an invoice, or drafts a reply to someone's enquiry, it is processing personal data the same way a staff member doing that job would be. The Irish Data Protection Commission (the DPC), the body that regulates data protection here, has been explicit that organisations must ensure AI systems comply with GDPR "from the outset" rather than treating it as an afterthought once the tool is already live (DPC, "AI, Large Language Models and Data Protection," 18 July 2024). The practical upshot for a small business: before an agent goes anywhere near customer data, you need to know what it's touching, why, and under what legal basis. This matters most acutely wherever the data itself is sensitive. See AI for clinics and practices for how that plays out in a setting where a chunk of the admin sits close to health data without ever needing to touch it.

For most day-to-day business admin, such as inbox triage, invoice chasing, CRM updates and support replies, the lawful basis is usually the same one you already rely on for a staff member doing that job: performance of a contract, a legal obligation, or legitimate interest.

Legitimate interest is the one worth understanding properly, because it's the basis most businesses lean on for operational AI use. It requires a genuine three-part test: the purpose has to be a real business interest, the processing has to be necessary to achieve it (not just convenient), and that interest has to be balanced fairly against the individual's rights and reasonable expectations. The European Data Protection Board's opinion on AI models sets out that balancing test explicitly, and gives examples, such as running a customer-facing conversational agent, where legitimate interest can apply, provided the assessment is genuinely done rather than assumed (EDPB Opinion 28/2024, 18 December 2024). If your AI agent is doing a job a person could reasonably be expected to do with that data (reading a support inbox, matching payments), the same lawful basis you'd document for a hire is usually the right starting point. It still has to be written down and kept current, not assumed.

Where lawful basis gets genuinely harder is anything closer to profiling, automated decisions with legal or similarly significant effect on a person (like automatically declining a customer, not just drafting a reply for a human to send), or using customer data to improve a model rather than to do the job in front of it. Those cases need their own assessment, and often a Data Protection Impact Assessment, before you proceed.

Data minimisation means giving the agent access to only the data it needs for its specific job, not a general login to every system "in case it's useful later."

The DPC's guidance flags a real risk here: broad or loosely scoped access to data can lead to "unwanted, unneeded or unanticipated processing of personal data" that nobody explicitly authorised and nobody is tracking (DPC, AI, LLMs and Data Protection, 2024). This is a design decision, not a policy statement: an AI employee built to chase overdue invoices should have access to the accounts data that job requires, not a standing connection to every customer record in the CRM. The same principle applies to what the agent is allowed to do with what it sees: reading an inbox to triage it is a narrower act of processing than storing every email's contents in a separate log "for reference." Before any agent goes live, you should be able to state plainly, in one sentence, what data it touches and why. If you can't, the scope is too wide.

When an AI agent uses a large language model to read or generate text, the relevant content (an email, a transaction description, a customer message) is sent to that model provider's infrastructure to be processed, and the terms governing that transfer, storage and retention are set by the provider's contract, not by your business.

This is the step most business owners haven't thought through, and it's the one that matters most. The DPC's guidance specifically warns about "memorisation" risk (the possibility that a model unintentionally retains and later reproduces fragments of what it processed) and about the difficulty of exercising data subject rights (access, correction, deletion) once data has passed into a system you don't control (DPC, AI, LLMs and Data Protection, 2024). Before any customer data reaches a model provider, you need to know: what the provider's contract says about training on your data, how long they retain it, where their servers are, and what their own sub-processors do with it. None of that is visible from the outside of a typical AI product. It's written into the vendor's terms, and most business owners never read that far.

"EU-hosted" tells you where a shared platform's data centre physically sits. It tells you nothing about who controls the account, who else's data shares that infrastructure, or what happens to your data if you stop paying.

A lot of AI vendors lead with "EU-hosted, GDPR-aligned" as a trust signal, and it isn't meaningless: data residency within the EU does simplify some cross-border transfer questions. But it's a claim about geography, not about control. Your data can be EU-hosted and still sit in a shared multi-tenant database alongside hundreds of other businesses' data, governed entirely by the vendor's terms, with your access to it ending the moment you cancel. A private server your business actually owns is a different and stronger position: the data sits on infrastructure dedicated to your business alone, and the question of "where is it and who can see it" has a much shorter, more concrete answer. See infrastructure you own for how that model works and what it changes about the GDPR conversation specifically. It doesn't remove your obligations as controller, but it changes what you can honestly say when a client or a regulator asks where their data actually is.

A Data Processing Agreement (DPA) is the contract required by GDPR whenever a third party processes personal data on your behalf, and it's the mechanism that makes an AI vendor's handling of your data legally accountable rather than just a line in a privacy policy.

The DPC's guidance on controller-processor relationships is explicit that this contract is a legal obligation, not a courtesy, and sets out the minimum provisions it must contain (DPC, "A Practical Guide to Controller-Processor Contracts"). At minimum, before signing up to any AI tool that will touch personal data, check that a DPA exists, that it names the categories of data being processed and the purpose, that it says what happens to the data on termination, and that it discloses any sub-processors (which, for most AI tools, includes the underlying model provider itself: your AI CRM add-on almost certainly has its own processing agreement with a model provider behind it, and that chain matters). If a vendor can't produce a DPA on request, that's a real answer about how seriously they take this, not a technicality to skip past.

Ask, plainly: what data does this touch, where does it go, who else can see it, what happens to it if we leave, and can you show me the contract that says so.

More specifically, a short list worth asking every vendor, whether it's a SaaS subscription or an agency building something bespoke:

• What personal data does the AI system process, and is that documented anywhere you can show me?
• Is my data used to train or improve the underlying model, and can that be turned off?
• Where is the data stored, and does a Data Processing Agreement cover the arrangement?
• What happens to our data if we cancel or the relationship ends?
• Who are the sub-processors, including which model provider sits underneath the product?
• Is the account and its data pooled with other customers, or dedicated to us?

A vendor that answers these clearly and quickly is a reasonable sign. A vendor that can't, or answers with marketing language instead of specifics, is worth being cautious about regardless of how capable the product looks.

GDPR sits alongside a second, newer set of rules specifically for AI systems. See the EU AI Act for small business for what that adds, and where should your AI agents run for how hosting choices affect both. If you're weighing up whether a specific job in your business is worth automating given the data involved, ask us whether it's worth automating, or send a brief describing the job, and the data protection conversation happens as part of mapping the work.