Does every customer support chatbot need a DPIA?

No. Article 35(1) GDPR requires one only where processing is likely to result in a high risk, and the WP29 criteria help decide that. A template that fills a reply from one field may meet none of them. An assistant that reads emails, joins them with order data and sends them to an outside provider can meet several, so the assessment is worth doing and writing down.

Is a DPIA mandatory for AI features in Austria?

It can be. Section 2 of the DSFA-V (BGBl. II Nr. 278/2018) requires a DPIA where one of six criteria applies, and criterion Z 4 names artificial intelligence. Processing that the DSFA-AV (BGBl. II Nr. 108/2018) exempts does not need one, and customer administration is on that list. Whether the exemption fits the exact processing is a question for counsel, so get a legal view before you rely on it.

What must a DPIA contain?

Article 35(7) GDPR asks for four things: a systematic description of the processing and its purposes, including any legitimate interest; an assessment of necessity and proportionality; an assessment of the risks to data subjects; and the measures planned to address those risks, including safeguards and security.

When do I have to consult the supervisory authority?

Under Article 36, when the DPIA shows that the processing would still be high risk after the measures you have planned. You consult the supervisory authority before the processing starts.

Does the EU AI Act replace the DPIA?

No. The AI Act sets its own duties, such as telling people that they are talking to an AI system, and high-risk rules for listed uses. The GDPR duty to assess the risk to people’s data still applies alongside it.

DPIA for an LLM support assistant

A support assistant that reads customer emails, looks up the order and drafts a reply sounds like a small feature. For data protection it is not small. The email is free text that can contain anything, the order record is personal data, the model runs at a provider, and the output goes back to a customer. This article works through a data protection impact assessment (DPIA) for exactly that feature – for a made-up shop – and ends with the risk table I would put in front of a data protection officer.

My answer up front: do the assessment before the first live reply. The GDPR requires a DPIA only where processing is likely to result in a high risk, but the WP29 guidance recommends one wherever that is unclear. In Austria, check the national lists first. A whitelist can exempt customer administration, while the blacklist names artificial intelligence, so the way you describe the processing decides which list applies.

When a DPIA is required

Article 35(1) GDPR requires a DPIA before processing that is likely to result in a high risk to the rights and freedoms of natural persons, in particular where it uses new technologies. Article 35(3) names three cases where a DPIA is required in particular: a systematic and extensive evaluation of personal aspects based on automated processing, on which decisions are based that significantly affect people; large-scale processing of special categories or criminal data; and systematic monitoring of a publicly accessible area on a large scale. A support assistant fits none of these by itself, so the question becomes the general high-risk test.

The WP29 guidelines WP248 rev.01, adopted on 4 April 2017 and revised on 4 October 2017, turn that test into nine criteria. Where it is not clear whether a DPIA is required, the WP29 recommends carrying one out nonetheless. Four of the nine criteria matter here.

Sensitive data or data of a highly personal nature. The guidelines name personal documents and emails explicitly as data that can fall under this criterion, not only the Article 9 categories.
Matching or combining datasets. Support emails and order records are collected for different purposes. Joining them is the point of the feature, and it can go beyond what customers expect.
Innovative use of new technology. The guidelines say that the use of a new technology can trigger the need for a DPIA, and an LLM feature is new technology for most support teams.
Data processed on a large scale. This depends on the number of people, the volume and range of data, the duration of processing and its geographic extent. A shop with many customers, long retention and national reach may meet several of these factors.

The guidelines say that a processing operation meeting two criteria would in most cases require a DPIA, and that one criterion can sometimes be enough. On my reading, this feature meets at least three of the four, so the assessment is not a close call. The decision flow below shows the order of questions I use.

Read top to bottom. The national lists are checked before the DPIA step, and the reasons are documented whenever no DPIA is carried out, as the guidelines ask.

Austria: the blacklist and the whitelist

Austria makes the question concrete. Under section 2(1) of the DSFA-V (BGBl. II Nr. 278/2018), a DPIA is required where the processing is lawful under Articles 6, 9 and 10 GDPR and no exemption under the DSFA-AV applies. Section 2(2) lists six criteria, and one is enough. Criterion Z 4 covers processing that uses new or novel technologies and names artificial intelligence explicitly.

Section 2(3) adds a second route: two or more of five criteria trigger a DPIA. They cover large-scale special category data, large-scale criminal data, location data, vulnerable people, and the matching of datasets. The assistant could meet the matching criterion as well.

The whitelist is the twist. The DSFA-AV (BGBl. II Nr. 108/2018) exempts the processing listed in its annex from the DPIA duty under Article 35(1) and (5). Its entry DSFA-A01 covers customer administration, accounting, logistics and bookkeeping. In my reading of the German text, it covers personal data processed in any business relationship with customers and suppliers, which describes a shop’s support mailbox well. The exclusion is aimed at businesses whose activity is processing data about third parties who are not their customers. An email that mentions a gift recipient is not obviously within that, but a reviewer may still ask whether the mailbox holds such data, so the reasoning belongs in the record.

