AI and GDPR: how Hungarian companies can use LLMs lawfully

The most common GDPR question we get before an LLM project starts is: "Are we even allowed to give customer data to AI?" The answer in 2026: yes, under the same conditions as any other data processor — most companies just don't know where to look for those conditions. The second most common question: "Is it enough if we anonymise the data?" The answer to that: it depends on what you mean by anonymisation, and in most cases what people call anonymisation is actually pseudonymisation, which is still personal data.

This article covers the practical side: what legal basis allows personal data to go to an LLM, what the data processing agreement with the AI provider needs to contain, what EU data residency options exist at the three major providers, what a pseudonymisation pipeline looks like in code, where things stand with retention and use for training, how to write a balancing test, and what the AI Act brings. At the end there's a checklist you can go through before starting a project.

One sentence on scope: this article is engineering and process experience, not legal advice; the legal assessment of any specific processing activity is the job of the company's data protection officer or lawyer, and this article supports that work rather than replacing it.

Document processing, a customer service assistant and an internal RAG chatbot are the three most common cases where this question comes up sharply; we covered the technical side of these in AI-based document processing and Building a RAG chatbot. Here comes the legal and protective layer.

What legal basis allows personal data to go to an LLM?

Using an LLM is not a new processing purpose, but a new tool for an existing purpose. The legal basis therefore attaches to the purpose, not the technology. Three typical cases:

Use	Typical legal basis (GDPR Article 6)	Note
Categorising customer emails, drafting replies	Performance of a contract (b) or legitimate interest (f)	Managing the customer relationship is the existing purpose; the LLM is a tool
Extracting data from supplier invoices	Legal obligation (c) + legitimate interest (f)	Accounting obligation; the contact's data is incidental
RAG chatbot over internal documents (including employee data)	Legitimate interest (f) with a balancing test	NAIH practice is stricter for employee data
Marketing segmentation with an LLM	Consent (a) or legitimate interest (f)	Profiling triggers Article 22 and notice obligations
Pre-screening CVs	Legitimate interest (f) + human decision	Article 22's ban on automated decisions means a human decides

What changes with an LLM: a new processor enters the picture (the model provider), possibly a new data transfer takes place (outside the EU), and the privacy notice needs updating, because the data subject has a right to know that their data is processed by an automated tool. The legal basis itself typically doesn't change.

Note: "Legitimate interest" is not a free pass. It requires a written balancing test (below), and if the data subject considers their own interest stronger, they can object. For employee data, NAIH practice does not accept consent as a legal basis because of the power imbalance; there, legitimate interest plus detailed notice is the workable route.

What should the data processing agreement with the AI provider contain?

The LLM provider is a processor under GDPR Article 28 if it receives personal data. You don't write the agreement (DPA) yourself — the provider offers it as part of its business terms; your job is to check that it covers everything and accept it. In 2026, all three major providers (Anthropic, OpenAI, Google) include a DPA in their business API terms.

What to check:

Element	Question	Where to look
Use for training	Is it excluded that your prompts and responses are used for training?	The "Training" or "model improvement" clause in the DPA or API terms
Retention period	How long does the provider retain the prompt? (0-30 days is typical, for abuse monitoring)	"Data retention"
Sub-processors	Who processes data on the provider's behalf (cloud, support), and are you notified of changes?	The "Subprocessors" list
Data transfer	If data goes to the US: EU-US Data Privacy Framework (DPF) certification or Standard Contractual Clauses (SCCs)	"International transfers"
Security measures	Encryption, access control, breach notification deadline	"Security measures", "Breach notification"
Audit rights	Can you request a certification (SOC 2, ISO 27001) or an audit?	"Audit"
Deletion at contract end	What happens to the data if you terminate?	"Deletion"

Important: the terms for consumer (free or individual-subscription) chat interfaces differ from the business API terms. On the consumer interface, use for training may be the default, and there's no DPA. For company use, the API or a business plan is the right choice, and employees need to be told not to paste customer data into their personal accounts.

Retention and use for training: two separate questions

The two points of the DPA are often conflated.

