AI data leak: how client data escapes your Irish apps

An AI data leak in your own software rarely looks like a hack. It looks like a developer’s debug log full of client names, a retrieval step that pulls the wrong file into a prompt, or a model calling a tool with a PPS number in its arguments. The data leaves through calls your application makes on purpose, and nobody sees it go.

Nonimo Gateway runs on your own servers. See plans and get in touch.

For an Irish business the consequence is not abstract. Under the GDPR and the Data Protection Act 2018 your firm is the controller of that data wherever the copies end up, and an exposed copy may be a breach you have 72 hours to report to the Data Protection Commission. The fix is the same in every case: send less, pseudonymise what you send, and keep the key at home.

The five routes of an AI data leak

These are the places personal data travels when an application calls an LLM API. Most firms have thought about the top one and few have mapped the rest.

route	how data gets out	who ends up holding it
the prompt	the user’s text and your system prompt go to the provider	the model provider
logs	your app, your gateway and your monitoring tools record requests	you, and any tool vendor
retrieval (RAG)	document chunks are pulled into the prompt automatically	the provider, plus your vector store
tool calls	the model passes arguments to functions you expose	the provider and the target system
provider retention	the provider keeps requests for abuse monitoring	the model provider, for a period

The prompt

This is the obvious one. A staff member pastes a client’s email into an internal tool, and the tool forwards it whole. The question is whether the task needed what was in it. Our list of what personal data to remove before AI applies just as much to text your app sends as to text a person pastes.

Logs

Every layer likes to log. Your web framework logs request bodies when an error occurs; your AI gateway records prompts for cost tracking; your error tracker captures the payload of a failed call. Each copy is personal data with its own retention, and the DPC’s guidance on AI asks for a retention schedule precisely so that inputs are not kept indefinitely. Cloud tools are no exception: AWS’s documentation for Bedrock Guardrails states that the input field in its CloudWatch invocation logs always contains the original, unmodified request, even where the guardrail masks data.

Retrieval

Retrieval-augmented generation puts your own documents into the prompt, chosen by similarity rather than by a person. If the store holds client files, the model can receive a paragraph about one client while answering a question about another. The provider then holds that paragraph too.

Tool calls

When a model can call functions, the arguments it generates are another channel. A booking tool might receive a name, a date of birth and an Eircode. The same AWS page says that in tool use workloads Bedrock Guardrails does not evaluate the tool call arguments, results or definitions, which is a useful reminder to check what any filter actually inspects.

Provider retention

The provider keeps a copy for a while even when it does not train on it. OpenAI’s data controls documentation says API data is not used for training by default and that abuse monitoring logs are kept for up to 30 days, with Zero Data Retention available on approval. Our guide to what ChatGPT keeps covers the consumer side.

When an AI data leak becomes a breach

Article 4(12) of the GDPR defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration or unauthorised disclosure of, or access to, personal data. Sending a prompt to a provider you have an Article 28 contract with is processing, not a breach. The leak becomes a breach when the copy lands somewhere you did not authorise: an exposed log bucket, a third-party monitoring tool with no agreement, a retrieval answer shown to the wrong customer.

At that point Article 33 applies. The DPC’s breach notification page asks organisations to report within 72 hours of becoming aware of a breach that presents a risk to individuals. The less a log holds, the smaller that risk, which is why minimising at source is worth more than any clean-up.

A worked example from a Dublin letting agent

The firm and the people are invented. A letting agent in Dublin 8 builds a tool that drafts replies to tenant queries. A typical request carries the tenant’s name, the PPSN copied from the application file, the address and a note about rent arrears. The app logs every request in full to help the developer, and retrieval pulls in the tenancy agreement.

Map it against the five routes and the leak is easy to see. The PPSN is in the prompt, the log and the provider’s 30-day monitoring copy, and nothing in the reply needs it. The arrears note is financial information about a named person, held in three places. Applying four steps changes that:

1. Minimise. The tool stops reading the PPSN from the file. The model never needed it.
2. Pseudonymise before the call. The tenant’s name and address become [PERSON_1] and [ADDRESS_1] before the request leaves.
3. Keep the key. The mapping from placeholder to real value stays on the agent’s own server, not in the prompt or the log.
4. Restore in the answer. The draft comes back with placeholders and the real values are filled in before staff read it.

The log now records placeholders. The provider’s copy holds no name, no address and no PPS number. If the log were ever exposed, it would say much less about anyone.

How to stop data leaking through your LLM calls

The steps above generalise into a short checklist for any Irish team building on an LLM API:

• Read your own logs for a day and count what personal data appears in them.
• Remove identifiers from the data source where the task does not need them; a CSV export is a common culprit.
• Put pseudonymisation between your app and the provider, so every call is covered, not just the ones someone remembered.
• Keep the mapping on your infrastructure and out of every log.
• Check what any filter inspects: prompt, response, streaming, tool calls. Our comparisons of the Kong AI Gateway and Portkey go through this point by point.

Nonimo Gateway, briefly

Nonimo Gateway puts that step in one place. It runs on your own servers, and the content does not pass through Nonimo. It is OpenAI-compatible, so you point your base_url at it. It replaces personal data before the request leaves and restores it in the response, and you keep your own OpenAI key. It is also available as a LiteLLM plugin. Plans and prices are on the Nonimo Gateway page. It helps you pseudonymise; minimising what you collect remains your call.

Where the proxy sits in your architecture is covered in our guide to an AI gateway for Irish firms, and whether you need a model of your own is in private LLM or privacy proxy. If your apps already send client data to an LLM, find the five routes in your own code this week. See Nonimo Gateway’s plans and get in touch.

Sources

Checked 20 October 2026.

• Regulation (EU) 2016/679, the GDPR. Article 4(12), the definition of a personal data breach; Article 5(1)(c) on data minimisation; Article 28 on processors; Article 33 on notifying the supervisory authority.
• Data Protection Commission, breach notification. Reporting within 72 hours of becoming aware of a breach that presents a risk to individuals.
• Data Protection Commission, AI, Large Language Models and Data Protection, 18 July 2024. Whether inputs are retained or reused; the need for a retention schedule.
• OpenAI, Data controls in the OpenAI platform. API data not used for training by default; abuse monitoring logs retained for up to 30 days; Zero Data Retention on approval.
• AWS, Bedrock Guardrails sensitive information filters. CloudWatch invocation logs keep the original request; tool call arguments, results and definitions are not evaluated.