So the honest answer for an Austrian shop is this. The whitelist may cover the basic support mailbox. The assistant is more than that mailbox: it adds a technology the blacklist names, and it sends personal data to a provider outside the shop’s own systems. I would not switch the assessment off on the strength of the whitelist. I would record the reasoning for the exemption, put it to counsel or to the Austrian data protection authority, and run the full analysis anyway, because the risks below apply whichever list is right.

The worked example: an assistant for a support inbox

The example shop sells household goods online and receives support emails in one shared inbox. An assistant reads each new email, extracts the order number, calls the order system for the status, items and shipping city, and asks an LLM provider to draft a reply in the customer’s language. A person on the support team edits the draft and sends it. Prompts and drafts are logged for quality review. The provider processes data in the United States. That is an assumption for this example, and you should check your own provider.

Personal data crosses the boundary twice: the prompt goes out and the draft comes back. A person is the last step before a customer sees anything.

Two design choices shape everything else. The model only drafts. It has no tool that sends mail, changes an order or issues a refund. And the prompt carries the order fields the reply needs, not the whole customer record.

Systematic description, necessity and proportionality

Article 35(7)(a) and (b) GDPR ask for a systematic description of the processing and its purposes, and for an assessment of necessity and proportionality. I keep this in the record of processing that Article 30(1) requires, and I write it as structured data rather than prose, so that it can be compared when the feature changes. A minimal entry for the example looks like this:

# one entry per feature: the Article 30 record and the Article 35(7)(a) description
processing: support-email-drafts
purpose: draft a reply to an order enquiry; a person reviews and sends it
legal_basis:
  - Art. 6(1)(b): answering an enquiry about an existing order
prompt_fields:
  - order number, status, items, shipping city
  - email text with card and bank numbers masked
not_in_prompt:
  - full order history, account notes, marketing profile
recipients:
  - LLM provider as processor (Art. 28), documented instructions only
  - transfer to the United States: DPF certification or SCCs (Art. 46)
retention:
  - provider abuse logs: up to 30 days by default (provider documentation)
  - own prompt and draft log: <N> days, set by the data protection officer
review: new provider, new prompt field or any use of emails for training (Art. 35(11))

Three things follow from the entry. First, answering an enquiry about an existing order rests on Article 6(1)(b), which covers processing necessary for a contract or for steps requested before one. Second, keeping drafts to improve quality is a different purpose. It needs a legitimate interest under Article 6(1)(f), and the balancing test is the real work. The EDPB’s Opinion 28/2024 on AI models sets out a three-step test for legitimate interest that I would apply here: identify a lawful, clearly articulated, real and present interest; check that the processing is necessary for it; then balance it against the rights of the people concerned, taking account of what they reasonably expect. Third, the privacy notice must say when data goes to a third country and which safeguard applies, as Article 13(1)(f) requires.

Two special cases need their own line in the description. First, emails can contain health or other special-category data, and an order can reveal it indirectly. The Court of Justice held in case C-184/20 that processing which reveals sensitive information indirectly, through deduction or cross-referencing, falls under Article 9(1). An order for a product that reveals a health condition can be enough, so the prompt should not carry product history beyond the current order. Second, Article 22(1) protects people against decisions based solely on automated processing that significantly affect them. A refund decided by the model would be a candidate. In this design a person reads every reply before it goes out, and the model decides nothing.

Risks to the people who write in

Hallucinated personal data. A model can state a delivery date, a name or an address that is not in the order record. The EDPB’s ChatGPT Taskforce report notes that the purpose of training is not necessarily accurate information, and that end users are likely to take the outputs as factually accurate. The accuracy principle in Article 5(1)(d) still applies. In the example the defence is structural: personal facts in a draft come only from the order record in the prompt, and a person checks the reply before it goes out.

Prompt injection through the email itself. The email body is untrusted input. OWASP describes indirect prompt injection as the case where an LLM accepts input from external sources, such as websites or files. A customer, or someone who forwards a message, can include an instruction to ignore the rules and list other orders from the same city. OWASP’s prevention list includes segregating and identifying external content, enforcing least privilege, and requiring human approval for high-risk actions. Here the model has no access to other customers’ records at all, and the person handling the case sees the email and the draft side by side. For the wider patterns, see my note on prompt injection defence.

Leakage through the output. OWASP’s entry on sensitive information disclosure names personal identifiable information and health records among the data that can leak, and it recommends strict access controls based on least privilege. The worst case is a reply to customer A that contains customer B’s order, which is a personal data breach. Article 32(1)(b) asks for the ongoing confidentiality and integrity of processing systems and services. Article 33 expects notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, as recital 85 explains. Masking before the call is covered in my note on PII redaction in LLM pipelines.