Retention at the provider. The major providers retain prompts and responses submitted via the API for a short period (typically up to 30 days) for abuse monitoring, then delete them; some business plans allow zero-day retention. This period also appears in your own privacy notice as the processor's retention period.

Use for training. In 2026, the business terms of the API exclude submitted data from model training by default. This isn't necessarily true for consumer interfaces; there, a setting or an opt-out is needed. The company rule is simple: customer data only via the API or a business plan where the exclusion is contractual.

Retention on your side. Your own traces (prompt, response, output) also contain personal data if the input did. The observability described in Prompt engineering in an enterprise environment therefore logs pseudonymised or reference-based input, and the trace also has a retention period (30-90 days), which needs to be recorded in your register.

What EU data residency options exist?

Data residency is really two separate questions: where does the processing run (which region's servers), and who has access (a company under which jurisdiction). EU-region processing solves the first; the DPA and the transfer mechanism solve the second.

Provider	EU-region processing in 2026	Note
Google (Gemini)	Vertex AI in EU regions (e.g. europe-west)	The Gemini developer API is not region-bound by default; Vertex is needed
OpenAI (GPT)	Azure OpenAI Service in EU regions; OpenAI's own EU data residency in some plans	The Azure route falls under Microsoft's DPA
Anthropic (Claude)	Via cloud partners (AWS Bedrock, Google Vertex AI) in EU regions; via the direct API per its own terms	With Bedrock, AWS's DPA also applies

The practical decision: if internal policy, the customer contract or the sector (healthcare, finance, public sector) requires processing within the EU, the router should only allow an EU-region path for tasks containing personal data. The router pattern described in Choosing a model: Claude vs GPT vs Gemini handles exactly this with a sensitive flag.

If some processing stays outside the EU (for example, the direct API proves more accurate for a given task), you need a legal basis for the transfer: the provider's certification under the EU-US Data Privacy Framework or Standard Contractual Clauses in the DPA, plus disclosure of the transfer in the privacy notice.

How do you build a pseudonymisation pipeline?

The lowest-risk personal data is the data that never reaches the model at all. Pseudonymisation replaces personal identifiers with substitute tokens before submission, and swaps them back in the response. The model then sees text like "[PERSON_1] is complaining about [ORDER_1]," which is enough for most tasks.

# Pseudonymisation wrapped around the LLM call (Python, simplified)
import re
from dataclasses import dataclass, field

@dataclass
class Vault:
    """Token → original value; discarded after the call, never logged."""
    forward: dict[str, str] = field(default_factory=dict)
    reverse: dict[str, str] = field(default_factory=dict)
    counters: dict[str, int] = field(default_factory=dict)

    def token(self, kind: str, value: str) -> str:
        if value in self.forward:
            return self.forward[value]
        self.counters[kind] = self.counters.get(kind, 0) + 1
        tok = f"[{kind}_{self.counters[kind]}]"
        self.forward[value] = tok
        self.reverse[tok] = value
        return tok

PATTERNS = {
    "EMAIL": re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+"),
    "TEL": re.compile(r"(\+36|06)[ -]?\d{1,2}[ -]?\d{3}[ -]?\d{3,4}"),
    "ADOSZAM": re.compile(r"\b\d{8}-\d-\d{2}\b"),
    "IBAN": re.compile(r"\bHU\d{2}(?: ?\d{4}){6}\b"),
}

def pseudonymize(text: str, vault: Vault, ner) -> str:
    for kind, pat in PATTERNS.items():
        text = pat.sub(lambda m: vault.token(kind, m.group(0)), text)
    # Names: regex won't catch these; use an NER model (e.g. spaCy for Hungarian) or a name list
    for name in ner.person_names(text):
        text = text.replace(name, vault.token("SZEMELY", name))
    return text

def rehydrate(text: str, vault: Vault) -> str:
    for tok, value in vault.reverse.items():
        text = text.replace(tok, value)
    return text

def run_safely(input_text: str, prompt: str, llm, ner) -> str:
    vault = Vault()
    masked = pseudonymize(input_text, vault, ner)
    answer = llm.complete(prompt, masked)          # the model only ever sees tokens
    result = rehydrate(answer, vault)
    del vault                                       # the key never outlives the call
    return result

Three notes on the code:

1. The vault dies with the call. If you persist it (to a log, a database), the pseudonymisation remains reversible on your side, which is fine — but then the vault itself is personal data too, and needs to be protected accordingly.
2. Recognising names is the hard part. Regex catches email addresses, phone numbers and tax IDs; it won't catch "Péter Kovács." You need a Hungarian NER model (spaCy's hu_core_news or similar) or a name list built from your own customer records, and you need to measure coverage: out of 100 real texts, how much personal data was left in.
3. Not every task tolerates this. If the model needs the name for something (for example, addressing the person in the reply), the token gets swapped back in the response — that works. If the task itself is about the person (profiling), pseudonymisation doesn't solve anything; there, the legal basis is the real question.

