Compliance decisions
ChatGPT
ChatGPT DPIA: a worked employee-use example
A DPIA is required where the proposed personal-data processing is likely to create a high risk under the applicable rules. Assess the specific task and data flow, not ChatGPT in the abstract. This worked example redesigns a raw-ticket proposal before any real customer data is used.
For DPOs, security architects and customer-service owners
A fictional support team chooses generic examples while unresolved risks are addressed.
Synthetic organisation, roles and assessment findings. Proposed safeguards have not been tested; no DPO or supervisory authority approval is claimed.01
Screen the use, not the product name
Article 35 GDPR requires a DPIA before processing likely to result in high risk, taking account of its nature, scope, context and purposes. It identifies particular cases and requires attention to supervisory-authority lists. A new AI tool is a reason to assess risk, not proof that every use automatically needs the same DPIA.
This example concerns an invented support team proposing to paste customer tickets into a managed ChatGPT workspace to improve wording. Tickets can include names, account references and unexpected health details. The example proceeds with a structured assessment; the actual organisation must apply its jurisdiction’s screening criteria and seek its DPO’s advice where designated.
Source context: EU GDPR: Regulation (EU) 2016/679 · ICO: Guidance on AI and data protection
02
Map the complete proposed flow
The original proposal moves text from a ticket system to an employee device, then to a ChatGPT workspace, with a draft copied back into the ticket. Separate uploaded files, saved conversations, copied outputs and any connected systems. Do not infer that the provider’s contractual commitment controls the organisation’s ticket system or employee downloads.
The revised example excludes attachments and connectors, uses generic problem descriptions and requires human checking before a reply is sent. These are proposed scenario controls, not claims that a particular ChatGPT plan or Aona deployment has been configured or tested.
Source context: EU GDPR: Regulation (EU) 2016/679
03
Compare a less intrusive way to meet the purpose
Article 35 calls for necessity and proportionality analysis, not just a list of security features. The purpose here is clearer wording. Alternatives include an approved writing template, invented examples, or a short description that omits the customer’s identity. The full ticket history is not necessary for the generic exercise.
Record the relevant Article 6 basis and transparency obligations for any real personal-data use. If special-category information is involved, assess the additional Article 9 condition. A DPA, training setting or DPIA form does not supply those legal grounds. Keep the named provider’s actual service and contract scope in the evidence pack.
Source context: EU GDPR: Regulation (EU) 2016/679
04
Assess effects on people and residual uncertainty
The risk is not only a leak. An inaccurate rewritten reply may misrepresent a complaint; unnecessary health details may reach another recipient; retained copies may complicate a rights request. Describe the affected person, possible consequence, proposed safeguard and evidence needed to assess its effectiveness.
The populated worksheet uses qualitative findings rather than fabricated probabilities. It records account restrictions, reduced inputs and human review as intended measures, with effectiveness not yet tested. The illustrative decision is to use generic examples rather than start the raw-ticket proposal. Any real high residual risk needs the relevant Article 36 prior-consultation analysis.
Source context: EU GDPR: Regulation (EU) 2016/679
05
Make the DPIA a living decision record
Assign responsibilities to roles that can act: the support owner defines the task, procurement verifies the service terms, security checks the data path and the DPO advises on the privacy assessment. Role names in this example do not represent a real person’s review or approval.
Review the assessment when the data, feature, recipients or risks change. Adding a connector or allowing bulk uploads can alter the original flow substantially. Keep the actual evidence and decision with the DPIA, and use the existing blank template when documenting your organisation’s own case.
Source context: EU GDPR: Regulation (EU) 2016/679
Put it into practice
Worked customer-support DPIA
Fictional assessment of wording assistance for customer replies. This completed teaching record reaches a redesign decision rather than asserting the original raw-ticket use is approved.
Synthetic organisation, roles and assessment findings. Proposed safeguards have not been tested; no DPO or supervisory authority approval is claimed.
Source
Customer ticket system
Keep original records in their controlled source.
Input
Reduced or invented wording context
Exclude identifiers for the teaching exercise.
Output
Human-reviewed draft
No automated reply is enabled by this example.
| Assessment element | Illustrative finding | Owner or follow-up |
|---|---|---|
| Purpose and scope | Improve reply wording; no automated customer decision or sending. | Support owner defines the permitted task. |
| Original data flow | Ticket text → employee device → ChatGPT workspace → draft back to ticket. | Security maps stored copies and recipients. |
| Necessity and alternative | Generic wording examples can meet the initial purpose without raw tickets. | Support owner chooses the reduced-context design. |
| Lawfulness and transparency | Any later real-data use needs its Article 6 basis and relevant Article 9 analysis. | Privacy owner verifies grounds and information for customers. |
| Risk to individuals | Unnecessary identifiers, unexpected health details and misleading drafts could affect customers. | Privacy and support owners assess consequence and scope. |
| Proposed safeguards | No attachments/connectors in the example; generic inputs; human reply review. | Security verifies actual configuration; support tests the review procedure. |
| Residual uncertainty | Service terms, retention and effectiveness are not established for a real deployment. | Procurement and security obtain the missing evidence. |
| Illustrative decision | Do not start raw-ticket processing; begin with invented wording examples. | Reassess real-data scope and any Article 36 implications before a later change. |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
chatgpt-support-dpia-example.mdInspect
# Worked customer-support DPIA
Synthetic organisation, roles and assessment findings. Proposed safeguards have not been tested; no DPO or supervisory authority approval is claimed.
Fictional assessment of wording assistance for customer replies. This completed teaching record reaches a redesign decision rather than asserting the original raw-ticket use is approved.
| Assessment element | Illustrative finding | Owner or follow-up |
| --- | --- | --- |
| Purpose and scope | Improve reply wording; no automated customer decision or sending. | Support owner defines the permitted task. |
| Original data flow | Ticket text → employee device → ChatGPT workspace → draft back to ticket. | Security maps stored copies and recipients. |
| Necessity and alternative | Generic wording examples can meet the initial purpose without raw tickets. | Support owner chooses the reduced-context design. |
| Lawfulness and transparency | Any later real-data use needs its Article 6 basis and relevant Article 9 analysis. | Privacy owner verifies grounds and information for customers. |
| Risk to individuals | Unnecessary identifiers, unexpected health details and misleading drafts could affect customers. | Privacy and support owners assess consequence and scope. |
| Proposed safeguards | No attachments/connectors in the example; generic inputs; human reply review. | Security verifies actual configuration; support tests the review procedure. |
| Residual uncertainty | Service terms, retention and effectiveness are not established for a real deployment. | Procurement and security obtain the missing evidence. |
| Illustrative decision | Do not start raw-ticket processing; begin with invented wording examples. | Reassess real-data scope and any Article 36 implications before a later change. |
## Review steps
- Trace every retained copy: Include the ticket, AI conversation, attachments, generated drafts and exported evidence.
- Test necessity: Explain why a generic description or approved template would not meet the proposed real-data purpose.
- Resolve the remaining risk: Record actual evidence and responsibilities; assess prior consultation where the legal threshold is met.
## Invented safe input
Rewrite this generic support message more clearly: “Please check the delivery instructions and contact our support team if they need updating.” Do not invent a customer, account number or personal circumstance.
## Illustrative disposition
Original proposal: paste raw tickets.
Decision in this teaching example: redesign; use generic wording context only.
Live-data approval: none represented.
Control validation: not run.
Review trigger: any proposal to add identifiable tickets, attachments, connectors or automatic replies.
## Source and scope
Guide: https://aona.ai/resources/guides/chatgpt-dpia-worked-example/
Source check: 21 September 2026. General information; no professional approval or installed-product result is represented.
- EU GDPR: Regulation (EU) 2016/679: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
- ICO: Guidance on AI and data protection: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
chatgpt-support-dpia-example.csvInspect
Assessment element,Illustrative finding,Owner or follow-up
Purpose and scope,Improve reply wording; no automated customer decision or sending.,Support owner defines the permitted task.
Original data flow,Ticket text → employee device → ChatGPT workspace → draft back to ticket.,Security maps stored copies and recipients.
Necessity and alternative,Generic wording examples can meet the initial purpose without raw tickets.,Support owner chooses the reduced-context design.
Lawfulness and transparency,Any later real-data use needs its Article 6 basis and relevant Article 9 analysis.,Privacy owner verifies grounds and information for customers.
Risk to individuals,"Unnecessary identifiers, unexpected health details and misleading drafts could affect customers.",Privacy and support owners assess consequence and scope.
Proposed safeguards,No attachments/connectors in the example; generic inputs; human reply review.,Security verifies actual configuration; support tests the review procedure.
Residual uncertainty,"Service terms, retention and effectiveness are not established for a real deployment.",Procurement and security obtain the missing evidence.
Illustrative decision,Do not start raw-ticket processing; begin with invented wording examples.,Reassess real-data scope and any Article 36 implications before a later change.
Before you proceed
Keep these distinctions clear
- A template is not a conclusion
- The assessment must explain the real flow, necessity, risks and evidence.
- A DPA does a different job
- Processor terms do not replace lawful basis, transparency or the DPIA decision.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate employee-AI visibility and sensitive-input policies for a named supported path.
It does not perform the controller’s DPIA, establish a lawful basis or route privacy approvals automatically.
Use the invented support text and a synthetic over-detailed variant to observe the agreed policy behaviour.
Review your use caseFAQ
Questions for this decision
Does every ChatGPT use require a DPIA?
Can we reuse this completed example as our approval?
Is an Article 28 DPA enough to finish the DPIA?
What changes should trigger review?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- EU GDPR: Regulation (EU) 2016/679
Articles 5, 6, 9, 12, 17, 19, 28, 32, 35 and 36 establish the relevant processing, rights, processor and risk-assessment requirements.
law · checked 2026-09-21 - ICO: Guidance on AI and data protection
UK guidance on risk assessment, accountability and the use of AI with personal information; distinct from the EU GDPR legal text.
regulator · checked 2026-09-21