Retention at the provider. As of October 2026, the OpenAI data controls page says that abuse monitoring logs are kept for up to 30 days by default, and that Zero Data Retention needs prior approval from OpenAI. The same page says that, since March 2023, API data is not used for training unless the customer opts in. These are provider defaults that can change, so the contract, not the web page, has to say which applies. Article 28(3)(a) requires a processor to act only on documented instructions, including for transfers, and the EDPB’s Guidelines 07/2020 say a processor must not process data otherwise than on the controller’s instructions. For the wider options, see my note on GDPR and LLM API data residency.

Transfers. The Commission’s adequacy decision 2023/1795 of 10 July 2023 finds that the United States ensures an essentially equivalent level of protection for organisations certified under the EU–US Data Privacy Framework. If the provider is not certified, standard contractual clauses adopted by the Commission under Article 46 are the fallback, as recital 108 describes. The adequacy decision can be suspended, amended or repealed if protection is no longer ensured, so the clauses should be ready before you need them.

Training on customer emails. The EDPB’s Opinion 28/2024 says that whether an AI model trained on personal data is anonymous must be assessed case by case, because personal data can sometimes be extracted from it, directly or through queries. It also says a model developed on unlawfully processed personal data can affect the lawfulness of its later deployment, unless the model is properly anonymised. The feature should therefore not use customer emails for fine-tuning. Any plan to do so is a new purpose that needs its own assessment.

Measures, owners and residual risk

The table lists each risk with my before and after ratings and the measure that changes the rating. Owners are roles rather than names, so the register survives staff changes. The ratings are my judgement for this example, not measured figures.

Risk and basis	Before	Measure and owner	After
Hallucinated personal data in a draft (Art. 5(1)(d))	High likelihood, medium impact	Facts only from the order record in the prompt; a person approves every reply (support lead, ML engineer)	Low
Customer B’s data in customer A’s reply (Art. 32, Art. 33)	Medium likelihood, high impact	Lookup scoped to the verified sender; cross-customer leak test before every release (backend lead)	Low
Instructions hidden in the email (OWASP LLM01)	High likelihood, high impact	No tools that send mail or change orders; email text handled as data; red-team set run before release (security engineer)	Medium, caught at review
Provider logs and retention (Art. 28, Art. 5(1)(e))	Likely by default, medium impact	Processor terms with documented instructions; written retention period; Zero Data Retention only if approved (legal and procurement)	Low to medium
Transfer to a provider outside the EU (Art. 13(1)(f), Art. 46)	Certain, medium impact	Check DPF certification or sign SCCs; transfer statement in the privacy notice (data protection officer)	Low, reviewed when the adequacy decision changes
Special-category inference from order history (Art. 9(1))	Medium likelihood, high impact	Only the current order goes into the prompt; product history that could reveal health is excluded (support lead)	Low
Emails used for training (Art. 6(1)(f), Opinion 28/2024)	Low likelihood, high impact	Contract excludes training on API data; no fine-tuning on emails without a new assessment (product owner)	Low

No row stays high after the measures, so on these assumptions prior consultation under Article 36 is not needed. Two rows keep a residual risk above low: prompt injection and retention at the provider. I would accept and record both, with the data protection officer’s view.

How the EU AI Act fits in

The AI Act does not replace the DPIA, and the two run in parallel. The Regulation applies from 2 August 2026 under Article 113. For a support assistant, the transparency duty I would check first is the one recital 132 describes: people should be notified that they are interacting with an AI system, unless that is obvious to a reasonably well-informed person. For the developer side of those duties, see my Article 50 checklist. Recital 20 also stresses AI literacy for providers, deployers and affected persons, which is a second thing to plan for.

High-risk obligations are a different question. Annex III point 5(b) lists AI systems used to evaluate the creditworthiness of natural persons or to establish a credit score, with an exception for fraud detection. A support assistant is not on that list. Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, moves the application dates of the Annex III high-risk rules to 2 December 2027 and those for Annex I systems to 2 August 2028. Its recital 40 keeps 2 August 2026 as the general date of application. The amendment did not postpone the Article 50 transparency duties: they apply from 2 August 2026.

What I would do first

Write the purpose, the prompt fields and the retention in one record, and send it to the data protection officer before the first pilot.
Put the whitelist reasoning in writing, and get counsel’s view on DSFA-A01 and on third-party data in forwarded emails.
Limit the prompt to the order fields and a masked email, and log only what the quality review needs.
Build a red-team set from real emails, including injected instructions, and make it part of the release check.
Sign processor terms with the provider, and take the retention and training settings from the contract, not from a web page.
Set the review triggers in the record: a new provider, a new prompt field, and any use of emails for training.

DPIA for an LLM support assistant: a worked example under GDPR Art. 35

Key takeaways