Tip: GDPR draws a sharp line between anonymisation (irreversible) and pseudonymisation (reversible with a key): anonymous data falls outside the regulation's scope, pseudonymous data does not. The pipeline above pseudonymises, because the vault can reverse it. That's correct — just don't call it anonymisation in your privacy notice.

How do you write a balancing test for LLM use?

If the legal basis is legitimate interest, GDPR (and NAIH practice) expects a written balancing test. The test answers three questions, and it doesn't need to run longer than a page:

Step	Question	LLM-specific angle
1. The interest	What is the controller's legitimate interest? Specific and measurable.	"Answering customer emails within 30 minutes instead of 4 hours" — not "efficiency"
2. Necessity	Can the purpose be achieved with less data or a different tool?	Is pseudonymisation in place? Are only the necessary fields submitted? A smaller model, an EU region?
3. Balancing	The data subject's interests and reasonable expectations; impact; safeguards	A new processor and a possible transfer to a third country; the right to object; human review; notice

The safeguards column is where technical measures (pseudonymisation, EU region, retention period, access log) earn legal weight: every safeguard you put in place reduces the impact on the data subject, and tips the balance in the controller's favour. That's why it pays to do the technical and legal work together, not one after the other.

A Data Protection Impact Assessment (DPIA) is mandatory when processing is likely to result in high risk: large-scale profiling, special category data (health, biometric) or systematic monitoring. For an invoice-extraction pipeline this typically isn't the case; for an LLM system analysing customer behaviour, it is.

What does the AI Act bring, and when?

The EU's AI Act phases in gradually: prohibited practices and the AI literacy obligation from February 2025, rules for general-purpose models from August 2025, most requirements for high-risk systems from August 2026, and certain sector-specific cases by 2027. For an average Hungarian SME, most LLM use (document processing, a customer service assistant, an internal knowledge base) is not high-risk, but three things still apply:

1. AI literacy (Article 4). Staff using the system need an adequate level of understanding: what it can do, what it can't, and when a human needs to decide. A short internal training session and some documentation is enough — but it's required.
2. Transparency (Article 50). If a person interacts with an AI system (a chatbot), they need to know it. For a customer service assistant, this is a single sentence on the interface.
3. Checking for high risk. HR (selection, promotion), credit assessment, educational evaluation, critical infrastructure: if an LLM supports a decision like this, the Annex III obligations (risk management, human oversight, logging, documentation) kick in. CV pre-screening is the typical SME case where this comes up.

The AI Act and GDPR run in parallel: the AI Act regulates the system's risk, GDPR regulates the data. A well-documented GDPR compliance effort (data map, legal basis, safeguards, logs) already covers most of what the AI Act's documentation requires.

Practical checklist before starting an LLM project

Twelve points, in order. If the answer to any point is "no," stop there before going live.

