Article 35 requires a data protection impact assessment where processing is "likely to result in a high risk" to data subjects. This page is a scaffold with the analysis pre-filled for the AI features of a stock deployment. Complete it before launch, keep it under version control, and revisit it when the processing changes.
Do you need one?
Article 35(3) lists three automatic triggers, and most EU supervisory authorities publish their own mandatory list. For a stock deployment:
| Trigger | Stock deployment |
|---|---|
| Systematic and extensive automated evaluation with legal/significant effects | No — AI output does not decide account access, billing, or eligibility |
| Large-scale special-category processing | Not by design — but users paste whatever they want into prompts |
| Systematic large-scale monitoring of a public area | No |
| National authority list (innovative technology, AI, large-scale data transfers) | Frequently yes |
The honest answer for most operators is yes, on two grounds: several authorities list "innovative technology including AI" explicitly, and free-text prompts sent to third-party processors are a large-scale transfer whose content you do not control.
If you conclude you do not need one, write down why. An undocumented conclusion is indistinguishable from never having considered it.
1. Description of processing
See Records of processing activity 3 for the systematic description. In short: users submit free-text prompts and upload documents; content is transmitted to third-party LLM providers; responses and prompts are stored in the account and surfaced in the data export.
2. Necessity and proportionality
| Question | Assessment |
|---|---|
| Is processing necessary for the purpose? | Yes — the feature is the LLM call |
| Could the purpose be achieved less intrusively? | Partially. Self-hosted models would remove the transfer but change the product. Document the decision. |
| Is data minimised? | Partially. Prompts are user-composed free text; you cannot minimise what you do not compose. Mitigation is guidance and retention, not filtering. |
| Is retention limited? | Prompts persist for account life. Consider a shorter window for chat history — see mitigations. |
| Is the legal basis sound? | Art. 6(1)(b): the user asked for the feature |
3. Risks to data subjects
R1 — Third-party data in prompts (likelihood: high, severity: medium)
A user pastes a customer email, a CV, or a medical note. That third party never consented, may be unaware, and cannot exercise rights against you because you cannot identify their data inside free text.
Mitigations: terms of service section 6 places responsibility on the user; /ai-transparency states plainly that prompts go to providers; provider DPAs must prohibit training on submitted content. Residual risk: medium. This is structural to conversational AI, not a defect you can close.
R2 — Special-category data in prompts (likelihood: medium, severity: high)
Health, biometric, political, or religious data in a prompt is Article 9 processing with no valid Article 9 condition.
Mitigations: contractual prohibition on submitting special-category data; retention limits; no analytics profiling over prompt content. Residual risk: medium. Consider input warnings if your vertical makes this likely (health, HR, legal).
R3 — International transfer (likelihood: certain, severity: medium)
Prompts reach US-based providers.
Mitigations: provider DPAs with SCCs and/or Data Privacy Framework certification; EU processing regions where the provider offers them; disclosure on the transparency page and in the privacy notice. Residual risk: low, assuming the DPAs are actually signed. Verify — do not assume the click-through covers you.
R4 — Inaccurate output relied upon (likelihood: high, severity: varies)
Models produce confident, wrong output, including about identifiable people. Under Article 5(1)(d) personal data must be accurate.
Mitigations: limitations section on /ai-transparency and in the chat disclosure; terms of service disclaim reliance; human review route via the contact page; no automated decisions with legal effect (Art. 22). Residual risk: low, provided you do not later wire AI output into an access or billing decision. If you do, this DPIA needs redoing.
R5 — Prompt content exposed by a breach (likelihood: low, severity: high)
Chat history is more revealing than most account data.
Mitigations: RLS scoped by membership; service-role separation; encryption at rest; the breach runbook. Residual risk: low.
R6 — Provider retains or trains on content (likelihood: low, severity: high)
Mitigations: enterprise/API tiers of the major providers exclude API content from training by default — confirm this for your contract tier, since it differs between consumer and API products. Residual risk: low if verified, high if assumed.
4. Recommended mitigations to implement
| Action | Priority |
|---|---|
| Sign and file a DPA with every configured LLM provider | Required before launch |
| Verify your tier excludes API content from training | Required before launch |
Set a chat-history retention window in cleanup-sessions rather than keeping prompts for account life | Recommended |
| Add an input warning in verticals where special-category data is likely | Situational |
| Re-run this DPIA before wiring AI output into any decision affecting a user | Required if it happens |
5. Outcome
Record the date, the assessor, the residual risk, and the sign-off. If any residual risk remains high after mitigation, Article 36 requires prior consultation with your supervisory authority before processing starts.
| Field | Value |
|---|---|
| Assessment date | (fill in) |
| Assessor | (fill in) |
| DPO consulted (Art. 35(2)) | (fill in, or record that no DPO is appointed) |
| Highest residual risk | Medium (R1, R2) |
| Art. 36 prior consultation required | No, on the stock assessment above |
| Review due | Annually, or on any change to AI processing |