Does an LLM chatbot deployed for customer service require a DPIA?

An LLM chatbot that processes customer personal data (name, contact details, account details, service history) at scale typically requires a DPIA under the EDPB signals. The scale threshold varies by supervisory authority; a customer base above a few thousand routinely qualifies. The DPIA covers the data flow through the LLM, the retention of the conversation content, and the downstream use of the AI output.

Can I rely on the model provider's DPIA when I deploy OpenAI or Anthropic in my product?

The controller obligation under Article 24 rests with the operator of the AI system. The model provider (OpenAI, Anthropic) is a processor (or in some deployments, a joint controller) but does not carry the controller's DPIA obligation. The operator has to conduct its own DPIA for the specific processing the operator performs, informed by the model provider's technical documentation.

How does a DPIA differ from the EU AI Act Article 27 FRIA?

The DPIA under GDPR Article 35 covers the risks to the rights and freedoms of natural persons in the context of personal data processing. The FRIA under AI Act Article 27 covers the risks to fundamental rights (broader than data protection) from a high-risk AI system's operation, whether or not personal data is processed. For AI systems that process personal data and qualify as high-risk under the AI Act, the two assessments run as a single combined document.

When does the DPIA have to be updated?

Article 35(11) requires an update when there is a change in the risk represented by the processing. Common triggers include: a change to the AI model version with different capabilities, a change to the deployment scope, a change to the data sources feeding the AI system, a change to the downstream uses of the AI output, or a new incident that surfaces a previously unassessed risk.

Do I need to consult the supervisory authority?

Article 36 requires prior consultation with the supervisory authority when the DPIA indicates the processing would result in a high risk in the absence of measures to mitigate the risk. If the controller's mitigation measures reduce the residual risk to an acceptable level, prior consultation is not required. If the residual risk remains high, the controller consults the supervisory authority before starting the processing.

GDPR AI DPIA: When Article 35 Requires a Data Protection Impact Assessment for an AI System

GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) when processing is likely to result in a high risk to the rights and freedoms of natural persons. The European Data Protection Board Guidelines 3/2019 on the processing of personal data through video devices, together with the earlier Article 29 Working Party Guidelines WP248, set the operational criteria for the "high risk" threshold. Deploying an LLM against personal data reliably clears the threshold. The EDPB's Guidelines 2/2023 on the processing of personal data in the context of the use of AI extend the earlier framework to AI systems specifically.

I want to walk through the mandatory triggers for a DPIA under Article 35, the EDPB signals that apply to AI systems, the process steps under Article 35(7), the coordination with the EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA), and the inspection-layer records that support the ongoing monitoring the DPIA references.

The mandatory DPIA triggers under Article 35(3)

Article 35(3) lists three cases where a DPIA is mandatory:

Systematic and extensive evaluation of personal aspects of natural persons, based on automated processing, including profiling, and on which decisions are based that produce legal effects or similarly significantly affect the natural person. An LLM that scores loan applications or screens job candidates falls under this trigger directly.

Processing on a large scale of special categories of data (Article 9) or of personal data relating to criminal convictions and offences (Article 10). An LLM that processes medical records, biometric identifiers, or racial and ethnic origin data at scale falls under this trigger.

Systematic monitoring of a publicly accessible area on a large scale. A biometric identification AI system operating in a public space falls under this trigger.

The Article 35(4) supervisory authority list adds nine additional cases in most member states. The Irish Data Protection Commission's list adds AI-based fraud detection, AI-based content moderation at scale, and AI-based hiring assessments. The French CNIL's list adds equivalent categories.

The EDPB signals that apply to AI systems

The EDPB Guidelines 2/2023 identify seven signals that indicate a likely high-risk processing when applied to AI systems. Two or more signals present in the same processing operation typically require a DPIA:

Evaluation or scoring of natural persons. An LLM that produces a scoring output on any natural person triggers this signal.

Automated decision-making with legal or similarly significant effect. An LLM output that produces the decision (or the recommended decision that the operator rubber-stamps) triggers this signal.

Systematic monitoring. An LLM that continuously processes personal data from monitoring feeds triggers this signal.

Sensitive data. Any processing of Article 9 categories through an LLM triggers this signal.

Data processed on a large scale. An LLM that processes personal data for more than a small pilot triggers this signal.

Matching or combining datasets. An LLM that combines personal data from multiple sources during inference triggers this signal.