1. Data map: what personal data reaches the model, whose it is, where it comes from, and for what purpose.
2. Data minimisation: fields that aren't needed don't get sent; pseudonymisation wherever the task tolerates it.
3. Legal basis per purpose, in writing; a balancing test where the basis is legitimate interest.
4. A DPA with the AI provider: training exclusion, retention, sub-processors, transfers, deletion.
5. API or business plan only; block consumer accounts for company data, backed by internal policy.
6. Data residency decision: EU region where policy, sector or the customer requires it; a router for sensitive tasks.
7. Legal basis for transfer if some processing stays outside the EU (DPF certification or SCCs).
8. Your own retention: traces pseudonymised, with a retention period and an access log.
9. Update the privacy notice: new processor, automated tool, transfer, retention, right to object.
10. Update the records of processing activities (Article 30) with the new processor and purpose.
11. Assess the need for a DPIA; rule out or address a high-risk AI Act case.
12. Human review and AI literacy: who decides, who checks, who has been trained.

Our own data-handling principles, described on the About page (we work in the client's environment, and we don't retain code or data), are the supplier side of this same list: a development partner is a processor too, and the same questions apply to them.

Frequently asked questions

Can I give customer data to ChatGPT, Claude or Gemini?

Yes, if you use it via the API or a business plan with a data processing agreement that excludes training use, the legal basis for the purpose is in place, and your privacy notice mentions the new processor. Not on a consumer account (a free or individual chat interface): there's no DPA there, and use for training may be the default.

Is it enough to anonymise the data before it reaches the LLM?

If the substitution is reversible (with a key, a vault), that's pseudonymisation, and the data remains personal: GDPR still applies, but the risk and the balancing test improve significantly. True anonymisation (irreversible) takes the data out of GDPR's scope, but it's not possible for most business tasks, because the response needs to be linked back to the person.

Do we need a DPIA for an LLM-based customer service assistant?

Typically not, if the assistant drafts replies that a human sends, there's no profiling, and the data is pseudonymised or minimised before it reaches the model. You do need one if the LLM analyses customer behaviour, makes an automated decision (for example, a discount or a rejection), or processes special category data (health data).

Does the AI Act apply to a Hungarian SME's LLM use?

Yes, but in most cases only the AI literacy and transparency obligations: training staff and disclosing when someone is talking to an AI system. High-risk requirements kick in only if the LLM supports an HR decision, a credit assessment, or a similar decision in an area listed in Annex III.

Closing

The GDPR side of LLM use in 2026 is neither a ban nor a grey area: it's a new processor coming on board, possibly a data transfer, and the paperwork that goes with them — the same paperwork most companies have already been through once when rolling out a cloud CRM or a payroll system. The difference lies in the technical safeguards: pseudonymisation, an EU region, a retention period, access control and logging, all of which tip the legal balancing test in the company's favour too.

The sequence we recommend: a data map and minimisation (one day), a DPA review and a data residency decision (one day), a pseudonymisation pipeline and trace rules (two to three days), legal basis, balancing test and privacy notice with your DPO or lawyer (one week turnaround). That's two weeks in total, running in parallel with the technical build, not after it.

Compared to that, the AI Act brings little that's new for a typical SME: training, transparency, and checking that the system doesn't make HR or credit decisions. If you've documented the GDPR side properly, most of the AI Act documentation is already in place.

Official sources

• GDPR — the text of the regulation (EUR-Lex): Article 6 legal bases, Article 28 processor, Article 30 records, Article 35 DPIA
• NAIH — Hungarian National Authority for Data Protection and Freedom of Information: Hungarian regulatory practice, opinions, balancing-test guidance
• EDPB — European Data Protection Board: guidelines, including the December 2024 opinion on AI models
• AI Act — the text of the regulation (EUR-Lex): Article 4 AI literacy, Article 50 transparency, Annex III high risk
• Anthropic — Privacy Center: API data handling, retention, DPA
• OpenAI — Enterprise privacy: data handling for the API and business plans

Related articles: Mobile app GDPR compliance, AI-based document processing, Claude vs GPT vs Gemini for business use.

If you're starting an LLM project and the question is what can go to the model and under what conditions, book a 30-minute call: we'll go through the data map, the provider's terms and the pseudonymisation options together, and work out with your DPO what's needed for a lawful launch. In our AI automation projects, this is part of discovery, not a fix applied after the fact.