Data concerning vulnerable subjects. An LLM that processes data on children, employees under management observation, or patients triggers this signal.

Innovative use or applying new technological or organisational solutions. The EDPB position treats LLM-based decisioning as an innovative use per se, which lowers the threshold for the other signals to force a DPIA.

The Article 35(7) DPIA process

Article 35(7) specifies the DPIA structure. The assessment has to describe the processing operations and the purposes of the processing. The assessment has to include the necessity and proportionality analysis. The assessment has to include the risk analysis to the rights and freedoms of data subjects. The assessment has to identify the measures the controller envisages to address the risks.

The processing description for an AI system has to name the model, the deployment topology, the data flow from the user through the model to the response, the retention of prompt and response data, and the downstream uses of the AI output.

The necessity analysis has to explain why the AI-based processing is necessary for the purpose. Necessity is not "the AI is faster than the previous process." Necessity is "the AI processing is required to achieve a specific purpose the controller has documented as legitimate."

The proportionality analysis has to explain why the AI-based processing is proportionate to the purpose. Proportionality includes the data minimization analysis: does the AI system process personal data that is not necessary for the purpose?

The risk analysis has to catalog the risks. GDPR-specific risks include: unauthorized re-identification from prompt content, unlawful automated decisions, discriminatory output, breach of data subject rights (Articles 12-22), unauthorized transfers to third countries (Articles 44-49), and unlawful retention.

The risk mitigation measures have to be specific. "The AI system will not process sensitive data" is not a measure; it is a control the assessment has to describe operationally.

The coordination with the EU AI Act Article 27 FRIA

The EU AI Act Article 27 requires a Fundamental Rights Impact Assessment for high-risk AI systems deployed by public bodies and private bodies providing public services. The FRIA and the DPIA overlap in scope for AI systems that process personal data.

The AI Office's implementing guidance (published Q2 2026) sets the integration pattern. The controller conducts a single combined DPIA+FRIA where the two obligations overlap. The combined assessment covers the data protection risks under Article 35 and the fundamental rights risks under Article 27 (including non-discrimination, freedom of expression, and access to public services).

The combined assessment has to name the specific data subjects and affected persons. The GDPR DPIA covers data subjects (natural persons whose personal data the processing addresses). The AI Act FRIA covers affected persons (natural persons the AI system's output affects, whether or not their personal data is processed).

The assessment has to be updated when a substantial change occurs. Under GDPR, "substantial change" includes a change to the purpose, a change to the processing, or a change to the technical or organizational measures. Under the AI Act, a similar trigger applies to the AI system's intended purpose and its operational parameters.

The Article 35(11) ongoing monitoring records

Article 35(11) requires the controller to carry out a review of the DPIA at least when there is a change in the risk represented by the processing operations. Ongoing monitoring produces the evidence the controller relies on for that review.

The monitoring has to cover the actual behavior of the AI system in operation. Static documentation about how the AI system is supposed to behave does not satisfy the ongoing monitoring requirement. The controller has to produce records that show what the AI system actually did over time.

The per-decision audit record produced at the AI gateway satisfies the ongoing monitoring evidence requirement. The record captures each request the AI system processed, the identity of the requester, the prompt content, the AI response, and the policy state that applied. The controller samples the record series periodically to assess whether the actual processing matches the DPIA description.

The record series also feeds the response to data subject requests under Articles 15-22. When a data subject requests access to their personal data under Article 15, the controller queries the record series for entries that reference the data subject and returns the applicable records. When a data subject requests erasure under Article 17, the controller identifies the applicable records and executes the erasure.

DeepInspect

The DeepInspect gateway produces the per-decision audit records the DPIA references for the Article 35(11) ongoing monitoring requirement. The records sit outside the application's control in tamper-evident storage. The record series answers three questions the supervisory authority asks at audit: what personal data has the AI system processed, what decisions has the AI system produced, and did the actual processing match the DPIA description.

The gateway's identity binding maps each request to the requester identity the DPIA identifies as the data subject or the affected person. The gateway's policy engine applies the DPIA's risk mitigation measures at request time and records the applied measure on each event. The records feed the data subject rights response under Articles 15-22.

If your organization is conducting or updating a DPIA for an AI system and needs to align the ongoing monitoring evidence to a specific inspection layer, let's talk today.